关于确定需要创建哪些索引的任何建议？答案

【问题标题】：Any suggestions for identifying what indexes need to be created?关于确定需要创建哪些索引的任何建议？
【发布时间】：2011-01-04 20:10:51
【问题描述】：

我必须改进用于报告的大约 75 个存储过程（由其他人创建）的性能。我的解决方案的第一部分是创建大约 6 个非规范化表，这些表将用于大部分报告。现在我已经创建了表，我有一项艰巨的任务是确定我应该创建哪些索引以最好地提高这些存储过程的性能。

我很想知道是否有人对查找哪些列可以包含在索引中提出任何建议？我已经考虑过使用 Profiler/DTA，或者可能使用如下所示的某种查询来找出流行的列。

SELECT name, Count(so.name) as hits, so.xtype
from syscomments as sc
INNER JOIN sysobjects so ON sc.id=so.id
WHERE   sc.text like '%ColumnNamme%'
AND xtype = 'P'
Group by name,so.xtype
ORDER BY hits desc

如果您有任何想法可以帮助我不必手动挖掘这 75 个 proc，请告诉我。

此外，插入每天只在此数据库上执行一次，因此插入性能对我来说不是一个大问题。

【问题讨论】：

标签： sql-server sql-server-2005 indexing

【解决方案1】：

您可以使用 SSMS 中的 SQL Server 探查器来查看您的表被调用的内容和方式，然后使用探查器中的数据库调整工具至少让您走上正确的道路。我知道大多数 DBA 可能会因为我推荐这个而对我大喊大叫，但对于像我这样的非 DBA 类型来说，它至少给了我们一个起点。

【讨论】：

是的，这是我正在考虑的选项之一。我从很多人那里听说过，您不应该依赖这种方法来生成索引。
我已经进行了相当多的调整，这是我成功使用的一种方法。从分析器中，您可以获得各种有用的信息，尤其是 CPU 和磁盘 IO 使用情况。这将向您显示哪些 SP 是最慢的（或者至少是那些可能从调整中受益最多的 SP）。然后，您可以打开它们并查看查询计划 - 尽管有人真正了解 Sql 查询计划吗？
听起来大多数人认为使用 profiler/dta 来了解我需要哪些索引是个好主意。在生产服务器上运行探查器几个小时会出现什么样的问题？
注意实时系统上跟踪的优先级。如果太高，它们会干扰实时站点的性能。我相信，如果您从分析器 UI 运行跟踪，它会自动以高优先级运行，因此我建议不要使用 UI 在实时系统上运行跟踪（尽管命令行版本还可以）。

【解决方案2】：

如果您知道所有活动都来自 75 个存储过程，那么我将使用分析器来跟踪哪些存储过程耗时最长且调用次数最多。一旦您知道哪些是然后查看这些 proc 并查看 Where 子句和 JOIN ON 部分中最常使用哪些列。最有可能的是，这些列是您想要放置非聚集索引的列。如果一组列经常一起使用，那么您很有可能希望为该组创建 1 个非聚集索引。您可以在一个表上拥有许多非聚集索引 (250)，但您可能不想在其上放置多个索引。我想你会发现数据被一遍又一遍地搜索并加入相同的列。记住 80/20 法则。在你所做的前 20% 的工作中，你可能会获得 80% 的速度提升。在某个时间点，添加索引的速度几乎没有提高，也就是您想要停止的时候。

【讨论】：

【解决方案3】：

对于确定需要创建哪些索引有什么建议吗？

是的！ 请 Sql Server 告诉你。

Sql Server 会自动保存可用于提高性能的索引的统计信息。这已经在您的后台进行。见此链接：
http://msdn.microsoft.com/en-us/library/ms345417.aspx

尝试运行这样的查询（取自 msdn）：

SELECT mig.*, statement AS table_name,
    column_id, column_name, column_usage
FROM sys.dm_db_missing_index_details AS mid
CROSS APPLY sys.dm_db_missing_index_columns (mid.index_handle)
INNER JOIN sys.dm_db_missing_index_groups AS mig ON mig.index_handle = mid.index_handle
ORDER BY mig.index_group_handle, mig.index_handle, column_id;

小心点。我见过人们把缺失的索引视图当作福音，并用它们来推出一堆他们并不真正需要的索引。在插入、更新和删除时的维护以及磁盘空间和内存使用方面，索引具有成本。要真正、准确地使用这些信息，您需要在任何更改之前和之后分析关键程序的实际执行时间，以确保成本不会超过索引的好处（单独或累积）。

【讨论】：

【解决方案4】：

我同意 bechbd - 使用良好的数据库流量样本（通过在实际办公时间在生产系统上运行服务器跟踪，以获得最佳快照），并让数据库优化顾问分析该样本。

我同意你的看法 - 不要盲目地依赖数据库优化顾问告诉你做的所有事情 - 这只是一个建议，但 DTA 不能将所有事情都考虑在内。当然 - 通过添加索引可以加快查询速度 - 但同时会减慢插入和更新速度。

另外 - 要真正找出是否有帮助，您需要实施它，再次测量并比较 - 这确实是唯一可靠的方法。涉及的变量和未知数太多了。

当然，您可以使用 DTA 对单个查询进行微调以使其执行得非常好——但这可能会忽略这个查询每周只调用一次的事实，或者通过调整这一个查询并添加一个索引，你会伤害其他查询。

索引调优始终是一种平衡、权衡和反复试验的游戏 - 它不是一门精确的科学，有一个公式和一本食谱书来严格确定您需要什么。

【讨论】：

【解决方案5】：

如果这是一个严格的报告数据库并且您需要性能，请考虑迁移到数据仓库设计。在报告方面，星型或雪花模式甚至会胜过非规范化的关系设计。

【讨论】：