最稳的结构同步方案是 mysqldump --no-data --skip-triggers --compact --set-gtid-purged=OFF，确保保留引擎、字符集等关键信息且避免触发器和 GTID 导致失败。
用 mysqldump + mysql 做结构同步最稳
只导出表结构、不带数据，是自动化同步的前提。直接用 mysqldump --no-data 最可靠，它能保留 create table 语句里的引擎、字符集、注释等关键信息，比手工拼 show create table 更少出错。
常见错误现象：mysqldump 默认会加 USE `db_name` 和 DELIMITER，如果目标库名不同或有存储过程，容易执行失败；导出时没加 --skip-triggers，可能把触发器也 dump 进来，而目标库权限不够导致导入中断。
- 务必加上
--no-data --skip-triggers --compact --set-gtid-purged=OFF - 导出前确认源库和目标库的
sql_mode一致，否则STRICT_TRANS_TABLES类设置可能让CREATE TABLE报错 - 导出命令示例：
mysqldump -h192.168.1.10 -uuser -ppass --no-data --skip-triggers mydb > schema.sql
批处理里用 mysql 导入要绕开权限和连接问题
Windows 批处理调 mysql 命令行工具，最容易卡在密码明文、连接超时、SQL 文件路径含空格这三处。
使用场景：每天凌晨同步测试库结构到开发库，不希望人工介入。
- 别在命令里写
-ppassword，改用配置文件——新建my.cnf，写入[client]段，加user=xxx和password=xxx，再用mysql --defaults-file=my.cnf -h127.0.0.1 mydb - 加
--connect-timeout=10 --max-allowed-packet=64M，避免大表结构（比如带长注释的分区表）导入中断 - 路径必须用双引号包裹，且推荐用绝对路径：
"C:\tools\mysql\bin\mysql.exe" --defaults-file="C:\sync\my.cnf" mydb
计划任务里执行失败，大概率是环境变量或工作目录不对
Windows 任务计划程序默认以系统上下文运行，PATH 里没有 mysql，当前目录也不是你脚本所在位置，所以批处理点开能跑，计划任务里就报 'mysql' is not recognized 或 schema.sql not found。
性能影响：每次同步只改结构，耗时通常在秒级，但若误加了 --databases 导出整个实例，文件变大、IO 升高，可能拖慢其他定时任务。
- 在任务属性 → “常规”页勾选“不管用户是否登录都要运行”，并勾选“不存储密码”（配合
my.cnf避免明文） - 在“操作”页，“起始于”字段必须填脚本所在目录，例如
C:\sync\，不能留空 - 所有路径（包括
mysql.exe、my.cnf、schema.sql）全部用绝对路径，不依赖%CD%或相对路径
结构差异大时，直接 mysql 导入会报错，得先清理再重建
mysql 不支持“如果存在则替换表结构”，遇到字段类型变更、主键调整、外键冲突等情况，DROP TABLE + CREATE TABLE 会因外键约束失败；而跳过错误（--force）又可能让部分表没更新，后续查不到问题。
兼容性影响：MySQL 5.7 和 8.0 的 json 字段默认值写法不同，如果跨版本同步，mysqldump 输出的 SQL 可能在目标库报语法错误。
- 导入前加一步：
mysql -e "SET FOREIGN_KEY_CHECKS = 0; DROP DATABASE IF EXISTS mydb; CREATE DATABASE mydb CHARACTER SET utf8mb4 COLLATE utf8mb4_0900_ai_ci;" - 确保
mysqldump和目标mysql版本尽量接近，MySQL 8.0 导出的--set-gtid-purged=OFF在 5.7 上可安全忽略，但反向不行 - 不要依赖
mysqldump --replace或--insert-ignore，它们对结构无效，只针对数据
my.cnf 文件的编码——必须存成 ANSI 或 UTF-8 无 BOM，Windows 记事本默认保存为 UTF-8 with BOM，会导致 mysql 读取失败，报错信息里根本看不出是配置文件的问题。 
