MySQL のパフォーマンスの話  ソースコードを通じて学ぶ MySQL のチューニングポイント Tetsuro IKEDA @ 2009/08/28
自己紹介 <ul><li>住商情報システム株式会社 勤務 </li><ul><li>MySQLのお仕事(構築、サポート、講師)
http://www.scs.co.jp/mysql </li></ul><li>Tritonn (トリトン) 開発 </li><ul><li>MyISAMに全文検索エンジンSennaを組込み
http://qwik.jp/tritonn </li></ul><li>groonga(ぐるんが)ストレージエンジン開発 </li><ul><li>全文検索用ストレージエンジン </li></ul></ul>
今日のお題 <ul>ソースコードを読むことを通じて パフォーマンスチューニングのための 正確な情報を手に入れよう 今回は MySQL 5.1.37 を使用しています </ul>
ソースディレクトリの構造 <ul><li>サーバはsqlディレクトリ
クライアントはclientディレクトリ
ストレージエンジンは独自のディレクトリ
それ以外はユーティリティ/依存ライブラリ </li></ul>
SQL処理の流れ <ul><li>ネットワーク受信
プロトコル処理
SQLパーサー
オプティマイザ
実行制御と結果送信
ストレージエンジン
※gdbでbacktraceを取れば1発で分かる </li></ul>
<ul>パラメータ設定(ユーザ視点) </ul><ul><li>my.cnfに書いておく
mysqldの起動引数として指定する
SET文で変更する
SHOW VARIAZLES文で確認する </li></ul>
パラメータ設定(プログラム視点) <ul><li>mysqld.cc のmy_long_options配列で定義
5.1以上のpluggable storage engineは別枠
グローバル変数とセッション変数がある
各パラメータ用のGlobal変数
Globalなglobal_system_variables変数
Class THDのvariables変数
Upcoming SlideShare
Loading in …5
×

MySQLのパフォーマンスの話

10,088 views

Published on

ソースコードを通じて学ぶ
MySQLのチューニングポイント

Published in: Technology
1 Comment
6 Likes
Statistics
Notes
  • 大変参考になりました。こちらに転載しても宜しいでしょうか? http://www.hotdocs.jp/
       Reply 
    Are you sure you want to  Yes  No
    Your message goes here
No Downloads
Views
Total views
10,088
On SlideShare
0
From Embeds
0
Number of Embeds
1,173
Actions
Shares
0
Downloads
39
Comments
1
Likes
6
Embeds 0
No embeds

No notes for slide

