实战上亿数据如何秒查.docxVIP

实战：上亿数据如何秒查 最近在忙着优化集团公司的一个报表。优化完成后， 报表查询速度有从半小时以上(甚至查不出)到秒查的质变。 从修改 SQL 查询语句逻辑到决定创建存储过程实现，花了 我 3 天多的时间，在此总结一下，希望对朋友们有帮助。 数据背景首先项目是西门子中国在我司实施部署的 MES 项 目，由于项目是在产线上运作(3 years+)，数据累积很大。 在项目的数据库中，大概上亿条数据的表有 5 个以上，千 万级数据的表 10 个以上，百万级数据的表，很多...(历史问 题，当初实施无人监管，无人监控数据库这块的性能问题。 ps:我刚入职不久...)不多说，直接贴西门子中国的开发人员 在我司开发的 SSRS 报表中的 SQL 语句： View Code 这个 查询语句，实际上通过我的检测和调查，在 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 代码： 1 /** * 某某跟踪报表 **/ --exec spName1 ,,,,,,公司代号 CREATE Procedure spName1 @MESOrderID nvarchar(320), --工单号,最多 30 个 7 @LotName nvarchar(700), --产品序列号,最多 50 个 @DateCode nvarchar(500), --供应商批次号,最多 30 个 @BatchID nvarchar(700), --组装件序列号/物料 批号,最多 50 个 @comdef nvarchar(700), --组装件物料编码,最 多 30 个 @SNCust nvarchar(1600), --外部序列号,最多 50 个 @OnPlant nvarchar(20) --平台 AS BEGIN SET NOCOUNT ON; /** * 1)定义全局的临时表，先根据六个查询条件的 任意一个，得出临时表结果 **/ CREATE TA