MySQL 8.0 默认max_connections为151，需同步调大table_open_cache、open_files_limit并解除系统级文件限制；HikariCP空闲连接断开因wait_timeout与idle-timeout未对齐；读写分离须基于Seconds_Behind_Master动态路由；长事务和锁等待需通过performance_schema实时监控。
MySQL 8.0 安装后为什么 max_connections 还是 151？
默认值根本扛不住高并发，必须手动调大，但光改配置文件还不够。MySQL 启动时会校验 table_open_cache、open_files_limit 和 max_connections 三者的逻辑关系：如果 table_open_cache 太小（比如默认 400），即使你把 max_connections 设成 2000，MySQL 实际生效的连接数仍可能被截断到几百。
实操建议：
- 在
/etc/my.cnf的[mysqld]段下同时设置：max_connections = 2000table_open_cache = 4000open_files_limit = 65535 - Linux 系统级限制也要同步放开：在
/etc/security/limits.conf中添加mysql soft nofile 65535和mysql hard nofile 65535，并确认systemd未覆盖该设置（检查/etc/systemd/system/mysqld.service.d/limits.conf） - 重启后用
mysql -e "SHOW VARIABLES LIKE 'max_connections';"和cat /proc/$(pgrep mysqld)/limits | grep "Max open files"双重验证
为什么 HikariCP 连接池空闲连接总被 MySQL 主动断开？
MySQL 默认 wait_timeout=28800（8 小时），但生产环境常设为 300–600 秒；而 HikariCP 默认 connection-timeout=30000（30 秒）、idle-timeout=600000（10 分钟），若未对齐就会出现“连接已关闭”异常。
实操建议：
- 服务端先统一设
wait_timeout = 600和interactive_timeout = 600 - HikariCP 配置必须匹配：
idle-timeout=300000（5 分钟，小于 wait_timeout）max-lifetime=1800000（30 分钟，避免连接老化）connection-test-query=SELECT 1（MySQL 8.0+ 推荐用isValid()，不依赖该配置） - 务必启用
keepalive-timeout（如 Netty 场景）或在连接字符串加?autoReconnect=true&failOverReadOnly=false（仅作兜底，不能替代合理超时对齐）
主从延迟突增时，读写分离中间件还在往从库发查询？
ShardingSphere、MyCat 或自研路由层若只靠心跳判断从库存活，会忽略 Seconds_Behind_Master。一旦主从延迟飙升到分钟级，读请求仍打到严重滞后的从库，导致业务读到脏数据或过期状态。
实操建议：
- 所有读写分离组件必须集成延迟探测：定期执行
SHOW SLAVE STATUS并提取Seconds_Behind_Master字段 - 设置分级阈值，例如：
延迟 1s ≤ 延迟 延迟 ≥ 30s → 摘除该从库节点（不是下线，是临时路由剔除） - 避免轮询式探测加重从库压力：用异步单线程定时任务 + 缓存结果，TTL 控制在 3–5 秒内
为什么压测时 Innodb_row_lock_time_avg 突然飙高？
这不是连接池或配置问题，而是事务粒度失控的信号。高并发下短事务变长事务（比如在事务里调外部 HTTP、做复杂计算），或未加索引导致全表扫描锁行，都会让 InnoDB 行锁等待时间雪球式增长。
实操建议：
- 用
SELECT * FROM information_schema.INNODB_TRX WHERE TIME_TO_SEC(TIMEDIFF(NOW(), TRX_STARTED)) > 2;快速揪出长事务 - 配合
information_schema.INNODB_LOCK_WAITS和INNODB_LOCKS（MySQL 5.7+ 已废弃，8.0+ 用performance_schema.data_lock_waits）定位阻塞源头 - 业务层强制约束：所有 DB 操作必须包裹在明确的
@Transactional(timeout = 3)中，超时自动回滚
真正卡点不在装得多快，而在连接生命周期管理是否闭环、主从状态是否实时感知、锁等待是否可量化——这些细节不补上，再大的连接数也只是把失败更快地分发出去。
