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

6,403 views
6,244 views

Published on

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

Published in: Technology
0 Comments
21 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
6,403
On SlideShare
0
From Embeds
0
Number of Embeds
2,274
Actions
Shares
0
Downloads
35
Comments
0
Likes
21
Embeds 0
No embeds

No notes for slide

お金をかけない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. おわり

×