0

OR Handler_read_next=999 を実行m_idxする(k1,k2,k3)
場合のインデックスがあります
SELECT c1,c2,c3... FROM tb FORCE INDEX (m_idx) WHERE k1=500 AND k2 IN(...) AND k2>2000 ORDER BY k1 LIMIT 1000;

SELECT c1,c2,c3... FROM tb FORCE INDEX (m_idx) WHERE k1 IN (500,1000,1500 ...) AND k2 IN(...) AND k2>2000 ORDER BY k1 LIMIT 1000;

しかし、k1で範囲を使用しようとすると、
SELECT c1,c2,c3... FROM tb FORCE INDEX (m_idx) WHERE k1>=500 AND k2 IN(...) AND k2>2000 ORDER BY k1 LIMIT 1000;
Handler_read_next = 58035
すべての場合でEXPLAINは、使用されるキーはであると言いm_idx
ますが、3番目のケースm_idxでは使用されていないと思います（k1にのみインデックスがあります）。
そうでなければ、なぜそれが1000行以上を読んでいるのか理解できません。インデックスと、テーブルから読み取られる条件を満たす行
をスキャンすることを期待していました。 しかし実際には、3番目のケースではインデックスをスキャンし、k1条件を満たす行がtbから読み取られ、行がtbから読み取られた後にk2とk3の条件がチェックされると思います。 私が使用するもの：MySql with MyISAM、WINDOWS 7 64、tbには100万行あります。 だから私の質問は： 左端のマルチインデックスの範囲で選択することは可能ですか？m_idxONLY the first 1000




または
私は何か他のことをしているのですか？
ありがとうございました。

4

1 に答える 1

0
  1. いいえそうではありません。
  2. いいえ、あなたはすべて正しくやっています

http://dev.mysql.com/doc/refman/5.1/en/range-optimization.html (「7.3.1.3.2. マルチパート インデックスの範囲アクセス方法」部分)

したがって、オプティマイザーがこのクエリをより高速に実行するのを助けることはできません。

FORCE INDEXオプティマイザは使用するインデックスをよりよく知っているため、 の使用は避けてください。

また：

k1>=500 AND k2 IN(...) AND k2>2000

どちらの部分がより少ないレコードを返すかに応じて、k1>=500または（に追加する前に手動で比較できるため、k2 IN(...) AND k2>2000なぜここで必要なのかわかりません）、インデックスを作成することもできます（一部が返すレコードの量が少ない場合） ）。> 2000IN()k2k2

于 2010-12-03T01:58:11.933 に答える