seb*_*eid 4 performance index sql-server index-tuning query-performance
假设我有一个包含 12 列的表 X。在我的查询中,我正在过滤这些条件:
select * from x where a=@a and b=@b
select * from x where a=@b and b=@b and c=@c
select * from x where a=@b and b=@b and d=@d
select * from x where a=@b and b=@b and e=@e
Run Code Online (Sandbox Code Playgroud)
该表是非常活跃的表,我需要避免阻塞。如果我需要在这个表上创建索引,我应该创建 4 个这样的索引:
(a,b) (include columns)
(a,b,c) (include columns)
(a,b,d) (include columns)
(a,b,e) (include columns)
Run Code Online (Sandbox Code Playgroud)
或者像这样:
(a,b) (include columns)
(c)
(d)
(e)
Run Code Online (Sandbox Code Playgroud)
或创建 1 个索引 (a,b,c,d,e)(包括列)
这些是每列的不同值的计数。总行数 1446631 , a = 366279 , b= 96 , c = 6 , e = 2 , d= 11098
如果所有的查询模式包括两个滤波器a
和b
,桌子被写入了很多,我认为对于测试的单一指标,看起来像这样:
(a,b) include (c,d,e,other include columns)
Run Code Online (Sandbox Code Playgroud)
原因是它需要维护一个索引而不是三个或四个,并且过滤器中第三列的选择性可能不会为单个查询增加太多额外的好处,因为前两列已经过滤掉了大部分表(好吧,实际上是第一列,因为第二列几乎没有不同的值)。您可以监控查询,并查看是否有任何模式或特定参数值会导致非常糟糕的估计、长时间运行或缺少索引警告。我怀疑他们不会,因为同样,根据您引用的密度,只要您的查询使用过滤器a
和 b
或至少,这应该会导致非常小的范围a
。
我要强调的是,你最终的结果不会是一个简单的“哦,这显然是你应该做的”的答案。您将需要测试你的硬件,你的数据,和您的查询模式(读取和写入),以确定您的工作负载的最佳指数(ES)。