【メモ】 MySQLのInnoDBストレージエンジンについてよくわかっていなかったのでメモ

gistfile1.txt

■発端。
1,000万件程度のランダムな数字文字列データをMySQLにINSERTする作業を実施。
Insertする前にSortすると、データのIOが40％程度削減できた。
理由はSortされていればPageをメモリ上にロードする回数が少なくて済むため、との事だったが
理解が浅かったので勉強。
以下InnoDBの話。

■参考
MySQL　InnoDBストレージエンジンのチューニング（前編）
InnoDBのアーキテクチャおさらい
http://enterprisezine.jp/dbonline/detail/3820?p=2

MySQL　InnoDBストレージエンジンのチューニング（後編）
http://enterprisezine.jp/dbonline/detail/3829

MySQLでインデックスを使って高速化するならCovering Indexが使えそう
http://blog.livedoor.jp/sasata299/archives/51336006.html

[前提知識]

・InnoDBではテーブルスペースは16KBのページ上に作成されていて、B+Treeはこのページ上に作成される
・InnoDBではレコードデータはクラスタインデックスをのリーフに保持されている
・InnoDBでは全ての変更はバッファプール(InsertBuffer)上で行われ、後からテーブルスペースへ書き込まれる

つまり、データを追加すべきページがDBキャッシュに読み込まれていなければそのページの読み込みが発生する
Insertされるデータが、PKで未Sortの場合、Insertする対象のページが読み込まれている可能性が低くなり、
都度ページを読み込む必要が出てくるためSortしてある場合と比較してIOが増える

以上！
==========================================================================================
【余談】
■InnoDB テーブルのデフラグメント化
ftp://ftp.ntu.edu.tw/MySQL/doc/refman/4.1/ja/innodb-file-defragmenting.html

上記の前提があるため、Insertするデータがクラスタインデックスのページに入らない場合、ページの分割が行われる
結果、それはページの未使用領域ができる=断片化している状態になり、ディスク容量的にも速度的にも非効率


■最強のMySQL HA化手法 - Semi-Synchronous Replication
http://nippondanji.blogspot.jp/2009/03/mysql-ha-semi-synchronous-replication.html