• Share
  • Email
  • Embed
  • Like
  • Save
  • Private Content
MySQLのパフォーマンスの話
 

MySQLのパフォーマンスの話

on

  • 12,281 views

ソースコードを通じて学ぶ

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

Statistics

Views

Total Views
12,281
Views on SlideShare
11,151
Embed Views
1,130

Actions

Likes
5
Downloads
36
Comments
1

12 Embeds 1,130

http://d.hatena.ne.jp 738
http://webmemo.uzuralife.com 280
http://www.slideshare.net 53
http://okyuu.com 24
http://74.125.153.132 14
http://webcache.googleusercontent.com 14
http://garagekidztweetz.hatenablog.com 2
http://www.freerss.net 1
http://rss.ameba.jp 1
http://hatenatunnel.appspot.com 1
http://localhost 1
http://static.slidesharecdn.com 1
More...

Accessibility

Categories

Upload Details

Uploaded via as OpenOffice

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel

11 of 1 previous next

  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
  • 大変参考になりました。こちらに転載しても宜しいでしょうか? http://www.hotdocs.jp/
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

    MySQLのパフォーマンスの話 MySQLのパフォーマンスの話 Presentation Transcript

    • MySQL のパフォーマンスの話  ソースコードを通じて学ぶ MySQL のチューニングポイント Tetsuro IKEDA @ 2009/08/28
    • 自己紹介
      • 住商情報システム株式会社 勤務
        • MySQLのお仕事(構築、サポート、講師)
        • http://www.scs.co.jp/mysql
      • Tritonn (トリトン) 開発
        • MyISAMに全文検索エンジンSennaを組込み
        • http://qwik.jp/tritonn
      • groonga(ぐるんが)ストレージエンジン開発
        • 全文検索用ストレージエンジン
    • 今日のお題
        ソースコードを読むことを通じて パフォーマンスチューニングのための 正確な情報を手に入れよう 今回は MySQL 5.1.37 を使用しています
    • ソースディレクトリの構造
      • サーバはsqlディレクトリ
      • クライアントはclientディレクトリ
      • ストレージエンジンは独自のディレクトリ
      • それ以外はユーティリティ/依存ライブラリ
    • SQL処理の流れ
      • ネットワーク受信
      • プロトコル処理
      • SQLパーサー
      • オプティマイザ
      • 実行制御と結果送信
      • ストレージエンジン
      • ※gdbでbacktraceを取れば1発で分かる
      • パラメータ設定(ユーザ視点)
      • my.cnfに書いておく
      • mysqldの起動引数として指定する
      • SET文で変更する
      • SHOW VARIAZLES文で確認する
    • パラメータ設定(プログラム視点)
      • mysqld.cc のmy_long_options配列で定義
      • 5.1以上のpluggable storage engineは別枠
      • グローバル変数とセッション変数がある
      • 各パラメータ用のGlobal変数
      • Globalなglobal_system_variables変数
      • Class THDのvariables変数
      • ※emacs+cscopeで簡単に調査可能
    • ステータス変数(ユーザ視点)
      • MySQLサーバが提供してくれる統計情報
      • SHOW STATUS文で確認できる
      • SQL文を実行すると増えたりする
      • グローバル変数とセッション変数がある
    • ステータス変数(プログラム視点)
      • 特定のコードを実行(通過)すると増加する
      • sql_class.hのsystem_status_var構造体で定義
      • Globalなglobal_system_variables変数
      • Class THDのstatus_var変数
      • ※emacs+cscopeで簡単に調査可能
    • 一休み:本の宣伝
      • 共著で書きました
      • 1年くらい前に発売
      • 中上級者向け
      • ソースの話もあり
    • ソース解析デモ(サーバ変数)
      • tmp_table_size と max_heap_table_size はどう違うの?
      • max_connections を越える接続ができるって本当?
    • tmp_table_size max_heap_table_size
      • create_tmp_table関数内でのみ参照
      • sql_select.cc:10173行目
      • CREATE TABLE … MAX_ROWS=# と同じ
      • 一時テーブルでは値の小さい方が採用される
      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);
    • max_connections
      • check_user関数
      • sql_connect.cc:406行目
      • connection_cound(既存の接続数)がmax_connections以下の場合のみOK
      • ただしSUPER_ACL保有者は例外
      • つまり特権ユーザは”Too many connections”でも接続できる
      bool count_ok= connection_count <= max_connections || (thd->main_security_ctx.master_access & SUPER_ACL);
    • ソース解析デモ(ステータス変数)
      • Com_select って何ですか
      • Handler_XXX が異常に増加します
      • -> ストレージエンジンて何やってるんですか?
    • Com_select
      • mysql_execute_command関数内
      • sql_parse.cc:2137行目
      • lexはSQLパーサー解析結果
      • THD->status_varの該当変数がインクリメント
        status_var_increment(       thd->status_var.com_stat[lex->sql_command])
    • Handler_XXX
      • 各ストレージエンジンのHandler実装関数
      • 例:ha_myisam.cc:1750行目
      • 関数が呼ばれるとインクリメント
        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; }
    • SELECT(テーブルスキャン)の流れ
      • handler::rnd_init -> OK
      • handler::rnd_next -> OK
      • handler::rnd_next -> OK
      • handler::rnd_next -> OK
      • handler::rnd_next -> EOF
    • SELECT ... LIMITの流れ
      • handler::rnd_init -> OK
      • handler::rnd_next -> OK
      • handler::rnd_next -> OK
      • LIMIT条件を満たしたところで終了
    • SELECT … ORDER Byの流れ (text/blob型使用時)
      • handler::rnd_init -> OK
      • handler::rnd_next -> OK
      • handler::position -> row_idを受け取っておく
      • handler::rnd_next -> EOF
      • sort_bufferを使ったquick sort処理
      • handler::rnd_pos -> OK
      • handler::rnd_pos -> OK
    • UPDATEの流れ
      • handler::rnd_init
      • handler::rnd_next -> はずれ
      • handler::rnd_next -> あたり
      • handler::update -> 更新
      • handler::rnd_next -> はずれ
      • handler::rnd_next -> あたり
      • handler::update -> 更新
      • handler::rnd_next -> EOF
    • 性能改善のためのアプローチ
      • そもそも負荷が掛からないようにする
      • 高性能なサーバを用意する
      • サーバをたくさん用意する
      • スキーマチューニングをする
      • パラメータチューニングをする
      • MySQLを改造して抜本的な高速化を試みる
    • Tritonnのしていること
      • MySQLのFulltext Parserは日本語対応していない&フレーズ検索が遅い
        • Fulltext ParserはDELIMITEDのみ対応
        • レコード単位転置インデックス
      • Senna全文検索エンジン
        • N-gramまたは日本語辞書にも対応
        • 完全転置インデックス
      • 全文検索機能をごっそりSennaに置き換える
    • 転置インデックスの仕組みの違い レコード単位転置 インデックス 完全転置 インデックス インデックスされる情報 単語IDとレコードIDのペアのみ保持 単語IDとレコードIDに加えて、レコード内の出現位置も保持 インデックスサイズ 小さい 大きい 検索性能 フレーズ検索で低速化 フレーズ検索も高速
    • Tritonnの問題点
      • MyISAMに依存
        • MyISAMの欠点をそのまま受け継いでいる
        • 参照/更新時のテーブルロック
        • あまりインテリジェントなエンジンではない
      • Sennaの限界
        • インデックスサイズに比例して更新コストがO(n)で増大する
      • メンテナンスが割と大変
        • 改造部分がMySQL本体と密結合
    • groonga ストレージエンジン ( 開発中 )
      • 全文検索を主目的としたストレージエンジン
      • MySQL 5.1で搭載されたPluggable Storage Engine Interfaceを利用、疎結合
      • カラム単位ストレージ
      • Fulltext、Hash、Patricia treeの3種類のインデックスをサポート
      • インテリジェントな高速化機能
        • Column pruning、cond_push、limit、order by
    • おしまい
      • ご清聴ありがとうございました
      • 質問はありますか?
      • @ikdttr にご連絡下さい(via Twitter)