记一次苦逼的Sql查询优化

最近在维护公司项目时，需要加载某页面，总共加载也就4000多条数据，竟然需要35秒钟，要是数据增长到40000条，我估计好几分钟都搞不定。卧槽，要我是用户的话估计受不了，趁闲着没事，就想把它优化一下，走你。

先把查询贴上：

select distinct  Pub_AidBasicInformation.AidBasicInfoId,

Pub_AidBasicInformation.UserName,

Pub_AidBasicInformation.District,

Pub_AidBasicInformation.Street,

Pub_AidBasicInformation.Community,

Pub_AidBasicInformation.DisCard,

Pub_Application.CreateOn AS AppCreateOn,

Pub_User.UserName as DepartmentUserName,

Pub_Consult1.ConsultId,

Pub_Consult1.CaseId,

Clinicaltb.Clinical,

cte3.AidName,

Pub_Application.IsUseTraining,

Pub_Application.ApplicationId,

tab.num

from   Pub_Consult1

INNER JOIN Pub_Application ON Pub_Consult1.ApplicationId = Pub_Application.ApplicationId

INNER JOIN Pub_AidBasicInformation ON Pub_Application.AidBasicInfoId = Pub_AidBasicInformation.AidBasicInfoId

INNER  JOIN(select ConsultId,dbo.f_GetClinical(ConsultId) as Clinical

from Pub_Consult1) Clinicaltb on Clinicaltb.ConsultId=Pub_Consult1.ConsultId

left join (select distinct ApplicationId, sum(TraniningNumber) as num from dbo.Review_Aid_UseTraining_Record

where  AidReferralId is null

group by  ApplicationId) tab

on tab.ApplicationId=Pub_Consult1.ApplicationId

left JOIN cte3 on cte3.ConsultId=Pub_Consult1.ConsultId

LEFT OUTER JOIN Pub_User ON Pub_Application.ReviewUserId = Pub_User.UserId

where Pub_Consult1.Directory = 0

order by Pub_Application.CreateOn desc

View Code

这样基本上就完事了，在没有建立索引的情况下需要8秒钟，比没索引用函数还是快了27秒。



把索引放进去，就只需1.6秒了，比建立索引用函数而不用子查询和sql for xml path快了1.9秒



查询里面还有个地方用了函数，估计再优化下还能提高执行效率，因为时间有限再加上篇幅有点长了，在这里就不多讲了。

最后做个总结吧，查询优化不外乎以下这几种办法：

1：增加索引或重建索引。通常在外键，连接字段，排序字段，过滤查询的字段建立索引，也可通过数据库引擎优化顾问提供的信息去建索引。有时候当你创建索引时，会发现查询还是按照索引扫描或聚集索引扫描的方式去执行，而没有去索引查找，这时很可能是你的查询字段和where条件字段没有全部包含在索引字段当中，解决这个问题的办法就是多建立索引，或者在创建索引时Include相应的字段，让索引字段覆盖你的查询字段和where条件字段。

2：调整查询语句，前提要先看懂别人的查询，搞清楚业务逻辑。

3：表分区，大数据量可以考虑。

4：提高服务器硬件配置。