这里有 2 个示例,每个示例有 2 个索引,假设所有这些索引都有很高的使用率,应该将它们合并还是分开?我的第一个想法是只有示例 #2 应该合并其索引。
示例#1:
CREATE INDEX [ix_Orders_1]
ON [dbo].[Orders] ([cancelled], [approved], [denied], [saved])
INCLUDE ([total], [subTotal], [tax])
CREATE INDEX [ix_Orders_2]
ON [dbo].[Orders] ([cancelled], [isQuote])
INCLUDE ([dateStamp], [userId])
示例#2:
CREATE INDEX [ix_Products_1]
ON [dbo].[Products] ([itemNumber])
INCLUDE ([altItemNumber], [description])
CREATE INDEX [ix_Products_2]
ON [dbo].[Products] ([itemNumber], [showPrice])
INCLUDE ([level_1], [level_2], [level_3], [level_4])
在示例 #1 中,由于两者的第二列不同,我认为它们应该保留为 2 个索引。
在示例#2中,索引可以合并为以下内容并保持其性能吗?
CREATE INDEX [ix_Products_3]
ON [dbo].[Products] ([itemNumber], [showPrice])
INCLUDE ([altItemNumber], [description], [level_1], [level_2], [level_3], [level_4])
索引键的组成实际上是一个向量,这意味着这个索引键的列的顺序对于它的搜索效率非常重要,否则就会被忽略...... 但搜索的“强度”在键的最后一列上比在第一列上要小,因为前一列后面的每一列都会过度过滤已经过滤的结果......这意味着最后一列过滤最少,在多列键的情况下,如果将其放入特定于 SQL Server 和最近的 PostGreSQL 的 INCLUDE 子句中,则可以忽略它...
换句话说,在示例#1 中,您可以尝试以下综合:
CREATE INDEX [ix_Orders_1]
ON [dbo].[Orders] ([cancelled]))
INCLUDE ([total], [subTotal], [tax], [approved], [denied], [saved], [dateStamp], [userId])
但我不确定它是否真的有用。这取决于优化器来决定,并且只有当“取消”的标准非常过滤时才会这样做,我对此表示怀疑,因为它可能是一个布尔值......
在第二个示例#2 中,您自己找到了合成。