文章转载自「开发者圆桌」一个关于开发者入门、进阶、踩坑的微信公众号
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优化都会不断提升你的优化能力和思考方式。