データベースで重要なindexであるが、全てのfieldにindexを定義するのは、多くの場合は無駄である。
定義しても、それが使用されなければ意味がない。
indexを定義することは、fieldのコピーを作ることに近く、更新性能の低下を招く。
全てのfieldにindexを追加すれば、テーブルが2つあるのと同じだ。
書込が発生すると、両方に書き込まねばならない(更新も同様)。
indexが役立つか分からないのに、全てのfieldに対してindexを設定するのは無駄。
読取がメインの場合は、ないよりはマシだろうが…
indexを設定しても全く使わないだろうfieldは、それほど考えなくても分かるはずだ。
よく見るのが、主キーには既にindexがあるのに、それとは別にindexを定義しているパターン。
冗長で無駄である。
なお、SQLによっては、indexが役に立たない(使われない)場合もある。
姓名の姓が●は、紙の電話帳で探せる。
紙の電話帳には、姓の順で並んでいるからだ。
しかし、名が●の場合は、これが使えない。
全ての姓に対して、名が●である可能性があるからだ。
複合indexを姓(sei),名(mei)の順で設定しても、名でのSELECT時には役に立たない。
同様に、名を第一基準にするORDER BY時にも役に立たない。
SELECT * FROM `user` ORDER BY `mei`,`sei` ;
また、LIKEで’%●’と前に%を入れた場合(後方一致)も、全てに一致する可能性があるのでindexが役立たない。
‘%●%’と挟んだ中間一致も同様。
演算しての比較なども、indexは役に立たない。
WHERE `price` * 1.08 > 1000 ;
のような場合。
indexにあるデータは`price`であって`price` * 1.08ではないからだ。
これは、両辺を1.08で割って
WHERE `price` > 1000/1.08 ;
とすると、indexが使用できるようになる。
否定形(<>)や、IS NULL、ORも、indexが利用できない。
但し、ORはINで書き換えると、indexを使用できるようになる。
EXPLAINで、設定したindexがpossible_keysに含まれており、keyで実際し使用されているか確認しておく。
翔泳社
売り上げランキング: 10,850
以下のSQLアンチパターンはおすすめ。
悪例を提示して解説してある。
あー、これこれ、あるある!みたいなwwwww
問題なく動いているから、というSQLの書き方をしていると、レコードが増えると重くなったりしない?
あとのことを考えていないのね。
また、予想した結果がSELECTされているからOK!と判断したりしてない?
様々なレコードが増えてきた場合、予期しない結果を返してこない?
オライリージャパン
売り上げランキング: 7,908
SQL中で型の変換を「意識せずに」してしまい、あれ?index使用してない?とかwww