max_connections合理值为300–800，需据qps、内存及连接池协同配置；超此范围易致内存耗尽或系统限制，非越大越好。
max_connections设多少才不爆？
电商大促时最常见报错是 Too many connections，根本原因不是连接数“不够多”，而是没算清真实并发需求。比如预估峰值QPS为5000，平均查询耗时50ms，理论最小连接数是5000 × 0.05 = 250；但实际要预留缓冲，建议按1.5–2倍设置，即375–500。超过这个值，光是连接建立/销毁开销就会拖垮性能。
关键点在于：max_connections 不是越大越好。设太高会挤占内存（每个连接默认消耗约2MB），还可能触发OS级限制（如Linux的ulimit -n）。必须同步检查并调高系统文件描述符上限。
- 线上建议值范围：300–800，具体看服务器内存和QPS预期
- 配套必须配
wait_timeout=300和interactive_timeout=300，避免空闲连接长期占位 - 如果应用层用了连接池（如HikariCP），要确保其
maximumPoolSize≤max_connections× 0.8，留出管理线程余量
thread_cache_size该不该开？开多大？
MySQL每处理一个新连接，都要创建新线程，开销不小。开启线程缓存后，断开的连接线程不会立即销毁，而是放进缓存复用——这对短连接高频场景（如HTTP接口直连DB）效果显著。
判断是否需要开启：查 SHOW STATUS LIKE 'Threads_created'。如果每秒创建线程数 > 2–3，说明缓存不足；如果长期为0，说明当前连接基本复用，可不开。
- 计算公式：缓存大小 ≈ 平均并发连接数 ÷ 4，但上限建议不超过16（实测再高收益递减）
- 典型配置：
thread_cache_size=8（中等负载）、12（大促前压测确认过连接波动大的集群） - 注意：它只对非持久连接生效；若用的是持久连接（如长连接池），此参数影响极小
innodb_thread_concurrency要不要设？
这个参数本意是限制InnoDB内部并发线程数，防止CPU过度争抢。但MySQL 5.6.2+默认为0（不限制），官方文档明确建议“绝大多数场景保持0”。强行设成非零值（如32或64）反而容易造成人为瓶颈，尤其在SSD+多核服务器上。
例外情况极少：只有当 SHOW ENGINE INNODB STATUS 中反复出现大量 semaphore waits，且确认是CPU调度混乱导致，才考虑设为 0 以外的值。即便如此，也应优先排查锁竞争、索引缺失等更根本的问题。
- 安全做法：保持
innodb_thread_concurrency=0 - 若真要调，最大不超过逻辑CPU核心数（
nproc命令结果） - 别和
innodb_read_io_threads/innodb_write_io_threads混淆——后两者控制IO线程数，SSD建议设为8–12
为什么连接池调优比SQL优化更先见效？
因为大促期间第一个被打穿的往往不是慢SQL，而是连接资源。一个未配置连接池的应用，每秒发起1000次请求，可能产生1000个TCP连接；而连接池复用下，可能只需50个活跃连接。前者直接触发 max_connections 上限，后者还能靠 thread_cache_size 缓冲抖动。
真正卡住系统的，常是连接排队等待、线程频繁创建销毁带来的上下文切换开销，而不是某条SQL跑得慢。所以压测时第一眼要看：Threads_connected 是否逼近 max_connections，Threads_created 是否突增，Aborted_connects 是否上升——这些信号比慢日志更早暴露问题。
复杂点在于：连接池行为受应用框架深度影响。Spring Boot默认HikariCP的 connection-timeout 是30秒，但MySQL的 wait_timeout 默认是28800秒，两者不匹配会导致连接被服务端静默断开，客户端却还在等——这种隐性超时最难排查。
