MySQL在XtraBackup备份时崩溃，大概率是被系统OOM killer杀死，需优先执行dmesg -T | grep -i "killed process" | grep mysqld确认；若存在对应记录，再查系统日志验证时间一致性，否则排查XtraBackup参数、磁盘空间或FTWRL锁超时。
MySQL在XtraBackup备份过程中崩溃，大概率不是XtraBackup自己崩了，而是它触发了MySQL进程被系统OOM killer强制杀死——尤其是备份时MySQL内存使用瞬间飙升，宿主机扛不住就“处决”mysqld。必须跳出“查MySQL日志”的惯性，从系统层反向验证。
确认是不是被oom-killer杀掉的
这是最关键的一步，跳过它后面全白忙。
- 立刻执行
dmesg -T | grep -i "killed process" | grep mysqld，看输出里有没有带时间戳的Killed process XXX (mysqld)记录 - 核对这个时间是否和XtraBackup执行期间MySQL突然退出的时间一致（注意容器场景下看宿主机
dmesg，不是容器内） - 再查
/var/log/messages或/var/log/syslog，搜索oom_kill或badness，确认同一时刻是否有匹配条目 - 如果没找到任何OOM痕迹，别调
innodb_buffer_pool_size——问题可能出在XtraBackup参数、磁盘空间不足、或MySQL配置里ftwrl锁等待超时
XtraBackup备份时MySQL内存为何会猛增
不是XtraBackup吃内存，是它迫使MySQL在短时间内密集加载大量资源：
-
FLUSH TABLES WITH READ LOCK（FTWRL）执行时，MySQL要为所有表构建元数据快照，尤其当有几百张表+大量触发器时，memory/sql/sp_head::main_mem_root会暴涨几GB - 备份InnoDB表前需扫描所有
.ibd文件并校验页，若表碎片严重或存在损坏页，会反复重试+缓存中间状态 - 如果启用了
performance_schema且未关闭memory/%统计，备份期间SQL线程加载触发器/SP上下文会触发大量内存分配 -
--parallel=4这类参数会让XtraBackup并发读多个表空间，MySQL侧对应产生多个后台线程，每个都带自己的sort_buffer_size、read_buffer_size
快速定位内存热点的SQL方法
别等崩溃后再查，备份前先跑一次实时内存分布快照：
- 连接MySQL后执行：
SELECT EVENT_NAME, CURRENT_NUMBER_OF_BYTES_USED FROM performance_schema.memory_summary_global_by_event_name WHERE CURRENT_NUMBER_OF_BYTES_USED > 104857600 ORDER BY CURRENT_NUMBER_OF_BYTES_USED DESC LIMIT 5;
关注前三名是否含memory/sql/sp_head、memory/innodb/buf_buf_pool、memory/heap/HP_SHARE - 特别检查：
SELECT * FROM performance_schema.memory_summary_global_by_event_name WHERE EVENT_NAME = 'memory/sql/sp_head::main_mem_root';
若该值 >500MB，说明触发器/存储过程是隐形炸弹 - 备份中若发现
Threads_running突增至20+且持续不降，大概率是FTWRL卡在某张大表或损坏表上，正在反复尝试获取锁
备份阶段能立即生效的缓解措施
这些操作不需要重启MySQL，适合应急：
- 临时关掉性能监控：
SET GLOBAL performance_schema = OFF;（注意：下次重启失效，如需永久关闭得改my.cnf） - 限制备份并发度：
--parallel=1或--use-memory=512M（XtraBackup 8.0+支持），避免MySQL侧线程数爆炸 - 跳过非关键对象：用
--exclude='mysql\.slave_.*'排除系统表，减少FTWRL扫描负担 - 提前清理大临时表：
SELECT CONCAT('DROP TEMPORARY TABLE IF EXISTS ', table_name, ';') FROM information_schema.tables WHERE table_schema = 'tempdb' AND table_type = 'TEMPORARY';防止备份时临时表元数据拖慢锁获取
真正危险的不是XtraBackup本身，而是它像一面镜子，把MySQL配置里那些平时不显眼的“内存叠buff”问题（比如max_connections=1000 + sort_buffer_size=4M + 几十个触发器）一次性照出来。每次备份前，建议用MemAvailable值减去3GB作为硬上限，重新核算innodb_buffer_pool_size和连接级缓冲总和——别信free -h里的total。
