MySQL高并发需分层设置超时：连接层（wait_timeout/interactive_timeout设60–300秒）、应用连接池（connection-timeout、idle-timeout≤max-lifetime）、查询层（long_query_time设1s并优化慢SQL）、监控熔断联动（Threads_running>80% max_connections时触发限流）。
MySQL 高并发场景下，设置合理的超时机制是防止连接堆积、资源耗尽和雪崩的关键。核心不是“一刀切”调大或调小，而是分层控制：连接建立、查询执行、空闲等待、事务持有四个环节都要有对应策略。
连接层超时：防止连接池打满
客户端（如应用连接池）和 MySQL 服务端需协同控制。服务端通过 wait_timeout 和 interactive_timeout 控制空闲连接存活时间（默认 28800 秒，即 8 小时），高并发下建议设为 60–300 秒。应用侧连接池（如 HikariCP、Druid）也必须配置 connection-timeout（获取连接等待上限）、idle-timeout（空闲连接回收）和 max-lifetime（连接最大存活期），且三者需满足：idle-timeout ≤ max-lifetime
查询层超时：阻断慢 SQL 扩散
单条查询超时靠 max_execution_time（5.7.8+ 支持，单位毫秒）实现，可全局设默认值（如 3000），也可在 SQL 前加 /*+ MAX_EXECUTION_TIME(2000) */ 精确控制。注意：它只对 SELECT 生效；UPDATE/DELETE 需靠 innodb_lock_wait_timeout（行锁等待，默认 50 秒）和 lock_wait_timeout（元数据锁等待，默认 31536000 秒）配合限制。线上建议将 innodb_lock_wait_timeout 调至 10–30 秒，避免长事务拖垮并发能力。
事务与连接生命周期绑定
避免“长事务 + 短连接”陷阱。应用必须显式控制事务边界（begin/commit/rollback），禁止在事务中做 RPC、文件读写等外部耗时操作。可借助 MySQL 的 innodb_rollback_on_timeout=ON（默认关闭），让锁等待超时后自动回滚事务，释放资源。同时开启 slow_query_log 并设置 long_query_time=1，配合 pt-query-digest 定期分析，把 >1s 的查询作为优化重点——超时只是兜底，根治慢 SQL 才是根本。
监控与熔断联动
仅靠 MySQL 内置参数不够。需采集 Threads_connected、Threads_running、Aborted_connects 等状态变量，当 Threads_running 持续 > 80% max_connections 或 Aborted_connects 短时突增，触发告警并启动应用层限流（如 Sentinel 或 Resilience4j）。真实生产中，数据库超时应是“最后一道闸门”，前面必须有连接池熔断、API 网关限流、业务降级等多层防护。
