mysqldump无法通过performance_schema或show processlist获取实时进度，因其采用短连接，语句执行快、痕迹短暂；最可靠方法是--verbose日志配合表计数估算百分比，或用pv监控写入速率预估eta。
mysqldump 本身不暴露实时进度，MySQL 服务端也几乎不记录它的执行过程——想拿到百分比或剩余时间，必须在客户端侧加干预，不能靠 performance_schema 或 SHOW PROCESSLIST 查“正在 dump 哪张表”来推断。
为什么 performance_schema.EVENTS_STATEMENTS_CURRENT 看不到 mysqldump 进度
因为 mysqldump 是短连接工具：每查一张表就建一次连接、发一条 SELECT、取完结果立刻断开。它在服务端留下的痕迹只是零星快照，EVENTS_STATEMENTS_CURRENT 里基本抓不到活跃语句；threads.PROCESSLIST_INFO 虽可能含表名，但字段易截断、状态不可靠（常为 Sleep），无法区分“刚查完第1张”还是“正卡在第99张”。
- 别在备份脚本里查
performance_schema.events_statements_history_long想凑出进度——查到的都是已结束的语句，没时序、无上下文 -
SHOW PROCESSLIST只能确认“有个 mysqldump 连接存在”，但Time列反映的是空闲时长，不是 dump 耗时 - 真正有用的只有客户端输出、文件写入行为、或你主动埋点的日志
用 --verbose + 表计数法估算百分比
这是最轻量、最可靠的进度估算方式，适用于绝大多数 mysqldump 场景。
- 先获取目标库总表数：
SELECT COUNT(*) FROM information_schema.TABLES WHERE TABLE_SCHEMA = 'your_db' - 执行带
--verbose的 dump：mysqldump --verbose --databases your_db > backup.sql 2> dump.log - 实时解析日志：用
tail -f dump.log | grep "Dumping data for table"统计出现次数，每匹配一行代表一张表开始导出 - 注意：
--verbose输出中 “Dumping data for table” 出现在数据导出阶段，比 “Creating table” 更贴近实际耗时主体 - 若库中含视图或空表，可额外过滤掉
CREATE VIEW和INSERT INTO ... SELECT类语句避免误计
用 pv 工具监控写入速率并预估剩余时间
当备份文件写入是瓶颈（如网络挂载盘、慢速 SSD），pv 能基于字节流给出实时速率和 ETA。
- 安装
pv：apt install pv（Debian/Ubuntu）或yum install pv（RHEL/CentOS） - 管道式 dump：
mysqldump --single-transaction your_db | pv -w 50 -s $(du -b /dev/stdin | awk '{print $1}') > backup.sql——但/dev/stdin大小未知，更实用的是先估算： - 经验公式：总大小 ≈
SELECT SUM(data_length + index_length) FROM information_schema.TABLES WHERE TABLE_SCHEMA = 'your_db'，单位字节 - 运行命令：
mysqldump --single-transaction your_db | pv -w 50 -s 2147483648 > backup.sql（假设估算 2GB） -
pv会显示当前速率、已传输量、预计剩余时间（ETA），但注意：该 ETA 仅对写入速率稳定有效；若 mysqldump 因锁表或网络抖动卡顿，pv会停转，此时需结合--verbose日志判断是否真卡住
对单张大表单独监控更准，但需改写 dump 逻辑
如果某张表占全库体积 70% 以上（比如日志表），整体表计数法误差会很大。这时应把它拆出来单独处理，并监控其内部进度。
- 用
--where分批导出：mysqldump --where="id BETWEEN 1 AND 100000" your_db logs_table > logs_part1.sql - 提前查总量：
SELECT COUNT(*) FROM logs_table（或用TABLE_ROWS快速估算） - 每次 dump 后记录偏移量到临时文件：
echo "100000" > /tmp/logs_offset，外部脚本可读取并计算百分比 - 避免用
LIMIT直接分页（易漏数据），优先用主键区间或时间范围（如created_at ） - 注意：
--where不支持视图，且需确保字段有索引，否则扫描代价反而更高
真正难的不是算百分比，而是区分“慢但正常”和“已卡死”。--verbose 日志间隔超过 30 秒无新表输出、pv 速率长期低于 1MB/s 且无波动、或 du -h backup.sql 卡在某个大小不动——这些信号比任何百分比都关键。进度监控的本质，是给运维一个“要不要杀掉重来”的决策依据，而不是追求精确到小数点后两位。
