直接查Threads_connected和max_connections即可：前者用SHOW GLOBAL STATUS LIKE 'Threads_connected'获取当前已建立的TCP连接总数，后者用SHOW VARIABLES LIKE 'max_connections'查看实例最大连接限制；二者比值超80%需预警。
怎么看当前连接数和最大允许连接数
直接查 Threads_connected 和 max_connections 就行，这是判断连接是否快撑爆的最硬指标。
常见错误是只看 SHOW PROCESSLIST，它只显示当前活跃会话，但有些连接可能空闲挂着没断开，Threads_connected 才是真实已建立的连接总数。
-
SHOW GLOBAL STATUS LIKE 'Threads_connected';—— 实时值，每秒都在变 -
SHOW VARIABLES LIKE 'max_connections';—— 静态配置，重启才生效 - 如果
Threads_connected长期 > 80% 的max_connections，大概率存在连接泄漏或应用未正确 close() - 注意：某些云厂商（如阿里云 RDS）会限制
max_connections上限，且不让你改，得看控制台配额
怎么确认慢查询日志真在记录
光开 slow_query_log = ON 不够，很多线上库开了但日志文件为空，根本原因是 long_query_time 默认是 10 秒，业务里基本没 query 能卡这么久。
必须手动调低阈值并验证日志路径是否可写：
-
SHOW VARIABLES LIKE 'slow_query_log';—— 确认是否为ON -
SHOW VARIABLES LIKE 'long_query_time';—— 建议设为1或0.5，尤其高并发 OLTP 场景 -
SHOW VARIABLES LIKE 'slow_query_log_file';—— 检查路径权限，MySQL 进程得有写入权限 - 执行一条人为慢 SQL 测试：
SELECT SLEEP(2);，再立刻tail -f日志文件看是否落盘
如何快速定位谁在耗连接、谁在刷慢查询
单靠状态变量只能看到“量”，要定位“人”和“SQL”，得结合 SHOW FULL PROCESSLIST 和慢日志解析。
容易踩的坑是：没加 FULL 导致 SQL 被截断；或者只看 State 列却忽略 Time 和 User。
-
SHOW FULL PROCESSLIST;—— 关注Time> 60s 且State是Locked、Sending data或Copying to tmp table的线程 - 慢日志别直接用 vim 打开，用
mysqldumpslow -s t -t 10 /var/lib/mysql/slow.log按执行时间倒序取 top 10 - 如果用了 ProxySQL 或中间件，慢查询可能被拦截或重写，得去中间件侧查日志，不能只盯 MySQL 原生日志
连接数突增但没慢查询？先查锁和事务
有时候 Threads_connected 暴涨，Slow_queries 却几乎为 0，说明不是 SQL 慢，而是连接卡在等资源——最常见的是锁等待或长事务。
这时候光看慢日志没用，得盯 InnoDB 锁状态和事务运行时长：
-
SHOW ENGINE INNODB STATUS\G—— 查TRANSACTIONS和LATEST DETECTED DEADLOCK部分 -
SELECT * FROM information_schema.INNODB_TRX WHERE TIME_TO_SEC(timediff(NOW(), trx_started)) > 60;—— 找运行超 60 秒的事务 -
SELECT * FROM information_schema.INNODB_LOCK_WAITS;—— 查当前锁等待链（MySQL 5.7+） - 注意：
INFORMATION_SCHEMA表查询本身可能被阻塞，如果卡住，说明锁问题已经很严重了
监控连接数和慢查询不是两个孤立动作。真正麻烦的往往是连接数上去了，慢查询没增加，但 QPS 掉了——这种时候，锁、事务、甚至客户端连接池配置（比如 HikariCP 的 maximumPoolSize 和 connection-timeout）全得一起看。
