MySQLは私にidの主キーを持っている連絡先のテーブルを持っている句は、インデックス

Question

を使用しないでと選択します。それはまた、二次インデックスidx_id_del_user（ID、削除、USER_ID）を有しています。

次のクエリは、インデックスを使用し、したがって、非常に高速である - 私は句で使用するとき0.0098s

に取り込ま

select id 
from jts_contacts 
where id = '00000402-25c8-7375-e3df-4ec5b66de11d' 
and deleted = 0; 

1行は、しかし外側のクエリがフルテーブルスキャンに入ります。私はそれが主キーまたはidx_id_del_userのいずれかを使用することを期待しています。ナイン

でフェッチ

select * 
from jts_contacts FORCE INDEX (idx_id_del_user) 
where id in 
(select id 
from jts_contacts 
where id = '00000402-25c8-7375-e3df-4ec5b66de11d') 
and deleted = 0 

1行は計画を説明 -

id, select_type,   table,   type, possible_keys,     key, key_len, ref, rows, Extra 
------------------------------------------------------------------------------------ 
1, 'PRIMARY',   'jts_contacts', 'ALL', '',       '', '',  '', 1127275, 'Using where' 
2, 'DEPENDENT SUBQUERY', 'jts_contacts', 'const', 'PRIMARY,idx_id_del_user', 'PRIMARY', '108', 'const', 1, 'Using index' 

このテーブルには、120万件のレコードを持っているし、テーブルを分析しました。 FORCE INDEXオプションなしで試しましたが、まだインデックスを使用していません。このクエリをより速くするための提案はありますか？

---

警告：結合の代わりに、句の使用は、これは既存の製品から生成されたクエリであるがために、動作します - 参加するには、使用するように変更することはできません。私が言うことができるものから、

Answer 1

、INは、一度に一致するすべてのレコードを通過し、句の値にそれらを比較して、1行。

したがって、deletedにインデックスを使用すると、レコードはdeleted = 0にしかなりません。

Answer 2

私はちょうど同じ問題を抱えていました。そして、Marcus Adamsの記事を読んだ後、私は同じテーブルのデータに基づいてテーブルに対してUPDATEを実行することによって学んだことを考えました：まず、このようなテーブルは：

SELECT * FROM jts_contacts WHERE id IN 
(SELECT id FROM 
    (SELECT id FROM jts_contacts WHERE id = '00000402-25c8-7375-e3df-4ec5b66de11d') 
temp) 
AND deleted = 0 

これは最初の派生tempテーブルに内側のクエリから完全な結果をフェッチして、それに基づいて外側のクエリを実行します。

このパターンは、秒未満に分からの私の類似したクエリの速度を増加させました。私はあなたがいない。