-
auo4 AI 观察 用户
数据库慢查询优化案例集：8条真实SQL从十几秒压到毫秒的完整修复过程
慢查询这件事，最折磨人的地方不在于它难，而在于它"时好时坏"。
开发环境里一条 SQL 跑 20 毫秒，上线以后偶尔变成 20 秒；白天一切正常，晚上高峰期接口集体超时；你给它加了索引，它反而更慢了。大多数人遇到这种情况的第一反应是"加个索引试试"，第二反应是"是不是数据库该升配了"，第三反应是"重启一下看看"。
这三种反应，恰好覆盖了慢查询排查里最贵的三条弯路。
这篇不讲索引原理，也不讲执行计划里每个字段是什么意思——那些内容你在任何一本数据库书里都能看到。这篇只做一件事：把 8 条真实生产环境里要命的 SQL，从"它慢在哪里"到"最后怎么改的"，一步一步摊开给你看。每一条都包含当时的现象、定位过程、根因、改法，以及改完之后真实的数据变化。
你不需要一次读完。建议的做法是：先扫一遍 8 个案例的"现象"部分，找到跟你当前状况最像的那一个，直接跳过去看。
案例一：一条分页查询，翻到 1000 页以后要 14 秒
现象
后台订单列表，前端默认展示 20 条一页。用户反馈"翻到后面就卡死"，运维日志显示第 1000 页左右的请求耗时 14 秒，数据库 CPU 同期飙到 9
内容摘要
一句话概述：8 条真实生产慢 SQL 的完整修复复盘，覆盖深分页、索引失效、隐式转换、跨列 OR 等八类高频根因，每条都给出定位过程与修复前后的耗时对比。
你将了解到：
- 为什么偏移量分页在数据量上万之后必然变慢，以及它的替代写法
- 索引建了却一条都没用上的几种典型情形，以及怎么一眼识别
- 回表、覆盖索引、联合索引列顺序，各自对耗时的影响量级
- 单条 SQL 并不慢、却在并发下拖垮连接池的判断方式
- 统计报表类查询为什么该换个思路，而不是继续优化那条 SQL
- 一份可以照着顺序执行的慢查询排查清单
适合人群：后端开发、DBA，以及需要自己定位线上性能问题的技术负责人。
以上为全文要点速览，完整内容需解锁后阅读