mysqldump 默认不导出分区定义，因mysql 5.6+默认跳过information_schema.partitions查询；需显式添加--include-partition参数（5.7+）或手动提取show create table中的partition by语句（5.6）。

mysqldump 导出分区表结构时为什么没包含 partition 定义？

默认情况下 mysqldump 不会导出分区定义，只生成基础 create table 语句，partition by 那部分直接被砍掉了——这是 mysql 5.6+ 的默认行为，不是你漏了参数。

根本原因是 mysqldump 默认启用 --no-create-info 的等效逻辑（实际是未显式启用分区支持），必须手动打开分区元数据导出开关。

• 加 --include-definer 没用，它管的是存储过程权限，不碰分区
• --skip-extended-insert 只影响 INSERT 格式，和建表无关
• 真正起作用的是 --tab 或 --no-create-info 以外的独立开关：--set-gtid-purged=OFF 不相关，但 --databases + --no-data 组合也不够

正确做法：必须显式加 --all？不对。要加的是 --routines？也不对。答案是：--no-create-info 要关掉，且必须加 --skip-triggers？错。唯一必要参数是：--no-create-info 的反向操作——即**不跳过建表语句**，再配合 --skip-data 和关键的 --set-gtid-purged=OFF（防止 GTID 冲突），但最核心的是：MySQL 5.7+ 要加 --include-partition。

示例命令：

mysqldump -u root -p --no-data --skip-triggers --skip-routines --set-gtid-purged=OFF --include-partition mydb mytable > mytable_struct.sql

用 SHOW CREATE TABLE 看到 PARTITION 但导出文件里没有？

这是因为 SHOW CREATE TABLE 返回的是服务器实时解析后的完整语句，而 mysqldump 在构造建表语句时，内部调用的是 SELECT * FROM information_schema.PARTITIONS + 拼接逻辑，但默认跳过这部分拼接。

常见误判场景：

• 在 MySQL 5.6 上用了 --include-partition —— 该参数不存在，会报错 Unknown argument: --include-partition
• 用 mysqldump --version 查到是 5.7.20，但服务端是 5.6.44 —— 客户端版本高没用，服务端不支持就无法获取分区元数据
• 用户有 SELECT 权限但没 PROCESS 权限 —— 实际不需要 PROCESS，但需要对 information_schema.PARTITIONS 有查询权（通常 SELECT on mydb.* 就够）

验证方式：执行 SELECT PARTITION_NAME FROM information_schema.PARTITIONS WHERE TABLE_SCHEMA='mydb' AND TABLE_NAME='mytable';，查不到结果说明分区信息不可见，mysqldump 自然导不出。

MySQL 5.6 怎么导出分区结构？

5.6 没有 --include-partition，得手动补全。别指望 mysqldump 自动搞定，它压根不识别分区语法。

MySQL

编写正确的MySQL查询，避免字符集、索引和锁方面的常见陷阱。

下载

可行路径只有两条：

• 用 SHOW CREATE TABLE 输出重定向，再用脚本提取 PARTITION BY 块（注意：MySQL 5.6 的输出中，PARTITION BY 在语句末尾，且含 COMMENT 和 DATA DIRECTORY 等干扰字段）
• 查 information_schema.PARTITIONS 表，按 PARTITION_ORDINAL_POSITION 排序，手写 ALTER TABLE ... REORGANIZE PARTITION 式的重建语句（适合少量分区）

简单取巧法（适用于快速备份结构）：

mysql -u root -p -e "SHOW CREATE TABLE mydb.mytable\G" | grep -E "^(CREATE|PARTITION|SUBPARTITION)" > mytable_partitioned.sql

⚠️ 注意：这个结果不能直接导入，因为缺少 DELIMITER 和引号转义，仅作参考；真实恢复前必须人工校验 PARTITION EXPRESSION 类型（RANGE/LIST/HASH/LINEAR HASH）是否匹配。

导入时提示 ERROR 1064 near 'PARTITION BY'？

大概率是目标 MySQL 版本不支持该分区类型，或 SQL 模式太严格。比如 MySQL 8.0 默认开启 ONLY_FULL_GROUP_BY，虽然不影响分区语法，但若导出文件里混入了视图或触发器定义，就可能触发解析失败。

更常见的原因：

• 源库是 5.7，导出用了 --include-partition，但目标库是 5.6 —— 直接报错，因为 5.6 不认识 PARTITION BY 语法
• 导出时用了 --compatible=mysql40 或类似兼容模式 —— 它会主动删掉所有分区定义
• 文件里有反斜杠转义问题，例如分区名含下划线或数字，被 shell 误展开（尤其用 $(...) 包裹命令时）

安全导入前必做三件事：

• 确认 SELECT VERSION() 在目标实例上返回的版本 ≥ 源实例
• 检查导出文件头部是否有 SET sql_mode = '...'，如有，确保目标库支持该 mode 组合
• 用 head -20 mytable_struct.sql 看第一行是否为 CREATE TABLE，且紧接着有 PARTITION BY 字样，而不是被注释或截断

分区表结构导出不是“一键备份”，它卡在版本、权限、参数、客户端/服务端协同四个咬合点上。少一个条件，PARTITION 就会静默消失。