1

この 2 つのクエリについては本当に混乱しています。クエリ速度が不安定です。これが私の 2 つのテーブル スキームです。

投稿テーブル: (id、タイトル、日付など...) [日付インデックス]

関係テーブル: (news_id, relationship_id) [両方と行ごとにインデックスがあります]

クエリ A:

SELECT *
FROM posts
WHERE id IN (
    SELECT news_id
    FROM relationships
    WHERE relation_id IN (?)
)
AND status = 1
ORDER BY `date` DESC

クエリ B:

SELECT *
FROM posts AS p
INNER JOIN relationships AS r ON r.news_id = n.id
WHERE r.relation_id IN (?)
AND n.status = 1
ORDER BY n.date DESC

奇妙な部分はテスト結果です。最初に 30 行の relationship_id を試します。

クエリ A: 合計 30 件、クエリにかかった時間は 5.56 秒

クエリ B: 合計 30、クエリにかかった時間は 0.03 秒

A は行数が少ないほど遅く、B は行数が少ないほど高速です。次に、3k 行の relationship_id を試します。

クエリ A: 合計 3,850、クエリにかかった時間は 0.05 秒

クエリ B: 合計 3,850、クエリにかかった時間は 0.70 秒

したがって、これは私を混乱させます。より多くのデータで、A はより高速になりました。最後に、+10k 行で複数の relationship_id を試します。例;relation_id IN (1, 2, 3, 4)

クエリ A: 合計 18,906、クエリにかかった時間は 0.01 秒

クエリ B: 合計 18,906、クエリにかかった時間は 3.34 秒

それで、私は何をすべきですか?クエリ A は非常に多くの行で高速ですが、行が少ないと遅くなります。このクエリの別の真の方法の提案はありますか? (下手な英語や文法の間違いでごめんなさい)

編集

これが SQL EXPLAIN です。

30 行のクエリ A 30 行のクエリ A

30 行のクエリ B クエリ B

18,000 行のクエリ A クエリ

18,000 行のクエリ B クエリ b 2

4

1 に答える 1

0

非常に奇妙ですが、それは MySQL です ;-)

status = 1オプティマイザは、これは強い制限であると考えています。それが維持されれば、あなたはやり遂げます

select status=1, count(*) as num from posts group by status=1

テーブルのほんの一部である場合status=1でも、30 行のソリューションは mysqls の観点からは非常に優れています。

大きな部分がある場合はstatus = 1、クエリを試してください

from posts ignore index (status) ...

また

from posts force index (id) ...

where-in-solution を強制します。

経由で取得できる詳細情報

explain select count(*) from relationships where relation_id in (1)

これは、インデックス統計に基づいてオプティマイザーが予想するサイズを示しています。

固定インデックスヒントの問題は、それらが固定されていることです。つまり、良いシナリオにも悪いシナリオにも適用されます。

一時テーブルがそれを回避するのに役立つ場合があります。関連する関係をそこに保存できます。

于 2013-05-12T16:41:31.277 に答える