实测备份资源消耗需用pidstat监控mysqldump进程的%CPU和%MEM，结合SHOW GLOBAL STATUS对比备份前后Threads_created、Created_tmp_tables等指标变化，并关注--single-transaction、--skip-extended-insert、--compress三个关键参数影响。
备份操作对CPU和内存的消耗必须实测，不能靠估算——因为同一份mysqldump命令在不同表结构、不同并发、不同buffer配置下，资源开销可能差3倍以上。
用pidstat抓取备份进程的实时CPU/内存占用
直接监控mysqldump自身进程比看整体系统负载更准，尤其当服务器跑着其他服务时：
- 先查出
mysqldump的PID：pgrep -f "mysqldump.*--databases"（注意过滤掉grep自身） - 用
pidstat -p <pid> 1</pid>每秒刷新一次，重点关注%CPU和%MEM列 - 如果
%CPU持续超过80%，说明备份本身在争抢CPU；若%MEM单次飙升超500MB，要警惕临时排序或大结果集缓存 - 别只看峰值——连续5秒以上>60%才值得干预
对比备份前后SHOW GLOBAL STATUS关键指标变化
备份会触发大量读页、临时表、线程创建等行为，这些都会在MySQL内部状态里留下痕迹：
- 备份前执行：
SELECT VARIABLE_NAME, VARIABLE_VALUE FROM performance_schema.global_status WHERE VARIABLE_NAME IN ('Threads_created', 'Created_tmp_tables', 'Innodb_buffer_pool_read_requests', 'Innodb_buffer_pool_reads'); - 备份完成后立刻再查一次，重点看：
-
Threads_created是否猛增 → 表明mysqldump启用了太多连接（比如--single-transaction+ 多表并行） -
Created_tmp_tables大幅上升 → 某些表导出时触发了隐式临时表（如含ORDER BY但没走索引） -
Innodb_buffer_pool_reads增长远超read_requests→ 缓冲池命中率暴跌，磁盘IO压力传导为CPU等待
-
mysqldump参数对CPU/内存影响最明显的三个选项
不是所有参数都平等——这三个开关实际决定资源吃紧程度：
-
--single-transaction：降低锁竞争，但会延长一致性读视图生命周期，增加undo段扫描开销，CPU集中在trx_purge相关函数上 -
--skip-extended-insert：把一条INSERT拆成多行，内存占用下降30%~50%，但CPU因解析/拼接SQL增多而上升10%~20% -
--compress：启用网络压缩，CPU上升明显（尤其在高吞吐场景），但内存峰值可能反降——因为减少socket buffer堆积 - 慎用
--opt（默认开启）：它自动加--add-drop-table--create-options等，导致额外元数据查询，小表影响不大，大库下会多占2~3个线程
备份期间free -m和top容易误判的两个现象
系统内存显示“可用内存少”不等于MySQL真缺内存，CPU飙高也不全是mysqldump的锅：
-
free -m里available偏低，但buff/cache很高 → 这是Linux把空闲内存用于文件缓存，mysqldump读表时自然填充，属正常行为，不用干预 -
top里mysqld进程CPU高，但mysqldump进程CPU只有5% → 真正耗CPU的是MySQL服务端在处理备份请求（如构建一致性快照、生成INSERT语句），不是客户端 - 真正该盯的是
mysqld进程的%CPU是否同步上涨，以及pidstat -p <mysqld_pid> -t 1</mysqld_pid>里是否有大量线程卡在row_search_for_mysql或filesort
最常被忽略的是：备份脚本里没加--no-autocommit，导致每条INSERT都触发一次事务提交逻辑，CPU浪费在线程同步和redo刷盘上——这个细节会让同样数据量的备份多耗15%~25% CPU。
