1000万件のレコードがあるテーブルがあります。これは大量のレコードと見なされますか？検索時間を心配する必要がありますか？そうでない場合、レコードは増え続けるので、それで何になるでしょうか？は大きなテーブルと見なされますか? テーブルのサイズは検索時間にどの程度影響しますか? また、問題が発生する前に、これらの問題を改善するために何ができますか?
ベストアンサー1
「大きい」というのは「スマート」と同じく相対的なものです。1,000 万行は適切なサイズですが、テーブルが大きいかどうかはいくつかの要因によって決まります。
- 幾つか列それらのデータ型は何ですか?
- インデックスはいくつありますか?
- テーブルの実際のサイズはどれくらいですか (たとえば、ページ数 * 8kb、これは から取得できます
sys.dm_db_partition_stats)? - どのような種類のクエリが実行されますか?
- 個々のインデックスはメモリ内に保持されますか、それともほとんどのクエリはクラスター化インデックス スキャン (基本的にテーブル全体をメモリ内に保持する必要があります) の恩恵を受けますか?
- マシンにはどれくらいのメモリがありますか?
- 何をするあなた大きいと考えますか?
検索時間は必ずしもサイズ自体によって決まるわけではなく、インデックス戦略の有効性と検索に実行するクエリの種類によって決まります。次のような場合:
WHERE description LIKE '%foo%'
その場合、通常のインデックスはまったく役に立たないので、心配し始める必要があります。このような場合には、フルテキスト検索を検討してください。
1 つの INT 列を持つテーブル (Numbers テーブルなど) に 1,000 万行あっても大したことはありません。しかし、長い説明、XML、地理データ、画像などを含む 1,000 万行の製品となると、話は別です。
SQL Server の最大容量仕様に、テーブル内の行数の上限が記載されていないのには理由があります。