データベースで重要な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で実際し使用されているか確認しておく。



以下のSQLアンチパターンはおすすめ。

悪例を提示して解説してある。

あー、これこれ、あるある!みたいなwwwww

問題なく動いているから、というSQLの書き方をしていると、レコードが増えると重くなったりしない?

あとのことを考えていないのね。

また、予想した結果がSELECTされているからOK!と判断したりしてない?

様々なレコードが増えてきた場合、予期しない結果を返してこない?

SQLアンチパターン
SQLアンチパターン
posted with amazlet at 14.06.29
Bill Karwin
オライリージャパン
売り上げランキング: 7,908


SQL中で型の変換を「意識せずに」してしまい、あれ?index使用してない?とかwww
[PR] au WALLETカードの情報 - auのプリペイドカードでショッピングをおトクに!