「数据传输」更稳，因其通过连接通道读取元数据，自动适配目标库引擎与字符集，并可显式控制外键、自增、注释等；而右键「转储 SQL 文件」依赖源库客户端设置，易缺失ENGINE、CHARSET、外键等关键项，导致乱码、插入失败或主键冲突。
跨库复制表结构，用「数据传输」比右键「转储 sql 文件」更可靠，尤其当目标库字符集、引擎或外键约束不一致时。
为什么「数据传输」比右键导出更稳
右键→「转储 SQL 文件」默认走的是源库连接的客户端设置（比如 SET NAMES latin1），一旦源库没显式声明 CHARSET=utf8mb4 或 ENGINE=InnoDB，导出的 CREATE TABLE 语句就可能缺关键项，导入到目标库后出现乱码、插入失败甚至主键冲突。而「数据传输」全程通过连接通道读取元数据，自动适配目标库的默认引擎和字符集，并能显式控制外键、自增、注释等细节。
常见错误现象：ERROR 1071 (42000): Specified key was too long（因目标库默认 utf8mb4 但索引字段超长）、ERROR 1215 (HY000): Cannot add foreign key constraint（外键列类型不一致或未勾选「Foreign keys」选项）。
使用场景：MySQL 同版本跨库迁移、测试库初始化、从生产库抽样建影子表
- 必须确保源库和目标库连接都已正确配置
charset=utf8mb4（在连接属性 → 「高级」页签里检查） - 如果目标库已存在同名表，不勾选
Truncate target table before transfer会导致后续插入报Duplicate entry -
Auto-increment value默认不继承，新表 ID 会从 1 开始；需在「高级」里手动勾选它，否则和已有数据冲突
「结构同步」适合批量对齐多个表，但不能替代单表复制
「工具」→「结构同步」本质是对比两个库的 DDL 差异并生成执行脚本，适合一次性拉齐整库结构（比如补漏视图、函数、存储过程），但它不会处理单表的数据迁移，也不支持跨服务器复制表结构——目标库必须是 Navicat 已建立的有效连接，且不能是只读实例。
容易踩的坑：CREATE VIEW 依赖其他视图时，若被依赖视图未提前创建，执行会报错；Navicat 不自动排序依赖顺序，得手动调整 SQL 执行顺序。
参数差异：
- 「忽略对象」里勾选
Comments会丢掉字段注释 - 勾选
Definer可能导致视图/存储过程创建失败（目标库无对应用户） - 「比较选项」中不勾选
Collation，即使源目标字符集不同也不会提示
拖放操作快但限制多，仅适用于同连接内跨库
直接鼠标拖拽表名到另一个数据库节点上，确实一秒完成，但它只在「同一个 Navicat 连接」下生效（即源库和目标库必须属于同一 MySQL 实例）。一旦涉及跨服务器、跨账号、或目标库权限受限（比如只有 INSERT 没有 CREATE），拖放会静默失败，连错误提示都不弹。
使用场景：本地开发环境快速建测试表、同一实例下分库分表调试
性能影响：拖放实际触发的是 CREATE TABLE ... LIKE + INSERT INTO ... SELECT，对大表会锁源表读、占目标库临时空间，线上慎用。
必须注意：
- 源表含
JSON、GENERATED COLUMN、分区表时，LIKE语法不复制这些特性，结果表结构不完整 - 外键、全文索引、空间索引均不会被拖放继承
- 目标库若已存在同名表，拖放会直接报错退出，不提供覆盖或跳过选项
真正需要跨库复制表结构时，别贪图右键两下或拖一下——先打开「数据传输」，确认源/目标连接可用、字符集一致、目标库有 CREATE 权限，再点「高级」逐项核对外键、自增、清空选项。那些看似省事的操作，往往在上线前半小时才暴露出字段长度截断或注释丢失的问题。
