能，但默认导出后分区结构丢失；需用--no-create-info导数据、-d导含PARTITION BY的建表语句，或手动保留结构；跨分区导出须查INFORMATION_SCHEMA.PARTITIONS确定边界再WHERE过滤。
mysqldump 能直接备份分区表吗？
能，但默认行为会把整个分区表当普通表导出，CREATE TABLE 语句里不带 PARTITION BY 子句，恢复后变成非分区表——数据还在，结构丢了。
关键在加 --skip-create-options 和手动保留建表语句，或者用 --no-create-info 配合单独导出表结构。
- 导结构（含分区定义）：
mysqldump -d --no-data db_name table_name > schema.sql - 导数据（跳过建表）：
mysqldump -t --skip-triggers db_name table_name > data.sql - 注意：
-t不会导触发器，--skip-triggers是防误触，不是必须；但分区表一般没触发器，可省
按分区名单独导出某个分区的数据
MySQL 原生 mysqldump 不支持 --where 按分区逻辑过滤，它只认 WHERE 条件，而分区键值可能跨多个列、或涉及函数（如 TO_DAYS(created_at)），直接写 WHERE 容易漏数据或报错。
更可靠的做法是：先查出目标分区的边界值，再用 WHERE 精确限定范围导出。
- 查分区信息：
SELECT PARTITION_NAME, TABLE_ROWS, PARTITION_DESCRIPTION FROM INFORMATION_SCHEMA.PARTITIONS WHERE TABLE_NAME = 'your_table' AND TABLE_SCHEMA = 'db_name'; - 对 RANGE 分区，
PARTITION_DESCRIPTION是上界值（如1000），实际数据范围是前一分区上界当前上界 - 导出示例（假设
log_date是分区键，p202404对应VALUES LESS THAN ('2024-05-01')）：mysqldump db_name your_table --where="log_date >= '2024-04-01' AND log_date p202404.sql
合并多个分区 SQL 文件时要注意什么
直接 cat *.sql | mysql 很危险：如果各文件都含 DROP TABLE 或 CREATE TABLE，会互相覆盖；若结构不一致（比如字段顺序、默认值、分区表达式不同），导入中途就失败。
必须保证：只有一个文件负责建表（且含完整分区定义），其余只导入数据。
- 检查每个
.sql文件头，删掉重复的CREATE TABLE和DROP TABLE（保留第一个即可） - 确认所有数据文件的
INSERT语句字段顺序与建表语句一致；如有INSERT INTO t(col1,col2) VALUES显式指定列，没问题；若用INSERT INTO t VALUES，必须严格对齐 - 导入前先清空目标表（用
TRUNCATE TABLE，别用DELETE，避免锁表和 binlog 膨胀）
分区表用 SELECT ... INTO OUTFILE 导出的坑
这个命令不走客户端，是 MySQL Server 直接写服务器本地磁盘，路径是相对于 MySQL 的 secure_file_priv 目录——不是你当前 shell 的工作目录，也不是任意路径。
而且它不生成建表语句，也不处理字符集自动转换，导出的文本文件缺字段元信息，后续加载容易乱码或列错位。
- 查允许路径：
SHOW VARIABLES LIKE 'secure_file_priv';，结果为空表示禁用，非空则必须用该路径下的子路径 - 导出时显式指定字段：
SELECT * FROM t PARTITION(p202404) INTO OUTFILE '/var/lib/mysql-files/p202404.csv' FIELDS TERMINATED BY ',' OPTIONALLY ENCLOSED BY '"'; - 导入需对应
LOAD DATA INFILE，且必须确保目标表已存在、分区已定义好；不能用mysqlimport，它不识别分区语法
分区表导出最麻烦的从来不是“怎么拿数据”，而是“怎么让结构和数据在另一环境严丝合缝地重建”。尤其跨版本迁移时，5.7 和 8.0 对 PARTITION BY HASH 表达式的解析可能有细微差异，光靠 dump 文件不一定保得住。真要稳妥，建议把 SHOW CREATE TABLE 输出和 SELECT 导出分开存，人工核对一次分区定义。
