1

だから私はこのクエリを持っています:

EXPLAIN SELECT SQL_CALC_FOUND_ROWS
    u.userid,
    u.firstname,
    u.lastname,
    u.job_title,
    u.email,
    u.org_id
FROM piltools.users u
WHERE
    u.org_id = 'VX3'
    AND (
        u.firstname LIKE 'Chris%'
        OR u.lastname LIKE 'Chris%'
        OR CONCAT(u.firstname, ' ', u.lastname) LIKE 'Chris%'
        OR u.email LIKE 'Chris%'
    )
    AND u.firstname !=''
    AND u.lastname !=''
    AND u.deleted = '0'

各列には個別にインデックスがあり、特にこのクエリ用に deleted,org_id,lastname,firstname,job_title,email,userid の CUSTOM インデックスを作成しましたが、explain を実行すると、次のように表示されます。

ID 1

select_type SIMPLE

テーブルU

タイプ参照

possible_keys電子メール、名、姓、org_id、削除済み、CUSTOM

キーorg_id

key_len 17

参照定数

行113967

追加の where の使用

必要なすべてのフィールドを持つ CUSTOM インデックスではなく、個々の org_id インデックスを使用しているのはなぜですか?

4

1 に答える 1

1

オプティマイザーは、「可能なインデックス」ごとにクエリを処理するのに必要な時間を評価しようとし、実際には、実行が最も速いと思われるインデックスを使用します。

ここで、愛情を込めてカスタム作成されたインデックスを使用しないことにした理由は、データのプロファイルを知らずに確実に伝えることはできませんが、

  • インデックスは、宣言に出現する順序で列をフィルター処理するためにのみ使用できます。インデックスを使用するにはCUSTOM、最初にレコードをフィルター処理する必要がありますdeleted(良い、これはWHERE句の一部です)、次にorg_id(これもフィルターの一部です)、次にlastnameなどです。

  • テーブル内のほとんどのレコードはおそらく条件WHERE deleted = 0に一致するため、最初にこのフィールドでフィルタリングする利点は「低い」と見なされます

  • でフィルタリングするメリットはorg_id、CUSTOMインデックスorg_idのみを使用するメリットと同じです。

  • lastname !=''（おそらく）ほとんどのレコードがこの条件を満たしているため、条件でフィルタリングする利点は「低い」と見なされます

  • 条件でフィルタリングする利点は、演算子lastname LIKE 'Chris%'のオペランドであるため、大幅に軽減されますOR

  • 上記と同じfirstname LIKE 'Chris%'

  • 残りのインデックス付き列はフィルタリングに使用されません

  • CUSTOMほとんどの場合、文字列列が含まれているため、インデックスは巨大です。オプティマイザーは、このインデックスをロードするコストが、考えられる利点と比較して高すぎると想定する場合があります。

FORCE INDEX句を追加することで、オプティマイザーにインデックスを使用するように誘導できます(キーワードが示唆するように強制しないでください)。

しかし、オプティマイザーは通常、よりよく知っています。使用しないことを選択した場合、私はこの決定を信頼します. のみ、この順序(org_id, deleted)、またはおそらく(org_id, deleted, lastname, firstname).

于 2013-06-19T22:47:02.123 に答える