information_schema.processlist 是最轻量实时的会话监控方式，支持sql过滤与关联，比文本型 show processlist 更适合脚本化；需结合 state、command 和 innodb_trx 等字段综合判断真慢sql与假活跃事务。
直接查 INFORMATION_SCHEMA.PROCESSLIST 是最轻量、最实时的会话监控方式，无需额外配置，但要注意它只反映“连接层”状态，不等于事务层活跃。
为什么 PROCESSLIST 比 SHOW PROCESSLIST 更适合脚本化监控
两者数据源一致，但 INFORMATION_SCHEMA.PROCESSLIST 是标准表，可加 WHERE、ORDER BY、字段筛选，也支持 JOIN 关联其他系统表（比如和 performance_schema.threads 补充 PROCESSLIST_INFO）；而 SHOW PROCESSLIST 输出是文本流，解析成本高、易出错。
常见错误现象：用 mysql -e "SHOW PROCESSLIST" 在 shell 脚本里 grep 字段，结果因列宽变化或空格缩进导致匹配失败。
实操建议：
- 始终用
SELECT ID, USER, HOST, DB, COMMAND, TIME, STATE, INFO FROM INFORMATION_SCHEMA.PROCESSLIST，避免SELECT *——INFO字段可能超长，影响网络传输和日志体积 - 过滤掉空闲连接：
WHERE COMMAND != 'Sleep'，否则 90% 的结果都是无效噪音 - 若需排除监控自身连接，加
AND USER != 'monitor_user'（替换为你的监控账号） - MySQL 8.0+ 中，
INFO默认被截断（max_allowed_packet 限制），如需完整 SQL，确保客户端连接时设置--column-type-info或在 SQL 前加SET SESSION group_concat_max_len = 1048576;
TIME 字段的真实含义和误判风险
TIME 是该线程处于当前 COMMAND 状态的秒数，不是 SQL 执行总耗时。比如一个事务里执行了 SELECT 后就停住没提交，TIME 会持续增长，但 COMMAND 可能还是 Query，STATE 是 Sending data 或空 —— 这类“假活跃”最容易被当成慢查询误杀。
使用场景：适合捕获明显卡住的连接（如 TIME > 300 且 STATE = 'Locked'），但不能单独作为事务是否异常的判断依据。
实操建议：
- 别只看
TIME，必须结合STATE和COMMAND：例如COMMAND = 'Sleep'时TIME表示空闲时长，完全无害 -
STATE = 'Sending data'不一定慢，可能是大结果集传输中；STATE = 'Sorting result'或'Copying to tmp table'才更值得警惕 - 生产环境阈值建议从
TIME >= 30开始试，主库慎用>= 5—— 短连接频繁建连也会触发误报
如何关联 PROCESSLIST 和真实事务状态
INFORMATION_SCHEMA.PROCESSLIST 里的 ID 字段对应 INFORMATION_SCHEMA.INNODB_TRX.trx_mysql_thread_id，这是唯一可靠的跨表关联键。仅靠 USER 或 HOST 匹配会出错，尤其在连接池复用场景下。
容易踩的坑：有人试图用 SHOW ENGINE INNODB STATUS 解析事务，但它只保留最近一次输出，无法用于轮询监控；还有人 JOIN performance_schema.threads 时用错字段（THREAD_ID ≠ PROCESSLIST.ID，得用 PROCESSLIST_ID）。
实操建议：
- 一次关联查询示例：
SELECT p.ID, p.USER, p.HOST, p.DB, p.TIME, p.STATE, t.TRX_STARTED, t.TRX_STATE, t.TRX_QUERY<br>FROM INFORMATION_SCHEMA.PROCESSLIST p<br>JOIN INFORMATION_SCHEMA.INNODB_TRX t ON p.ID = t.TRX_MYSQL_THREAD_ID<br>WHERE t.TRX_STATE = 'RUNNING' AND TIMESTAMPDIFF(SECOND, t.TRX_STARTED, NOW()) > 60;
- 注意
INNODB_TRX是内存视图，高频扫描（如每 5 秒）会影响性能，建议轮询间隔 ≥ 15 秒 - MySQL 8.0+ 中，
INNODB_LOCKS已废弃，查锁必须用performance_schema.data_locks，其ENGINE_TRANSACTION_ID才对应INNODB_TRX.TRX_ID
真正难的是区分“真慢 SQL”和“假活跃事务”——前者要优化语句或索引，后者往往只是应用端忘了 COMMIT 或连接池配置不当。监控脚本里光筛 TIME 不够，必须把 TRX_STARTED、TRX_STATE、STATE 三者时间戳和状态组合起来看，缺一不可。
