CubicLouve

Spring_MTの技術ブログ

MySQL 5.6から導入されたoptimizer_traceを使ってみる

きっかけは下のブログ

rkmathi.hatenablog.com

実際に使われるindexはSQLオプティマイザがコスト計算した結果で変わると思われる。

http://dbstudy.info/files/20120310/mysql_costcalc.pdf

コスト計算の結果は、MySQL 5.6から導入されたoptimizer_traceを使えば分かります。(多分)

MySQL :: MySQL 5.6 リファレンスマニュアル :: 21.11 INFORMATION_SCHEMA OPTIMIZER_TRACE テーブル

optimizer_traceはset optimizer_trace='enabled=on';でonにできる。

mysql>  show variables like 'optimizer_trace';
+-----------------+--------------------------+
| Variable_name   | Value                    |
+-----------------+--------------------------+
| optimizer_trace | enabled=off,one_line=off |
+-----------------+--------------------------+
1 row in set (0.00 sec)

mysql> set optimizer_trace='enabled=on';
Query OK, 0 rows affected (0.00 sec)

mysql>  show variables like 'optimizer_trace';
+-----------------+-------------------------+
| Variable_name   | Value                   |
+-----------------+-------------------------+
| optimizer_trace | enabled=on,one_line=off |
+-----------------+-------------------------+
1 row in set (0.01 sec)

optimizer_traceの結果はSELECT * FROM information_schema.OPTIMIZER_TRACE; で取得できる。

上記ブログのテーブルを少し行数を減らしてEXPLAINした時の、optimizer_traceの結果を比べてみた。

Using index conditionとなる場合

gist03a9f09fb154cf24442a

table_scanのコストが101258。

idx_datetimeを使ったコストが100671。

Using whereとなる場合

gistaa3e50cbf1a9563aa95f

table_scanのコストが101258。

idx_datetimeを使ったコストが109235。

table_scanのコストの方が低くなっているのがわかる。