我应该使用多个单字段索引，而不是特定的多列索引吗？

Question

这个问题是关于 SQL Server 索引技术的有效性。我认为它被称为“索引交集”。

我正在使用一个现有的 SQL Server (2008) 应用程序，该应用程序存在许多性能和稳定性问题。开发人员在索引方面做了一些奇怪的事情。我无法获得关于这些问题的结论性基准，也无法在互联网上找到任何真正好的文档。

表上有许多可搜索的列。开发人员在每个可搜索列上创建了一个单列索引。理论上，SQL Server 将能够组合（交叉）这些索引中的每一个，以在大多数情况下有效地访问表。这是一个简化示例（真实表有更多字段）：

CREATE TABLE [dbo].[FatTable](
    [id] [bigint] IDENTITY(1,1) NOT NULL,
    [col1] [nchar](12) NOT NULL,
    [col2] [int] NOT NULL,
    [col3] [varchar](2000) NOT NULL, ...

CREATE NONCLUSTERED INDEX [IndexCol1] ON [dbo].[FatTable]  ( [col1] ASC )
CREATE NONCLUSTERED INDEX [IndexCol2] ON [dbo].[FatTable] ( [col2] ASC )

select * from fattable where col1 = '2004IN' 
select * from fattable where col1 = '2004IN' and col2 = 4

我认为针对搜索条件的多列索引要好得多，但我可能错了。我看到查询计划显示 SQL Server 在两个索引查找上执行哈希匹配。当您不知道如何搜索表时，这也许有意义？谢谢。

Answer 1

你需要的是覆盖索引，即。可以自行满足查询的索引。但是“覆盖”索引有一个问题：它覆盖了一个特定的查询。所以为了制定一个好的索引策略，你需要了解你的工作量：哪些查询正在访问数据库，哪些是关键的，哪些不是，每种类型的查询运行的频率等等等等。然后你平衡每个索引的写入和更新成本，然后你就有了你的索引策略。如果听起来很复杂，那是因为它很复杂。

但是，您可以应用一些经验法则。MSDN 很好地涵盖了基础知识：

• 索引设计基础
• 一般索引设计指南
• 聚集索引设计指南
• 非聚集索引设计指南

社区也贡献了大量文章，例如。网络广播录音 – DBA 达尔文奖：索引版。

并具体回答您的问题：每列上的单独索引可以工作，前提是每列都具有高选择性（许多不同的值，每个值在数据库中仅出现几次）。在两个索引范围扫描之间使用散列连接的结果访问计划通常效果很好。具有低选择性的列（很少有不同的值，每个值在数据库中出现多次）没有必要单独索引，查询优化器将简单地忽略它们。然而，当低选择性色谱柱与高选择性色谱柱配对时，它们多次成为良好的组合键。