MySQLのTips
http://forge.mysql.com/wiki/Top10SQLPerformanceTipsというのがあったので、和訳してみる。
(11/23 追記)id:pekeqさんとsodaさんのコメントを受け一部更新
(4/27 追記と修正)id:hirose31さんの指摘を受け修正。あと元のサイトが構成変更していたので追従
クエリのパフォーマンスに関するTips(データベースのデザインとインデックスについても)
- EXPLAINを使ってクエリの実行プロファイルを取れ
- スロークエリログを使え(常に有効にしておけ!)
- GROUP BYを使っているか使えるなら、DISTINCTを使うな
- Insertのパフォーマンス
- バッチ処理によるINSERTとREPLACE
- INSERTの代りにLOAD DATAを使う
- LIMIT m,nは案外速くない
- 2000件以上のレコードに対してORDER BY RAND()を使ってはいけない
- 頻繁に更新するデータに対してや大きな結果を取得するときにはSQL_NO_CACHEを付けろ *1
- LIKEクエリの先頭にワイルドカードを使わないこと*2
- 相関副問い合わせ、WHERE句の中のIN SELECTを避けること(出来ればIN自体使わない)
- 比較時に演算されないようにする、インデックスされたカラムはそのまま使う(関数などを適用しない)
- ORDER BYとLIMITは等式とインデックスがあるときに有効に働く
- textやblobをメタデータから分離する。 必要でもないのにtextやblobを結果に入れないこと。
- FROM句のサブクエリで生成した抽出テーブルはBLOBをソートしないで取得するときに便利。(IDなどで検索してから残りを取得するようなケースで自己結合を使うと高速化できます)
- 時系列でソートされているデータに対してはALTER TABLE ... ORDER BY という文を使うと、特定のフィールドで並べ直すことができる。このフィールドに対するクエリは高速化されます。
- どんなときに複雑なクエリを分解したり、単純なクエリをまとめるかを知ること
- こまごまと余計なデータを掃除すること
- キャッシュが有効となるように似たクエリには完全に同一の物を発行すること
- SQLの標準に準拠しましょう
- 古くて廃止予定の機能は使わないこと
- 5.0未満では複数のインデックスがあるときのORをUNION結合にすることで速くなる(LIMIT句があるとき)、5.0以降はindex_mergeが処理する。 *3
- InnoDBにおいて毎回 COUNT *は使ってはいけない。使うとしたらすこしだけにしておくかサマリテーブルに対してにしておくべき。全ての行数を数えること必要なら、SQL_CALC_FOUND_ROWSとSELECT FOUND_ROWS()を使うべし
- 事前にSELECTになくていいようにINSERT .. ON DUPLICATE KEYによる更新を使う
- サブクエリの代りにGROUP BYのmaxを使う
スケーリングに関するTips
ネットワークのパフォーマンスに関するTips
- 欲しいデータだけ取得してトラフィックを最小に
- ページングやチャンキングで情報取得に制限をつける
- SELECT *を使うな
- 長いクエリをもっと効率的にできるなら、大量の小さくて短時間で終わるクエリを注意すること
- ラウンドトリップの時間を減らせるようなら multi_queryを使う
OSのパフォーマンスに関するTips
MySQLサーバ全般についてのTips
- innodb_flush_commit=0にしておくとスレーブとのずれがなくなる
- データ型を最適化し、一貫したデータ型を使うこと。 PROCEDURE ANALYSE()を使うと必要最低限のデータ型を判断するときの手助けになる。
- ペシミスティックロックではオプティミスティックロックを使う。出来れば排他ロックではなく、共有ロックを使う。FOR UPDATEとLOCK IN SHARED MODE。
- 出来るならtextやblobは圧縮すること
- 静的なデータは圧縮する
- 静的なデータを頻繁にバックアップしない
- 効くようならクエリキャッシュを有効にしてバッファキャッシュを増やす
- 設定パラメータについて。http://docs.cellblue.nl/2007/03/17/easy-mysql-performance-tweaks/ がいいリファレンスです。
- 設定変数とtips
- 標準添付の設定のひとつを使う
- key_buffer、UNIXキャッシュ、コネクション毎の変数、innodbのメモリ周りの変数
- システム全体でのメモリとコネクション毎のメモリについて注意する
- SHOW STATUSとSHOW VARIABLES(5.0以上の場合GLOBALとSESSION毎)でチェックする
- スワップに気をつけること、特にLinuxで(OSのファイルキャッシュをバイパスするにはinnodb_flush_method=O_DIRECTを付ける、但しOS依存)
- テーブルのデフラグ、インデックスの再構築、テーブルのメンテ
- innodb_flush_log_at_trx_commit=1を使うなら、バッテリバックアップされたキャッシュコントローラを使うこと
- たくさんのRAMは速いディスクよりも幸せ
- 64-bitアーキテクチャ使う
- --skip-name-resolve *5
- 大きなINSERT用に myisam_sort_buffer_sizeを増やすこと(これはコネクション毎の変数)
- INSERT時のキャッシュのメモリチューニングパラメータについて見ておくこと
- データウェアハウス環境ではtempテーブルのサイズを大きくすること(デフォルトは32Mb)。ちなみに、テーブルはディスクに書き込まれない。(あとデフォルトが16Mbのmax_heap_table_sizeにも制約される)
- SQL_MODE=STRICTで実行すると詳細な警告が得られる
- /tmpはバッテリバックアップされたライトバックキャッシュのある場所に置く
- innodbのログファイルをバッテリバックアップされたRAMディスク上に置くことを検討する
- クライアントでは--safe-updatesを使う*6
- 冗長なデータは冗長
ストレージエンジンについてのTips
- InnoDBは常に主キーをインデックスの一部として保持する、そのため主キーが大きくなりすぎないようにすること。
- マスタとスレーブで異なるストレージエンジンを使うとよい。たとえば全文検索インデックスとか
- ログなどの用途でBLACKHOLEエンジンとレプリケーションの組み合わせはFEDERATEDテーブルよりも速い。
- 今使っているストレージエンジン、どれが用途最適か、その他のエンジンがあることを知るべし
- 例えばログ用にMERGEテーブルとARCHIVEテーブル
- 古いデータの保管。やたらと溜めこむべからず。これらの用途にはARCHIVEテーブルとMERGEテーブル
- OLTP用途にはテーブルレベルロックではなく行レベルロックを使うこと
- スキーマやストレージエンジンはテスト環境で試してから選ぶ
データベースデザインとパフォーマンスのTips
- まっとうなクエリスキーマをデザインすること。テーブルの結合を怖がることはない、大抵非正規化よりも速い
- booleanフラグは使うべからず
- インデックスを使う
- かといって全部にインデックスを張らない
- 重複したインデックスを張らない
- SELECTとINSERTの比が小さいときは大きなカラムに対してインデックスを作らないこと
- インデックスに冗長なカラムが含まれていないかを注意する
- まずは正規化、その後で必要なところを非正規化
- MAX()の代りによく考えられたキーとORDER BYを使う
- データベースは表計算ソフトじゃない、Accessは非常に似てるけどな。 んで、Accessは本当のデータベースじゃない。
- IPアドレスにはINET_ATONとINET_NTOAを使え。charやvarcharにするべからず
- ドメインの検索が楽になるから、メールアドレスはREVERSE()で逆にすることを習慣にする
- NULLデータ型はNOT NULLよりも大きな容量を格納できる
- 適切な文字コードを選択すること。 UTF16はどんな文字だろうと個々の文字を2バイトで格納する。Latin1はUTF8より速い。
- 上手くトリガを使おう
- min_rowsとmax_rowsを使うと正確な容量が見積もることができる。これによって予め確保すべき容量や基準となる点が計算できます。
- 同じようなプレフィックスを持つデータに対してHASHインデックスを使う
- intデータに対してmyisam_pack_keysを使う
- 動いているコードに触ることなくスキーマを変更できるようにしておくこと
- テーブルとデータベースは分離しておくこと、これによって異なる設定変数の恩恵に被かれる。
その他
*1:query cacheが汚れるからだと思われる
*2:%で始まるLIKE条件にはインデックスが使われないため
*3:5.0未満では1クエリニ対して1インデックスしか使われないため複数の条件がORで結合されているときには、条件毎にクエリを実行しその結果をUNION結合(つまりORで集める)するという最適化をやってくれる。5.0からはindex_mergeという機能が入ったため、こちらが使われる。
*4:InnoDBではトランザクションログと実データが分離されている。前者は通常コミットのタイミングでディスクへ同期書き込みされるので、どの瞬間に取ったLVMのスナップショットであってもトランザクションログから一貫性の保たれた状態へロールフォワード出来るということ
*5:名前索きの抑止
*6:誤操作防止のため、where句なしでのupdateを出来なくしてくれる