2

この左結合のインデックス作成に問題があります:

SELECT comments.id, comments.topid, comments.username, comments.body, comments.dt, comments.active, users.email
FROM comments
LEFT JOIN registered_users.users
ON comments.username = users.username
WHERE postid = 12 AND active = 1
ORDER BY id desc

私はインデックスを持っています:

コメント -> キーネーム (postid) - postid、active、id

ユーザー -> キー名 (ユーザー名) - ユーザー名

私が得ている結果は次のとおりです。

+----+-------------+----------+------+---------------+--------+---------+-------------+------+---------------------------------+
| id | select_type | table    | type | possible_keys | key    | key_len | ref         | rows | Extra                           |
+----+-------------+----------+------+---------------+--------+---------+-------------+------+---------------------------------+
|  1 | SIMPLE      | comments | ref  | postid        | postid | 5       | const,const |  116 | Using temporary; Using filesort |
|  1 | SIMPLE      | users    | ALL  | NULL          | NULL   | NULL    | NULL        |    1 |                                 |
+----+-------------+----------+------+---------------+--------+---------+-------------+------+---------------------------------+

「一時的なファイルソートを使用」しないようにするには、どうすればこれを修正できますか?

4

4 に答える 4

1

おそらく、3つの列すべてでインデックスを作成します

commentsInnoDB テーブルです

ALTER TABLE comments ADD INDEX new_index (active,postid,username);

commentsMyISAM テーブルです

ALTER TABLE comments ADD INDEX new_index (active,postid,id,username);

なぜ新しいインデックスを提案するのですか?

commentsインデックスでテーブルを検索するpostid場合でも、断続的にテーブルにアクセスして、id 列とユーザー名列を確認する必要があります。WHEREインデックス内のandORDER BY節からの列を増やすと、オプティマイザーの作業が軽減されます。

警告

検索が少し速くなったとしても、あなたが言ったので、ファイルソートはやむを得ないかもしれません

ORDER BY id desc

試してみる ！！！

于 2013-06-30T05:11:11.020 に答える
0

active がフラグの場合、オプティマイザーがそれを処理するのに十分な選択性がない可能性があります。postid のみにインデックスを設定してみましたか?

于 2013-06-30T05:12:57.247 に答える