从库报“too many connections”错误，主因是其max_connections值低于主库，且复制线程（io/sql/parallel workers）与客户端连接共同耗尽连接数；需先set global临时调高，再修改my.cnf永久生效，并验证配置加载正确。
从库报 Too many connections 错误，不是主库配错了
MySQL 从库单独触发 Too many connections，大概率是它的 max_connections 值比主库低，而复制线程 + 应用连接一起压上来就超了。主库调高了没用，从库得自己改。
- 检查当前值：
SHOW VARIABLES LIKE 'max_connections'; - 重点看从库的值是否明显低于主库（比如主库 1000，从库才 151）
- 注意：从库的
slave_parallel_workers线程、slave_sql_thread、slave_io_thread都算在max_connections里，不是只算客户端连接
临时调高但不重启：用 SET GLOBAL max_connections
线上不能立刻重启？可以先在线调高，让复制和查询先跑起来。但要注意这个值不会持久化，MySQL 重启后会回到配置文件里的值。
- 执行：
SET GLOBAL max_connections = 1000; - 确认生效：
SELECT @@max_connections; - 风险点：如果当前活跃连接已接近原上限，
SET GLOBAL可能失败，需先杀掉部分闲置连接（KILL对应ID） - 该操作需要
SYSTEM_VARIABLES_ADMIN或SUPER权限，普通REPLICATION SLAVE账号不够
永久生效必须改 my.cnf 并重启
临时改完只是救火，真正要稳住得写进配置。别漏掉 mysqld section，也别改错实例——特别是多实例部署时，容易改到主库配置上。
- 编辑配置文件，加在
[mysqld]下：max_connections = 1000 - 确认配置文件路径：
mysql --help | grep "Default options" -A 1 - 重启前建议先
mysqladmin shutdown，避免 kill -9 导致 binlog 不完整 - 重启后务必验证：
SELECT @@hostname, @@max_connections;，防止加载了错误配置文件
为什么从库更容易触发连接数超限
从库负载模型和主库不同，容易被忽略的是“隐式连接消耗”。比如并行复制开启后，每个 worker 都占一个连接；再叠加监控工具每秒连一次、应用直连从库做读请求，很容易突破默认 151。
-
slave_parallel_workers设为 8 → 至少多占 8 个连接 - 慢查询或长事务阻塞 SQL thread → 连接堆积不释放
- 某些 ORM 或中间件（如 ShardingSphere）建连接不复用，短连接风暴更明显
- 注意：
wait_timeout和interactive_timeout影响空闲连接释放，但从库上这两个值调太小反而可能加剧重连压力
真正麻烦的不是调数字，而是得摸清从库上到底谁在连、连多久、连多少——SHOW PROCESSLIST 要盯住 User 和 Command 列，别只看数量。
