dbeaver或datagrip可可视化对比两库表结构差异，但不自动同步；需手动触发schema对比、过滤系统库、关注真实影响项（如on update、sql_mode、lower_case_table_names等），避免盲目执行插件生成的alter语句。
用 dbeaver 或 datagrip 看清两个库的表结构差异
可视化工具本身不“同步”，但能快速暴露差异，是人工校验和生成同步脚本的前提。重点不是点几下就搞定，而是避免把 create table 当成万能解——比如生产库有 on update current_timestamp，测试库没写，dbeaver 的对比结果里会标红，但不会告诉你这个字段在业务上是否允许被重置。
- 必须连上两个库后，在工具里手动触发「Compare Schemas」（DBeaver）或「Compare with DataSource」（DataGrip），不能只看单个库的 DDL 预览
- 注意过滤：默认可能包含
information_schema和mysql系统库，要关掉，否则满屏红色误报 - 字段顺序不同会被当成“结构不一致”，但 MySQL 实际执行
ALTER TABLE ... ADD COLUMN时顺序不影响功能，这类差异可忽略 - 字符集差异（如
utf8mb4_0900_as_csvsutf8mb4_general_ci）在对比界面里常显示为“collation mismatch”，但它可能只是排序规则不同，数据存储完全兼容
别信插件自动生成的 ALTER 语句，先看它改了什么
像 Flyway、Liquibase 的 UI 插件，或者 Navicat 的“结构同步”功能，点一下就输出一堆 ALTER TABLE，但它们默认不检查外键依赖、不处理分区表、也不管你有没有在生产库上开了 sql_log_bin=0。最危险的是：它可能把 DROP COLUMN 当成安全操作推到生产环境。
- 生成前务必勾选「Preview only」或导出为 SQL 文件再打开看——重点扫三类语句：
DROP、MODIFY（非CHANGE）、带ALGORITHM=INPLACE的大表变更 - 如果目标库是 MySQL 5.7，插件可能默认用
ALGORITHM=COPY，导致锁表数小时；而 8.0 默认INPLACE，但对全文索引或虚拟列仍会退化 - 插件通常忽略
COMMENT字段差异，但如果你用它存字段中文名或审计标记，这部分差异就丢了
真正要同步的从来不是“结构”，而是“行为一致性”
两个库字段类型一样、索引一样，不代表查询结果一样。比如测试库用了 TINYINT(1) 存布尔值，生产库用 BOOLEAN（本质还是 TINYINT），看起来一样，但 ORM 框架读取时可能一个返回 true/false，一个返回 1/0。
- 检查
sql_mode：测试库可能是STRICT_TRANS_TABLES，生产库是空，插入超长字符串时一个报错一个截断 - 确认
lower_case_table_names设置：Windows 测试库设为 1，Linux 生产库是 0，会导致SELECT * FROM User在生产报错（找不到小写表名） - 函数行为差异：MySQL 8.0 的
JSON_CONTAINS对 null 处理更严格，测试库没开 strict mode 可能绕过，生产一查就空
同步失败后怎么快速定位是结构问题还是权限/配置问题
看到 ERROR 1142 (42000): ALTER command denied to user 别急着改 SQL，先跑一条 SHOW GRANTS FOR CURRENT_USER。很多“结构同步失败”根本不是 DDL 写错了，而是账号没 ALTER 权限，或者被 max_allowed_packet 卡住（尤其含大注释或枚举值多的表）。
- 先执行
SELECT @@max_allowed_packet, @@sql_mode, @@lower_case_table_names对比两边值 - 如果插件报错
Unknown column 'xxx' in 'field list'，大概率不是少字段，而是同步过程中某个ALTER TABLE被部分执行，导致中间状态不一致 - 用
mysqldump --no-data导出两边 schema，再用diff命令行比——跳过工具 UI 的缓存干扰，也避开图形界面自动格式化带来的假差异
结构同步最麻烦的永远不是语法对不对，而是“谁在什么时候改过什么，又忘了告诉别人”。可视化工具只能照出镜子，照不出人影背后的手。
