3

このクエリをさらに高速化できるかどうかに興味がありますか? または、より適切に機能する同様のクエリが他にある場合は?

SELECT id,source FROM posts
WHERE id = ANY(SELECT image_id FROM `post_tags` WHERE tag_id = (SELECT id FROM `tags` WHERE tag = _utf8 '$TAG' collate utf8_bin))
  AND posts.exists = 'n'
ORDER BY posts.ratecount DESC
LIMIT 0,100

以下を使用しない場合:

  AND posts.exists = 'n'
ORDER BY posts.ratecount
DESC LIMIT 0,100

クエリを使用可能なレベルまで高速化しますが、私がやっていることには多少必要です。

  • タグ テーブルには、'tag' と 'id' の両方に一意のインデックスがあります。
  • タグには 83K 行あります。
  • Post_tags には、「image_id」、「tag_id」の一意のインデックスがあります。また、それぞれの通常のインデックス。
  • Post_tags には 471K 行あります。
  • 投稿には「id」の一意のインデックスがあります。また、'exists' と 'ratecount' の通常のインデックス。
  • Posts テーブルには約 110 万行あります。
4

2 に答える 2

0

誰かが提案したように、JOINを使用してそれを機能させることができました。

SELECT * FROM posts
LEFT JOIN post_tags ON post_tags.image_id = posts.id
JOIN tags ON post_tags.tag_id = tags.id
WHERE tags.tag = _utf8 '$tag' collate utf8_bin
  AND posts.exists = 'n'
ORDER BY posts.ratecount DESC
LIMIT 0,100

所要時間が 22 秒から 0.26 秒に短縮されました。

于 2012-04-16T20:30:41.683 に答える
0

TAG テーブルはどのように見えますか? ID フィールドと TAG フィールドのみが含まれていますか? 一意のインデックスを作成して、TAG(TAG, ID)最も内側のクエリでインデックスを検索するだけです。

POST_TAGS テーブルはどうですか? TAG_ID と IMAGE_ID の組み合わせだけですか? ここでも、 に一意のインデックスを作成しPOST_TAGS(IMAGE_ID, TAG_ID)ます。

インデックス内のフィールドの順序は重要であり、解析プランPOST_TAGS(TAG_ID, IMAGE_ID)で使用するインデックスとは大きく異なることに注意してください。POST_TAGS(IMAGE_ID, TAG_ID)

また、一意のインデックスを持つ POSTS テーブルPOSTS(ID, POSTS, RATEACCOUNT)が役立ちます (これは冗長なインデックスであり、INSERT、UPDATE、および DELETE に余分なコストがかかることはわかっていますが、このクエリでは役立ちます)。

ちなみに、内部クエリで JOIN を使用すると、パフォーマンスが向上する場合があります。確認してください。

于 2012-04-16T06:22:13.367 に答える