MySQL高并发变慢是多环节叠加所致：连接耗尽、慢查询阻塞、锁竞争加剧、硬件配置不足共同导致性能下降。
MySQL在高并发下变慢，不是单一原因导致的，而是多个环节在压力叠加下同时暴露问题。核心在于：数据库是有状态、强一致性的系统，无法像无状态服务那样简单扩容，所有读写最终都要落到物理存储和锁机制上。
连接资源被快速耗尽
每个客户端连接都会占用MySQL一个线程（或线程池中的工作单元）。当QPS从几百飙升到几千时，若应用未合理复用连接、连接池配置过松（如最大连接数设得过高但未限流），就会出现：
- 大量连接堆积，Threads_connected 接近或超过
max_connections，新请求被拒绝或排队等待 - 连接创建/销毁频繁，引发上下文切换开销，CPU使用率异常升高
- 空闲连接未及时释放（idle_timeout 设置不合理），长期占用资源
慢查询引发连锁阻塞
一条未优化的SQL，在低并发时可能只是“稍慢”，但在高并发下会成为雪崩起点：
- 全表扫描（EXPLAIN中type=ALL）大量消耗I/O和CPU，拖慢整个实例响应
- 缺乏分页或条件过滤的统计类查询，一次执行数秒，阻塞后续事务
- 慢查询日志中
Slow_queries突增，且集中在少数几张表（如orders、user_logs） - 查询未走索引，或索引失效（如对字段做函数操作：
WHERE DATE(create_time) = '2025-12-23'）
锁竞争与事务等待加剧
InnoDB虽支持行锁，但高并发更新同一热点数据（如商品库存、账户余额）时，锁会迅速成为瓶颈：
- 多个事务争抢同一行的X锁，形成等待队列，SHOW ENGINE INNODB STATUS 中可见大量
lock wait - 长事务持有锁时间过久（如事务内混入HTTP调用、日志写入），放大阻塞范围
- 死锁频发，MySQL自动回滚部分事务，业务侧需重试，进一步推高负载
- 元数据锁（
Waiting for table metadata lock）在DDL操作期间阻塞所有DML，影响面极大
硬件与配置跟不上增长节奏
即使SQL和架构合理，底层资源不足也会直接拖垮性能：
-
InnoDB Buffer Pool 过小，缓存命中率（
Innodb_buffer_pool_hit_rate）低于95%，大量查询被迫走磁盘 -
redo log太小（
innodb_log_file_size），频繁刷盘，Innodb_log_waits不为0 - 磁盘I/O饱和（
iostat -x 1显示 %util ≥ 95%），尤其是机械盘或未优化的云盘 - CPU满载且无法横向分担，主库承担全部写+部分读，成为单点
