可通过查询information_schema.processlist判断mysqldump当前处理的表，重点观察user、state（如sending data）和substring(info,1,200)字段，确认其正在执行的select语句及对应表名。
mysqldump 本身不提供百分比进度，但通过 information_schema.PROCESSLIST 可以准确判断它正在处理哪张表、卡在哪一步——这是生产环境最可靠、最轻量的实时观测方式。
怎么看 mysqldump 当前在 dump 哪张表
连接 MySQL 后执行：
SELECT ID, USER, HOST, DB, COMMAND, TIME, STATE, SUBSTRING(INFO, 1, 200) AS INFO FROM information_schema.PROCESSLIST WHERE USER = 'backup' AND COMMAND = 'Query' AND INFO LIKE 'SELECT %';
关键点：
-
USER = 'backup'必须匹配你运行 mysqldump 时所用的账号，避免误判其他长查询 -
STATE = 'Sending data'表示正在从某张表读取行数据；如果长时间停留在此状态，说明这张表大或索引差 -
INFO字段默认只显示前 100 字符，必须用SUBSTRING(INFO, 1, 200)才能看到完整表名（例如SELECT * FROM `orders` WHERE ...） - 若看到
Copying to tmp table，说明当前语句含GROUP BY或ORDER BY，触发了临时表，不是卡死，但可能慢
为什么 SHOW PROCESSLIST 看不到“XX% 完成”
MySQL 的线程状态是瞬时快照，不是连续计数器。它只告诉你“此刻在做什么”，不记录“已处理多少行”或“共多少行”。几个典型现象：
-
--single-transaction模式下，STATE长期停留在Starting transaction或executing—— 这是正常行为，事务已开启，后续以流式方式拉取数据 - 大表导出时，
Sending data可能持续数分钟，不代表卡住，而是 I/O 或网络吞吐限制 - 如果
STATE = 'Locked'或'Waiting for table flush'，大概率是被 DDL（如ALTER TABLE）或未提交事务阻塞，需查performance_schema.data_lock_waits
如何避免误读 processlist 导致误操作
常见误判场景和应对：
- 看到多个
USER = 'backup'连接？可能是并发 dump 多库，注意区分DB字段，别 kill 错连接 -
INFO显示SELECT DATABASE()或空值？那是 mysqldump 初始化阶段，还没开始真正 dump 表，不用干预 - 用
root账号跑 dump，但PROCESSLIST里USER显示为'root'@'localhost'—— 此时不能只靠USER过滤，加HANDLER = 'mysqldump'不现实，建议改用专用账号（如backup）并严格授权 -
TIME值很大（比如 > 300），但STATE是Sending data？先看磁盘 I/O（iostat -x 1）和网络（iftop），再决定是否中断
真正影响进度感知的，从来不是 SQL 状态本身，而是 mysqldump 的输出粒度：它默认按表写入，中间无缓冲输出。哪怕一张表要导 20 分钟，终端也完全静默——这时候盯着 PROCESSLIST 看表名切换，比等终端打印更靠谱。
