mydumper导出超大单表必须加--chunk-filesize，否则默认整表导出为单文件，易致OOM、恢复卡死；需配合--threads并确保表有主键或唯一索引，InnoDB生效，MyISAM不支持。
mydumper 导出超大单表必须加 --chunk-filesize
不加这个参数，mydumper 默认把整张表导出为一个 SQL 文件，遇到几亿行的表，单文件动辄几十 GB，不仅导出慢、内存溢出风险高，后续恢复时 myloader 也容易卡死或 OOM。关键不是“能不能导”，而是“导完还敢不敢用”。
正确做法是强制分块：
-
--chunk-filesize=100表示按约 100MB 的数据量切分（单位是 MB，不是行数），生成table.00000.sql、table.00001.sql等多个小文件 - 搭配
--threads=8或更高（视 CPU 核心数而定），每个线程负责一个 chunk，真正实现并行导出 - 注意：该参数仅对 InnoDB 表生效；MyISAM 表不支持 chunk，会退化为全表锁+单文件导出
- 若表无主键或唯一索引，
mydumper无法安全分片，会报错Cannot chunk table xxx: no primary key or unique key，此时需先加索引或改用全表导出
myloader 恢复大表前必须关约束、调缓冲池
myloader 默认行为是逐文件执行 INSERT，对大表来说，每条语句都走完整事务流程，性能极差。直接跑默认命令，可能一小时才导入几万行。
必须在目标库提前执行以下准备：
- 关闭外键与唯一性检查：
SET FOREIGN_KEY_CHECKS=0; SET UNIQUE_CHECKS=0;（恢复完成后记得开回来） - 增大
innodb_log_file_size（例如设为2G），避免导入中频繁刷盘导致 checkpoint 阻塞 - 临时调高
innodb_buffer_pool_size（建议占物理内存 70%），否则大量磁盘随机读写拖垮 IO - 使用
--overwrite-tables参数，避免因目标库已存在同名表而中断
恢复命令本身也要并行化：myloader -d ./backup/ -t 16 -o，其中 -t 16 表示启用 16 个线程并发导入不同 chunk 文件。
kashen-mysql DDLtoExcel
下载
解析 MySQL 8.0 的 DDL 脚本，并将表结构导出为 Excel 格式。适用于用户需将 MySQL 的 `CREATE TABLE` 语句转换为结构化的 Excel 文件场景，导出内容包含字段名、数据类型、长度及精度等信息。支持多张表的批量处理，每张表对应 Excel 中的一个独立工作表。适用于数据库文档编写、数据字典生成及模式分析等任务。
metadata 文件里的 binlog 位点决定能否做时间点恢复
超大表导出耗时长，期间业务持续写入，mydumper 在启动时记录的 binlog 位置（保存在 metadata 文件里）就是整个备份的“一致性快照点”。这不是某个表的快照，而是所有表统一的时间锚点。
这意味着：
- 不能只拿这张大表的
.sql文件去恢复——它单独恢复后，和其他表的数据就不再处于同一时间点，主从或应用逻辑可能出错 - 若要精确恢复到故障前一秒，必须结合
metadata中的binlog_pos和后续 binlog，用mysqlbinlog+mysql补齐 - 如果备份过程中有非事务表（如 MyISAM），
metadata里 binlog 位点对它们不保证强一致，这类表只能当作“尽力而为”处理
别忽略 --less-locking 对业务的影响
虽然文档说 --less-locking 能减少锁表时间，但它的真实效果取决于存储引擎和表结构：
- 对 InnoDB 表，它会让
mydumper尽早释放FLUSH TABLES WITH READ LOCK，但前提是所有表都有主键或唯一索引；否则仍会全程持锁 - 对含大量 TEXT/BLOB 字段的大表，
--less-locking可能引发mysqld内部 buffer 不足，报错Packet too large，此时得同步调大max_allowed_packet - 线上环境慎用
--no-locks（跳过锁表）：它靠START TRANSACTION WITH CONSISTENT SNAPSHOT保一致性，但若备份期间有长事务未提交，会导致mydumper卡住等待，反而延长业务阻塞时间
真正影响业务的是锁持续时间，而不是有没有锁——测出来单表锁 3 秒还是 30 秒，比参数名更重要。
