1日に1,000万から5,000万の挿入があり、選択に迅速に応答する必要があるテーブルを設計する方法について、いくつかの推測が必要です...インデックスを使用する必要がありますか?または、間接費が高すぎるでしょうか?
編集:トランザクション量について心配していません...これは実際には割り当てです...そして私はテーブルのデザインを理解する必要があります「このテーブルが知っているので、主キーに基づかない選択に非常によく応答する必要があります毎日膨大な量の挿入物を受け取ります」
1日に1,000万から5,000万の挿入があり、選択に迅速に応答する必要があるテーブルを設計する方法について、いくつかの推測が必要です...インデックスを使用する必要がありますか?または、間接費が高すぎるでしょうか?
編集:トランザクション量について心配していません...これは実際には割り当てです...そして私はテーブルのデザインを理解する必要があります「このテーブルが知っているので、主キーに基づかない選択に非常によく応答する必要があります毎日膨大な量の挿入物を受け取ります」
ベストレートは、挿入順序と同じPKソートであり、他のインデックスはありません。1日1万から5万はそれほど多くありません。挿入するだけの場合、ダーティリードのマイナス面は見られません。
選択を最適化する場合は、挿入に行レベルのロックを使用します。
インデックスの断片化を測定します。適切な曲線因子を使用して、定期的にインデックスを最適化します。フィルファクターは、インデックスの断片化の速度と最適化の頻度を決定しました。
絶対に。少なくとも主キー、外部キー、そしてレポートに必要なものは何でも、やりすぎないでください。1日10k〜50kの挿入は問題ありません。100万回の挿入のようなものであれば、個別のテーブルやデータディクショナリなどを考え始めることができますが、ニーズに応じて心配する必要はありません。
1日あたり50,000回実行し、1日が8時間労働であったとしても、平均して1秒あたり2回未満の挿入になります。それよりもはるかに高いピークが発生する可能性があると思いますが、一般に、SQLServerは見た目よりもはるかに高いトランザクションレートを処理できます。
テーブルがかなり広い場合(多数の列またはいくつかの非常に長い列)、代理(IDENTITY)列によるクラスタリングを検討することをお勧めします。あなたのボリュームは、テーブルの最後にある悪いホットスポットを作るのに十分ではありません。これと組み合わせて、データの一貫性(つまり、FK)と取得(PK、自然キーなど)に必要なすべてのキーにインデックスを使用します。インデックスにフィルファクタを設定することに注意し、定期的なダウンタイムウィンドウ中にインデックスを再構築することを検討してください。
テーブルがかなり狭い場合は、自然キーでのクラスタリングを検討することもできますが、応答時間の期待に応えることができることを確認する必要があります。