这个问题是关于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在两个索引搜索上进行哈希匹配.当你不知道如何搜索表时,这可能是有意义的吗？谢谢.
解决方法
你需要什么覆盖索引,即.可以满足查询的索引.但是“覆盖”索引有一个问题：它覆盖了特定的查询.因此,为了开发一个好的索引策略,您需要了解您的工作负载：哪些查询正在访问数据库,哪些是关键的,哪些不是,每种类型的查询运行的频率等等等等.然后你将此与每个索引的写入和更新成本相平衡,并且您有自己的索引策略.如果它听起来很复杂,那是因为它很复杂.
但是,您可以应用一些经验法则. MSDN很好地介绍了基础知识：
> Index Design Basics
> General Index Design Guidelines
> Clustered Index Design Guidelines
> Nonclustered Index Design Guidelines
社区也提供了无数的文章,例如. Webcast Recording – DBA Darwin Awards: Index Edition.
并且具体回答您的问题：每列的单独索引都可以工作,前提是每列具有高选择性(许多不同的值,每个值在数据库中只出现几次).使用两个索引范围扫描之间的散列连接生成的访问计划通常可以很好地工作.具有低选择性的列(几个不同的值,每个值在数据库中出现多次)对于自己编制索引是没有意义的,查询优化器将简单地忽略它们.但是,低选择性色谱柱在与高选择性色谱柱配对时,可以多次制备出良好的复合键.
