SQL性能优化-查询条件与字段分开执行，union代替in与or，存储过程代替union

PS：概要、背景、结语都是日常“装X”，可以跳过直接看优化历程

环境：SQL Server 2008 R2、阿里云RDS；辅助工具：SQL 审计

概要

　　一个订单列表分页查询功能，单从SQL性能来讲，从几十万数据量时，适当加一些索引随便写SQL；到百来万数据量时，需要做一些SQL语句优化；再到几百万上千万的数据量情况下，很多意想不到的情况就出现了（在大部分中小公司没有专业DBA的情况下，“万能”的研发就得顶上去了）。

背景

　　进入公司后，系统已经初具规模，已有成型的框架。随着业务的不断增长，系统功能的不断增加，一些性能问题开始涌现出来。
　　以下订单列表查询页面的优化历程，有幸参与了整个过程，以前做研发或项目管理的时候，整天扑在功能开发上，很难有时间去深入研究一些比较难解决的问题。现在做团队管理，反而有更多的时间让我来思考与总结，以下的每一步优化其实都不是一开始就想到的，而是经过无数次的摸索以及线上测试验证，最终找到合适于现阶段的优化方案。
　　本人非专业DBA，目前的岗位是研发管理，园友们如果有更好的解决方案欢迎讨论。当然我们也有想过一些更彻底的解决方案，我会在第五部分进行描述，如：冗余数据、数据库分区、分表、分库等，但受制于研发资源、开发周期等只能搁置。从公司的角度来讲，永远都是用最小的成本去实现最大的价值。

优化历程

　　以下所有“执行统计信息”都是在现有的数据量情况下，且所有条件都是页面默认打开的情况下(订单主表大概1千万左右，其他附属表最大1亿左右，以下所有表名、字段名都替换过且有些删减)。统计信息限于篇幅，只贴出了执行时间，具体分析用的扫描次数、逻辑读次数就没贴了，时间只是其中一个参考值，扫描次数，逻辑读次数也是很重要的参考值。

　　（一）、一条SQL语句实现查询条件，返回字段
　　　　1、查询总记录数：

    具体SQL如下：select sum(a) from (select 1 a from (SELECT DISTINCT *,(SELECT '@#@#@' + rtrim (pd.Remark) FROM dbo.wf_pda pd WHERE pd.ProcessID=temp.ProcessID AND pd.ActID=-2 FOR XML PATH('')) AS BackReasonFROM (SELECT tpo.OrderNo,emark.Remark,finance.a,sup.b,ph.c,ph.ProcessID,re.d,tpro.eFROM dbo.tp_orderMain tpo INNER JOIN dbo.tp_remark remark ON tpo.OrderNo = remark.OrderNoINNER JOIN dbo.tp_finance finance ON tpo.OrderNo = finance.OrderNoINNER JOIN dbo.tp_tpro tpro ON tpo.OrderNo = tpro.OrderNoLEFT JOIN dbo.wf_reph ph ON tpo.OrderNo=ph.WareCodeLEFT JOIN dbo.tp_re re ON tpo.OrderNo=re.OrderNoLEFT JOIN dbo.tp_sup sup ON tpo.OrderNo = sup.OrderNoINNER JOIN dbo.com_juris AS juris ON juris.UserId = '200000' AND juris.CompanyId = tpo.ClientCode WHERE tpo.OpDate BETWEEN '2018-06-28' AND '2018-07-06'             ) AS temp ) as temps where 1=1            ) p执行统计信息：SQL Server parse and compile time: CPU time = 421 ms, elapsed time = 439 ms.SQL Server Execution Times:CPU time = 71621 ms,  elapsed time = 111959 ms.

