8

データベースに1.000.000レコードを含むテーブルがあるとします。

私が実行した場合：

SELECT * FROM [Table] LIMIT 1000

1000このクエリは、レコードを含むテーブルを持っている場合と同じ時間がかかりますか?

SELECT * FROM [Table]

?

まったく同じ時間がかかるかどうかを探しているわけではありません。最初のものの実行に2番目のものよりもはるかに時間がかかるかどうかを知りたいだけです。

私は1.000.000記録と言いましたが、そうかもしれません20.000.000。それはほんの一例でした。

編集：
もちろん、LIMITを使用して同じテーブルで使用しない場合、LIMITを使用して構築されたクエリはより速く実行されるはずですが、私はそれを求めていません...

ジェネリックにするには:

Table1:Xレコード
Table2:Yレコード

(X << Y)

私が比較したいのは：

SELECT * FROM Table1

と

SELECT * FROM Table2 LIMIT X

編集2：
これが私がこれを求めている理由です：

私はデータベースを持っており、5 つのテーブルとそれらのいくつかの間の関係があります。それらのテーブルの 1 つ (100% 確信しています) には about5.000.000レコードが含まれます。SQL Server CE 3.5、Entity Framework を ORM として使用し、LINQ to SQL を使用してクエリを作成しています。

基本的に 3 種類の単純でないクエリを実行する必要があり、ユーザーにレコードの制限を表示することを考えていました (多くの Web サイトがそうであるように)。ユーザーがより多くのレコードを表示したい場合、オプションは検索をさらに制限することです。

Xそれで、私がこれを行うことを考えていたので（クエリごとのレコードに制限する）、またはデータベースXにいくつかの削除を行う必要がある結果（最近のもの）のみをデータベースに保存することを考えていたので、質問が出てきましたが、私はちょうど考えていました...

したがって、そのテーブルには5.000.000複数のレコードが含まれる可能性があり、ユーザーなどを表示したくないのですが、このようにしても、クエリは行1000を返す場合と同じくらい遅くなります。5.000.000

4

3 に答える 3

6

TAKE 10001000000 レコードのテーブルから - = 10001000/1000000 レコードを参照 (および返す) だけでよいため、1000000/1000 ( ) 倍高速になります。少ないので、当然速くなります。

TAKEする順序を指定していないため、結果はかなり（疑似）ランダムになります。ただし、次数を導入すると、次の 2 つのいずれかが true になります。

  1. ORDER BY 句はインデックスの後に続きます。上記のステートメントは依然として当てはまります。
  2. ORDER BY 句はインデックスを使用できません。TAKE を使用しない場合よりもわずかに高速になります。
    • すべてのレコードを検査し、並べ替える必要がありますORDER BY
    • サブセットのみを配信 (TAKE カウント)
    • したがって、最初のステップでは高速ではありませんが、2 番目のステップではすべてのレコードよりも少ない IO/ネットワークが必要になります

1000 レコードのテーブルから 1000 レコードを取得する場合、(1) 順序付けなし、または (2) のケースに従っている限り、10 億から 1000 レコードを取得するのと同等です (大きな違いはほとんどありません)。インデックスに対する順序付け

于 2011-04-19T04:41:17.833 に答える
2

両方のテーブルが、インデックス、行のサイズ設定、およびその他の構造に関して同等であると想定します。また、その単純なSELECTステートメントを実行していると仮定します。SQLステートメントに句がある場合はORDER BY、明らかに大きなテーブルの方が遅くなります。私はあなたがそれを求めていないと思います。

X = Yの場合、クエリエンジンは、この単純なSELECTステートメントに対してまったく同じ順序（基本的にはテーブルスキャン）でレコードを処理するため、明らかに同じ速度で実行されるはずです。クエリプランに違いはありません。

Y> Xが少しだけの場合は、同様の速度です。

ただし、Y >> X（YにはXよりもはるかに多くの行があることを意味します）の場合、LIMITバージョンは遅くなる可能性があります。クエリプランのためではなく（これも同じである必要があります）、データレイアウトの内部構造にさらにいくつかのレベルがある可能性があるためです。たとえば、データがツリーにリーフとして保存されている場合、ツリーレベルが増える可能性があるため、同じページ数にアクセスするのに少し時間がかかる場合があります。

言い換えれば、1000行が10ページの1ツリーレベルに格納される可能性があります。1000000行は、10000ページの3〜4ツリーレベルに格納できます。それらの10000ページから10ページだけを取得する場合でも、ストレージエンジンは3〜4ツリーレベルを通過する必要があり、これには少し時間がかかる場合があります。

これで、ストレージエンジンがデータページを順番に、またはリンクリストとして保存する場合、たとえば、実行速度に違いはありません。

于 2011-04-19T04:59:18.050 に答える
1

フィールド、順序、およびすべてのレコードを指定しない限り、ほぼ線形になります。しかし、それはあなたをあまり買わない。クエリが何か便利なことをしたいと思うとすぐにバラバラになります。

これは、有用な結論を導き出し、ある状況で設計を選択するために使用される方法について教えてくれる場合は、かなり興味深いものになります。

説明してくれてありがとう。

私の経験では、実際のユーザーがいる実際のアプリケーションには、100万行のテーブル全体を返す興味深いクエリや有用なクエリがほとんどありません。ユーザーは自分の活動や特定のフォーラムスレッドなどについて知りたがっています。したがって、あなたが珍しいケースでない限り、実際に選択基準を手に入れるまでに、妥当な結果サイズについて話し合うことになります。

いずれにせよ、ユーザーは数百を超える行が多いと便利なことは何もできず、それらを転送するのに長い時間がかかり、合理的な方法でスクロールすることができませんでした。

MySQLには、主にLIMITおよびOFFSET（開始レコード番号）修飾子があり、説明したように、ページング用のリストのチャンクを作成するという正確な目的があります。

これと他の多くの戦略を使い果たすまで、スキーマの設計とレコードのパージについて考え始めるのは逆効果です。この場合、まだ解決していない問題を解決しないでください。数百万行のテーブルは、正しくインデックス付けされている限り、実際には大きくありません。

于 2011-04-19T05:05:17.570 に答える