mysql连接复用依赖客户端连接池而非服务端多路复用，服务端无协议层复用机制；thread_cache_size用于缓存空闲线程以减少创建开销，建议设为4～8；连接池配置不当（如min_idle过高、超时不匹配）是连不上主因。
MySQL 连接复用靠的是连接池，不是 MySQL 自己的“多路复用”
MySQL 协议本身是同步、单请求-单响应的，不支持像 HTTP/2 那样的多路复用（multiplexing）。所谓“多路复用连接”，实际是应用层通过连接池（如 mysql-connector-python 的 pool_size、maxconn，或 Go 的 sql.DB.SetMaxOpenConns()）复用 TCP 连接，避免反复握手和认证开销。
直接在 MySQL 服务端配置“多路复用”不存在——你搜到的那些 max_connections、thread_cache_size 都是为并发连接服务的，不是复用协议层通道。
- MySQL 5.7+ 默认使用线程池插件（
thread_pool），但需手动安装启用，且只对高并发 OLTP 场景有收益，小流量反而增加延迟 - 真正起作用的是客户端连接池：控制最大连接数、空闲超时、最小空闲数，而不是服务端参数
- 误配
max_connections过高会导致内存耗尽（每个连接约占用 2–4MB 内存），出现ERROR 1040 (HY000): Too many connections
thread_cache_size 怎么设才不拖慢新连接建立
thread_cache_size 控制 MySQL 空闲线程缓存数量。当客户端断开，对应的工作线程不会立刻销毁，而是放进缓存，下次新连接可直接复用，省去线程创建/销毁开销。
但它不是越大越好，也不是“必须调”。默认值通常是 0 或 4，取决于版本和负载模型。
- 观察
Threads_created状态变量：如果它持续增长（比如每秒 > 1），说明频繁创建线程，可适当调大thread_cache_size - 上限建议不超过 CPU 核心数 × 2；超过后缓存命中率几乎不提升，还浪费内存
- 若用连接池（如应用层已控制连接数），
thread_cache_size设为 4～8 足够，不必强求匹配连接池大小 - 注意：该参数只影响“线程复用”，不影响连接复用；连接仍需客户端主动 close 或超时回收
多线程写入慢？先看是不是 autocommit 和事务粒度问题
MySQL 多线程性能瓶颈往往不在并发能力，而在事务冲突、锁等待和日志刷盘。盲目增加线程数反而加剧竞争。
典型表现：QPS 上不去、innodb_row_lock_time_avg 升高、大量 UPDATE 被阻塞在 Waiting for table metadata lock 或 Waiting for row lock。
- 确保写操作在事务中批量提交，避免每个
INSERT单独 commit（即关闭autocommit=0，显式COMMIT） - 批量插入优先用
INSERT INTO ... VALUES (...), (...), (...)，而非循环单条INSERT -
innodb_flush_log_at_trx_commit=1是安全底线，但会限制写吞吐；若允许短暂丢失（如日志类数据），可设为 2 - 避免长事务：事务越长，锁持有时间越久，其他线程等待越明显；用
SELECT ... FOR UPDATE前务必确认必要性
连接池配置不当导致“明明没多少请求，却连不上”
最常见的故障不是 MySQL 撑不住，而是应用侧连接池把连接占满又不释放，或连接泄漏，最终所有新请求卡在获取连接阶段。
现象包括：应用报 timeout: can't get connection from pool、MySQL Threads_connected 接近 max_connections、但 Threads_running 很低。
- 检查连接池的
max_idle_time（或wait_timeout对应值）：必须小于 MySQL 的wait_timeout（默认 28800 秒），否则连接可能被服务端主动断开，客户端却还在用，触发异常 - 设置合理的
max_lifetime（如 3600 秒），强制连接定期重建，避免因网络闪断导致的僵死连接 - 开启连接池的连接验证（如
test_on_borrow=true或connection_test_query=SELECT 1），但别在每次获取时都执行复杂语句 - 监控
Aborted_connects：突增往往意味着连接池配置与 MySQL 超时不一致，或认证失败（如密码过期、host 不匹配）
最易被忽略的一点：连接池的“最小空闲数”（min_idle）如果设得过高，冷启动时会一次性建一堆连接，瞬间打满 max_connections，而此时业务还没开始跑——这种错配在容器重启或蓝绿发布时特别致命。
