4
私はソリューションを実装するために必要な特別なシナリオのために、単一のテーブルでデータベースを設計しています。テーブルは短時間で数億行になりますが、各行はかなりコンパクトです。行がたくさんある場合でも、すばやく高速に挿入、更新、選択する必要があるため、そのジョブに最適なインデックスを選択する必要があります。SQL Serverのインデックス - 非常に大きな値域に対してwhere句を持つ非常に大きなテーブル - where句のインデックスが必要ですか？
私のテーブルには、次のようになります。
create table dbo.Domain
(
Name varchar(255) not null,
MetricType smallint not null, -- very small range of values, maybe 10-20 at most
Priority smallint not null, -- extremely small range of values, generally 1-4
DateToProcess datetime not null,
DateProcessed datetime null,
primary key(Name, MetricType)
);
選択クエリは次のようになります。
select Name from Domain
where MetricType = @metricType
and DateProcessed is null
and DateToProcess < GETUTCDATE()
order by Priority desc, DateToProcess asc
更新の第1のタイプは次のようになります。
merge into Domain as target
using @myTablePrm as source
on source.Name = target.Name
and source.MetricType = target.MetricType
when matched then
update set
DateToProcess = source.DateToProcess,
Priority = source.Priority,
DateProcessed = case -- set to null if DateToProcess is in the future
when DateToProcess < DateProcessed then DateProcessed
else null end
when not matched then
insert (Name, MetricType, Priority, DateToProcess)
values (source.Name, source.MetricType, source.Priority, source.DateToProcess);
2番目のタイプのアップデートは次のようになります：
update Domain
set DateProcessed = source.DateProcessed
from @myTablePrm source
where Name = source.Name and MetricType = @metricType
これらは最適な挿入、更新、選択速度の指標ですか？
-- for the order by clause in the select query
create index IX_Domain_PriorityQueue
on Domain(Priority desc, DateToProcess asc)
where DateProcessed is null;
-- for the where clause in the select query
create index IX_Domain_MetricType
on Domain(MetricType asc);
ああ、私はインクルード句を認識していませんでした。 –
@NathanRidley：私の回答をもっと更新しました。 – gbn
ああ、それはいい考えです。あなたはそれが真剣に大きな違いをもたらすと思いますか？最初の実行では、データベースには約1億5000万行の行があるはずです。 –