SQL Server：テーブルの最大行数
データベーステーブル（SQL Serverバージョン8、9、または10）の1つに大量のデータを格納するソフトウェアを開発しています。たとえば、1日あたり約100,000件のレコードがそのテーブルに挿入されます。これは、年間約3,600万レコードです。パフォーマンスが低下することを恐れて、毎日新しいテーブル（名前に現在の日付が含まれるテーブル）を作成して、テーブルあたりのレコード数を減らすことにしました。
いいアイデアだったかどうか教えてください。 SQL Serverテーブルにレコード制限はありますか？または、パフォーマンスが大幅に低下する前に、テーブルに保存できるレコードの数（多かれ少なかれ）を知っていますか？
これに対する一般的な答えを出すのは難しいです。それは本当に多くの要因に依存します：
- 行のサイズは何ですか
- 保存するデータの種類（文字列、ブロブ、数値）
- データを使用して何をしますか（アーカイブとして保持し、定期的に照会します）
- テーブルにインデックスはありますか-いくつありますか
- サーバーのスペックは何ですか
等.
ここで別の場所で回答したように、1日あたり100,000です。したがって、テーブルごとに過剰です。テーブルが増えると、メンテナンス/クエリの悪夢が大きくなります。
これらは一部です SQL Server 2008 R2の最大容量仕様
- データベースサイズ：524,272テラバイト
- SQL Serverのインスタンスごとのデータベース：32,767
- データベースごとのファイルグループ：32,767
- データベースあたりのファイル数：32,767
- ファイルサイズ（データ）：16テラバイト
- ファイルサイズ（ログ）：2テラバイト
- テーブルごとの行：使用可能なストレージによって制限されます
- データベースごとのテーブル：データベース内のオブジェクトの数によって制限されます
SQL Server 2008 R2には、60億行をわずかに超える3列のテーブルがあります。
毎日クエリを実行し、顧客向けの分単位のシステム分析チャートを作成しています。データベースのパフォーマンスの低下に気づきませんでした（毎日1 GB増加するという事実により、バックアップの管理は私が望むよりも少し複雑になります）。
2016年7月更新
〜245億行までにして、バックアップが2年以上前のレコードを切り捨てることを決定するのに十分な大きさになるまで（〜700 GBを複数のバックアップに保存） 、高価なテープを含む）。パフォーマンスがこの決定の重要な動機ではなかったことに注意する価値があります（つまり、それはまだうまく機能していました）。
SQL Serverから200億行を削除しようとしていることに気付いた人は、 この記事 を強くお勧めします。リンクが停止した場合の関連コード（完全な説明については記事を読んでください）：
ALTER DATABASE DeleteRecord SET RECOVERY SIMPLE;
GO
BEGIN TRY
BEGIN TRANSACTION
-- Bulk logged
SELECT *
INTO dbo.bigtable_intermediate
FROM dbo.bigtable
WHERE Id % 2 = 0;
-- minimal logged because DDL-Operation
TRUNCATE TABLE dbo.bigtable;
-- Bulk logged because target table is exclusivly locked!
SET IDENTITY_INSERT dbo.bigTable ON;
INSERT INTO dbo.bigtable WITH (TABLOCK) (Id, c1, c2, c3)
SELECT Id, c1, c2, c3 FROM dbo.bigtable_intermediate ORDER BY Id;
SET IDENTITY_INSERT dbo.bigtable OFF;
COMMIT
END TRY
BEGIN CATCH
IF @@TRANCOUNT > 0
ROLLBACK
END CATCH
ALTER DATABASE DeleteRecord SET RECOVERY FULL;
GO
2016年11月更新
これだけのデータを単一のテーブルに保存する場合は、しないでください。テーブルパーティション化を検討することを強くお勧めします（手動またはEnterpriseエディションを実行している場合は組み込みの機能を使用）。これにより、1週間に1回（週/月/など）テーブルを切り捨てるのと同じくらい簡単に古いデータを削除できます。エンタープライズ（ない）がある場合は、月に1回実行し、2年以上前のテーブルを削除し、来月のテーブルを作成し、すべてのパーティションを結合する動的ビューを再生成するスクリプトを書くことができます。簡単にクエリできるようにテーブルをまとめます。明らかに、「1か月に1回」と「2年以上」は、ユースケースの意味に基づいて定義する必要があります。数百億行のデータを含むテーブルから直接削除すると、a）膨大な時間がかかり、b）トランザクションログが数百または数千回いっぱいになります。
私はMSSQLを特に知りませんが、3,600万行はエンタープライズデータベースとしては大きくありません。メインフレームデータベースと連携して、100,000行は構成テーブルのように聞こえます:-)。
私はMicrosoftのソフトウェアのsomeの大ファンではありませんが、これはここで話しているAccessではありません。エンタープライズDBMSでかなりのデータベースサイズを処理できると思います。
本当に分割する必要がある場合、分割するのに十分な解像度の日があったのではないかと思います。
行の制限については知りませんが、1億7千万行を超えるテーブルは知っています。分割されたテーブル（2005+）または複数のテーブルを接続するビューを使用して、速度を上げることができます。
SQL Server 2005および2008には、10億行を超えるテーブルがあります（毎日3,000万行追加されます）。それを毎日新しいテーブルに分割するネズミの巣を下るのは想像できません。
適切なディスクスペース（とにかく必要）とRAMを追加する方がはるかに安価です。
状況によって異なりますが、単純にするためにすべてを1つのテーブルに保持する方が良いと思います。
1日あたり100,000行は、それほど大きな量ではありません。 （サーバーのハードウェアに依存）。個人的には、MSSQLが単一のテーブルで最大1億行を問題なく処理するのを見てきました。インデックスを順序どおりに保持している限り、それはすべて良好です。重要なのは、インデックスをディスクにスワップアウトする必要がないように、メモリをheapsにすることです。
一方、それはあなたが多くのクエリを作成する必要がある場合、データをどのように使用しているかに依存し、数日にわたるデータが必要になる可能性は低いです（したがって、テーブルを結合する必要はありません）複数のテーブルに分割するのが高速です。これは、産業用プロセス制御など、10秒ごとに50,000台の機器の値を読み取るアプリケーションでよく使用されます。この場合、速度は非常に重要ですが、単純さは重要ではありません。
テーブルで整数主キーを1回（最大24億行）オーバーフローさせました。行の制限がある場合、年間わずか3,600万行でヒットすることはほとんどありません。
十分なディスク容量ができるまで、テーブルにデータを追加できます。パフォーマンスを向上させるには、SQL Server 2005への移行を試みてからテーブルをパーティション分割し、異なるディスクにパーツを配置します（実際に役立つRAID構成がある場合）。パーティショニングは、エンタープライズバージョンのSQL Server 2005でのみ可能です。次のリンクでパーティショニングの例を見ることができます。 http://technet.Microsoft.com/en-us/magazine/cc162478.aspx
また、最もよく使用されるデータ部分のビューを作成することもできます。これもソリューションの1つです。
これが助けたことを願っています...
Windows2003上のSQL Server 8で私が遭遇した最大のテーブルは、5つのカラムを持つ7億9,900万でした。しかし、それが良い意志であるかどうかは、SLAおよび使用例に対して測定することです。 50-100,000,000レコードをロードし、それがまだ機能するかどうかを確認します。