　　　　2、查询第一页订单信息

    具体SQL如下：SELECT * FROM (select ROW_NUMBER() Over(ORDER BY temps.OpDate) as RowId,*from (        SELECT DISTINCT *,(SELECT '@#@#@' + rtrim (pd.Remark) FROM dbo.wf_pda pd WHERE pd.ProcessID=temp.ProcessID AND pd.ActID=-2 FOR XML PATH('')) AS BackReasonFROM (SELECT tpo.OrderNo,emark.Remark,finance.a,sup.b,ph.c,ph.ProcessID,re.d,tpro.eFROM dbo.tp_orderMain tpo INNER JOIN dbo.tp_remark remark ON tpo.OrderNo = remark.OrderNoINNER JOIN dbo.tp_finance finance ON tpo.OrderNo = finance.OrderNoINNER JOIN dbo.tp_tpro tpro ON tpo.OrderNo = tpro.OrderNoLEFT JOIN dbo.wf_reph ph ON tpo.OrderNo=ph.WareCodeLEFT JOIN dbo.tp_re re ON tpo.OrderNo=re.OrderNoLEFT JOIN dbo.tp_sup sup ON tpo.OrderNo = sup.OrderNoINNER JOIN dbo.com_juris AS juris ON juris.UserId = '200000' AND juris.CompanyId = tpo.ClientCode WHERE tpo.OpDate BETWEEN '2018-06-28' AND '2018-07-06'             ) AS temp ) as temps where 1=1) as temp_table_temp where RowId between 1 and 10　　执行统计信息：SQL Server parse and compile time: CPU time = 1092 ms, elapsed time = 1122 ms.SQL Server Execution Times:CPU time = 36223 ms,  elapsed time = 45982 ms.

　　　　小结：

　　　　　　在最开始的时候，很常见的写法就是一条SQL、加一些合适的索引，就实现所有功能，在数据量小的情况其实是最优的，甚至索引都是越少越好，因为索引越多插入更新的速度会更慢。但在现有的数据量的情况下，已经完全无法接受了，我们抛开编译时间，查询总记录数耗时111.9秒，查询第一页耗时45.9秒。
　　　　　　这是我们3年前的实现方式，当时也是因为数据量的增长，查询慢，通过不断的测试，最后有了第二部分。

　　（二）、SQL拆分：先查询满足条件的订单号、再根据订单号查询数据(in)

　　　　1、查询总记录数：

    具体SQL如下：select sum(a) from (select 1 a from (SELECT tpo.OrderNo,tpo.OpDateFROM dbo.tp_orderMain tpo INNER JOIN dbo.com_juris AS juris ON juris.UserId = '200000' AND juris.CompanyId = tpo.ClientCode WHERE tpo.OpDate BETWEEN '2018-06-28' AND '2018-07-06') as temps where 1=1            ) p　　执行统计信息：SQL Server parse and compile time: CPU time = 0 ms, elapsed time = 27 ms.SQL Server Execution Times:CPU time = 31 ms,  elapsed time = 124 ms.

　　　　2、查询第一页订单号

    具体SQL如下：SELECT * FROM (select ROW_NUMBER() Over(ORDER BY temps.OpDate) as RowId,*from (SELECT tpo.OrderNo,tpo.OpDateFROM dbo.tp_orderMain tpo INNER JOIN dbo.com_juris AS juris ON juris.UserId = '200000' AND juris.CompanyId = tpo.ClientCode WHERE tpo.OpDate BETWEEN '2018-06-28' AND '2018-07-06') as temps where 1=1        ) as temp_table_temp where RowId between 1 and 10　　执行统计信息：SQL Server parse and compile time: CPU time = 0 ms, elapsed time = 4 ms.SQL Server Execution Times:CPU time = 0 ms,  elapsed time = 0 ms.

　　　　3、根据订单号查询信息

    具体SQL如下：SELECT *,(SELECT '@#@#@' + rtrim (pd.Remark) FROM dbo.wf_pda pd WHERE pd.ProcessID=temp.ProcessID AND pd.ActID=-2 FOR XML PATH('')) AS BackReasonFROM (SELECT tpo.OrderNo,emark.Remark,finance.a,sup.b,ph.c,ph.ProcessID,re.d,tpro.eFROM dbo.tp_orderMain tpo INNER JOIN dbo.tp_remark remark ON tpo.OrderNo = remark.OrderNoINNER JOIN dbo.tp_finance finance ON tpo.OrderNo = finance.OrderNoINNER JOIN dbo.tp_tpro tpro ON tpo.OrderNo = tpro.OrderNoLEFT JOIN dbo.wf_reph ph ON tpo.OrderNo=ph.WareCodeLEFT JOIN dbo.tp_re re ON tpo.OrderNo=re.OrderNoLEFT JOIN dbo.tp_sup sup ON tpo.OrderNo = sup.OrderNoINNER JOIN dbo.com_juris AS juris ON juris.UserId = '200000' AND juris.CompanyId = tpo.ClientCode where tpo.OrderNo IN ('10001','10002','10003','10004','10005','10006','10007','10008','10009')  ) AS temp ORDER BY temp.OpDate DESC执行统计信息：SQL Server parse and compile time: CPU time = 46 ms, elapsed time = 59 ms.Table 'tp_orderMain '. Scan count 16, logical reads 617278, physical reads 0, read-ahead reads 0, lob logical reads 0, lob physical reads 0, lob read-ahead reads 0.Table 'tp_re'. Scan count 8, logical reads 37312, physical reads 0, read-ahead reads 0, lob logical reads 0, lob physical reads 0, lob read-ahead reads 0.SQL Server Execution Times:CPU time = 2044 ms,  elapsed time = 2075 ms.