MySQLのパフォーマンスの話

  1. 1. MySQL のパフォーマンスの話  ソースコードを通じて学ぶ MySQL のチューニングポイント Tetsuro IKEDA @ 2009/08/28
  2. 2. 自己紹介 <ul><li>住商情報システム株式会社 勤務 </li><ul><li>MySQLのお仕事(構築、サポート、講師)
  3. 3. http://www.scs.co.jp/mysql </li></ul><li>Tritonn (トリトン) 開発 </li><ul><li>MyISAMに全文検索エンジンSennaを組込み
  4. 4. http://qwik.jp/tritonn </li></ul><li>groonga(ぐるんが)ストレージエンジン開発 </li><ul><li>全文検索用ストレージエンジン </li></ul></ul>
  5. 5. 今日のお題 <ul>ソースコードを読むことを通じて パフォーマンスチューニングのための 正確な情報を手に入れよう 今回は MySQL 5.1.37 を使用しています </ul>
  6. 6. ソースディレクトリの構造 <ul><li>サーバはsqlディレクトリ
  7. 7. クライアントはclientディレクトリ
  8. 8. ストレージエンジンは独自のディレクトリ
  9. 9. それ以外はユーティリティ/依存ライブラリ </li></ul>
  10. 10. SQL処理の流れ <ul><li>ネットワーク受信
  11. 11. プロトコル処理
  12. 12. SQLパーサー
  13. 13. オプティマイザ
  14. 14. 実行制御と結果送信
  15. 15. ストレージエンジン
  16. 16. ※gdbでbacktraceを取れば1発で分かる </li></ul>
  17. 17. <ul>パラメータ設定(ユーザ視点) </ul><ul><li>my.cnfに書いておく
  18. 18. mysqldの起動引数として指定する
  19. 19. SET文で変更する
  20. 20. SHOW VARIAZLES文で確認する </li></ul>
  21. 21. パラメータ設定(プログラム視点) <ul><li>mysqld.cc のmy_long_options配列で定義
  22. 22. 5.1以上のpluggable storage engineは別枠
  23. 23. グローバル変数とセッション変数がある
  24. 24. 各パラメータ用のGlobal変数
  25. 25. Globalなglobal_system_variables変数
  26. 26. Class THDのvariables変数
  27. 27. ※emacs+cscopeで簡単に調査可能 </li></ul>
  28. 28. ステータス変数(ユーザ視点) <ul><li>MySQLサーバが提供してくれる統計情報
  29. 29. SHOW STATUS文で確認できる
  30. 30. SQL文を実行すると増えたりする
  31. 31. グローバル変数とセッション変数がある </li></ul>
  32. 32. ステータス変数(プログラム視点) <ul><li>特定のコードを実行(通過)すると増加する
  33. 33. sql_class.hのsystem_status_var構造体で定義
  34. 34. Globalなglobal_system_variables変数
  35. 35. Class THDのstatus_var変数
  36. 36. ※emacs+cscopeで簡単に調査可能 </li></ul>
  37. 37. 一休み:本の宣伝 <ul><li>共著で書きました
  38. 38. 1年くらい前に発売
  39. 39. 中上級者向け
  40. 40. ソースの話もあり </li></ul>
  41. 41. ソース解析デモ(サーバ変数) <ul><li>tmp_table_size と max_heap_table_size はどう違うの?
  42. 42. max_connections を越える接続ができるって本当? </li></ul>
  43. 43. tmp_table_size max_heap_table_size <ul><li>create_tmp_table関数内でのみ参照
  44. 44. sql_select.cc:10173行目
  45. 45. CREATE TABLE … MAX_ROWS=# と同じ
  46. 46. 一時テーブルでは値の小さい方が採用される </li></ul>if (thd->variables.tmp_table_size == ~ (ulonglong) 0) // No limit share->max_rows= ~(ha_rows) 0; else share->max_rows= (ha_rows) (((share->db_type() == heap_hton) ? min(thd->variables.tmp_table_size, thd->variables.max_heap_table_size) : thd->variables.tmp_table_size) / share->reclength);
  47. 47. max_connections <ul><li>check_user関数
  48. 48. sql_connect.cc:406行目
  49. 49. connection_cound(既存の接続数)がmax_connections以下の場合のみOK
  50. 50. ただしSUPER_ACL保有者は例外
  51. 51. つまり特権ユーザは”Too many connections”でも接続できる </li></ul>bool count_ok= connection_count <= max_connections || (thd->main_security_ctx.master_access & SUPER_ACL);
  52. 52. ソース解析デモ(ステータス変数) <ul><li>Com_select って何ですか
  53. 53. Handler_XXX が異常に増加します
  54. 54. -> ストレージエンジンて何やってるんですか? </li></ul>
  55. 55. Com_select <ul><li>mysql_execute_command関数内
  56. 56. sql_parse.cc:2137行目
  57. 57. lexはSQLパーサー解析結果
  58. 58. THD->status_varの該当変数がインクリメント </li></ul><ul>status_var_increment(       thd->status_var.com_stat[lex->sql_command]) </ul>
  59. 59. Handler_XXX <ul><li>各ストレージエンジンのHandler実装関数
  60. 60. 例:ha_myisam.cc:1750行目
  61. 61. 関数が呼ばれるとインクリメント </li></ul><ul>int ha_myisam::rnd_next(uchar *buf) { ha_statistic_increment(&SSV::ha_read_rnd_next_count); int error=mi_scan(file, buf); table->status=error ? STATUS_NOT_FOUND: 0; return error; } </ul>
  62. 62. SELECT(テーブルスキャン)の流れ <ul><li>handler::rnd_init -> OK
  63. 63. handler::rnd_next -> OK
  64. 64. handler::rnd_next -> OK
  65. 65. handler::rnd_next -> OK
  66. 66.
  67. 67. handler::rnd_next -> EOF </li></ul>
  68. 68. SELECT ... LIMITの流れ <ul><li>handler::rnd_init -> OK
  69. 69. handler::rnd_next -> OK
  70. 70. handler::rnd_next -> OK
  71. 71. LIMIT条件を満たしたところで終了 </li></ul>
  72. 72. SELECT … ORDER Byの流れ (text/blob型使用時) <ul><li>handler::rnd_init -> OK
  73. 73. handler::rnd_next -> OK
  74. 74. handler::position -> row_idを受け取っておく
  75. 75.
  76. 76. handler::rnd_next -> EOF
  77. 77. sort_bufferを使ったquick sort処理
  78. 78. handler::rnd_pos -> OK
  79. 79. handler::rnd_pos -> OK </li></ul>
  80. 80. UPDATEの流れ <ul><li>handler::rnd_init
  81. 81. handler::rnd_next -> はずれ
  82. 82. handler::rnd_next -> あたり
  83. 83. handler::update -> 更新
  84. 84. handler::rnd_next -> はずれ
  85. 85. handler::rnd_next -> あたり
  86. 86. handler::update -> 更新
  87. 87. handler::rnd_next -> EOF </li></ul>
  88. 88. 性能改善のためのアプローチ <ul><li>そもそも負荷が掛からないようにする
  89. 89. 高性能なサーバを用意する
  90. 90. サーバをたくさん用意する
  91. 91. スキーマチューニングをする
  92. 92. パラメータチューニングをする
  93. 93. MySQLを改造して抜本的な高速化を試みる </li></ul>
  94. 94. Tritonnのしていること <ul><li>MySQLのFulltext Parserは日本語対応していない&フレーズ検索が遅い </li><ul><li>Fulltext ParserはDELIMITEDのみ対応
  95. 95. レコード単位転置インデックス </li></ul><li>Senna全文検索エンジン </li><ul><li>N-gramまたは日本語辞書にも対応
  96. 96. 完全転置インデックス </li></ul><li>全文検索機能をごっそりSennaに置き換える </li></ul>
  97. 97. 転置インデックスの仕組みの違い レコード単位転置 インデックス 完全転置 インデックス インデックスされる情報 単語IDとレコードIDのペアのみ保持 単語IDとレコードIDに加えて、レコード内の出現位置も保持 インデックスサイズ 小さい 大きい 検索性能 フレーズ検索で低速化 フレーズ検索も高速
  98. 98. Tritonnの問題点 <ul><li>MyISAMに依存 </li><ul><li>MyISAMの欠点をそのまま受け継いでいる
  99. 99. 参照/更新時のテーブルロック
  100. 100. あまりインテリジェントなエンジンではない </li></ul><li>Sennaの限界 </li><ul><li>インデックスサイズに比例して更新コストがO(n)で増大する </li></ul><li>メンテナンスが割と大変 </li><ul><li>改造部分がMySQL本体と密結合 </li></ul></ul>
  101. 101. groonga ストレージエンジン ( 開発中 ) <ul><li>全文検索を主目的としたストレージエンジン
  102. 102. MySQL 5.1で搭載されたPluggable Storage Engine Interfaceを利用、疎結合
  103. 103. カラム単位ストレージ
  104. 104. Fulltext、Hash、Patricia treeの3種類のインデックスをサポート
  105. 105. インテリジェントな高速化機能 </li><ul><li>Column pruning、cond_push、limit、order by </li></ul></ul>
  106. 106. おしまい <ul><li>ご清聴ありがとうございました
  107. 107. 質問はありますか?
  108. 108. @ikdttr にご連絡下さい(via Twitter) </li></ul>

×