mysqldiff 能直接用但易漏关键差异，需加--force、--show-reverse等参数；原生输出不可直接执行，应人工校验patch.sql；无工具时可查information_schema导出比对；自动化ALTER TABLE易因版本限制和依赖顺序失败。
mysqldiff 能不能直接用？
能，但默认行为容易漏掉关键差异。它只比对表结构（CREATE TABLE 语句层面），不检查索引顺序、外键约束名、列注释、字符集继承关系这些实际影响同步的细节。
常见错误现象：mysqldiff 报“no differences”，但应用上线后报 Unknown column 或 Cannot add or update a child row —— 往往是源库某列有 COMMENT 或目标库外键名不一致导致的元数据不兼容。
实操建议：
- 加
--force强制输出所有差异，避免静默跳过 - 必须加
--show-reverse，否则生成的 SQL 是「从左到右」单向的，而你常需要反向修复测试库 - 用
--skip-table-options慎重：跳过ENGINE、ROW_FORMAT等会掩盖生产环境不一致风险
怎么让 diff 结果真正可执行？
原生 mysqldiff 输出的是类 SQL 的伪指令（比如 ALTER TABLE ... ADD COLUMN ...），但不保证语法兼容 MySQL 版本，也不处理依赖顺序（例如先删外键再删列）。
使用场景：需要把开发库结构推到预发库，且预发库已有业务数据，不能丢表重导。
实操建议：
- 用
--changes-for=server2明确指定目标端，避免方向搞反 - 输出先存成文件：
mysqldiff --server1=u:p@h1:3306 --server2=u:p@h2:3306 db1:db2 --changes-for=server2 > patch.sql - 手动检查
patch.sql中是否有DROP FOREIGN KEY `fk_xxx`但没带对应ALTER TABLE ... DROP INDEX—— MySQL 5.7+ 要求先删索引再删外键 - 涉及
TEXT/BLOB列加默认值时，MySQL 8.0.19+ 才支持，旧版本得拆成两步：ADD COLUMN+UPDATE
没有 mysqldiff 怎么临时比对？
很多线上环境没装 MySQL Utilities，或者权限受限无法连双库。这时候靠查询 information_schema 最稳。
性能 / 兼容性影响：查 information_schema.COLUMNS 和 STATISTICS 是轻量级操作，但跨库 JOIN 效率低，建议分别导出再本地比对。
实操建议：
- 导出源库结构快照：
SELECT TABLE_NAME, COLUMN_NAME, DATA_TYPE, IS_NULLABLE, COLUMN_DEFAULT, COLUMN_COMMENT, ORDINAL_POSITION FROM information_schema.COLUMNS WHERE TABLE_SCHEMA = 'db_name' ORDER BY TABLE_NAME, ORDINAL_POSITION > src_cols.csv - 同理导出目标库，用
diff src_cols.csv dst_cols.csv看列级差异 - 查索引一致性：
SELECT TABLE_NAME, INDEX_NAME, SEQ_IN_INDEX, COLUMN_NAME, COLLATION FROM information_schema.STATISTICS WHERE TABLE_SCHEMA = 'db_name' ORDER BY TABLE_NAME, INDEX_NAME, SEQ_IN_INDEX - 注意
COLUMN_DEFAULT字段在 MySQL 8.0+ 会显示表达式（如CURRENT_TIMESTAMP），而 5.7 显示为NULL，别误判为差异
alter table 自动化修复为什么总失败？
自动拼 ALTER TABLE 语句看似省事，但 MySQL 对原子性要求严：一个语句里不能同时 ADD COLUMN 和 MODIFY COLUMN，也不能在 ADD INDEX 同时 DROP INDEX。
容易踩的坑：
-
json类型列在 5.7 不支持默认值，8.0 支持但需显式写DEFAULT (JSON_OBJECT())，括号不能少 - 修改
VARCHAR长度时，如果原列有索引且长度超 767 字节（utf8mb4），要先DROP INDEX再MODIFY，否则报ERROR 1071 -
ALTER TABLE ... RENAME COLUMN是 8.0.4+ 才有，老版本只能CHANGE COLUMN，但后者会重写整表，大表慎用 - 任何含
ALGORITHM=INPLACE的语句，在只读实例或低内存环境下可能退化成COPY，锁表时间远超预期
复杂点在于：结构差异从来不是孤立的。改一列类型可能牵扯三个视图、两个存储过程、一套 ORM 映射配置。比对只是起点，真正难的是确认每个变更在上下游是否都可接受。
