2 つの SQL ステートメント、後者のランタイムは実行時間を意味し、データ量は 150W
フィールドの説明 zhuanid は数値です。 webid は数値です。 空は 0 または 1 です。
SQL の最初の文で使用される共通インデックスは、zhuanid webid の空の番号のインデックスのセットです。
SQL の 2 番目の文で使用されるインデックスは、zhuanid webid の空のインデックスのセットです。Time と ID はインデックスのセット
最初の文のカウントにこれほど時間がかかるのはなぜですか?2 番目の文の複雑なクエリに比べて、非常に時間がかかりません。
最初の文は SQL、リミット 1 です
2 番目の文は SQL、リミット 0、10 です
count に 150 万個のアイテムを数えるように依頼しました。最初の 10 個のアイテムをチェックするよりも速くしたいですか?
私の推測: インデックス フィールドが null 非許容に設定されていないため、count(*) はインデックスを使用できません。
さらに、これら 2 つのステートメント自体は同等ではありません。最初のステートメントはテーブル全体に対するものですが、2 番目のステートメントは同等ではないようです。
最初の SQL 結果セットが非常に大きい場合は、条件を満たすすべてのレコードをスキャンする必要があります。この場合、2 番目の SQL は時間 ID インデックスを使用するだけで済みます。条件を満たす 10 件のレコードを見つけるだけです。さらに、zhuanid 空の webid の結合インデックスは、zhuanid 列と webid の範囲部分のみを使用します。
最初の SQL が実行された後、結果はキャッシュに保存されます。
2 番目の SQL の実行は最初の SQL のキャッシュに依存するため、より高速になります (実際には 2 番目の SQL はソートを使用するため、遅くなるはずです)。
最初の SQL が実行された後にポスターを実行できます
リーリーキャッシュをリセットしてから 2 番目の SQL を実行すると、結果は異なります。