SQL性能优化其实没那么复杂，掌握几个技巧就能明显提升效率

SQL性能优化听起来很高深,但其实核心就是让数据库少干活、干快活，你不需要成为数据库专家，只要注意几个常见的地方，效率就能立竿见影，很多经验都来自像《高性能MySQL》这样的经典书籍，以及一线工程师们的实践总结。

最有效的就是用好索引,你可以把索引想象成书本的目录，如果你要在一本没有目录的百科全书里找某个特定内容，只能一页一页翻，这就是“全表扫描”，非常慢，而索引就是帮数据库快速定位数据的“目录”，索引不是越多越好，因为它就像书的目录，每增加一个目录也要占页数（磁盘空间），并且增加新内容时维护目录也需要时间（影响写入速度），关键是在经常用来查询、排序或分组的列上建立索引，你经常用用户ID来查订单，那就在订单表的用户ID这一列加索引，但要注意，如果某个列只有“男”、“女”两种值，建索引的意义就不大，因为数据库通过索引定位后，仍然要处理大量数据，根据《数据库系统概念》中的观点，索引的选择性越高，其价值越大。

要小心编写你的查询语句,避免让数据库做无用功，一个常见的大坑是SELECT *，它会把所有列的数据都捞出来，哪怕你只需要两列，这不但增加了数据库的传输负担，还可能迫使数据库去读取更多的数据页，老老实实写上你需要的具体列名，另一个大问题是滥用子查询，尤其是那种返回结果集很大的、或者被重复执行的子查询，很多情况下，你可以把它改成JOIN连接，因为数据库优化器对JOIN的优化通常更成熟，你想找出没有下过订单的用户，用NOT IN子查询可能会让数据库对子查询结果进行多次全表扫描，而改用LEFT JOIN并筛选出连接结果为NULL的记录，效率往往会高很多，这个技巧在《SQL反模式》这本书里被反复强调。

第三,注意分页查询的优化，很多人做分页就是LIMIT 10000, 20，意思是跳过前1万条，取20条，数据库的执行方式是先取出10020条数据，然后扔掉前1万条，再把最后20条给你，当偏移量很大时，这个“扔掉”的动作成本极高，一个实用的技巧是使用“游标分页”或者叫“seek method”，你上次看到的最大ID是10000，那么下一页就是WHERE id > 10000 LIMIT 20，这样数据库直接用索引定位到ID>10000的位置，取20条就行，效率天壤之别，这个方法是数据库专家丹尼斯·卡特（Dennis Carter）等人在技术博客中经常推荐的。

第四,学会利用数据库的“执行计划”，大部分数据库都提供EXPLAIN（在MySQL中）或EXPLAIN ANALYZE（在PostgreSQL中）这样的命令，它不会真正执行你的SQL，而是会告诉你数据库打算怎么执行它：用哪个索引、要不要全表扫描、怎么连接表，你看不懂那些复杂的专业术语没关系，重点关注它是否提示了“全表扫描”（Full Table Scan）或者“文件排序”（Using filesort），这些通常是性能瓶颈的信号，通过调整你的查询语句或索引，让执行计划里的“全表扫描”消失，你的查询速度基本就能大幅提升，这个工具是数据库留给你的“性能诊断器”，一定要用起来。

理解数据库的设计也至关重要,表结构设计得不合理，后期再怎么优化SQL也事倍功半，把经常要一起查询的字段放在一张表里（适度反范式化），避免频繁的跨表连接，再比如，对于像“状态”这种值很少的字段，如果数据量极大且查询频繁，有时使用枚举类型或甚至分表存储，可能比加索引更有效，这些设计思想在马丁·福勒（Martin Fowler）的《企业应用架构模式》中有相关讨论。

SQL性能优化并不神秘,核心就是：用索引快速定位，写查询直奔主题，分页时避免大偏移，用执行计划查看数据库的“想法”，并在设计之初就考虑效率问题，坚持从这些实际的地方入手，你就能解决大部分常见的性能瓶颈。