　　　　小结：

　　　　　　从上面的结果可以看出来，获取订单总记录数、获取第一页的订单信息总时间在150毫秒左右就可以查出来，不过在根据订单号in查询订单信息的时候，发现耗时2秒。细心的园友应该也发现我在这个“统计信息”里面多复制了一些东西，有两个表的扫描次数、逻辑读次数都不正常，其中主表617278次，导致总耗时2秒。但这条语句最特殊的是不同的订单号执行结果完全不一样，我开始以为是订单号跨度越大越慢(我的猜测依据是订单号是主键且升序排列)，但在我测试的过程中发现完全没有规律，甚至在我查8条记录的情况下，耗时2秒(执行多次结果一致)，我再随便找2个17年的订单号一起查询，结果可以几十毫秒出来。我们通过SQL审计发现至少有一半以上该语句执行时间在1-2秒，甚至有一些达到3-4秒，不稳定（一直没有找到原因，现在只是找了替代方法满足了稳定了性能，参考第三，第四部分）。
　　　　　　这种写法是3年前我们优化的结果，在当时的执行统计信息不是今天这样的结果，基本可以在几百毫秒完成查询，运行到前段时间基本也没有用户再抱怨此功能慢的问题。但最近又开始陆续有用户抱怨这里慢的问题，我们通过SQL审计发现3年前很“优秀”的SQL，现在不灵了，性能不稳定。
　　　　　　下面先分析一下这种写法：
　　　　　　　　1、可以看出来，把显示字段跟查询条件分开后，查询的时候关联的表大大减少，大大提高的索引查询、分页查询的速度；
　　　　　　　　2、而在需要关联多个表查询显示字段时，已经是聚焦索引查找了，在正常情况下基本可以毫秒级的完成；

　　（三）、用union代替in与or

　　　　查询总记录数、第一页的订单号跟第二部分是一样的，没变。

　　　　3、根据订单号查询信息

　　具体SQL如下（PS：因为SQL但长，只列了前2条）：SELECT *,(SELECT '@#@#@' + rtrim (pd.Remark) FROM dbo.wf_pda pd WHERE pd.ProcessID=temp.ProcessID AND pd.ActID=-2 FOR XML PATH('')) AS BackReasonFROM (SELECT tpo.OrderNo,emark.Remark,finance.a,sup.b,ph.c,ph.ProcessID,re.d,tpro.eFROM dbo.tp_orderMain tpo INNER JOIN dbo.tp_remark remark ON tpo.OrderNo = remark.OrderNoINNER JOIN dbo.tp_finance finance ON tpo.OrderNo = finance.OrderNoINNER JOIN dbo.tp_tpro tpro ON tpo.OrderNo = tpro.OrderNoLEFT JOIN dbo.wf_reph ph ON tpo.OrderNo=ph.WareCodeLEFT JOIN dbo.tp_re re ON tpo.OrderNo=re.OrderNoLEFT JOIN dbo.tp_sup sup ON tpo.OrderNo = sup.OrderNoINNER JOIN dbo.com_juris AS juris ON juris.UserId = '200000' AND juris.CompanyId = tpo.ClientCode where tpo.OrderNo = '10002') AS temp UNIONSELECT *,(SELECT '@#@#@' + rtrim (pd.Remark) FROM dbo.wf_pda pd WHERE pd.ProcessID=temp.ProcessID AND pd.ActID=-2 FOR XML PATH('')) AS BackReason  --订单回滚原因FROM (SELECT tpo.OrderNo,emark.Remark,finance.a,sup.b,ph.c,ph.ProcessID,re.d,tpro.eFROM dbo.tp_orderMain tpo INNER JOIN dbo.tp_remark remark ON tpo.OrderNo = remark.OrderNoINNER JOIN dbo.tp_finance finance ON tpo.OrderNo = finance.OrderNoINNER JOIN dbo.tp_tpro tpro ON tpo.OrderNo = tpro.OrderNoLEFT JOIN dbo.wf_reph ph ON tpo.OrderNo=ph.WareCodeLEFT JOIN dbo.tp_re re ON tpo.OrderNo=re.OrderNoLEFT JOIN dbo.tp_sup sup ON tpo.OrderNo = sup.OrderNoINNER JOIN dbo.com_juris AS juris ON juris.UserId = '200000' AND juris.CompanyId = tpo.ClientCode where tpo.OrderNo = '10003') AS temp 　　执行统计信息：SQL Server parse and compile time: CPU time = 967 ms, elapsed time = 1023 ms.SQL Server Execution Times:CPU time = 32 ms,  elapsed time = 22 ms.

