我目前正在努力加快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]
这将使用从备份恢复的数据库从17秒到5秒来减少测试服务器(运行相同版本的SQL Server,2008 R2)上的查询的执行时间。
然而,在生产服务器上,执行时间从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
查询不是我写的,看起来过于复杂,但我想在不改变任何查询的情况下解决这个问题。我最大的惊喜是整个系统的索引效果并不相同。
答案 0 :(得分:2)
嗯,测试数据与生产系统的数量和分布可能完全不同 - 因此,您在测试系统上确定的几百行可能不在具有数十万行的生产系统上以相同的方式工作..
数据的数量和分布是查询优化器如何决定是否使用索引(或者只是执行表扫描)的关键因素。因此,任何性能调整必须对实际数据(或其副本)执行 - 而不是在“虚拟”开发或测试系统上只有一小部分数据......
答案 1 :(得分:0)
你可以使用探查器和DTA,它会提供建议以包含索引。
遇到问题首先检查列version_date,user_id的索引不是。如果有alredy索引,那么你必须确定索引的碎片级别。如果碎片在5到30%之间,那么你必须重新组织索引,如果碎片超过30%那么你必须重建索引。
检查片段 转到必需的表并转到索引 - &gt;你的索引名称上的rc - &gt;属性 - &GT; fragmentaion
如果ur表或视图不包含任何索引,请尝试创建一个聚簇索引,然后创建非聚簇索引。