合理值需结合Max_used_connections历史峰值、应用连接池规模及内存估算，推荐起步设400并同步调低wait_timeout；必须写入my.cnf重启生效，且ulimit -n须≥max_connections+200。
max_connections设多少才算合理？
别一上来就往高了调，max_connections设太高会吃光内存——每个连接平均占 256KB–1MB，1000 连接就是近 1GB 内存。先看真实负载再定值：
执行 SHOW STATUS LIKE 'Threads_connected' 查当前连接数；SHOW STATUS LIKE 'Max_used_connections' 看历史峰值；预留 20%–30% 余量，比如峰值稳定在 800，就设 max_connections = 1000。
临时改用 SET GLOBAL max_connections = 1000（重启失效）；永久生效必须写进配置文件：/etc/my.cnf 的 [mysqld] 段里加一行 max_connections = 1000，然后重启服务。
为什么只调max_connections根本不管用？
单纯加 max_connections 是给漏水的桶加高桶沿，掩盖不了连接泄露、慢查询卡死、空闲连接不释放这些真问题。
常见症状：SHOW PROCESSLIST 里一堆 Sleep 状态且 Time 超过 300 秒的连接，基本就是应用没关连接；Query 状态 Time 很高，说明 SQL 卡住了。
必须同步做三件事：
• 应用层强制用连接池（HikariCP/Druid），禁用每次请求新建连接
• 设连接超时（connectionTimeout）、空闲回收（idleTimeout）、最大活跃数（maximumPoolSize）
• 数据库侧调 wait_timeout 和 interactive_timeout 到 300–600 秒，让僵死连接自动断开
单个用户连接数怎么精准限制？
全局 max_connections 控不住某个账号疯跑脚本或 bug 泄露连接，得用 MAX_USER_CONNECTIONS。ALTER USER 'app_user'@'%' WITH MAX_USER_CONNECTIONS 8 ——立即生效，不用重启，也不用 FLUSH PRIVILEGES。
注意：
• 用户有多个 host（如 'app_user'@'192.168.1.%' 和 'app_user'@'localhost'），必须分别执行 ALTER USER
• 设为 0 表示不限制，退回到全局限制，线上账号别留 0
• 验证是否生效不能只看 SHOW GRANTS（它不显示这个值），要查 SELECT User, Host, max_user_connections FROM mysql.user WHERE User = 'app_user'
• 实时连接数得看 performance_schema.threads，不是 SHOW PROCESSLIST ——后者不区分后台线程，容易误判
连接池配置和用户连接上限怎么对齐？
应用连接池的 maximumPoolSize 必须 ≤ 数据库侧该用户的 MAX_USER_CONNECTIONS 值，否则第 N+1 个连接会直接被 MySQL 拒绝，报错 ERROR 1226 (42000): User 'xxx' has exceeded the 'max_user_connections'。
例如：MySQL 给 app_user 设了 MAX_USER_CONNECTIONS 20，那 HikariCP 的 maximumPoolSize 就不能超过 20，建议设成 16–18，留点余量给管理连接或临时脚本。
另外，连接池的 minIdle 不宜设太高，空闲连接长期挂着等于白占额度；maxLifetime 建议设短于数据库的 wait_timeout，避免连接被服务端主动断开后池里还当活连接用。
