最直接的表结构差异比对方法是用 pg_dump --schema-only 导出开发库和生产库的 schema，再用 diff -u 比较文本；需统一 PostgreSQL 版本、加 --no-owner --no-privileges，并注意 pg_get_constraintdef() 与 pg_dump 输出不一致等细节。
用 pg_dump --schema-only 提取表结构再 diff
开发库和生产库表结构不一致，最直接的办法不是进可视化编辑器点来点去，而是用命令行导出 schema，靠文本 diff 定位差异。可视化工具（比如 dbeaver、tableplus）的“比较结构”功能常卡在权限、连接超时或视图/分区表兼容性上，反而慢且不准。
实操建议：
- 确保两边数据库用相同 PostgreSQL 版本导出，否则
pg_dump输出格式可能微调（比如约束顺序、注释位置），造成误报差异 - 统一加
--no-owner --no-privileges，避免因用户/角色名不同导致大量噪音 - 对单张表，用
pg_dump -t "schema.table" --schema-only比全库快，也方便 grep 过滤 - 导出后别直接肉眼比对，用
diff -u a.sql b.sql | grep "^[-+]"快速扫变更行
注意 pg_get_constraintdef() 和实际 DDL 的行为差异
有些可视化工具内部用 pg_get_constraintdef() 拼 DDL，但这个函数返回的定义不一定和 pg_dump 生成的一致——比如 CHECK 约束里带函数调用时，它可能省略 schema 前缀，而 pg_dump 默认保留；又或者对自定义类型约束，输出格式不稳定。
这意味着：如果你看到工具提示“约束内容不同”，但手动查 pg_constraint 和 pg_dump 输出一致，大概率是工具自身解析逻辑有偏差。
实操建议：
- 遇到约束差异告警，先运行
SELECT pg_get_constraintdef(oid) FROM pg_constraint WHERE conrelid = 'schema.table'::regclass，和pg_dump输出逐行比对 - 特别留意
GENERATED ALWAYS AS列、IDENTITY列，老版本 pg_dump 可能漏导默认值表达式 - 如果用的是 Citus 或 TimescaleDB 扩展，
pg_get_constraintdef()对分布键/时间分区约束的支持更弱，必须以pg_dump为准
MySQL 用户别硬套 SHOW CREATE TABLE
MySQL 没有 pg_dump 那种稳定 schema 导出机制，SHOW CREATE TABLE 输出受 SQL mode、字符集、存储引擎参数影响极大。同一张表，在开发库（sql_mode=STRICT_TRANS_TABLES）和生产库（空 mode）下，SHOW CREATE TABLE 可能差出十几行。
实操建议：
- 统一两边
sql_mode再导出，或改用mysqldump --no-data --skip-triggers --skip-routines，它比SHOW CREATE TABLE更可控 -
ENGINE=InnoDB后面的ROW_FORMAT、KEY_BLOCK_SIZE等参数，除非业务强依赖，否则 diff 时建议忽略——用grep -v "ROW_FORMAT\|KEY_BLOCK_SIZE"预处理 - MySQL 8.0+ 的隐藏主键（
innodb_table_stats相关元数据）不会出现在SHOW CREATE TABLE，但会影响备份恢复一致性，这点常被可视化工具忽略
字段顺序变化不算结构差异，但某些 ORM 会报错
PostgreSQL 和 MySQL 都允许 ALTER TABLE 调整字段顺序（ALTER TABLE t ALTER COLUMN c TYPE int AFTER d 不合法，但可通过重建表实现），但标准 SQL 并不保证字段顺序语义。所以 pg_dump 输出的字段顺序，只反映当前物理顺序，不构成“结构差异”。
问题在于：Django、SQLAlchemy 这类 ORM 生成 migration 时，会把字段顺序当作 schema 的一部分；如果你用可视化工具导出的 DDL 建表，字段顺序和 ORM 预期不一致，后续 migrate 可能失败或静默跳过字段。
实操建议：
- 用
\d+ table_name（psql）或SELECT column_name, ordinal_position FROM information_schema.columns WHERE table_name='t' ORDER BY ordinal_position查真实顺序，和 ORM 的 model.py 字段顺序人工对齐 - 不要依赖可视化工具“一键同步结构”，尤其当它自动调整字段顺序时——先确认团队是否约定字段顺序为 schema 一部分
- 线上环境禁止用
ALTER TABLE ... ADD COLUMN插中间，一律追加到末尾，从源头减少顺序分歧
结构 diff 看似简单，真正麻烦的是那些“看起来一样，其实执行行为不同”的细节：扩展类型隐式转换、索引包含列的版本兼容性、COMMENT 是否带双引号……这些不会高亮在可视化界面里，得靠导出后的文本逐行盯。
