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满载且无法横向分担，主库承担全部写+部分读，成为单点