让我们假设一个像这样的表
[KEY] [int] NOT NULL,
[INT1] [int] NULL,
[INT2] [int] NULL,
[INT3] [int] NULL,
[STR1] [varchar](20) NULL,
[STR2] [varchar](20) NULL,
[STR3] [varchar](20) NULL,
查询非常灵活，但总是喜欢这种格式:
SELECT KEY FROM [TABLE] WHERE...
对于 [int] 的搜索条件在单列上出现过几次，而大多数时候在多列上出现。类型，疑问为 BETWEEN或>=或<= ，对于varchar ，始终查询为 =或IN [] 。所有条件均与 AND 连接
由于查询并不总是固定在同一列上，所以我想知道是否创建 INDEX在每一列上，它会提高性能，还是根本浪费。
最佳答案
不要只在每一列上创建索引 - 这完全是浪费时间和资源!
基本上，我的方法始终是:
在任何“普通”表(除了临时表等)上定义一个良好主键和集群键 - 这已经是一大进步了
在任何外键列上放置非聚集索引 - 这确实有很大帮助，尤其是使用 JOIN 时
就是这样!
然后:
- 观察您的系统 - 查看何时运行缓慢
- 衡量系统性能
- 捕获服务器端跟踪以获得代表性工作负载
- 分析该工作负载，看看哪些其他索引可能会有所帮助
- 进行调整 - 一次一项
- 反复测量，看看系统性能是否有所提高
您需要完整的、有代表性的工作负载来查看哪些查询真正常见且经常使用 - 并查看哪些索引可能对这些频繁查询有益。否则，您可能会为所有错误的查询提供索引帮助，并且实际上可能会减慢速度......
您会惊讶地发现非聚集索引很少能真正发挥作用!
不要过度索引 - 这和没有索引一样糟糕 - 如果不是更糟的话!情况可能会更糟，因为您拥有的每个索引都需要在其生命周期内维护...而且天下没有免费的午餐 - 即使在这里也是如此...
请参阅 Kimberly Tripp 的精彩博客文章 Indexes: just because you can doesn't mean you should!关于这个主题 - 非常有帮助，有很多见解。或者基本上，just read anything Kim has blogged on indexes - 她是索引女王，她在博客上发布的任何内容通常都非常有帮助和有益!
此外，SQL Server 2005 及更高版本提供 DMV(动态管理 View )，使您可以根据 SQL Server 查询优化器的意见找出哪些索引未使用(可以删除)或缺失。请参阅SQL Server - Find missing and unused indexes更多细节。但请注意:这些是动态 View - 它们会在每次系统启动时重置，并且可能不完全准确 - 不要只执行它们告诉您的所有操作 - 对所有内容都持保留态度并考虑仔细你所做的事情 - 记录下来，以便在事情变得更糟而不是更好时可以撤消它!
关于sql-server - 关于在 SQL Server 上为各种查询创建单列索引，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/10465946/