网站后端响应延迟的原因大部分都来自于数据访问层。当接口耗时由几百毫秒上升到几秒的时候，应该首先检查的是数据库慢查询日志，而不是直接增加硬件资源。
慢查询日志的采集要先设置好合理的阈值。交易类接口把 long_query_time 控制在0.5秒以内，报表类可以放宽到2秒左右，并且打开未走索引语句的记录开关。日志文件本身没有可读性，需要用pt-query-digest或者类似的工具进行参数化聚合，按照“总耗时=单次耗时×执行次数”的顺序排列，把资源消耗最大的前十条语句模板提取出来。
进入分析阶段之后，对每一条候选语句进行 EXPLAIN 操作，主要关注三种信号：执行类型为全表扫描、索引键为空、额外信息中出现 Using filesort 或者 Using temporary。扫描行数与返回行数的比值越大，说明无效读取越严重，优化空间也越大。常见的根因有缺少联合索引、排序字段没有加入索引、深分页偏移量过大、查询列中包含大文本字段、条件列上嵌套函数导致索引失效等。
整改行动要遵循最小变更的原则。优先补充符合最左前缀的联合索引或者覆盖索引，把 SELECT * 收敛为必要的字段，把 LIMIT 100000,20 改为基于上次主键游标的续扫方式。索引变更需要在从库预演执行计划，确认没有回退后再进行灰度上线，并且保留回滚脚本。对于写入密集的表，要评估新增索引所带来的写放大成本，不能以读性能为代价来换取写阻塞。
优化之后，用P95响应时间、扫描行数、锁等待时长三个指标来建立前后的基线对比。之后把慢日志周榜、索引命中率、缓冲池命中率纳入常规监控中，新上线的语句必须经过执行计划评审，在几个月之内可以把数据库整体的响应时间减少一半以上，大大减少了连接池耗尽和接口超时的情况。
慢查询治理的目的不是要消除每一条异常的SQL语句，而是要建立“采集-归因-整改-回归”的持续循环，使得数据层的性能随着业务的增长而得到控制。