近在忙着优化集团公司的一个报表。优化完成后，报表查询速度有从半小时以上(甚至查不出)到秒查的质变。从修改SQL查询语句逻辑到决定创建存储过程实现，花了我3天多的时间，在此总结一下，希望对朋友们有帮助。
　　数据背景
　　首先项目是西门子中国在我司实施部署的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语句分析。