MySQL响应慢八成卡在连接层，需查SHOW PROCESSLIST看State异常、performance_schema定位等待事件、Threads_connected与Threads_running差值判断连接池问题，并排查DNS解析、SSL握手等网络层延迟。
查 SHOW PROCESSLIST 看有没有卡住的连接
MySQL 响应慢，八成先卡在连接层——不是 SQL 慢，是连接根本没轮到执行。直接连上数据库跑 SHOW PROCESSLIST，重点看 State 列是不是长期停在 Sending data、Locked、Copying to tmp table 或空着不动。
-
State是Sleep但Time超过 300 秒？大概率是应用没正确 close 连接，连接池泄漏了 - 多个查询卡在同一个表的
Waiting for table metadata lock？说明有长事务或 DDL 正在执行，其他查询全被堵住 - 看到一堆
Connect状态且Host是同一台应用服务器？可能是连接数打满，新请求在排队等连接
用 performance_schema 查真实等待事件
SHOW PROCESSLIST 只给快照，看不出“为什么卡”。开启 performance_schema（默认 5.7+ 已开），查 events_waits_current 和 events_statements_current 才能定位瓶颈类型。
- 如果
EVENT_NAME大量是wait/io/file/innodb/innodb_data_file，说明磁盘 I/O 吃紧，不是 SQL 问题，是 buffer pool 不够或刷脏太慢 - 看到一堆
wait/synch/mutex/innodb/...？线程在抢锁，可能并发写入高，或存在热点更新（比如计数器字段） -
SQL_TEXT显示语句简单但TIMER_WAIT很高？别急着优化 SQL，先检查是否被锁住或等待 buffer pool latch
监控 Threads_connected 和 Threads_running 的差值
这两个状态变量比慢日志更早暴露问题：Threads_connected 是当前总连接数，Threads_running 是真正干活的线程数。差值大，说明大量连接空转或阻塞。
- 差值持续 > 200？检查
max_connections是否设得太小，或者应用连接池配置不合理（比如最小连接数设太高） -
Threads_running长期 > 50 且波动剧烈？说明并发请求压过处理能力，不是单条 SQL 慢，是整体吞吐见顶 - 注意：某些监控工具把
Threads_connected当“活跃连接”展示，这是错的——Sleep连接不算活跃，得看Threads_running
别只盯着慢查询日志，先确认是不是连接认证或网络层拖慢
响应慢不一定发生在执行阶段。如果 SHOW PROCESSLIST 里大量连接 State 是 Connecting to master 或刚进来就消失，可能是 DNS 解析、SSL 握手、或 TCP 连接建立阶段出问题。
- 检查 MySQL 的
skip_name_resolve = ON是否启用，否则每个新连接都会做反向 DNS 查询，超时直接卡 30 秒 - 客户端用
mysql -h 127.0.0.1而不是localhost，避免 Unix socket 路径误判或权限绕过带来的延迟 - 抓包看三次握手和 SSL handshake 耗时（用
tcpdump -i any port 3306），如果 SYN-ACK 延迟高，问题根本不在 MySQL
Threads_connected 高，未必是业务增长，也可能是连接没释放；State 是 Sending data，未必是 SQL 慢，可能是网卡打满或客户端读取太慢。得把连接状态、等待事件、网络路径三者串起来看，漏掉哪一层都可能白忙活半天。 
