【感想】MySQLのパフォーマンスに関する記事を読んで

以下の記事を読んで自分なりに解釈＆所感。

Yakst - MySQLの大きなテーブルでのパフォーマンスを改善する10の方法

1.MyISAMではなくInnoDBを使う。
　→MySQLのチューニングとしてはまぁ普通の考え。
　　「古い時代のアーキテクチャ」とか「ファイルシステムに毛が生えたようなもの」って聞いたし。
　　が、当然ながら新規構築なら設計時に大前提で考慮することなので、後からチューニングとかって類の考えではない。

2.InnoDBは、ユニークでないセカンダリインデックスを・・・
　→つまり5.5以降+InnoDBにバージョンアップしろと。
　　新しいバージョンにするというアプローチはパフォーマンス改善の考え方としてはありだけど、
　　チューニングとは言えないかも。
　　アプリ変更・テストが必要なケースなどが多々あるので優先度は高くできない。

3.パーティショニングは・・・MySQL5.7.2で・・・
　→これは知らなかった。ていうかまだリリースされていないし。
　　新機能を使うというアプローチもチューニングとは言い難いけど。
　　でも、「パーティション化する」は立派なチューニング。

4.InnoDBの圧縮機能を使う
　→圧縮はread/write性能が悪くならないかちょっと心配だけど5.6でかなり良くなったとのウワサ。
　　Oracleなども圧縮機能はある。
　　データ縮小によるフルスキャン性能UP ＞ read/write性能down と判断できるなら検討の余地あり。

5.ソートしたデータをバルクロード
　→ロード方法を変えて時間を短縮するアプローチもよくやるね。

6.不要なインデックスを消す
　→地味に必要。なかなか運用中手をつけにくいけど。
　　インデックスが多いと更新性能が落ちるので。

7.プライマリキーの種類（データ型）変更
　→データ型とデータ長もread性能に響くので、テーブル設計時の重要な要素。

8.新しいテーブルにバルクロードする場合は、PRIMARY KEY以外のインデックスは後で作る。
→大事。
　 データの一意性が保証されているものをロードするなら、PrimaryKeyですらロード後に作る。
　 ロード処理をバッチに入れていたりするなら、チューニング（調整）になるが、
　 どちらかというとお作法（常識）な気がする。

9.メモリを増やせば (ry
　→当然ね。
　　InnoDB＆Readメインならとにかくバッファにどれだけ載せられるかが勝負なので。

10.メモリと同じく、SSDも役に立つ。
　→これも。今だとioDriveが選択肢か。

・・・とまぁ、人の書いたもので感想述べただけですが、
設計・運用でパフォーマンスに影響する要素のまとめとして、勉強になりました。