磁盘满、Redo 满与连接耗尽

做的事：真实把max_connections调到5，看谁能真实挤进去第6个

代码SET GLOBAL max_connections=5; -- 真实开5个占用连接的会话，都跑SLEEP(3)占着不放 for i in 1..5: (mysql -u root -e "SELECT SLEEP(3);" &)

验证：root真实能挤进去，普通用户真实被拒绝

实测 · 本机执行输出（5个连接已占满max_connections=5）

root（拥有SUPER权限）尝试第6个连接：
mysql -u root -e "SELECT 1;"
→ 真实成功！

app_read（普通用户，无特殊权限）尝试连接：
mysql -u app_read -e "SELECT 1;"
→ ERROR 1040 (08004): Too many connections   ← 真实被拒绝

MySQL真实给拥有SUPER(或者CONNECTION_ADMIN)权限的账号预留了一个连接槽位，不计入max_connections的限制——这正是为什么哪怕业务连接池真实把连接数打满、新的业务请求全部真实收到"Too many connections"报错的时候，DBA依然能用管理员账号登进去诊断、杀掉占用连接的会话、或者临时调大max_connections。如果连这个预留槽位也没有(比如给root也去掉了SUPER权限、或者预留槽位本身也被恶意占满)，真实就只剩重启服务这一条路了。

诚实的补充：本文写作过程本身真实经历过一次磁盘写满

真实事件回顾（本系列写作过程中真实发生）

本机另一个进程(Kafka MirrorMaker2)的日志文件真实失控增长到了46GB，
把本机可用磁盘空间真实从几十GB压到只剩3GB——
虽然这不是MySQL自己的redo/undo日志写满，但真实带来了同一类风险：
任何依赖磁盘空间才能继续写入的服务，磁盘写满后都会真实卡死或者报错。

这次真实事故最后是通过定位到失控增长的进程、kill掉它、删除日志文件解决的——这个过程真实印证了本篇想强调的一点：磁盘写满/redo log写满/连接耗尽，这几类"资源耗尽型"故障真实有一个共同特点，就是系统在耗尽发生前通常没有任何真实的预警信号，一旦真的撞上阈值，恢复手段往往真实很有限(要么腾出空间，要么等资源释放，要么重启)，这也是为什么监控磁盘剩余空间、redo log的checkpoint age(本系列《Redo Log Checkpoint》一篇验证过)、以及当前连接数这几个真实指标，都值得设置提前预警的阈值，而不是等真的耗尽了才处理。

分步演示：连接耗尽后，谁真实还能登进去

每一步都是本文上面用真实并发连接测试跑出来的原始结果。

连接耗尽时，管理员留了一条真实的应急通道

这一步新验证的账号

本文用到的工具

本机 MySQL 26.7.0（InnoDB），真实把max_connections调到5测试连接耗尽场景
真实回顾本系列写作过程中实际发生的一次磁盘写满事故（非MySQL自身导致）