共计 2325 个字符，预计需要花费 6 分钟才能阅读完成。
这篇文章将为大家详细讲解有关如何让 SQL 再快一点儿，丸趣 TV 小编觉得挺实用的，因此分享给大家做个参考，希望大家阅读完这篇文章后可以有所收获。
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 再快一点儿”这篇文章就分享到这里了，希望以上内容可以对大家有一定的帮助，使各位可以学到更多知识，如果觉得文章不错，请把它分享出去让更多的人看到。
