Navicat 不支持从备份中还原单个表分区，因其备份文件（.ncb 或 .sql）不识别分区结构，还原操作仅支持库或表粒度，无法按分区选择；真正可行方案是通过 mysqldump --where 配合原库分区信息导出指定分区数据。
navicat 无法直接从备份中还原单个表分区，.ncb 或 .sql 备份文件都不支持“按分区粒度”还原 —— 不是操作不对，是功能压根不存在。
Navicat 的备份文件根本不识别分区结构
无论你用的是 .ncb（Navicat 加密格式）还是纯文本 .sql（如 mysqldump 生成），Navicat 自身的「还原」或「数据传输」界面里都没有「分区」这个可勾选项。备份文件里的 CREATE TABLE 语句可能含 PARTITION BY RANGE，但 Navicat 在解析时只认库→表两级，分区只是建表语句里的一段 DDL 文本，不会被拆成独立对象。
- 右键备份 → “还原”，只会全库执行，分区定义和所有分区数据一并写入
- 用“数据传输”选中某张分区表 → 默认导出整张表所有分区的数据，无法限定只导
p202401或p202402 - 试图在 SQL 文件里搜索
PARTITION p202401并手动截取：大概率失败，因为 MySQL 不允许单独INSERT INTO ... PARTITION (p202401)（除非目标表已存在且分区已定义）
真正能提取特定 RANGE 分区数据的路径只有一条：用 mysqldump + --where 配合分区名
前提是你有权限连上**原库**（不是备份文件），且该表使用 RANGE 或 LIST 分区（HASH/KEY 不适用）。Navicat 只是客户端，真正干活的是 MySQL 服务端的 mysqldump 工具。
- 先查清分区边界：
SELECT PARTITION_NAME, PARTITION_DESCRIPTION FROM INFORMATION_SCHEMA.PARTITIONS WHERE TABLE_NAME = 'orders' AND TABLE_SCHEMA = 'mydb'; - 假设
p202403对应VALUES LESS THAN (1706774400)（时间戳），则导出命令为：mysqldump -u root -p mydb orders --where="created_at >= '2024-03-01' AND created_at orders_p202403.sql - 加
--no-create-info避免重复建表；加--skip-triggers --skip-routines防干扰 - 导出后，在 Navicat 中右键目标库 → “运行 SQL 文件”即可导入——此时数据天然落在对应 RANGE 分区内（前提是目标表分区结构完全一致）
从已有的全库 SQL 备份中硬抽分区数据风险极高
如果你手头只有 full_backup.sql，且原库已不可用，想从中提取 p202403 分区的数据，必须意识到：MySQL 的分区数据在逻辑备份里根本没被标记，所有 INSERT 语句都指向整表名，不带 PARTITION 子句。
- 用
grep -A 100 "INSERT INTO `orders`" full_backup.sql抽出全部插入语句，再靠WHERE条件过滤时间字段 —— 这要求你100%确认字段名、类型、时区，且备份未启用--skip-extended-insert（否则每行一个 INSERT，grep -A会截断） - 若备份含注释或跨行 INSERT（如大 JSON 字段），
sed/awk脚本极易漏数据或语法错误，导入时报ERROR 1064 - 最危险的是忽略分区裁剪（partition pruning）：即使你手动拼出
INSERT ... SELECT ... WHERE created_at BETWEEN ...，目标表若没提前建好对应分区，MySQL 会报ERROR 1731（No partition found for given value）
别信“Navicat 分区还原插件”或隐藏设置
截至 2026 年 4 月，Navicat 官方文档、更新日志、支持论坛均无任何关于分区级还原的功能描述。“高级特权”“分区向导”“对象粒度还原”等说法均来自误传或第三方营销文案。真实限制来自 MySQL 协议层：备份工具只能按表导出，分区是存储引擎内部机制，不在客户端协议暴露范围内。
复杂点在于：分区不是数据容器，而是查询路由规则。你看到的“某个分区丢失”，本质是 WHERE 条件匹配不到任何分区——恢复的关键永远是重建正确的分区定义 + 补齐对应范围的数据，而不是在备份文件里找一个叫 p202403 的独立块。
