数据库慢查询你一般怎么优化？
后端开发第 2 / 13 题答题框架
参考思路：慢日志定位→执行计划分析(索引失效/回表)→索引与 SQL 改写→必要时读写分离或缓存。给量化案例最有说服力。
五个经典回答示范
回答一 · 校招应届版
我的步骤是：先开慢日志定位具体 SQL；用 explain 看执行计划，重点看 type、key、rows 和 Extra——全表扫描、索引失效、文件排序都是信号；然后建合适索引或改写 SQL；最后压测验证。我在实习时把一个 3 秒的列表查询通过联合索引和覆盖索引降到 60 毫秒。
回答二 · 1-3年经验版
我优化过一个订单列表页：症状翻页越深越慢。explain 发现深分页扫了 80 万行。三个手段组合：游标分页用上一页最大 ID 起查、查询列做成覆盖索引避免回表、状态过滤条件前置到索引最左列。上线后 P99 从 4 秒到 120 毫秒。同时把这条 SQL 加进了慢查询周报，防止劣化。
回答三 · 资深版
慢查询治理我分三层：单条 SQL 层——执行计划分析、索引设计遵循最左前缀与区分度、避免函数操作列；架构层——读写分离、冷热分离、count 类查询走中间表或缓存；机制层——慢日志阈值分级告警、DDL 走审核平台、索引冗余度定期清理。优化的目标不是单条变快，而是系统慢查询数量趋势下降。
回答四 · 追问应对
追问『为什么索引失效』：对列做函数或运算、隐式类型转换、前导通配符 like、or 连接非索引列、联合索引不满足最左前缀；『回表是什么』：二级索引只存主键，查完还要回聚簇索引取整行，覆盖索引可避免；『加索引有什么代价』：写入维护成本和空间，高频更新的表要克制。
回答五 · 反面示范
『慢 SQL 就是数据库数据多了变慢，把 MySQL 换成性能更好的数据库，或者加内存就行了。』——点评：没有执行计划分析的任何环节，把优化等同于升硬件；换库是重大架构决策不是 SQL 优化手段。答不出 explain 的关键字说明没实际优化过。
怎么练这道题
- 打开 模拟练习，选择「后端开发」方向，限时 3 分钟作答本题。
- 对照上方答题框架，逐点检查：哪些要素没覆盖、哪里表达啰嗦。
- 用自己项目的真实经历替换框架中的占位内容，重讲一遍并录音回听。
这类题在真实面试中常被追问细节，
建议进入限时模式练一遍。