InnoDB vs MyISAM (vs Falcon) を読んで興味深いと思った点

• InnoDB vs MyISAM vs Falcon benchmarks - part 1

を読んだ。興味深かった。

だけだとナンなので、思ったことをメモってみる。

がんばれFalcon

まだ生まれたてなのでベンチマークの結果は参考程度に。

InnoDB vs MyISAM

The second goal of benchmark was a popular myth that MyISAM is faster than InnoDB in reads, as InnoDB is transactional, supports Foreign Key and has an operational overhead. As you will see it is not always true.

の通り、どちかというと(Falconより)InnoDBとMyISAMの性能比較の方が興味深い点が多かった。

READ_PK_POINT

このエントリの環境で、ピークで45000qps。
16 Threadsのqpsがよくて、これ以上の平行度だと徐々にqpsは悪くなる。
→無闇にmax_connectionsを増やしてもパフォーマンスはスケールしない。

READ_KEY_POINT

MyISAMは128 Threadsでガクンとqpsが落ちる。preadが問題ぽいといっている。InnoDBはガクンとは落ちない。
Falconはトリッキーらしいｗ

READ_KEY_POINT_LIMIT

4 ThreadsだとMyISAMよりInnoDBの方がはるかにqpsが高いが、Threadsが増えるに従いInnoDBのqpsは低下いていく。一方、MyISAMは低下せず一定。

READ_KEY_POINT_NO_DATA

これもInnoDBの勝ち。
つか、
複合インデックス（KEY (col1, col2)とか）で、WHERE句でcol1を使ってSELECT col2 FROMすると、col2のためのreadは発生しないらしい。なんでかというと、WHEREの処理で(複合)インデックスをreadして、それをつかってcol2の値を返せるので、col2のためにまたreadする必要がないから。
って知らんかったよ。

READ_KEY_POINT_NO_DATA_LIMIT

これもInnoDBの勝ち。
でも、Threadsが増えると徐々にInnoDBとMyISAMのqpsの差は縮まる。

READ_PK_POINT_INDEX

WHERE句で主キーでひっかけて、主キーの値だけを返す。もっとも効率的にインデックスを活用するクエリ。
MyISAMとInnoDBの差がほとんどないのは、もっとも効率的なケースだとあまり差が出ないということぽい。

READ_PK_RANGE

InnoDB圧勝。
これもpreadの問題かもと書いてある。

READ_PK_RANGE_INDEX

MyISAMのqpsが落ちない。
これは、インデックスにアクセスするだけなら（性能低下の原因となる）preadが発生しないから、だそうな。

READ_KEY_RANGE

これもThreadsが増えるとMyISAMはがっくり落ちる。

READ_KEY_RANGE_LIMIT

でも、LIMITがつくとMyISAMはInnoDBといい勝負。

READ_FTS

フルテーブルスキャン。
Threadsが小さいときはInnoDBの方がいいけど、128 Threadsで逆転してMyISAMのほうがよくなる。