做数据库运维这些年，最怕半夜接到电话说系统卡死了。排查SQL性能瓶颈这事儿，说白了就是个经验活。你翻那些官方文档，动不动就是几百页的理论，可真正到生产环境出问题的时候，哪有时间从头翻书？今天我就把自己踩过的坑、试过的招儿整理出来，5个技巧，不求多，但求实用。
第一个技巧：学会用EXPLAIN读懂执行计划。很多新手查慢查询，上来就盯着SQL语句本身改，其实90%的问题都出在执行计划上。你写个SELECT FROM orders WHERE status = 1，看着挺简单，可数据库实际怎么跑的？是全表扫描还是走索引？用没用到临时表？这些信息全藏在EXPLAIN的输出里。我习惯先看type这一列，如果是ALL，那就意味着全表扫描，十有八九要出事。这时候别急着改SQL，先看看表结构，是不是缺了索引。我记得有次排查一个报表查询，慢到30秒才出结果，一看执行计划，type是ALL，rows显示要扫描800万行。加了个联合索引后，直接降到0.3秒。
第二个技巧：别迷信索引，更要会看索引的“性价比”。很多人一听性能差，第一反应就是加索引，可索引不是越多越好。写操作频繁的表，每多一个索引，插入和更新就要多维护一棵B+树。我见过最夸张的例子，一张表30个字段，建了25个索引，结果每次插入数据要花2秒钟。更坑的是，有些索引建了根本用不上。你可以在慢查询日志里抓几条典型的SQL，用EXPLAIN看看实际走了哪个索引。有时候数据库优化器会选错索引，这时候可以用FORCE INDEX强制指定。但记住，这是临时方案，根本解决办法是删掉那些冗余索引，重新设计合理的索引策略。
第三个技巧：关注慢查询日志，但别只盯着执行时间。默认配置里，longquerytime设成10秒，这太宽松了。生产环境我通常会调到1秒甚至0.5秒。但光看时间还不够，还要看锁等待时间和返回行数。有些查询执行时间不长，可返回了10万行数据，前端根本用不完。这种问题根源在业务层，SQL写成了SELECT ，但页面只需要展示前20条。解决办法很简单，加上LIMIT分页，或者只查需要的字段。还有个常见陷阱：隐式类型转换。比如where条件写的是where userid = '123'，但userid字段是int类型，数据库就得把全表的数据类型转一遍，索引直接失效。
第四个技巧：学会用performanceschema和sys schema。MySQL 5.7以后自带的这两个工具，比你自己写脚本抓数据靠谱得多。sys schema里有个叫statementanalysis的表，直接按总执行时间排序，一眼就能看出哪些SQL是真正的“耗能大户”。还有个表叫ioglobalbyfilebybytes，能告诉你哪些数据文件读写最频繁。我处理过一个案例，业务反馈某个接口偶尔超时，查慢查询日志却找不到规律。后来用performanceschema一查，发现是磁盘IO在高峰期出现瓶颈，某个索引文件频繁被读写。调整了innodbbufferpool_size，把热点数据尽量留在内存里，问题就解决了。
第五个技巧：分区表不是万能药，用不好反而更慢。大表分区确实能提升查询性能，但前提是查询条件能精确匹配到分区键。我见过有人把订单表按年份分区，结果查询条件里没带年份，全表扫描不说，还多了个合并分区的开销。更坑的是，分区表对DDL操作有诸多限制，比如不能直接加全局唯一索引。如果你的业务场景是频繁插入且很少删除，可以用分区表实现“数据归档”的效果：把旧分区直接DROP掉，比DELETE快得多。但如果是OLTP场景，表关联频繁，分区表带来的收益往往不如一个设计良好的索引来得实在。
说回开头那个问题，排查SQL性能瓶颈，真不是什么高深学问。关键是要有系统的方法论：先定位问题SQL，再分析执行计划，然后针对性优化索引或改写SQL，验证效果。这5个技巧，每一个都是我拿生产环境的血泪教训换来的。别指望看完一篇文章就能变成优化高手，但至少下次遇到慢查询，你知道该从哪里下手了。数据库优化的本质，就是理解数据是怎么存储的、怎么被访问的，然后想办法让这个过程更高效。就这么简单，也这么不简单。
