数据库为什么先死：读懂 MySQL 的极限
2026/8/24大约 3 分钟
亿级规模系统系列 · 阶段 2 · 缓存体系 · 第 9/49 篇 · 🚧 占位待学
上一篇：《压测入门：不压测，一切架构都是猜》
下一篇：《读写分离与主从复制：读扩展的第一刀》
学习大纲：《QPS 过万与亿级消息系统设计学习总纲》
状态：待学习。 本文为占位文档：知识点清单、实验与验收标准已就绪，正文待按「先学习、先实验、再撰写」补全。
对应总纲单元：阶段 2 · 单元 2.1
一、本文要解决的问题
流量一大，为什么总是数据库先挂？因为它是链路里唯一「既慢又不能加机器」的环节——应用可以无状态横向扩，数据的每一次读写却都要落在具体的盘上。先看清它死掉的姿势，才知道后面每一刀（读写分离、缓存、分库）分别救什么。
二、知识点清单
- 连接数天花板：max_connections、连接建立成本，以及「连接池打满」的报错样子
- buffer pool：为什么热数据在内存里快、冷数据落盘慢，命中率的意义
- 慢查询三源：索引失效、回表过多、大事务；explain 的解读（type / rows / extra）
- 写热点：同一行的并发更新在行锁上排队，TPS 的真实极限
- 单机极限量级认知：读几千到几万 QPS（吃内存与索引）、写几千 TPS（吃盘与锁），及压垮它的三种姿势（连接风暴 / 慢查询拖垮 buffer pool / 热点行锁竞争）
三、动手实验（学习时必须真跑）
- 压测一个随机 id 查询接口直到数据库崩溃边缘，全程观察：Threads_connected、buffer pool 命中率、慢查询日志增长
- 分别制造三种死法：把连接池调大于 max_connections / 去掉索引全表扫 / 并发更新同一行，各记录现象与报错
- 给热点行更新做「合并更新」（累加改异步批量）优化，对比 TPS
四、验收标准（全部通过才进入下一篇）
五、写作提示（补正文时遵守）
- 开篇问题驱动；结构走「是什么 → 为什么 → 怎么做 → 背景知识」
- 所有代码、命令、输出必须先在本机跑通再写入，不得杜撰
- 版本口径以总纲环境清单为准（Spring Boot 3.x / MySQL 8.0 / Redis 8.x / RocketMQ 5.3.x / Kafka 4.3 / ShardingSphere 5.5.3）
- 涉及版本敏感结论时标注出处与时间
本篇完成后，把文首导航块的「🚧 占位待学」去掉，并在总纲处打卡。