可通过 show processlist 查看 mysqldump 当前操作的表，重点观察 state（如 sending data）和 info 字段，并确认连接用户为 dump 进程；info 可能被截断，需用 substring 提取完整语句。
怎么查 mysqldump 正在备份哪张表
mysqldump 本身不暴露实时进度，但可以通过 SHOW PROCESSLIST 观察它当前执行的 SQL。如果启用了 --verbose（或 -v），它会在终端打印 “Dumping data for table xxx” 这类提示，但生产环境通常不加这个参数。
更可靠的方式是连上 MySQL，查 information_schema.PROCESSLIST 或直接用 SHOW PROCESSLIST：
SELECT ID, USER, HOST, DB, COMMAND, TIME, STATE, INFO FROM information_schema.PROCESSLIST WHERE COMMAND = 'Query' AND INFO LIKE 'SELECT %';
重点看 STATE 字段：如果是 Sending data，说明正在读取某张表的数据；Copying to tmp table 可能意味着有 GROUP BY 或 ORDER BY 触发了临时表；Locked 则大概率卡在表锁或元数据锁上。
-
INFO字段可能被截断（默认 100 字符），用SELECT SUBSTRING(INFO, 1, 200) FROM ...看更全的语句 - 如果 mysqldump 加了
--single-transaction，STATE多数时间会停在Starting transaction或executing，不代表卡住，而是事务已开启、正在流式读取 - 注意区分用户：确保你看到的是
dump用户的连接，不是其他应用的长查询
为什么 SHOW PROCESSLIST 看不到 dump 进度百分比
MySQL 的线程状态是离散的、事件驱动的，不是连续进度条。它只告诉你“此刻在做什么”，不告诉你“还剩多少”。比如 Sending data 可能持续几秒，也可能几十分钟——取决于表大小、索引效率、磁盘 I/O 和网络带宽。
真正影响感知进度的，其实是 mysqldump 的输出行为：
- 默认按表 dump，每张表 dump 完才写入文件，中间无输出 → 看起来“卡住”
- 加
--skip-triggers --skip-routines --skip-events可减少元数据查询开销，让STATE更快切换到Sending data - 使用
--tab模式导出为文本时，STATE会频繁切换，但实际写盘仍依赖 OS 缓冲，lsof -p [pid]才能看到文件写入偏移量
mysqldump 备份慢，PROCESSLIST 显示 Waiting for table flush 怎么办
这是典型元数据锁（MDL）阻塞，常见于备份期间有 DDL（如 ALTER TABLE、DROP TABLE）或长时间未提交的事务在运行。
先定位谁在 hold 锁：
SELECT BLOCKING_TRX_ID, BLOCKED_TRX_ID FROM performance_schema.data_lock_waits;
或者更直接地查活跃事务：
SELECT TRX_ID, TRX_STARTED, TRX_STATE, TRX_QUERY FROM information_schema.INNODB_TRX ORDER BY TRX_STARTED;
- 如果发现
TRX_STATE = 'RUNNING'且TRX_QUERY为空，可能是空闲事务（autocommit=OFF 后没 commit） -
Waiting for table flush有时也因FLUSH TABLES WITH READ LOCK未释放，检查是否有其他备份脚本或监控工具在抢锁 - 避免在业务高峰跑全库 dump；对大表单独 dump，并加
--where="1 limit 1000000"分批验证
用 pt-heartbeat 或 INFORMATION_SCHEMA.TABLES 估算剩余时间靠谱吗
不靠谱。pt-heartbeat 测的是复制延迟，和本地 dump 无关；TABLE_ROWS 是估算值（尤其 InnoDB），误差常达 50% 以上，且不包含 BLOB/TEXT 实际体积、索引大小、压缩比等关键因子。
真正可操作的参考点只有两个：
- 用
du -h对比目标备份文件增长速度（注意：gzip 压缩是流式，文件大小不能线性推算原始数据量） - 结合
SELECT TABLE_NAME, DATA_LENGTH + INDEX_LENGTH FROM information_schema.TABLES WHERE TABLE_SCHEMA = 'db_name' ORDER BY DATA_LENGTH DESC LIMIT 5;找出最大几张表，手动用mysqldump -t -d db_name table_name | wc -c测单表裸数据大小，反推耗时 - 记住：网络传输（如远程 dump）、加密（SSL）、压缩（–compress）都会显著拉长时间，但不会反映在
PROCESSLIST的STATE里
进度这种事，本质是 IO + CPU + 锁的叠加结果。盯着 STATE 只能防卡死，没法算还剩几分钟——别信任何“自动估算进度”的脚本，它们只是把随机数包装得像真的一样。
