お金をかけないDBチューニング  @boss_sato
DBサーバが重たい場合の対応• サーバ側 • 台数増やす、スペックアップ• DB側 • レプリケーション 台数増やす • my.cnfチューニング• アプリ側 • SQLチューニング
DBサーバが重たい場合の対応• サーバ側 • 台数増やす、スペックアップ• DB側 • レプリケーション 台数増やす • my.cnfチューニング• アプリ側 • SQLチューニング
DBサーバが重たい場合の対応• サーバ側 • 台数増やす、スペックアップ• DB側 • レプリケーション 台数増やす • my.cnfチューニング コストがかかる!•監視対象が増える! アプリ側 重たいSQLが残ったまま! •SQLチューニング...
DBサーバが重たい場合の対応• サーバ側• 台数増やす、スペックアップ•    今回チューニングするのはこれ    DB側• レプリケーション 台数増やす• my.cnfチューニング• アプリ側• SQLチューニング
my.cnfチューニング
my.cnfの設定方法## 雛形ファイルがあるのでそれをコピーする$ pwd/usr/share/doc/MySQL-server-5.5.28$ ls -1 my-*my-huge.cnfmy-innodb-heavy-4G.cnfmy-la...
my.cnfの雛形ファイルの種類 ファイル名               適したサーバmy-small.cnf   64MB以下のメモリを搭載したサーバmy-medium.cnf 128MB以下のメモリを搭載したサーバmy-large.cnf ...
my.cnfのチューニングmy.cnfのチューニング      メモリ割当の最適化以下の点に留意しながら最適化を行う•サーバーのリソース•サーバー上で稼働しているミドルウェア• key_buffer_size • key_buffer_size =...
my.cnfのチューニング• sort_buffer_size • sort_buffer_size = 2M • ソートを行う場合のバッファサイズ • ORDER ¦ GROUP BYの実行速度があがる• record_buffer_size • ...
my.cnfのチューニング最適なメモリサイズの割り振り  key_buffer_size+(sort_buffer_size + record_buffer_size)  max_connections実メモリサイズ + スワップメモリサイズ※MyS...
SQLチューニング
SQLの解析• slow_queryを設置する## /etc/my.cnfに以下を記述[mysqld]long_query_time=1log-slow-queries=/var/log/slow_query.log## 以下を記述するとインデ...
SQLの解析• mysqlslowdumpコマンドで解析$ mysqldumpslow [option] [log_file]## よく使うオプションは-s(並び替え)-s c → 総クエリ数の多い順-s l → 総ロックタイムの長い順-s r ...
## 文字列 → S、 数字 → N と置換してくれる## Count:総クエリ数 Time=平均実行時間(総実行時間)## Lock=平均ロックタイム(総ロックタイム) Rows=平均行数(総行数)$ mysqldumpslow -s c s...
重たいSQLの傾向• 複数テーブルをまたいだORDER BYSELCT *FROM tbl1INNER JOIN tbl2 ON ...INNER JOIN tbl3 ON ...ORDER BY tbl1.created DESC, tbl2...
重たいSQL対応その1• SQLを分割する(ID取得)SELCT tbl1.idFROM tbl1INNER JOIN tbl2 ON ...INNER JOIN tbl3 On ...ORDER BY tbl1.created DESC, t...
重たいSQL対応その1• SQLを分割する(表示データ取得)SELCT *FROM tbl1INNER JOIN tbl2 ON ...INNER JOIN tbl3 On ...WHERE tbl1.id = 1• 取得したID毎に表示用のS...
重たいSQL対応その2• 無駄なJOIN、ORDER BYを減らすSELCT tbl1.idFROM tbl1INNER JOIN tbl2 ON ...// INNER JOIN tbl3を削除ORDER BY tbl1.created DE...
重たいSQLの対応まとめ• 最低限のレコードを取得するようにする• なるべくJOINの数を減らす• テーブルをまたぐORDER BYはなるべく避け る基本的な事をやるだけでも数sec落とす事は可能※10万件越えたあたりから効果は現れる?
それでもダメなら
おわり
お金をかけないDBチューニング
Upcoming SlideShare
Loading in...5
×

お金をかけないDBチューニング

5,621

Published on

DB(MySQL)の初歩的なチューニングについてのLT。

Published in: Technology

