MySQL不支持恢复单个分区，因分区仅为逻辑切分、物理上属同一表；备份还原均以整表为单位，需通过数据筛选、分区重建或binlog精准回放等间接方式实现目标分区恢复。
MySQL 不支持“恢复单个分区”这种原子操作，分区只是表的逻辑切分，物理上仍属于同一张表；恢复必须基于整表粒度，再通过数据筛选或分区重建实现目标效果。
为什么不能直接恢复单个分区
分区表在 MySQL 中本质是一张表，INFORMATION_SCHEMA.PARTITIONS 仅记录元数据，.ibd 文件也并非按分区独立存储（除非使用 ALGORITHM=INPLACE + REMOVE PARTITIONING 后再重建，但已非原分区）。所有备份工具（mysqldump、xtrabackup）都以表为单位备份/还原，没有「只导出 p202401 分区」的原生命令。强行复制某个分区对应的文件片段会破坏 InnoDB 表空间一致性，导致启动失败或数据损坏。
从 mysqldump 恢复指定分区的数据
适用于已有全表 dump 且分区字段可过滤（如 dt DATE 或 id INT 范围分区）的场景。不能靠 grep 表名提取，必须解析并重写 INSERT 语句。
- 确认 dump 文件中该表的
CREATE TABLE包含完整PARTITION BY定义，否则导入后变成普通表 - 用
mysqlpump --user=root --password --databases db_name --tables tbl_name --where="dt >= '2024-01-01' AND dt p202401.sql直接导出目标分区数据（推荐，mysqlpump支持--where，mysqldump不支持） - 若只有老式
mysqldump全表备份，需先导入到临时库，再用INSERT INTO target_tbl SELECT * FROM tmp_tbl WHERE dt BETWEEN ...抽取分区数据 - 导入前执行
SET FOREIGN_KEY_CHECKS=0;，避免外键约束中断插入
用 XtraBackup 恢复后只保留特定分区
物理备份恢复的是整表，但可通过 ALTER TABLE ... REORGANIZE PARTITION 或 TRUNCATE PARTITION 快速清理无关分区，比逐行 DELETE 高效得多。
- 先用
xtrabackup --copy-back恢复整表到目标实例（确保innodb_file_per_table=ON） - 执行
ALTER TABLE tbl_name TRUNCATE PARTITION p202312, p202402;删除不需要的分区（注意：该操作不可回滚） - 若需保留多个不连续分区，用
REORGANIZE PARTITION合并后再拆分，但要求分区表达式支持（如 RANGE/LIST） - 检查
SELECT PARTITION_NAME, TABLE_ROWS FROM INFORMATION_SCHEMA.PARTITIONS WHERE TABLE_NAME='tbl_name';验证剩余分区行数是否匹配预期
binlog 回放时精准定位分区变更
当误操作仅影响某一分区（如 DELETE FROM tbl WHERE dt = '2024-01-15'），可用 binlog 精确还原，但前提是 binlog_format=ROW 且日志未被清理。
- 用
mysqlbinlog --base64-output=DECODE-ROWS -v mysql-bin.000001 | grep -A 10 -B 5 "tbl_name" | grep -E "(WHERE|@1=|@2=)"初筛事件 - 结合
--start-datetime和--stop-datetime缩小范围，避免导入大量无关 DML - ROW 格式下，每个事件包含具体列值（如
@3=20240115），可人工或脚本过滤出目标分区的 INSERT/UPDATE - 禁止直接执行原始 binlog 输出：需将
DELETE转为对应INSERT，UPDATE转为反向UPDATE，否则会二次破坏
最易被忽略的是分区裁剪（partition pruning）失效问题：恢复后若查询没走分区，说明 WHERE 条件未匹配分区表达式（比如用了函数 DATE(dt) 而不是直接比较 dt），会导致全表扫描——这会让恢复失去意义。
