有什么建议可以确定需要创建哪些索引?

时间:2010-01-13 21:09:07

标签: sql-server sql-server-2005 indexing

我的情况是我必须提高用于报告的大约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个触发器,请告诉我。

此外,插件每天只在此DB上执行一次,因此插入性能对我来说不是一个大问题。

5 个答案:

答案 0 :(得分:4)

  

有哪些建议可以确定需要创建哪些索引?

是的! 请求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;

小心点。我已经看到人们将缺失的索引视图作为福音,并使用它们推出一堆他们并不真正需要的索引。就插入,更新和删除时间的维护以及磁盘空间和内存使用而言,索引具有成本。要真实,准确地使用此信息,您需要在任何更改之前和之后分析关键过程的实际执行时间,以确保索引(单个或累积)的好处不会超过成本。

答案 1 :(得分:2)

如果您知道所有活动都来自75个存储过程,那么我将使用分析器来跟踪哪个存储过程占用时间最长并且被称为最多。一旦你知道哪些是那些procs,看看哪些列最常用于Where子句和JOIN ON部分。最有可能的是,那些是您希望放置非聚集索引的列。如果一组列经常一起使用,那么您很可能希望为该组创建1个非聚集索引。您可以在表(250)上拥有许多非聚集索引,但您可能不希望在其上放置多个非聚簇索引。我想你会发现数据正在被搜索并反复加入相同的列。记住80/20规则。在前20%的工作中,你可能会获得80%的速度提升。对于添加的索引,您将获得非常小的速度提升,即您想要停止时。

答案 2 :(得分:2)

我同意bechbd - 使用您的数据库流量的良好样本(通过在实际办公时间内在生产系统上运行服务器跟踪,以获得最佳快照),并让Database Tuning Advisor分析该抽样。

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

另外 - 要真正了解某些事情是否有所帮助,您需要实施它,再次测量并进行比较 - 这才是真正唯一可靠的方法。涉及的变量和未知数太多了。

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

索引调整始终是一种平衡,权衡和试错的游戏 - 它不是一个精确的科学,有一个公式和食谱书来严格确定你需要什么。

答案 3 :(得分:1)

您可以在SSMS中使用SQL Server分析器来查看表的调用内容和方式,然后使用分析器中的数据库调整工具至少启动正确的路径。我知道大多数DBA可能会尖叫我推荐这个,但对于我这样的非DBA类型,至少给我们一个起点。

答案 4 :(得分:0)

如果这是一个严格的报告数据库并且您需要性能,请考虑转移到数据仓库设计。在报告时,星形或雪花模式甚至会超越非规范化的关系设计。