备案站点的慢查询定位与索引优化

先定位，再优化

「站点变慢」的排查顺序里，数据库几乎永远是第一嫌疑人。但直接凭感觉加索引是最低效的做法——真正的瓶颈往往只有两三条 SQL，找到它们比优化十条无关查询有用得多。

关键要点

• 优化从慢查询日志与执行计划开始，不从「我觉得这里慢」开始。
• 索引失效大多不是缺索引，而是写法让索引用不上。
• 覆盖索引能免掉回表，对高频查询收益最大。
• 索引不是越多越好：每个索引都会让写入变慢、占用空间。

第一步：把慢的那几条找出来

开启慢查询日志并设定阈值（例如 200 毫秒），运行一段时间后按总耗时而不是单次耗时排序——一条 50 毫秒但每秒执行 500 次的查询，危害远大于一条 2 秒但每天只跑一次的报表。

拿到候选 SQL 后看执行计划，重点关注三件事：是否走了索引、扫描行数与返回行数的比例、是否出现临时表或文件排序。扫描 10 万行只返回 10 行，就是典型的索引选择问题。整体压测与瓶颈定位方法见 性能优化与压测。

索引用不上的五种典型写法

写法	为什么失效	改法
在列上套函数，如 DATE(created_at)=…	索引存的是原值	改成范围查询 >= … AND < …
隐式类型转换，字符串列传数字	触发全表转换比较	类型对齐
前导通配 LIKE '%关键词%'	无法定位起点	用全文检索或搜索引擎
联合索引跳过前导列	最左前缀原则	调整索引列顺序
OR 连接不同列	难以合并索引	拆成 UNION ALL 或补索引

联合索引的列顺序要按「等值条件在前、范围条件在后」排列，范围条件之后的列无法再用于索引定位——这是联合索引最容易被浪费的地方。

覆盖索引与回表

普通二级索引命中后还要回主键索引取完整行，这一步叫回表。如果查询需要的列都包含在索引里，就可以直接从索引返回结果，省掉回表的随机 IO。对高频接口，把 SELECT * 收敛成只查需要的几列，再配一个覆盖索引，效果往往比换硬件明显。这也是为什么 SELECT * 在热点路径上是个坏习惯。

深翻页：LIMIT 100000, 20 的陷阱

这条语句要求数据库先扫描并丢弃前 10 万行，页码越大越慢。改造方式：

• 游标分页：记住上一页最后一条的排序键，下一页用 WHERE id > 上次最大值 ORDER BY id LIMIT 20，耗时与页码无关。
• 延迟关联：先用覆盖索引查出这一页的主键，再回表取完整行。
• 对外接口直接限制最大可翻页数，后台导出走异步任务，见 消息队列与异步任务运维。

索引的代价

每加一个索引，写入时就要多维护一棵树，同时占用磁盘与内存缓存。常见的收敛做法：删掉长期零命中的索引、合并前缀重复的索引（(a) 可被 (a,b) 覆盖）、避免在低区分度列（如状态、性别）上单独建索引。

加索引本身也是一次高风险变更

大表加索引可能锁表或引发主从延迟，必须按在线变更流程执行，见 数据库变更与在线 DDL 实践。变更窗口内要盯住连接数与复制延迟，见 数据库运维与高可用。

优化之外：缓存与连接

不是所有慢查询都该靠索引解决。读多写少的热点数据更适合缓存，见 缓存与 Redis 运维；而当慢查询导致连接被长期占用时，还要同步检查连接池配置，见 数据库连接池与连接数治理。

常见坑

• 凭感觉加索引：索引堆了一堆，慢的那条还是慢。
• 只看单次耗时：忽略了高频小查询的总开销。
• 索引列上套函数：索引形同虚设。
• 深翻页不改造：后台列表页越往后越卡。
• 测试数据量太小：在一千行的表上什么方案都快。

常见问题

慢查询日志阈值设多少合适？

先设一个能筛出明显问题的值（如 500 毫秒）看整体情况，再逐步调低到 100～200 毫秒做精细优化。阈值太低会记录大量正常查询，反而增加磁盘压力。

为什么加了索引还是不走索引？

常见原因有三个：写法导致索引失效；优化器认为全表扫描更划算（通常出现在表很小或筛选后行数占比很高时）；统计信息过期导致估算失真。先看执行计划再判断。

能不能给每个查询条件都建索引？

不建议。索引会拖慢写入、占用存储，过多索引还会让优化器选错。更有效的做法是用少量联合索引覆盖高频查询组合。

报表类的慢查询也要这样优化吗？

报表更适合分离处理：走只读从库或离线数仓，避免和在线业务抢资源。在主库上优化一条每天跑一次的报表，性价比很低。

资料来源

MySQL、PostgreSQL 官方文档中关于索引结构、执行计划与慢查询日志的公开说明，以及覆盖索引、游标分页等通用数据库优化实践。本文为通用运维说明，仅供参考，具体以实际数据库版本与数据分布为准。