　　　　小结：

　　　　　　在实验了很多种写法，临时表，表变量，Wtih等后，还是没法稳定性能，在慢的那几个订单号面前，依旧兵败如山倒。当然我们也有想过可能是索引出了问题，需要重建或碎片整理，但对于投产的库，没有十足的把握，以及成熟的方案情况下，不敢去实施。
　　　　　　一个偶然的机会，我拿一个订单号做实验发现很快，于是想到了union，动手测试发现每一条不同SQL第一次的编译时间为1秒左右，执行时间只有22毫秒。真实情况下，每一次的订单号都不一样的，执行总时间基本都会在1.1秒左右，超出我们的期望值，且SQL语句太长，不直观。这个方案其实是没有在我们的生产环境最终实施的，只是一个中间方案，不过它给了我一个方向，单订单号的情况执行性能很稳定，那现在唯一要解决的就是编译时间的问题，要减少编译时间那基本就想到存储过程了。

　　（四）、用存储过程代替union

　　　　存储过程创建：

    CREATE PROCEDURE [dbo].[pro_OrderList_Select]@OrderNo VARCHAR(50)ASBEGIN SELECT *,(SELECT '@#@#@' + rtrim (pd.Remark) FROM dbo.wf_pda pd WHERE pd.ProcessID=temp.ProcessID AND pd.ActID=-2 FOR XML PATH('')) AS BackReasonFROM (SELECT tpo.OrderNo,emark.Remark,finance.a,sup.b,ph.c,ph.ProcessID,re.d,tpro.eFROM dbo.tp_orderMain tpo INNER JOIN dbo.tp_remark remark ON tpo.OrderNo = remark.OrderNoINNER JOIN dbo.tp_finance finance ON tpo.OrderNo = finance.OrderNoINNER JOIN dbo.tp_tpro tpro ON tpo.OrderNo = tpro.OrderNoLEFT JOIN dbo.wf_reph ph ON tpo.OrderNo=ph.WareCodeLEFT JOIN dbo.tp_re re ON tpo.OrderNo=re.OrderNoLEFT JOIN dbo.tp_sup sup ON tpo.OrderNo = sup.OrderNoINNER JOIN dbo.com_juris AS juris ON juris.UserId = '200000' AND juris.CompanyId = tpo.ClientCode where tpo.OrderNo = @OrderNo                ) AS temp ENDGO

　　　　3、根据订单号查询信息

    具体SQL如下（使用.net的DataSet获取多行数据）

　　　　EXEC pro_OrderList_Select @OrderNo = '10002'　　　　EXEC pro_OrderList_Select @OrderNo = '10003'　　执行统计信息：由于是分开执行，执行计划太多，我只列其中第四部分有问题的那个表的信息，执行总时间通过客户端统计信息查看，平均在100毫秒左右。Table 'tp_orderMain'. Scan count 2, logical reads 14, physical reads 0, read-ahead reads 0, lob logical reads 0, lob physical reads 0, lob read-ahead reads 0.Table 'tp_re'. Scan count 0, logical reads 4, physical reads 0, read-ahead reads 0, lob logical reads 0, lob physical reads 0, lob read-ahead reads 0.

　　　　小结：

　　　　　　存储过程的最大优点就是它是预编译的，编译时间短，我们这次也是充分利于它的优点。把单条订单信息查询创建一个存储过程，然后定义一个表变量，把从存储过程中查询的信息插入表变量中，再查询表变量。总执行时间基本稳定在100毫秒左右，总算是解决了问题。
　　　　　　接下来我们来说说存储过程的缺点：维护成本高，版本控制不方便，并且对于数据库来说，要尽量减少业务逻辑，因为对于增加程序服务器是很容易的，增加一台服务器做负载均衡即可。但数据库虽然你可以加很多从库，但在没有分库策略的情况下，主库还是只有一个，所以我们的代码规范里面有一条就是禁止使用存储过程。通过跟架构师讨论，最后决定为了解决性能问题，放开了使用存储过程的限制，但只允许用于此类列表查询用，其他功能依旧不允许使用存储过程。