お金をかけないDBチューニング

  1. 1. お金をかけないDBチューニング @boss_sato
  2. 2. DBサーバが重たい場合の対応• サーバ側 • 台数増やす、スペックアップ• DB側 • レプリケーション 台数増やす • my.cnfチューニング• アプリ側 • SQLチューニング
  3. 3. DBサーバが重たい場合の対応• サーバ側 • 台数増やす、スペックアップ• DB側 • レプリケーション 台数増やす • my.cnfチューニング• アプリ側 • SQLチューニング
  4. 4. DBサーバが重たい場合の対応• サーバ側 • 台数増やす、スペックアップ• DB側 • レプリケーション 台数増やす • my.cnfチューニング コストがかかる!•監視対象が増える! アプリ側 重たいSQLが残ったまま! •SQLチューニング ➡運用の手間がかかる  サーバが重たい原因が残ったまま
  5. 5. DBサーバが重たい場合の対応• サーバ側• 台数増やす、スペックアップ• 今回チューニングするのはこれ DB側• レプリケーション 台数増やす• my.cnfチューニング• アプリ側• SQLチューニング
  6. 6. my.cnfチューニング
  7. 7. my.cnfの設定方法## 雛形ファイルがあるのでそれをコピーする$ pwd/usr/share/doc/MySQL-server-5.5.28$ ls -1 my-*my-huge.cnfmy-innodb-heavy-4G.cnfmy-large.cnfmy-medium.cnfmy-small.cnf$ cp my-huge.cnf /etc/my.cnf
  8. 8. my.cnfの雛形ファイルの種類 ファイル名 適したサーバmy-small.cnf 64MB以下のメモリを搭載したサーバmy-medium.cnf 128MB以下のメモリを搭載したサーバmy-large.cnf 512MB以下のメモリを搭載したサーバ 1GB∼2GB以下のメモリを搭載したmy-huge.cnf サーバ my-innodb- 4GBのメモリとInnoDBで作成したDBheavy-4G.cnf で構築したサーバ
  9. 9. my.cnfのチューニングmy.cnfのチューニング メモリ割当の最適化以下の点に留意しながら最適化を行う•サーバーのリソース•サーバー上で稼働しているミドルウェア• key_buffer_size • key_buffer_size = 256M • インデックスを保存するバッファサイズ • メモリの余裕がある場合は多く振る
  10. 10. my.cnfのチューニング• sort_buffer_size • sort_buffer_size = 2M • ソートを行う場合のバッファサイズ • ORDER ¦ GROUP BYの実行速度があがる• record_buffer_size • record_buffer_size = 2M • インデックスを含まないクエリの実行速度 があがる
  11. 11. my.cnfのチューニング最適なメモリサイズの割り振り key_buffer_size+(sort_buffer_size + record_buffer_size) max_connections実メモリサイズ + スワップメモリサイズ※MySQL以外のミドルウェアがある場合は そちらに振るメモリも考慮して割り振る
  12. 12. SQLチューニング
  13. 13. SQLの解析• slow_queryを設置する## /etc/my.cnfに以下を記述[mysqld]long_query_time=1log-slow-queries=/var/log/slow_query.log## 以下を記述するとインデックスを使用しないSQLも拾えるlog-queries-not-using-indexes
  14. 14. SQLの解析• mysqlslowdumpコマンドで解析$ mysqldumpslow [option] [log_file]## よく使うオプションは-s(並び替え)-s c → 総クエリ数の多い順-s l → 総ロックタイムの長い順-s r → 総行数の多い順-s t → 総実行時間の長い順-s a(l ¦ r ¦ c) → 各平均の長い順
  15. 15. ## 文字列 → S、 数字 → N と置換してくれる## Count:総クエリ数 Time=平均実行時間(総実行時間)## Lock=平均ロックタイム(総ロックタイム) Rows=平均行数(総行数)$ mysqldumpslow -s c slow_query.log ¦ lessCount: 49 Time=1.49s (73s) Lock=0.00s (0s) Rows=1.0 (49),user[user]@2hosts SELECT * FROM tbl1 WHERE name = S ORDER BY id LIMIT NCount: 36 Time=1.47s (52s) Lock=0.00s (0s) Rows=1.0 (36),user[user]@2hosts SELECT * FROM tbl2 WHERE id = S AND deleted = S ORDER BY id LIMIT N . . .
  16. 16. 重たいSQLの傾向• 複数テーブルをまたいだORDER BYSELCT *FROM tbl1INNER JOIN tbl2 ON ...INNER JOIN tbl3 ON ...ORDER BY tbl1.created DESC, tbl2.created.DESCLIMIT 0, 20;• ページングでよく使われるSQL• Using temporary; Using filesort がどうして も発生してしまう
  17. 17. 重たいSQL対応その1• SQLを分割する(ID取得)SELCT tbl1.idFROM tbl1INNER JOIN tbl2 ON ...INNER JOIN tbl3 On ...ORDER BY tbl1.created DESC, tbl2.created DESCLIMIT 0, 20;• レコードをIDのみにする• レコードを減らすだけでもクエリ実行時間は 結構減る
  18. 18. 重たいSQL対応その1• SQLを分割する(表示データ取得)SELCT *FROM tbl1INNER JOIN tbl2 ON ...INNER JOIN tbl3 On ...WHERE tbl1.id = 1• 取得したID毎に表示用のSQLを実行する• SQL本数は増えるが、IDをキーに取得してい るので実行時間は0.1secとかで収まる
  19. 19. 重たいSQL対応その2• 無駄なJOIN、ORDER BYを減らすSELCT tbl1.idFROM tbl1INNER JOIN tbl2 ON ...// INNER JOIN tbl3を削除ORDER BY tbl1.created DESCLIMIT 0, 20;• JOIN先のテーブルの件数次第では、JOINを減 らすだけでXsec下げれたりする• ORDER BYも同様• ある程度の不整合に目をつぶるかも。。
  20. 20. 重たいSQLの対応まとめ• 最低限のレコードを取得するようにする• なるべくJOINの数を減らす• テーブルをまたぐORDER BYはなるべく避け る基本的な事をやるだけでも数sec落とす事は可能※10万件越えたあたりから効果は現れる?
  21. 21. それでもダメなら
  22. 22. おわり
  1. A particular slide catching your eye?

    Clipping is a handy way to collect important slides you want to go back to later.

×