0


0

結合時にインデックスを使用する

以下のクエリにEXPLAINを使用すると、

SELECT cha.cid AS cid,
       cha.data AS dl
FROM cha, c_users
WHERE uid = 808
AND cha.cid = c_users.cid;
  1. 「cha」テーブルでフルスキャンを実行します

  2. c_users`からのマルチカラムインデックス( cid`、 uid)を使用します。

なぜ `cha`の主キーインデックスを使用せず、全テーブルスキャンを使用しないのですか。 クエリ/テーブルを最適化するより良い方法はありますか。

編集:cha.cidは私の主キーです。 以下のコメントの後に追加。

4 Answer


1


通常のBTREE、および(cid、uid)のインデックスでは、cidを指定せず、uidのみを検索する場合、スキャンが必要になります。 (uid、cid)のインデックス(順序に注意してください)が役立つ/できます。

これは、使用されることを保証するものではありません。MySQLは、特定のインデックス/結合が使用されるインデックスの特定の大部分を必要とする可能性が高い場合、フルスキャンがより高速(連続読み取り)であると推測できます。 。 スキャンと比較してキーを使用する方が実際に速いかどうかは、「FORCE INDEX」で確認できます(テストする前にテストサーバーでクエリキャッシュを無効にします)。


0


uid列のインデックスを作成します。

パフォーマンスについて質問するとき、EXPLAINおよびCREATE TABLEステートメントの出力により、ヘルパーがより簡単になります。 次回追加してください。


0


`cha`にはこのクエリで使用できるhttp://en.wikipedia.org/wiki/Index_(database)#Covering_Index[covering index]がないため、データページにアクセスしてデータの一部を取得する必要がありますニーズ。 テーブルの統計に基づいて、オプティマイザは、最初にインデックスをスキャンしてからデータページにジャンプするIO時間は、テーブルをスキャンするよりも悪いと判断しました。


-1


しないだろう…​

SELECT cha.cid AS cid,
       cha.data AS dl
    FROM cha INNER JOIN c_users ON cha.cid = c_users.cid
    WHERE uid = 808;

もっと慣用的になりますか?

(knittlのコメントを考慮して編集)。