　　（五）、更高一层次的，冗余数据，分区，分表，分库

　　　　冗余数据：针对列表显示字段，涉及一对多关系的表，使用冗余字段保存起来；
　　　　分区：分区需要对每条SQL进行特定优化，要保证大部分查询都在一个分区内解决，不然可能比没分区之前更慢。
　　　　分表，分库，跟分区类似，只是更彻底，对于一个已经成熟且规模庞大的系统，无论是风险还是工作量，都是巨大的，相当于小重构。
　　　　当然，未来随着业务量的增长，可能有一天会去做这件事情，不过可能那时会是整个系统的重构，因为一些历史遗留问题，系统拆分不合理，这个订单处理系统已经不堪负重了。

结语

　　任何一个系统的完善都不是一蹴而就的，以上优化其实历时3年，都是在系统运行过程中，业务量的不断增长，性能问题开始突显，以及对系统要求的不断提高，而驱动研发去不断的优化。每个阶段优化的方案也有所不同，最好的不一定是最优的，找合适系统现阶段发展的才是最优的。这是一个系统不断优化的过程，也是整个团队能力不断提升的过程。

转载于:https://www.cnblogs.com/tihb666/p/9274611.html

SQL性能优化-查询条件与字段分开执行，union代替in与or，存储过程代替union相关推荐

SQL性能优化技巧，常见优化10经验，数据库查询好慢，还能怎么办
我熟练应用ctrl c和ctrl v 开发curd代码好多年了. mysql查询为什么会慢,关于这个问题,在实际开发经常会遇到,而面试中,也是个高频题. 遇到这种问题,我们一般也会想到是因为索引. 那 ...
java mysql查询字段换行,java类中写sql语句，查询条件包含换行
java类中写sql语句,查询条件包含换行 detachedCriteria.add(Restrictions.or( Restrictions.like("chengBanDanWeiId ...
ORACLE+SQL性能优化
1. 访问Table的方式 ORACLE 采用两种访问表中记录的方式: a. 全表扫描全表扫描就是顺序地访问表中每条记录. ORACLE采用一次读入多个数据块(database block)的方 ...
高效sql性能优化极简教程
一,sql性能优化基础方法论对于功能,我们可能知道必须改进什么:但对于性能问题,有时我们可能无从下手.其实,任何计算机应用系统最终队可以归结为: cpu消耗内存使用对磁盘,网络或其他I/O设备的 ...
做 SQL 性能优化真是让人干瞪眼
很多大数据计算都是用 SQL 实现的,跑得慢时就要去优化 SQL,但常常碰到让人干瞪眼的情况. 比如,存储过程中有三条大概形如这样的语句执行得很慢: select a,b,sum(x) from T ...
如何进行正确的SQL性能优化
在SQL查询中,为了提高查询的效率,我们常常采取一些措施对查询语句进行SQL性能优化.本文我们总结了一些优化措施,接下来我们就一一介绍. 1.查询的模糊匹配尽量避免在一个复杂查询里面使用 LIKE ...
想让DBA瞬间崩溃，那就让他去做SQL性能优化
本文分享自华为云社区<做 SQL 性能优化真是让人干瞪眼>,作者: 石臻臻的杂货铺 . 很多大数据计算都是用 SQL 实现的,跑得慢时就要去优化 SQL,但常常碰到让人干瞪眼的情况. 比如 ...
Oracle的SQL性能优化
ORACLE SQL性能优化注意事项: select distinct 列, ... from tab 1 jon tab2 on () where ... group by ... havi ...
MySQL高性能实战——part3——分析SQL,定位慢SQL(性能优化的前提)
前言: 此文借鉴<MySQL高性能>一书,还有MySQL官方文档,笔者将通过自身的一些实战经验和阅读习惯对本书进行一个总结,整理,归纳出企业级开发中常用的优化案列和部分概念!! 官方文 ...

SQL性能优化-查询条件与字段分开执行，union代替in与or，存储过程代替union

SQL性能优化-查询条件与字段分开执行，union代替in与or，存储过程代替union相关推荐

最新文章

热门文章