5

私はクエリの最適化に慣れていないので、まだすべてを理解しているわけではありませんが、この単純なクエリでさえ期待どおりに最適化されない理由がわかりません。

私のテーブル:

+------------------+-----------+------+-----+-------------------+----------------+
| Field            | Type      | Null | Key | Default           | Extra          |
+------------------+-----------+------+-----+-------------------+----------------+
| tasktransitionid | int(11)   | NO   | PRI | NULL              | auto_increment |
| taskid           | int(11)   | NO   | MUL | NULL              |                |
| transitiondate   | timestamp | NO   | MUL | CURRENT_TIMESTAMP |                |
+------------------+-----------+------+-----+-------------------+----------------+

私のインデックス:

+-----------------+------------+-------------------+--------------+------------------+-----------+-------------+----------+--------+------+------------+---------+---------------+
| Table           | Non_unique | Key_name          | Seq_in_index | Column_name      | Collation | Cardinality | Sub_part | Packed | Null | Index_type | Comment | Index_comment |
+-----------------+------------+-------------------+--------------+------------------+-----------+-------------+----------+--------+------+------------+---------+---------------+
| tasktransitions |          0 | PRIMARY           |            1 | tasktransitionid | A         |         952 |     NULL | NULL   |      | BTREE      |         |               |
| tasktransitions |          1 | transitiondate_ix |            1 | transitiondate   | A         |         952 |     NULL | NULL   |      | BTREE      |         |               |
+-----------------+------------+-------------------+--------------+------------------+-----------+-------------+----------+--------+------+------------+---------+---------------+

私のクエリ:

SELECT taskid FROM tasktransitions WHERE transitiondate>'2013-09-31 00:00:00';

これを与える：

+----+-------------+-----------------+------+-------------------+------+---------+------+------+-------------+
| id | select_type | table           | type | possible_keys     | key  | key_len | ref  | rows | Extra       |
+----+-------------+-----------------+------+-------------------+------+---------+------+------+-------------+
|  1 | SIMPLE      | tasktransitions | ALL  | transitiondate_ix | NULL | NULL    | NULL | 1082 | Using where |
+----+-------------+-----------------+------+-------------------+------+---------+------+------+-------------+

すべてを正しく理解している場合、すべての行がストレージ エンジンから取得され、サーバー レイヤーでフィルター処理されることUsing whereを意味します。ALLこれは準最適です。インデックスの使用を拒否し、ストレージ エンジン (innoDB) から要求された範囲のみを取得するのはなぜですか?

乾杯

4

4 に答える 4

0

私は MySQL 8.0 の初心者で、2 つの簡単なチュートリアルを完全に終了しました。「2つの回答」というラベルの付いたセクションを読んだところ、そのセクションの最後に提案されているステートメントを使用すると、元の目的USE INDEXまたはFORCE INDEX以下のステートメントが無効になるように思われることがわかりました。WHERE推奨されるステートメントは、MySQL の代わりにUSE INDEXorを使用してステートメントを介してテーブルをソートするようなものFORCE INDEXです。USE INDEX動作しますが、自然なorを使用するのと同じではないように思えFORCE INDEXます。Lname 列で 10 行のテーブルにインデックスを付けるという単純な要求を MySQL が無視する理由を知っている人はいますか?

分野 タイプ ヌル 鍵 デフォルト 追加
ID 整数 いいえ PRI ヌル 自動増加
名前 varchar(20) いいえ MUL ヌル
Fname varchar(20) いいえ ムル ヌル
街 varchar(15) いいえ ヌル
生年月日 日にち いいえ ヌル 
CREATE INDEX idx_Lname ON TestTable (Lname);
SELECT * FROM TestTable USE INDEX (idx_Lname);
SELECT * From Testtable FORCE INDEX (idx_LastFirst);
于 2021-04-01T13:54:39.423 に答える