让SQL再快一点儿

文章转载自「开发者圆桌」一个关于开发者入门、进阶、踩坑的微信公众号

SQL即结构化查询语言(Structured Query Language)，是一种特殊目的的编程语言，是一种数据库查询和程序设计语言，用于存取数据以及查询、更新和管理关系型数据库系统。

 

从接触编程到如今一直从事和数据库相关的工做，SQL是我使用时间最长的程序语言，没有之一。

 

关于SQL优化的文章网上不少，很具体，写的很不错，这里再也不赘述。这篇文章将会结合平时工做中遇到的问题和经验心得来阐述如何作好SQL优化，其中有错误和不足的地方，还请你们纠正补充。

 

对于数据库优化有两个层面，一是SQL优化，属于业务层优化；一是数据库设计、表空间规划、缓存等属于管理层面的优化，咱们这里只讨论SQL优化这个层面。

 

接受挑战

不要被运行效率低下或者复杂的SQL吓倒，要敢于接收它的挑战，问题很明确就是要把这个SQL优化快一点，解决方法确定比遇到的问题多。

 

越是运行慢，越是复杂的SQL优化的空间就越大。

 

分析场景

数据处理大体能够分红两大类：联机事务处理OLTP（on-line transaction processing）、联机分析处理OLAP（On-Line Analytical Processing）。OLTP是传统的关系型数据库的主要应用，主要是基本的、平常的事务处理，例如银行交易。OLAP是数据仓库系统的主要应用，支持复杂的分析操做，侧重决策支持，而且提供直观易懂的查询结果。 

 

OLTP 系统强调数据库内存效率，强调内存各类指标的命令率，强调绑定变量，强调并发操做，对于SQL的执行效率有很高的要求；

 

OLAP 系统则强调数据分析，强调SQL执行时机，强调磁盘I/O，强调分区等。

 

OLTP要求事务一致性和快速执行，SQL执行时间通常以毫秒或者秒为单位；OLAP对事务一致性要求不高，SQL执行时间以分钟或者小时为单位。所以，不一样的业务场景，SQL优化的方法也是不一样的。

 

定位SQL优化点

因为数据库产品、参数配置甚至同一款产品的不一样发行版本都会致使同一条SQL出现不一样的运行效率。随着业务数据的增加，本来运行良好的SQL也会出现瓶颈。

 

变化再多也有规律可循，SQL运行效率低根本的问题就是SQL表关联太多、SQL逻辑太复杂、表数据量太大、未使用索引等，这些就是咱们要优化的点。

 

拿到运行效率低的SQL之后，要分析一下该条SQL用到哪些表？哪些索引？表中的数据量是多少？对整个SQL运行的基础环境有一个清晰的认识。

 

优化SQL最经常使用的辅助工具就是数据库自己提供的“执行计划”，如何开启、使用执行计划分析和优化SQL，可点击文章最后左下角「阅读原文」查看以前整理的一篇关于《数据库SQL执行计划应用初探》的文章。

 

进行SQL优化

定位到SQL执行效率低下的缘由之后，要想办法优化它，下面是一些通用的处理思路，能够参考一二。

 

索引；索引是关系型数据库中SQL优化的利器，设计良好的索引以及在SQL中正确应用索引基本上能解决大部分的SQL优化问题。能够经过执行计划分析SQL中索引的应用状况。

 

变通；3+6与4+5的结果都是9，作事的方式并非惟一的，可能一种SQL写法效率很低，然而你换一个思路试试其余的写法，效率会有很大的提高，这个须要不断的尝试和摸索。

举个栗子，以Oracle为例查询公司男性与女性员工的薪资总和

select  

(select sum(salary) from employee where sex='男')  男性薪资总和,

(select sum(salary) from employee where sex='女')  女性薪资总和

from dual

更好的写法应该是

select

sum(case when sex='男' then salary else 0 end) 男性薪资总和,

sum(case when sex='女' then salary else 0 end) 女性薪资总和

from employee

 

我刚入门SQL时，就是采用了第一种写法，逻辑最简单明了，可是一个employee表却被扫描了两次（在没有索引的状况下），随着数据量的增长，这条SQL必然出现效率低的问题，第二种写法就会优化不少，效率更高。这是一个简单不能再简单的变通了（固然是如今看来，当时可能想不到）。

 

分解；把复杂的一条SQL能够拆解为多条简单SQL分步骤执行，可能你会以为分步骤执行作了不少额外的工做，可是每条简单的SQL执行的会很是快，总体上提高了SQL执行效率。

 

SQL分解最经常使用的就是建立中间表，中间表只保存须要的字段和数据行，同时增长必要的索引，可大大提高SQL的执行效率。

 

环境；SQL优化要在同一个环境中进行，不一样的环境中SQL执行路径多是不一样的，优化的方法也是不一样的。尽可能排除环境因素对SQL优化的影响。

 

经验；经验很重要，可是避免陷入经验主义。你可能在Oracle中有着很是丰富的SQL优化经验，可是在DB2数据库中可能就不灵了，不要纠结，这很正常。在我从Oracle数据库转向DB2数据库时就出现了不少问题，在Oracle中积累的经验转移到DB2中行不通，只能另辟蹊径。

 

SQL优化须要经验，可是不能太依赖经验，要不断调整本身的思路。每款数据库产品都有本身的特色，要了解它们，而后去不断应用。好在大部分的经验是通用的，只是略加调整便可，不要太大压力。

 

把平时优化SQL的技巧和方法总结下来，在真实的SQL优化场景中反复使用和调整，逐渐造成本身的一套优化经验。

 

总结

上面总结了一些我我的的SQL优化经验，包治百病的良药是不存在的，具体问题仍是须要当事人具体分析，优化思路是相通的。

 

SQL优化这事儿不须要刻意为之，当你写的SQL不知足业务要求时天然就要优化，每次的SQL优化都会不断提高你的优化能力和思考方式。