アプリケーションで頻繁に使用される約100,000レコードのテーブルがあります。ID（ID）列があり、クラスター化インデックスがあり、すべてが正常に機能しました。しかし、いくつかの理由で、Uniqueidentifier列を主キーとして使用する必要がありました。そのため、非クラスター化インデックスを追加し、ID列のクラスター化インデックスを削除しました。しかし今では、ピーク時にお客様から多くのパフォーマンス低下の問題が発生しています。テーブルにクラスター化されたインデックスがないためですか？
2 に答える
2
主キーを追加したという事実は、クラスター化インデックスを削除する必要があったことを意味するものではありません。2つの概念は異なります。非クラスター化インデックスと選択した個別のクラスター化インデックス（古いID列など）によって一意の識別子PKを実装できます。
しかし、本当の問題は、uniqueidentifier PKを追加したときに、アプリケーションをどのように変更したかということです。この新しいPKによって（uniqueidentifierによって）レコードを取得するようにアプリケーションコードも変更しましたか？新しいPKを参照するようにすべての結合を更新しましたか？ID古い列を参照するすべての外部キーcosntraintsを変更しましたか？または、アプリケーションは古いIDID列を使用してデータを取得し続けますか？私の期待は、アプリケーションとテーブルの両方SELECT ... FROM table WHERE pk=@uniqueidentifierを変更し、アクセスがの形式で普及していることです。このようなアクセスのみが発生した場合、クラスター化されていない一意の識別子の主キーがあり、クラスター化されたインデックスがない場合でも、テーブルはOKを実行する必要があります。したがって、何か他のものが働いているに違いありません。
IDアプリケーションは、古いID列に基づいてテーブルに引き続きアクセスしますID古いID列に基づくクエリに結合がありますID古い列のテーブルを参照する外部キー制約があります
最終的には、パフォーマンスのトラブルシューティングの問題が発生し、パフォーマンスのトラブルシューティングの問題としてアプローチします。待機とキューの方法論とパフォーマンスのトラブルシューティングフローチャートの2つの優れたリソースがあります。
于 2012-07-12T06:37:55.487 に答える
1
こんにちは私はあなたがNEWID（）の代わりにNEWSEQUENTIALID（）でクラスター化インデックスとしてuniqueidentifier列を作ることができると思います。newsequentialidはシーケンシャルIDを生成するため、クラスター化されたインデックスの場合は最適です。
于 2012-07-12T09:06:57.320 に答える