实战：上亿数据如何秒查？

                                            实战：上亿数据如何秒查？

作者：杭伟
原文：http://www.cnblogs.com/hangwei/p/4399238.html

数据背景

首先，项目是西门子中国在我司实施部署的MES项目，由于项目是在产线上运作(3 years+)，数据累积很大。在项目的数据库中，大概上亿条数据的表有5个以上，千万级数据的表10个以上，百万级数据的表，很多...

(历史问题，当初实施无人监管，无人监控数据库这块的性能问题。ps:我刚入职不久...)不多说，直接贴西门子中国的开发人员在我司开发的SSRS报表中的SQL语句：

select distinct b.MaterialID as matl_def_id, c.Descript, case when right(b.MESOrderID, 12) < '001000000000' then right(b.MESOrderID, 9)  
else right(b.MESOrderID, 12) end  as pom_order_id, a.LotName, a.SourceLotName as ComLot, 
e.DefID as ComMaterials, e.Descript as ComMatDes, d.VendorID, d.DateCode,d.SNNote, b.OnPlantID,a.SNCUST
from  
(
    select m.lotname, m.sourcelotname, m.opetypeid, m.OperationDate,n.SNCUST from View1 m
    left join co_sn_link_customer as n on n.SNMes=m.LotName
    where 
    ( m.LotName in (select val from fn_String_To_Table(@sn,',',1)) or (@sn) = '') and 
    ( m.sourcelotname in (select val from fn_String_To_Table(@BatchID,',',1)) or (@BatchID) = '')
    and (n.SNCust like '%'+ @SN_ext + '%' or (@SN_ext)='')
) a
left join 
(
    select * from Table1 where SNType = 'IntSN'
    and SNRuleName = 'ProductSNRule'
    and OnPlantID=@OnPlant
) b on b.SN = a.LotName
inner join MMdefinitions as c on c.DefID = b.MaterialID
left join  Table1 as d on d.SN = a.SourceLotName 
inner join MMDefinitions as e on e.DefID = d.MaterialID
where not exists (
 select distinct LotName, SourceLotName from ELCV_ASSEMBLE_OPS 
where LotName = a.SourceLotName and SourceLotName = a.LotName
) 
and (d.DateCode in (select val from fn_String_To_Table(@DCode,',',1)) or (@DCode) = '')
and (d.SNNote  like '%'+@SNNote+'%' or (@SNNote) = '')
and ((case when right(b.MESOrderID, 12) < '001000000000' then right(b.MESOrderID, 9)  
else right(b.MESOrderID, 12) end) in (select val from fn_String_To_Table(@order_id,',',1)) or (@order_id) = '')
and (e.DefID in (select val from fn_String_To_Table(@comdef,',',1)) or (@comdef) = '')

--View1是一个嵌套两层的视图(出于保密性，实际名称可能不同)，里面有一张上亿数据的表和几张千万级数据的表做左连接查询
--Table1是一个数据记录超过1500万的表

这个查询语句，实际上通过我的检测和调查，在B/S系统前端已无法查出结果，半小时，一小时 ... 。因为我直接在SQL查询分析器查，半小时都没有结果。

(原因是里面对一张上亿级数据表和3张千万级数据表做全表扫描查询)不由感慨，西门子中国的素质(或者说责任感)就这样？

下面说说我的分析和走的弯路(思维误区)，希望对你也有警醒。

探索和误区

首先相关表的索引，没有建全的，把索引给建上。

索引这步完成后，发现情况还是一样，查询速度几乎没有改善。后来想起相关千万级数据以上的表，都还没有建立表分区。于是考虑建立表分区以及数据复制的方案。

这里有必要说明下：我司报表用的是一个专门的数据库服务器，数据从产线订阅而来。就是常说的“读写分离”。

如果直接在原表上建立表分区，你会发现执行表分区的事物会直接死锁。原因是：表分区操作本身会锁表，产线还在推数据过来，这样很容易“阻塞”，“死锁”。

我想好的方案是：建立一个新表(空表)，在新表上建好表分区，然后复制数据过来。

正打算这么干。等等！我好像进入了一个严重的误区！

分析： 原SQL语句和业务需求，是对产线的数据做产品以及序列号的追溯，关键是查询条件里没有有规律的"条件"(如日期、编号)，贸然做了表分区，在这里几乎没有意义！反而会降低查询性能！

好险！还是一步一步来，先做SQL语句分析。

一. 对原SQL语句的分析

1. 查询语句的where条件，有大量@var in ... or (@var ='') 的片段

2. where条件有like '%'+@var+'%'

3. where条件有 case ... end 函数

4. 多次连接同一表查询，另外使用本身已嵌套的视图表，是不是必须，是否可替代？

5. SQL语句有*号，视图中也有*号出现

二. 优化设计

首先是用存储过程改写，好处是设计灵活。

核心思想是：用一个或多个查询条件(查询条件要求至少输入一个)得到临时表，每个查询条件如果查到集合，就更新这张临时表，最后汇总的时候，只需判断这个临时表是否有值。以此类推，可以建立多个临时表，将查询条件汇总。

　　

这样做目前来看至少两点好处：

1.省去了对变量进行 =@var or (@var='')的判断；

2.抛弃sql拼接，提高代码可读性。

再有就是在书写存储过程，这个过程中要注意：

1. 尽量想办法使用临时表扫描替代全表扫描；

2. 抛弃in和not in语句，使用exists和not exists替代；

3. 和客户确认，模糊查询是否有必要，如没有必要，去掉like语句；

4. 注意建立适当的，符合场景的索引；

5. 踩死 "*" 号；

6. 避免在where条件中对字段进行函数操作；

7. 对实时性要求不高的报表，允许脏读(with(nolock))。

三. 存储过程

如果想参考优化设计片段的详细内容，请参阅SQL代码：

由于代码部分太长，本文长度限制，请到http://www.cnblogs.com/hangwei/p/4399238.html查看

虽然牺牲了代码的可读性，但创造了性能价值。本人水平有限，还请各位不吝赐教！

最后，将SSRS报表替换成此存储过程后，SQL查询分析器是秒查的。B/S前端用时1~2秒！

四. 总结

平常的你是否偶尔会因急于完成任务而书写一堆性能极低的SQL语句呢？写出可靠性能的SQL语句不难，难的是习惯。

本文的优化思想很简单，关键点是避免全表扫描 & 注重SQL语句写法 & 索引，另外，如果你查询的表有可能会在查询时段更新，而实际业务需求允许脏读，可加with(nolock)预防查询被更新事物阻塞。

版权申明：内容来源网络，版权归原创者所有。除非无法确认，我们都会标明作者及出处，如有侵权烦请告知，我们会立即删除并表示歉意。谢谢。

-END-