私が現在の (雇用主の) 会社に入ったとき、新しいデータベース スキーマが設計されました。これは、作成される、または作成される予定の多くのツールのベースとなります。SQL の知識が限られているため、テーブルはかなり適切に設計されていると思います。私の唯一の懸念は、ほぼすべてのテーブルにマルチパートの主キーがあることです。すべてのテーブルには、少なくとも CustomerId と独自のキーがあります。これらは確かに特定のレコードを定義していますが、複数のキー (ここでは 4 倍について話している) は非常に非効率的であると感じています。
今日、2 つのテーブルを結合し、最初のテーブルから 1 つの文字列フィールドを選択してそれらを区別する単純な繰り返しのクエリで、想像を絶するほどの CPU 使用率が発生していました。
select distinct(f.FIELDNAME) as fieldName
from foo f
inner join bar b
on f.id = b.fId
where b.cId = @id;
実行計画を確認すると (私は EP ヒーローではありません)、3 つの主要な CPU ポイントがあることに気付きました。インデックスに対する個別の (予想どおり) および 2 つのシーク。個人的には、インデックスのシークは非常に高速であるべきだと思いますが、それぞれのコストの 18% を占めています。これは正常ですか?(4 つの) クラスター化インデックスが原因ですか?
--UPDATE--
クエリは Lucene インデックスの作成に使用されます。これは、ほぼ毎週発生する 1 回限りの処理です (矛盾しているように聞こえますが)。私が見る限り、ここで結果を再利用することはできません。