3

我目前正在努力提高 Microsoft SQL Server 2008 R2 的性能。在分析查询时，Microsoft Database Engine Tuning Tool 会使用此查询创建索引：

CREATE NONCLUSTERED INDEX [samplelocation1] ON [dbo].[sample_location]  
(
    [sample_id] ASC,
    [sample_code] ASC
) WITH (SORT_IN_TEMPDB = OFF, IGNORE_DUP_KEY = OFF, DROP_EXISTING = OFF, ONLINE = OFF) ON [PRIMARY]

这将使用从备份恢复的数据库在测试服务器（运行相同版本的 SQL Server，2008 R2）上执行查询的时间从 17 秒缩短到 5 秒。

然而，在生产服务器上，执行时间从 17 秒增加到 1 分 40 秒。这是怎么回事？

查询：

select * 
from sample_view  
where version_date >= '<date>' 
  and version_date - 0.9999999 <= '<date>' 
  and (cus_id in (select company_id 
                  from company_emp_relation_view 
                  where user_id = '<userid>') 
       or 
       fac_id in (select company_id 
                  from company_emp_relation_view 
                  where user_id = '<userid>'))  
  and sample_code in (select min(sample_code)  
                      from sample_location 
                      group by sample_id) 
  and (rfq_status<>'I') 
  and location <> 'D'  
order by 
  version_date desc

该查询不是我编写的，看起来过于复杂，但我想在不更改任何查询的情况下解决这个问题。我最大的惊喜是索引的效果在不同系统之间是不一样的。

4

2 回答 2

2

好吧，您的测试与生产系统上的数据量和分布可能完全不同 - 因此，您在具有几百行的测试系统上确定的任何内容可能在具有数百行的生产系统上的工作方式不同数千行..

数据的数量和分布是查询优化器如何决定是否使用索引（或者只是进行表扫描）的关键因素。因此，必须对实际数据（或其副本）执行任何性能调整——而不是在只有一小部分数据的“虚拟”开发或测试系统上执行......

于 2012-11-28T05:46:51.257 回答
0

你可以使用分析器和 DTA ，它会给出建议以包含索引。

解决您的问题首先检查列 version_date ， user_id 的索引没有。如果已经存在索引，那么您必须确定索引的碎片级别。如果碎片在 5% 到 30% 之间，那么你必须重新组织索引，如果碎片超过 30%，那么你必须重建索引。

检查fragmentaion 转到所需的表并转到索引-> rc on ur index name--> properties--> fragmentaion

如果您的表或视图不包含任何索引，请尝试创建一个聚集索引，然后创建非聚集索引。

于 2012-11-28T05:49:44.767 回答