mysqldump 不被 Performance Schema 的 statement instruments 捕获，因其短查询、无长事务；监控进度需客户端侧实现，如 --verbose 解析、表数统计或写标记日志。
mysqldump 本身不走 Performance Schema，别白查 EVENTS_STATEMENTS_CURRENT
mysqldump 是客户端工具，它通过 MySQL 协议发起查询（如 SELECT、SHOW CREATE TABLE），但这些语句的执行过程**不会被 Performance Schema 的 statement instruments 捕获为“当前正在运行”的语句**。原因很直接：mysqldump 每次只发一个短查询、拿完结果就断开连接，中间没有长事务或持续执行的 SQL 线程。所以你在 performance_schema.EVENTS_STATEMENTS_CURRENT 或 events_statements_history_long 里基本看不到它——就算看到，也是零星的、已结束的快照，没法构成进度依据。
真正能查到的只有连接和线程状态，不是备份进度
你可以用 SHOW PROCESSLIST 或查 performance_schema.threads + processlist_info 字段，看到类似 mysqldump --user=root ... 这样的连接，但它的 PROCESSLIST_STATE 大概率是 NULL 或 Sleep，因为 dump 过程中大部分时间在客户端解析、写文件，服务端线程早已空闲。这不是 bug，是协议设计使然。
唯一有点用的关联点是：performance_schema.threads 中的 PROCESSLIST_INFO 可能包含当前正在 dump 的表名（如果 mysqldump 正在执行 SELECT * FROM t1），但这个字段不稳定、易截断、且无法区分“刚开查”还是“快结束了”，不能用于进度计算。
想监控进度？得从客户端侧加 hook，不是靠服务端表
要真实反映 mysqldump 进度，必须在调用端做手脚，而不是指望 MySQL 自身暴露指标。常见有效做法包括：
• 加 --verbose 并实时解析输出：mysqldump --verbose --databases db1 | grep -E "Dumping data|CREATE TABLE"，配合计数器统计已出现的表名数量
• 预先查表总数：用 SELECT COUNT(*) FROM information_schema.TABLES WHERE TABLE_SCHEMA = 'db1' 获取总表数，再和 --verbose 输出匹配，算百分比
• 对大表单独监控：若某张表占备份体积 80%，可在脚本中对它加 --where="id > X" 分批 dump，并记录每次 LIMIT 偏移量
• 写临时标记文件：每 dump 完一张表，就 echo "$(date +%s) table_name" >> /tmp/dump_progress.log，外部脚本可 tail 实时读取
Performance Schema 能帮上忙的唯一场景：物理备份（xtrabackup）
Percona XtraBackup 在 prepare 或 copy-back 阶段会启动内部线程，部分操作（如 log copying、page archiving）可能触发 wait/io/file/innodb/innodb_log_file 类等待事件。这时查 performance_schema.events_waits_current 或 events_waits_history_long 才有意义——但注意，它反映的是 I/O 等待，不是“还剩多少没拷”，更不是逻辑进度。
真正可靠的物理备份进度，还是得看 xtrabackup 自己的 --progress 输出，或解析其日志里的 Progress: 123456789/987654321 bytes 这类行。
别把 performance_schema 当万能表；它不记录客户端行为，也不聚合业务语义。备份进度这事，得在 shell 里动手脚，不是在 SQL 里查表。
