日期:2026-07-11
难度:中等
标签:#面试 #MySQL #性能优化 #场景题 #VIP
一句话答案
MySQL 优化应从指标和瓶颈出发,依次检查 SQL 与索引、表结构、事务锁、内存与日志配置、存储硬件、复制架构和业务访问模型,并用压测验证而非盲目调参。
面试口语版
我会先建立基线,看 QPS、P99、CPU、IOPS、Buffer Pool 命中、锁等待、连接数、复制延迟和慢 SQL。最常见收益来自 SQL 和索引:减少扫描、回表、临时表、filesort 和深分页;表结构上选合理类型、短主键、控制大字段和归档冷热数据。再治理长事务、死锁、热点更新和连接池。实例层按工作集配置 Buffer Pool,评估 redo 容量、刷盘策略和磁盘性能,但不牺牲未确认的持久性。单机到瓶颈后再做缓存、读写分离、分区、分库分表或数仓分流。
原理拆解
| 层次 | 典型手段 |
|---|---|
| SQL | 慢日志、EXPLAIN ANALYZE、改写查询 |
| 索引 | 联合/覆盖索引、删除重复索引 |
| 表结构 | 合理类型、主键、大字段与冷热分离 |
| 事务 | 缩短事务、统一锁顺序、降低热点 |
| 实例 | Buffer Pool、redo、连接与 IO 配置 |
| 架构 | 缓存、读写分离、分片、异步化 |
关键细节
- CPU 高可能是扫描行数过大,IO 高可能是缓存不足或随机访问;必须先找到资源因果链。
- 命中率、平均耗时等单一指标可能掩盖 P99 和热点 SQL。
- 参数优化应有回退方案,特别是持久性、复制和内存相关参数。
面试官追问
- CPU 突然升高如何排查?
- Buffer Pool 多大合适?
- 为什么加索引可能让系统更慢?
- 何时需要分库分表?
高分补充
用“发现—归因—改动—压测—灰度—回归监控”形成闭环,优化目标应绑定业务 SLO,而不是追求某个参数好看。
学习清单
- 按 SQL、存储、事务、实例、架构五层准备案例。