最可靠方法是直接查 INFORMATION_SCHEMA.COLUMNS 和 sys.columns，用 system_type_id + max_length + precision + scale 判断类型，比对 is_nullable、column_default、is_identity、collation_name 等细节，并用 EXCEPT 差集比对。
SQL Server 存储过程中怎么比对两个库的表结构差异
直接查 INFORMATION_SCHEMA.COLUMNS 和 sys.columns 最可靠，别信第三方工具生成的 DDL。不同 SQL Server 版本对 sys.types 的 user_type_id 映射不一致，用 system_type_id + max_length + precision + scale 组合判断数据类型才稳。
常见错误是只比字段名和类型，漏掉 is_nullable、column_default（尤其是带括号的默认值如 (getdate())）、is_identity。这些差异会导致后续 INSERT 失败或主键冲突。
- 把源库和目标库的列元数据分别查到临时表，用
EXCEPT做差集比对，比字符串拼接 DDL 更快更准 - 注意
collation_name：跨地域部署时，一个库是Chinese_PRC_CI_AS，另一个是SQL_Latin1_General_CP1_CI_AS，就算字段名类型都一样，也算结构不一致 - 不要在存储过程中动态拼
ALTER TABLE ... ADD COLUMN后立刻执行——SQL Server 不允许在单个批处理里先改结构再引用新字段
MySQL 存储过程里如何安全地 ALTER TABLE 同步字段
MySQL 5.6+ 支持 ALGORITHM=INPLACE，但不是所有 ALTER 都能免锁。比如给大表加 NOT NULL 字段且无默认值，会触发全表拷贝；加有默认值的字段虽快，但该默认值会写入磁盘所有行（除非用 ADD COLUMN ... DEFAULT 'x' ALGORITHM=INSTANT，仅 8.0.12+ 支持）。
真实同步场景下，必须分三步走：先 ADD COLUMN（带默认值），再用循环分批 UPDATE 填历史数据（避免长事务阻塞），最后 MODIFY COLUMN 改约束。不能图省事一步到位。
- 用
SELECT COUNT(*)判断目标表是否为空，空表可直接CREATE TABLE LIKE，跳过逐字段比对 -
information_schema.COLUMNS中的column_comment和extra（如auto_increment）也要比，否则主从复制可能异常 - 禁止在存储过程中调用
PREPARE/EXECUTE执行含变量的ALTER——MySQL 对 prepare 的 DDL 支持有限，8.0 下某些语法会报ER_UNSUPPORTED_ALTER_IN_PREPARE
PostgreSQL 函数中怎么避免 pg_dump 无法捕获的结构漂移
PostgreSQL 的 pg_get_constraintdef() 和 pg_get_expr() 是还原约束和默认值的关键，但它们返回的是“可执行字符串”，不是原始定义。比如源库用 CHECK (status IN ('A','I'))，目标库还原后可能变成 CHECK ((status = ANY (ARRAY['A'::text, 'I'::text])))——语义等价，但字符串不等，导致比对误报。
真正要同步的不是“看起来一样”，而是“行为一致”。所以比对时得归一化：把 ANY(ARRAY[...]) 展开成 IN，把带类型强制的文本（'x'::text）去掉类型标注，再哈希比对。
- 用
pg_get_serial_sequence()检查序列依赖，避免只建了字段没建关联序列 -
pg_class.relkind = 'r'过滤掉视图和物化视图，否则pg_dump --schema-only会漏掉CREATE MATERIALIZED VIEW语句 - 分区表要单独处理：
pg_partitioned_table视图必须查，否则子表结构变化不会触发父表同步逻辑
跨数据库同步结构时，哪些地方最容易被忽略
字符集和排序规则不是“设了就完事”。SQL Server 的 utf8mb4 等价于 MySQL 的 utf8mb4_0900_as_cs，但 PostgreSQL 默认用 en_US.utf8，三者 collation 强度不同，WHERE name = 'abc' 在一个库区分大小写，另一个不区分，应用层就会出错。
还有两个硬伤：一是外键的 ON UPDATE CASCADE，MySQL 支持，SQL Server 只支持 NO ACTION 和 SET NULL，PostgreSQL 全支持——同步时若不做策略映射，目标库建表会失败；二是 JSON 字段，MySQL 用 JSON 类型，SQL Server 用 NVARCHAR(MAX) 加 CHECK 约束，PostgreSQL 用 JSONB，类型名不同，校验逻辑也得跟着换。
- 时间类型统一用
TIMESTAMP WITH TIME ZONE（PostgreSQL）、DATETIMEOFFSET（SQL Server）、TIMESTAMP（MySQL 8.0.22+ 支持时区）——别用DATETIME或DATE，跨时区插入数据会偏移 - 索引名长度限制不同：SQL Server 最长 128 字符，MySQL 64 字符，PostgreSQL 63 字符。自动生成索引名时得截断并加哈希后缀，否则建索引失败
- 权限同步不在结构同步范围内，但
GRANT SELECT ON TABLE如果没同步，下游应用连查询都会被拒，这个得单独跑脚本补
