mysqldump可完整备份分区表结构与数据，但恢复前须确保目标库无同名表；物理备份（如percona xtrabackup）更快更可靠，但需保证.frm与.ibd文件成对一致，且必须加--single-transaction保障一致性，否则易致分区数据缺失或计数不一致。
mysqldump 能完整备份分区表结构和数据，但恢复时若目标库已存在同名表会失败；物理备份（如 Percona XtraBackup）更快更可靠，但必须确保 .frm 和 .ibd 文件成对一致，否则恢复后分区不可用。
用 mysqldump 备份分区表时必须加 --single-transaction
分区表本质仍是 InnoDB 表，不加事务控制会导致备份过程中新写入的数据被截断或重复。常见错误现象是：恢复后部分分区数据缺失，或 SELECT COUNT(*) 与原始值不符。
-
mysqldump -u root -p --single-transaction --routines --triggers db_name table_name > backup.sql—— 必须包含--single-transaction，否则无法保证一致性 - 不要用
--lock-tables或--lock-all-tables：它们会阻塞写入，且对分区表无额外收益，反而增加 RTO - 导出文件里必须含
PARTITION BY定义，检查备份文件开头是否有类似PARTITION BY RANGE (YEAR(created_at))的语句
恢复时不能直接 mysql -u ... 就完事
如果目标库中已存在同名表，CREATE TABLE 语句会报错 ERROR 1050 (42S01): Table 'xxx' already exists，后续 INSERT 全部跳过，最终表为空。
- 先删旧表：
DROP TABLE IF EXISTS table_name;，再导入 - 或者用
mysql -u root -p db_name -e "source /path/to/backup.sql"，但前提是 SQL 文件里没带USE db_name，否则可能导入到错误库 - 导入后立刻验证：
SELECT PARTITION_NAME, TABLE_ROWS FROM INFORMATION_SCHEMA.PARTITIONS WHERE TABLE_NAME = 'table_name';—— 确保每个分区的TABLE_ROWS非零且与源库接近
用 Percona XtraBackup 恢复分区表要手动导入表空间
物理备份恢复后，InnoDB 不会自动识别新增的分区 .ibd 文件，必须显式执行 ALTER TABLE ... IMPORT TABLESPACE，否则查询分区时报错 Tablespace is missing for table xxx。
- 全量恢复后，对每个分区执行：
ALTER TABLE table_name DISCARD PARTITION p2023 TABLESPACE;→ 替换对应p2023.ibd→ALTER TABLE table_name IMPORT PARTITION p2023 TABLESPACE; - 不能只对主表执行
IMPORT TABLESPACE：分区表的每个.ibd是独立表空间，必须逐一分区操作 - 恢复前确认
innodb_file_per_table = ON，否则备份中不含独立.ibd，无法按分区粒度恢复
最容易被忽略的是分区元数据和权限一致性
备份时 mysqldump 默认不导出用户权限，而分区表常依赖特定账号的 SELECT 或 ALTER 权限；物理备份也不含权限信息。恢复后若权限缺失，应用连基本 SELECT 都会报 ERROR 1142 (42000)。
- 逻辑备份时加
--all-databases或单独导出权限：mysqldump -u root -p --no-data --skip-add-drop-table mysql user db > grants.sql - 物理备份恢复后，需手动执行
GRANT ... ON db_name.table_name TO 'user'@'%';，特别注意是否需要GRANT ALTER ON db_name.*（分区维护必需） - 检查
SHOW CREATE TABLE输出里的COMMENT或DATA DIRECTORY字段——如果原表用了自定义路径，恢复后这些路径可能不存在或权限不对
