MySQL 高并发面试重在问题识别、分层优化与实战取舍：先按 SQL/ 连接 / 存储 / 架构层定位瓶颈；写操作聚焦事务缩时、锁范围缩减与批量 / 异步化；读压力优先缓存并防控穿透、击穿、雪崩；分库分表需权衡阶段成本，避免过早过度设计。
MySQL 高并发系统面试，考的不是“会不会建表”，而是你能不能在流量突增、数据量暴涨、业务逻辑复杂的情况下，让数据库不拖后腿、不出错、还能稳住响应时间。核心是： 问题识别能力 + 分层优化意识 + 实战取舍经验 。
一、先看瓶颈在哪：别一上来就加索引或分库
高并发问题往往不是单一原因。要习惯按请求链路快速定位：
- SQL 层 ：慢查询多不多？执行计划是否走了索引？有没有
SELECT *、ORDER BY RAND()、隐式类型转换这类“杀手”？ - 连接层 ：应用是否复用连接？有没有连接泄漏？`max_connections` 是否被耗尽？线程池是否启用？
- 存储层 ：磁盘 I/O 是否打满（iowait 高）？Buffer Pool 命中率是否低于 95%？redo log 刷盘是否成为瓶颈？
- 架构层 ：读多写少？是否该上读写分离？热点 key 是否集中在某几行（比如库存扣减）？单表千万级后是否考虑归档或分区？
二、写操作扛不住？聚焦事务、锁和批量处理
并发写比读更易出问题，重点不在“快”，而在“不冲突、不阻塞、不丢数据”：
- 尽量缩短事务时间：DML 后早 commit，避免在事务里调外部接口或做复杂计算；
- 减少锁范围：用主键更新代替非主键条件更新；避免
UPDATE …… WHERE name = 'xxx'这类没索引的语句； - 把“多次小写”变“一次大写”：比如秒杀扣库存，用
UPDATE stock SET num = num - 1 WHERE id = ? AND num >= 1原子判断，而不是先查再更新； - 允许异步化：日志、通知、积分等非核心写入，走 MQ 落库，削峰填谷。
三、读压力大？优先用缓存，但得防穿透、击穿、雪崩
MySQL 不是万能的读库，缓存是高并发系统的“减压阀”，但要用得稳：
- 穿透 ：查一个根本不存在的 ID（比如 -1 或超长字符串）。方案：布隆过滤器拦截，或缓存空值（设短过期）；
- 击穿 ：热点 key 过期瞬间大量请求打穿缓存。方案：互斥锁（如 Redis setnx）、逻辑过期（value 内带时间戳，后台异步刷新）；
- 雪崩 ：大量 key 同时过期。方案：过期时间加随机扰动（如 base + rand(1~300) 秒）；
- 缓存与 DB 一致性：优先选择“先更 DB，删缓存”策略；若要求强一致，可加订阅 binlog（如 canal）同步更新缓存。
四、撑不住了？分库分表不是银弹，得看阶段和成本
分库分表是重操作，面试官想听的是你有没有权衡意识：
- 单机扛不住前，先确认是不是 SQL、索引、配置、硬件没榨干（比如 Buffer Pool 设置太小、没开 query cache 但其实它已废弃，别踩坑）；
- 分片键选不好 = 白忙：要满足高频查询条件、数据分布均匀、避免跨库 JOIN 和分布式事务；
- 中小公司优先用 读写分离 + 缓存 + 归档冷数据 ，比盲目分片更可控；
- 真要分，推荐 ShardingSphere 或 MyCat 这类中间件方案，而不是应用层硬编码分片逻辑。
面试时不一定要答全，但每说一点，都要带出“为什么在这里做这个决定”——这才是区分背题者和实战者的分水岭。
