如何实时追踪 mysqldump 的备份进度？
当你在生产环境执行一个大型数据库备份时，看着 mysqldump 命令启动后似乎就“卡住”了，这感觉确实让人心里没底。它到底在备份哪张表？完成了多少？会不会卡死了？别急，虽然 mysqldump 本身没有内置的进度条，但我们完全有办法透视它的工作状态。
可通过 SHOW PROCESSLIST 查看 mysqldump 当前操作的表，重点观察 STATE（如 Sending data）和 INFO 字段，并确认连接用户为 dump 进程；INFO 可能被截断，需用 SUBSTRING 提取完整语句。
怎么查 mysqldump 正在备份哪张表
mysqldump 进程本身不会主动报告实时进度，但它的每一个动作，都会在 MySQL 服务端留下痕迹。最直接的窗口，就是查看 SHOW PROCESSLIST 命令的输出，观察它正在执行的具体 SQL 语句。当然，如果你在启动 mysqldump 时加了 --verbose 参数，它会在终端打印类似 “Dumping data for table `xxx`” 的提示，不过在生产环境，为了输出简洁，这个参数通常会被省略。
更可靠的做法是，连接到目标 MySQL 实例，查询 information_schema.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字段显示的 SQL 语句可能会被截断（默认只显示前100个字符）。这时可以用SELECT SUBSTRING(INFO, 1, 200) FROM ...来获取更完整的语句。 - 如果 mysqldump 使用了
--single-transaction参数，你可能会发现它的STATE长时间停留在Starting transaction或executing。别紧张，这并不代表卡住了，而是说明事务已经启动，正在以流式方式读取数据。 - 最后，务必确认你观察到的连接用户是执行备份的
dump用户，别和其他应用的长查询搞混了。
为什么 SHOW PROCESSLIST 看不到 dump 进度百分比
这可能是最让人困惑的一点：为什么只能看到它在“做什么”，却看不到“做了多少”？原因在于，MySQL 的线程状态机制是离散的、事件驱动的，它就像一个任务清单，只告诉你当前在执行哪项任务，而不是一个从0%到100%的连续进度条。比如 Sending data 这个状态，可能持续几秒钟，也可能长达几十分钟——这完全取决于表的大小、索引效率、磁盘 I/O 速度以及网络带宽。
真正影响我们对进度感知的，其实是 mysqldump 自身的输出行为模式：
- 默认情况下，它按表进行备份，只有完整备份完一张表的数据后，才会将结果写入文件，中间过程没有任何输出，所以看起来就像“静止”了一样。
- 通过添加
--skip-triggers --skip-routines --skip-events等参数，可以减少对存储过程、触发器等元数据的查询开销，这样STATE就能更快地切换到实质性的数据读取阶段（Sending data）。 - 如果使用
--tab模式将数据导出为文本文件，STATE的切换会频繁得多，但实际的磁盘写入速度仍受操作系统缓冲区影响。这时，通过lsof -p [pid]命令查看文件写入的偏移量，反而能获得更直观的进展信息。
mysqldump 备份慢，PROCESSLIST 显示 Waiting for table flush 怎么办
遇到 Waiting for table flush，这通常是元数据锁（MDL）阻塞的典型信号。它常常发生在备份过程中，恰好有 DDL 操作（比如 ALTER TABLE、DROP TABLE）在执行，或者存在长时间未提交的事务。
第一步是定位锁的持有者：
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却忘记提交的“空闲事务”。 Waiting for table flush有时也可能是因为FLUSH TABLES WITH READ LOCK操作没有释放。检查一下，是否有其他备份脚本或监控工具在同一时间尝试获取锁。- 一个根本的预防建议是：尽量避免在业务高峰期执行全库 dump。对于特别大的表，可以考虑单独备份，甚至使用
--where="1 limit 1000000"这样的条件进行分批导出和验证。
用 pt-heartbeat 或 INFORMATION_SCHEMA.TABLES 估算剩余时间靠谱吗
坦率地说，不太靠谱。pt-heartbeat 工具主要用于测量主从复制延迟，跟本地 dump 的进度没有直接关系。而 INFORMATION_SCHEMA.TABLES 表中的 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命令测试单表的数据量大小，以此反推大致的耗时比例。 - 必须记住：网络传输（如远程备份）、SSL 加密、使用
--compress参数进行压缩，这些都会显著增加备份时间，但这些开销在PROCESSLIST的STATE里是看不到的。
说到底，备份进度是 I/O 吞吐、CPU 处理能力和锁竞争情况叠加后的综合结果。盯着 STATE 主要是为了预防进程卡死，想精确计算“还剩几分钟”几乎是不可能的任务。所以，最好别相信任何声称能“自动估算进度”的脚本，它们多半只是把一些随机数包装得看起来像那么回事而已。
