必须拆分导出结构和数据：先用mysqldump -d --no-data导出含partition by的建表语句，再用mysqldump -t --skip-triggers --no-create-info导出纯数据；按分区导出需查information_schema.partitions确定边界并精准where过滤；超大分区须配合--single-transaction、--max-allowed-packet及主键分批；合并导入前需清理重复建表语句并统一insert列名格式。
mysqldump导出分区表时结构丢失怎么办
默认mysqldump会把分区表当普通表导出，CREATE TABLE语句里没有PARTITION BY子句，恢复后变成非分区表——数据还在，但分区逻辑彻底失效。
必须拆开导出结构和数据：
- 导完整建表语句（含分区定义）：
mysqldump -d --no-data db_name table_name > schema.sql - 导纯数据（跳过建表）：
mysqldump -t --skip-triggers --no-create-info db_name table_name > data.sql -
--no-create-info比--skip-create-options更直接，它明确跳过所有CREATE TABLE语句，避免误留不带分区的建表语句
按单个分区导出数据要绕开WHERE陷阱
mysqldump不支持--partition=p202404这类原生语法，硬写--where="log_date >= '2024-04-01'"容易漏数据或全表扫描——尤其当分区键是函数表达式（如TO_DAYS(created_at)）时，WHERE根本无法命中分区裁剪。
正确做法是先查边界，再精准过滤：
- 查分区范围：
SELECT PARTITION_NAME, PARTITION_DESCRIPTION FROM INFORMATION_SCHEMA.PARTITIONS WHERE TABLE_NAME = 'your_table' AND TABLE_SCHEMA = 'db_name' - 对
RANGE分区，PARTITION_DESCRIPTION是上界值（比如'2024-05-01'），实际数据范围是前一分区上界到当前上界 - 导出示例：
mysqldump db_name your_table --where="log_date >= '2024-04-01' AND log_date p202404.sql - 务必确认
log_date字段有索引，否则--where会触发全表扫描，备份过程夯住
分块导出超大分区表防OOM和锁表
单个分区若达几十GB，直接mysqldump会吃光内存、触发max_allowed_packet错误，甚至因长事务拖慢线上查询。
关键参数组合不能少：
- 加
--single-transaction（仅InnoDB有效），保证一致性且不锁表 - 配
--skip-lock-tables，但绝不能单独用——它不解决一致性，必须和--single-transaction一起用 - 调大客户端限制：
--max-allowed-packet=512M，同时确认服务端max_allowed_packet≥该值 - 对超大分区，优先按主键ID分批：
--where="id BETWEEN 1 AND 100000"，每次记录最大id作为下一批起点，避免漏数据
合并多个分区SQL文件导入前必须清理头尾
直接cat *.sql | mysql极危险：每个文件都含DROP TABLE和CREATE TABLE，后导入的会覆盖前一个；若分区定义不一致（比如字段顺序、DEFAULT值不同），中途就失败。
必须人工干预：
- 只保留第一个文件的
CREATE TABLE ... PARTITION BY语句，其余文件开头的建表和删表语句全部删掉 - 检查所有
INSERT INTO t VALUES语句——如果没显式指定列名，字段顺序必须和建表语句完全一致；建议统一改用INSERT INTO t(col1,col2) VALUES格式 - 导入前先清空目标表：
TRUNCATE TABLE your_table，别用DELETE，避免锁表和binlog膨胀 - 加
--force参数容错：mysql --force db_name ，它只跳过运行时错误（如重复主键），不处理语法错误
分区表备份最易被忽略的点是：结构与数据分离后，没人校验schema.sql里PARTITION BY是否真包含所有分区定义——特别是后期新增过分区却忘了更新备份脚本，恢复时分区数对不上，数据就“隐身”了。
