mysql慢查询日志不记录xtrabackup等物理备份的i/o操作，仅捕获mysqldump等工具执行的慢sql；需结合performance_schema和iostat定位真实i/o瓶颈。
如何确认慢查询日志是否真在记录备份相关操作
MySQL 慢查询日志（slow_query_log）默认只记录 SELECT、INSERT、UPDATE、DELETE 等客户端发起的 SQL 语句，而物理备份（如 mysqldump 或 mysqlpump）产生的查询会被记录，但逻辑备份工具本身不触发慢日志；XtraBackup 等物理备份工具完全绕过 SQL 层，其 I/O 行为根本不会出现在慢日志里。
所以第一步必须明确：你看到的“备份慢”，到底是备份工具执行 SQL 导致的慢（比如 mysqldump --single-transaction 在大表上启事务卡住），还是磁盘 I/O 本身拖慢了备份进程（比如 XtraBackup 读取 ibdata1 时被系统 I/O 压垮）。
实操建议：
- 检查
slow_query_log是否开启，且long_query_time设得足够低（例如0.1），否则备份中那些“不算慢但很耗时”的查询会被忽略 - 对
mysqldump类工具，在命令中加--log-error=backup.err并配合--verbose，观察是否卡在某个SELECT或SHOW CREATE TABLE - 用
pt-query-digest分析慢日志时，加--filter '$event->{arg} =~ m/^(SELECT|SHOW)/i'过滤出备份期间的典型语句，别被管理语句干扰
为什么 slow_query_log 里查不到 I/O 等待，得看 performance_schema
慢查询日志只告诉你“这条 SQL 执行了 12 秒”，但不告诉你这 12 秒里有 11.8 秒花在等待磁盘读——这是 performance_schema 的职责。特别是 events_waits_summary_global_by_event_name 和 file_summary_by_instance 这两张表，能直接定位到哪个文件（如 /var/lib/mysql/ibdata1）或哪类 I/O（如 wait/io/file/innodb/innodb_data_file）在拖慢整体节奏。
常见错误现象：备份时 SHOW PROCESSLIST 显示线程状态是 Copying to tmp table 或 Sending data，但 CPU 使用率很低，top 看 %wa 却长期高于 60%——这就是典型的磁盘 I/O 等待，和慢日志无关。
实操建议：
- 确保
performance_schema已启用（performance_schema=ON），且关键消费者已打开：UPDATE setup_consumers SET ENABLED='YES' WHERE NAME LIKE 'events_waits%'; - 备份前执行一次
TRUNCATE TABLE performance_schema.events_waits_summary_global_by_event_name;，避免历史噪音干扰 - 备份过程中运行：
SELECT EVENT_NAME, COUNT_STAR, SUM_TIMER_WAIT/1e9 AS time_s FROM performance_schema.events_waits_summary_global_by_event_name WHERE EVENT_NAME LIKE 'wait/io/file/innodb%' AND SUM_TIMER_WAIT > 0 ORDER BY SUM_TIMER_WAIT DESC LIMIT 5;
重点关注innodb_data_file和innodb_log_file的等待时间
磁盘 I/O 瓶颈的三个典型信号与对应验证方式
不是所有 I/O 高都等于瓶颈。真正影响备份性能的，是随机读放大、吞吐饱和或延迟突增。这三个信号在不同层级表现不同，需要交叉验证。
使用场景：XtraBackup 全量备份时耗时从 25 分钟涨到 1 小时，iostat -x 1 显示 %util 接近 100%，但 await 只有 3ms——这说明设备没堵死，可能是队列深度或并发策略问题；若 await 超过 20ms 且 r_await 显著高于 w_await，才更可能是磁盘响应能力不足。
实操建议：
-
看内核层：用
iostat -xmt 1观察r/s、w/s、rkB/s、wkB/s，对比备份前后数值。SSD 上avgqu-sz长期 > 4 通常意味着 I/O 请求积压 -
看 MySQL 层：查
INFORMATION_SCHEMA.INNODB_METRICS中log_writes、buffer_pool_reads、buffer_pool_read_requests，计算缓存命中率（1 - buffer_pool_reads/buffer_pool_read_requests）。低于 95% 时，备份中大量物理读会加剧 I/O 压力 -
看文件系统层：用
lsof -p $(pgrep mysqld) | grep -E '\.ibd|ibdata|ib_logfile' | wc -l确认备份是否被迫读取大量冷数据文件；若数字远大于当前活跃表数量，说明 buffer pool 太小或预热不足
备份参数与 I/O 行为的隐式耦合关系
很多备份参数表面看是控制并发或压缩，实际会剧烈改变 I/O 模式。比如 mysqldump --skip-lock-tables --single-transaction 在大事务中可能引发长 rollback segment 扫描，间接导致大量 undo log 读；xtrabackup --parallel=4 不是简单开 4 个线程，而是让每个线程按 chunk 读取 ibd 文件，chunk 大小由 innodb_page_size 决定，最终体现为随机读还是顺序读，取决于表空间碎片程度。
性能影响常被忽略的一点：启用 innodb_buffer_pool_dump_at_shutdown 后，备份前 MySQL 关闭会 dump 缓存热点页，若此时启动备份，两个高 I/O 操作叠加，iowait 会雪崩式上升。
实操建议：
- XtraBackup 加
--throttle=100（单位 IOPS）比单纯调--parallel更可控，尤其在混部环境 -
mysqldump避免用--opt（默认含--extended-insert），它会让单条 INSERT 包含上千行，内存压力大且生成临时文件多；改用--skip-extended-insert+--net_buffer_length=262144 - 备份窗口内禁用
innodb_buffer_pool_dump_now和innodb_buffer_pool_load_now，防止 buffer pool 主动刷盘干扰
真正的瓶颈往往藏在「备份工具没报错、MySQL 没告警、iostat 数值看起来还行」的中间地带——这时候得把 performance_schema 的等待事件、iostat 的细分指标、以及备份命令的实际 I/O 模式三者对齐，缺一不可。
