MySQL如何备份非常大的数据库_mydumper多线程逻辑导出工具

mydumper 能显著加速大库导出，前提是表结构合理且 I/O 与网络不瓶颈；它通过多线程并发 dump 表（支持表内分块）远超 mysqldump 单线程性能，尤其适用于上百张表、超 100GB 场景。mydumper 能不能真正加速大库导出能，但前提是表结构合理、磁盘 I/O 和网络不成为瓶颈。它靠多线程并发 dump 表（甚至表内分块），比 mysqldump 单线程快数倍——尤其是有上百张表、总数据量超 100GB 的场景。常见错误现象：mydumper 启动后只跑一两个线程、CPU 利用率低、导出速度没提升。这往往不是工具问题，而是默认参数太保守或 MySQL 侧限制了并发。必须显式指定 -t（线程数），默认是 4，对大库通常不够；建议从 -t 8 或 -t 16 起调，观察 SHOW PROCESSLIST 中活跃连接数是否匹配MySQL 的 max_connections 得留足余量，mydumper 每个线程建一个连接，-t 16 就要至少 20+ 连接空闲如果表含大量 BLOB/TEXT 字段，开启 --skip-tz-utc 和 --compress 反而可能拖慢，因为压缩耗 CPU，而磁盘或网络未必是瓶颈导出时为什么某些表被跳过或报错 “Table doesn’t exist”不是表真丢了，而是 mydumper 在初始扫描阶段读取 INFORMATION_SCHEMA.TABLES 后，后续 dump 时该表已被 DDL 修改（比如被 DROP 或 RENAME），导致一致性视图失效。使用场景：线上边导出边做表结构变更，或定时任务和运维操作未错开。加 --no-schemas 不能解决这个问题，它只跳过建表语句生成，不解决元数据快照问题真正有效的是 --snapshot-all（需 MySQL 5.6+ 且开启 binlog），它会先获取一个全局一致的 GTID 或 binlog position，再导出，确保所有线程看到同一时刻的表状态若 MySQL 版本旧或未开 binlog，只能靠业务低峰期操作 + --lock-all-tables（会加全局读锁，影响写入）mydumper 导出的文件怎么还原？不要想当然用 sourcemydumper 输出是多个 .sql（建表）和 .csv（数据）文件，混在一起用 source 会报错，因为 source 不认识 CSV 格式，也不处理文件依赖顺序。 通义听悟 阿里云通义听悟是聚焦音视频内容的工作学习AI助手，依托大模型，帮助用户记录、整理和分析音视频内容，体验用大模型做音视频笔记、整理会议记录。