2017-04-04 37 views
0

私の例では、最初の(マスタ)テーブルの主キーによって互いに関連する2つのテーブルがあります。第2のテーブルは、第1の(マスタ)テーブルに関連する複数の行を有することができる。私の実際の世界の例では、何千ものクライアントが同時に選択、更新、挿入、削除している何万行もあります。私が経験している問題は、同時更新と選択のためにロックしていることです。非ユニーク列のSQL Serverクラスタ化インデックス

プライマリテーブルに戻って非一意のid列を作成すると、クラスタードインデックスが私の状況に何か役立つでしょうか?

表構造:クエリは、通常のように見える

wks_master: wks_master_id [primary key], other_columns.... 
wks_std_apps: wks_std_apps_id [primary key], wks_master_id, other_columns.... 

select * 
from wks_std_apps 
where wks_master_id = @wks_master_id 

update wks_std_apps 
set blah... 
where wks_master_id = @wks_master_id 
+0

選択と更新の両方で、列が索引付けされている場合は、特定の 'wks_master_id'の行をより迅速に見つけることができます。しかし、クラスタ化する必要はありません。 – user1935361

+0

現在のクラスタード・インデックスはありますか?もしそうなら、それはユニークですか? –

答えて

1

理想的には、第2のテーブルには、クラスタ化インデックスなど、サーバー(これはの組み合わせとすることができるでしょうユニークなプライマリキーを持っているでしょう列)。値が一意でない場合は、クラスター化されていないインデックスを使用します。

+0

クラスタ化されていないインデックスを追加すると、すぐに問題が解決されました。挿入/更新/削除は少し罰せられますが、選択はこのdbのトランザクションの大部分です。 –

関連する問題