根本原因是MySQL的lower_case_table_names配置与Navicat行为不匹配：当源库和目标库该参数不一致，或表名大小写混用时，SHOW CREATE TABLE返回的表名被系统强制转换，导致Navicat误判结构差异；必须统一各环境配置并禁用混合大小写表名。
Navicat 结构对比失败，**根本原因不是工具出错，而是 MySQL 的 lower_case_table_names 配置与 Navicat 行为不匹配**——尤其当源库和目标库配置不一致，或表名在物理层面大小写混用时，SHOW CREATE TABLE 返回的表名格式会被系统强制转换，导致 Navicat 拿到“看似不同”的 DDL，误判为结构差异。
为什么 Navicat 显示的表名总是小写？
这不是 Navicat 的 bug，而是它默认适配 MySQL 的存储行为：
- MySQL 在
lower_case_table_names = 1（Windows/macOS 默认）时，会把所有表名转为小写存盘，INFORMATION_SCHEMA.TABLES.TABLE_NAME也返回小写 - 即使你在 Navicat 中手动重命名为
UserProfile，重启后仍显示userprofile，因为磁盘上只有userprofile.frm（或userprofile.ibd） - 若你强行在 Linux 上设
lower_case_table_names = 0，而 Navicat 连的是 Windows 环境的 MySQL，它发的查询仍可能被服务端静默转小写，造成元数据读取错位
结构对比前必须检查的三个配置层
Navicat 对比的是 DDL 字符串，而 DDL 来源受三层控制，缺一不可：
-
MySQL 服务端配置：查
SELECT @@lower_case_table_names。值为0表示区分大小写，1表示不区分且强制小写存储 -
Navicat 连接参数：在连接属性 → 高级 → 勾选
Use Unicode，并确认未启用任何“自动转换表名”类插件（Navicat 本身无此选项，但第三方脚本可能干扰） -
实际磁盘文件名：登录服务器，进数据库目录（如
/var/lib/mysql/mydb/），用ls -l看真实文件名。若存在UserTable.frm和usertable.frm并存，说明已处于损坏状态，Navicat 必然对比失败
对比时跳过大小写干扰的实操设置
Navicat 16+ 提供了关键开关，但默认关闭，必须手动启用：
- 打开「结构同步」向导 → 点击「选项」→ 进入
Compare Options - 勾选
Ignore table name case（注意：该选项仅在 Navicat for MySQL 16.0.12 及以上版本可见） - 同时勾选
Compare column character sets和Compare collations，避免因字符集声明隐式差异（如 TEXT 字段没写CHARACTER SET utf8mb4）被误标为表级不一致 - 如果对比 Oracle，必须额外确认 Navicat 的「高级」设置中启用了
Convert object names to uppercase，否则带双引号的"User"和无引号的USER会被视为两个对象
最危险但常被忽略的操作：跨环境同步时改配置
在测试库临时设 lower_case_table_names = 1 再同步，上线后切回 = 0 ——这会导致：
- 原
UserLog表被 MySQL 重命名为userlog，但 Navicat 缓存里还记着旧名，后续 DDL 执行报ERROR 1146 (42S02): Table 'db.UserLog' doesn't exist - 从库复制中断：主库写
ALTER TABLE UserLog ADD c1 INT，从库因找不到UserLog直接报错停止 SQL 线程 - 修复成本极高：必须停服、导出所有表的
CREATE TABLE语句、批量替换表名、再导入，且无法保证触发器/存储过程里的硬编码表名同步更新
真正安全的做法是：**所有环境初始化时统一 lower_case_table_names 值，并禁止在 SQL 中显式使用大小写混合的表名**——Navicat 生成的 DDL 会跟随这个底层规则，而不是反过来迁就工具显示。
