再起動してもテーブル構造が保持されるのはわかった。 じゃ、レコードはどうなの？ レコードなしに戻る？ 実験してみるか・・・。 ※実験結果 クラスターのプロセスを落としても、レコードは保持される。 ただ、落とし方が異常(O…

レコードが一件しかないとインデックスが使われない模様。 当然といえば当然。 MySQLは賢いね。

一般ユーザ権限でmysqldを起動すると、1024以上のファイルを開いた際にエラーになるので注意。 一般ユーザでは起動させないのが無難。 ↑ 嘘かも？ どっちにしろ、対策は my.cnfにopen_files_limit…

インデックスの更新・削除も必要になるから動作が重くなるってのは理解できるが、どの程度重くなる？ 2倍？ 2倍なら使い物にならないよね。 インデックスの数を増やすことによる負荷の伸び方も気になるな。 一次関数的ならいいんだ…

EXPLAIN文を使えば検証できる。これ便利だな。 使い方は のように、SELECT文の前にEXPLAINを記述するだけでOK。

・フィールドが格納している値の種類が少ない(カーディナリティが低い)場合、そのフィールドにインデックスを作成してもあまり効果はない。 マルチカラムインデックスに関する注意 ・インデックスの要素となる列を含む条件式は、「A…

このようなテーブルに対し、 というSQL文を実行すると MySQL が不適切な INDEX(id_a,id_d など) を使用してしまうことがあるらしい。 のように使用する INDEX を指定することで回避できるらしい。

id_aとid_bの複合インデックスと id_aに対する単独インデックスが定義されていた場合、 WHERE句でid_aのみを指定する場合、単独インデックスを適切に使ってくれるのだろうか。 MySQLの不具合の話もあるし、…

みたいなクエリがあった場合、id_bにもインデックス振った方がよさそうな気はするな・・・。 こういう場合はid_aとid_bの複合インデックスになるんだろうか。 単独だと、一つのインデックスしか使えないから、 複合がよさ…

id_aとid_bの複合インデックスを振っていた場合、 id_a、id_bそれぞれに対する単独インデックスは必要？ 複合インデックスだけを振っている状態で みたいな、id_bを指定しない句があった場合、高速化される？ イ…