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 这类中间件方案，而不是应用层硬编码分片逻辑。

面试时不一定要答全，但每说一点，都要带出“为什么在这里做这个决定”——这才是区分背题者和实战者的分水岭。