用SQLAlchemy检查两库表结构差异最稳，核心是分别反射源库与目标库的MetaData，再逐表比对Column级属性（类型类、长度、nullable、default等），并按方言生成安全ALTER语句，跨库需降级为重建+迁移模式。
如何用 SQLAlchemy 检查两个数据库的表结构差异
核心是把源库和目标库的 MetaData 分别反射（reflect）出来，再逐表比对列、索引、主键、外键等元信息。不能只比表名是否存在，必须深入到 Column 级别——比如同名字段在源库是 String(255)，目标库是 Text，就属于不兼容变更。
实操建议：
立即学习“Python免费学习笔记（深入）”；
- 用两个独立的
Engine实例分别连接源库（如 MySQL）和目标库（如 PostgreSQL），避免事务或方言混用问题 - 反射时显式传入
only=[...]限制表范围，否则大库可能卡住或内存爆掉 - 对
Column比较要拆解：类型名（col.type.__class__.__name__）、长度（col.type.length）、是否为空（col.nullable）、默认值（col.default和col.server_default） - 注意方言差异：PostgreSQL 的
SERIAL和 MySQL 的INT AUTO_INCREMENT在 SQLAlchemy 中都映射为Integer，但实际建表语义不同，需额外判断
怎样生成安全的 ALTER TABLE 语句（而非 DROP/CREATE）
直接 drop_all() + create_all() 会清空数据，生产环境绝对禁止。必须基于差异分析结果，拼出最小化 DDL，例如只加缺失列、只改可变长度字段（ALTER COLUMN ... TYPE VARCHAR(500)）、跳过不可逆操作（如删主键）。
实操建议：
立即学习“Python免费学习笔记（深入）”；
- 用
sqlalchemy.dialects.postgresql或sqlalchemy.dialects.mysql下的CompileDialect获取方言特定的visit_*方法，避免手写 SQL 出错 - 对字段类型变更，优先用
ALTER COLUMN ... TYPE（PostgreSQL）或MODIFY COLUMN（MySQL），但需确认目标类型能无损转换（如VARCHAR(100) → VARCHAR(200)可行，反过来不行） - 新增列必须带
server_default或允许NULL，否则已有行无法填充值，执行会失败 - 外键变更要分两步：先删旧 FK（
DROP CONSTRAINT），再建新 FK（ADD CONSTRAINT），且需确保引用表已存在
如何处理跨方言同步（比如从 SQLite 迁移到 PostgreSQL）
SQLAlchemy 的抽象层在跨方言时会失效——SQLite 不支持 ALTER COLUMN TYPE，PostgreSQL 不支持 IF NOT EXISTS 在所有 DDL 中生效。硬同步必然失败，必须降级为“重建+迁移”模式。
实操建议：
立即学习“Python免费学习笔记（深入）”；
- 检测到跨方言（
engine.dialect.name != target_engine.dialect.name）时，自动切换策略：导出源表数据为 Python 对象列表，用target_metadata.create_all()建新表，再批量session.bulk_insert_mappings() - 禁用 SQLite 的
foreign_keys=ON约束检查，否则插入顺序错乱会报错；PostgreSQL 则需在事务开头加SET CONSTRAINTS ALL DEFERRED - 时间类型要特别小心：SQLite 用字符串存 datetime，PostgreSQL 用
TIMESTAMP WITH TIME ZONE，同步前需统一转成datetime.datetime对象再插 - 不要依赖
inspect.get_columns()的default字段——SQLite 返回的是 SQL 字符串（如"CURRENT_TIMESTAMP"），PostgreSQL 返回的是None或text()对象，需按方言分别解析
为什么不能跳过事务和锁控制直接跑同步脚本
哪怕只是加一列，也可能导致整张表被锁（MySQL 的 ALGORITHM=INPLACE 并非默认，PostgreSQL 9.6+ 虽支持并发 DDL，但 ADD COLUMN 仍需短时排他锁）。线上表没锁保护，同步中途被业务写入，轻则数据不一致，重则死锁回滚失败。
实操建议：
立即学习“Python免费学习笔记（深入）”；
- 所有 DDL 必须包裹在
with engine.begin() as conn:中，确保原子性；跨多表操作要单事务，避免部分成功 - 对大表（>100 万行），在执行
ALTER TABLE前加SELECT pg_advisory_lock(...)（PostgreSQL）或GET_LOCK()（MySQL）做应用层互斥，防止多个同步任务撞车 - 在 DDL 前后记录
inspect.get_indexes()和inspect.get_pk_constraint()，用于事后校验是否真生效，而不是只信返回码 - 永远保留上一次同步的
metadata快照（存 JSON 文件或专用表），下次运行前先比对快照，避免重复执行相同变更
最易被忽略的是外键依赖顺序和方言特有约束（如 MySQL 的 CHECK 在 8.0.16+ 才真正生效）。没有针对具体目标库做方言适配的同步脚本，上线即事故。
