2010-01-13 72 views
2

我处于一种情况,我必须提高用于报告的大约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上每天执行一次,所以插入性能对我来说不是一个大问题。

回答

1

您可以使用SSMS中的SQL Server分析器查看您的表是如何调用的,然后使用分析器中的数据库调整工具至少启动您的正确路径。我知道大多数DBA可能会尖叫我,因为我推荐这个,但对于我们这样的非DBA类型,比如我自己,它至少给了我们一个起点。

+1

是的,这是我正在考虑的选项之一。我听到很多人都说你不应该依靠这种方法来生成你的索引。 – 2010-01-13 21:20:36

+0

我已经做了相当多的调整,这是我用过的一个很成功的方法。从探查器中,您可以获得各种有用的信息,尤其是CPU和磁盘IO使用情况。这将告诉你哪些SP最慢(或者至少可以从调优中获益最多)。然后,您可以打开这些查询并查看查询计划 - 虽然有人真的了解Sql查询计划吗? – MrTelly 2010-01-13 21:41:29

+0

听起来好像大多数人认为使用profiler/dta来了解我需要的索引是个好主意。在我的生产服务器上运行Profiler几个小时可以期待什么样的问题? – 2010-01-13 21:58:30

2

如果您知道所有活动都来自75个存储过程,那么我将使用分析器来跟踪哪些存储过程花费最长时间并被称为最多。一旦你知道哪些是那些,然后看看那些特效,并查看哪些列最常用的Where子句和JOIN ON部分。最有可能的是,这些列是您希望放置非聚集索引的列。如果一组列经常被同时使用,那么您很可能需要为该组创建一个非聚集索引。你可以在一个表上有很多非聚集索引(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; 

当然,做出真实的,准确的利用这些信息,你需要配置文件的实际执行在任何变化之前和之后的关键程序的时间。

2

我同意bechbd--使用数据库流量的一个很好的示例(通过在实际工作时间在生产系统上运行服务器跟踪以获得最佳快照),并让数据库调整顾问分析该采样。

我同意你 - 不要盲目依靠数据库优化顾问告诉你做的一切 - 这只是一个建议,但DTA不能把所有的事情都考虑进去。当然 - 通过添加索引可以加快查询速度 - 但您会同时放慢插入和更新速度。

而且 - 要真正查出是否有帮助,你需要实现它,再次测量和比较 - 这是真正的唯一可靠方法。涉及的变量和未知量太多。

当然,您可以使用DTA来微调单个查询以实现出色的性能 - 但这可能会忽略这样一个事实,即该查询每周只被称为一次,或者通过调整这一个查询并且添加一个索引,你会伤害其他查询。

指数调整始终是一个平衡,权衡和试错类的游戏 - 这不是一个配方和食谱严格确定你所需要的确切的科学。

0

如果这是严格的报告数据库,并且您需要性能,请考虑转移到数据仓库设计。在报告时,即使是非规范化的关系设计,明星或雪花模式也会表现优异。