私も
日付型を文字型 にするのではなく、固定値側を 文字型を日付型 に
変換して比較する方が
よい、という意見には同意ですが、
DB項目を変換する場合は、DBのレコード数=変換数ですが、固定値を変換すれば1回で済む。
については
「問題はそこではない」
という意見です。
DBサーバの能力やレコードの件数にもよりますが、システム全体の実行時間に比べると、その理由による性能の差など、微々たるものに過ぎないと考えるからです。
もっと重要な問題は、MySQLの場合、
「カラムに何らかの関数や演算を適用すると、そのカラムに張られたインデックスを使用できない」
ということです(※)。
どういうことかというと、例えTestDatabase.registdate
にインデックスが張られていたとしても、
sql
1DATE_FORMAT(TestDatabase.registdate, '%Y-%m') = '2016-07'
という式ではそのインデックスを使用できない、ということです。
一方、
sql
1TestDatabase.registdate >= '2016-07-01' AND TestDatabase.registdate < '2016-08-01'
や
sql
1TestDatabase.registdate BETWEEN '2016-07-01 00:00:00' AND '2016-07-31 23:59:59.999'
といった式では、そのインデックスを使用できます。
現在、このカラムにインデックスが張られていないとしても、将来、インデックスが必要になる可能性を考慮して、今のうちから後者のような形式にしておくほうが無難だと、私は考えます。
※信用できる根拠が見つからず、ご提示できないのが恐縮ですが、例えば以下のような場合、MySQLはインデックスを使用できません。
sql
1# カラムに演算を適用している
2SELECT * FROM tbl_name WHERE key_col + 1 = 0;
3
4# カラムに(MIN、MAX以外の)関数を適用している
5SELECT * FROM tbl_name WHERE DATE_FORMAT(key_col, '%Y-%m') = '2016-07'
6
7# LIKE値がワイルドカード文字で始まっている
8SELECT * FROM tbl_name WHERE key_col LIKE '%Patrick%';
3番目のSQLに関してのみ、根拠として以下を見つけることができました。
http://dev.mysql.com/doc/refman/5.6/ja/index-btree-hash.html
バッドをするには、ログインかつ
こちらの条件を満たす必要があります。
退会済みユーザー
2016/08/10 02:38
退会済みユーザー
2016/08/10 02:38