JDBC环境下跨MySQL与PostgreSQL迁移的外键依赖表创建排序

你遇到的外键依赖排序本质是经典的有向图拓扑排序问题，完全不需要依赖精度不足的数据库创建时间字段，基于你已经收集好的表元数据就能在Java端高效实现，适配MySQL和PostgreSQL双向迁移的需求。
之前用表创建时间排序的方案本身存在硬伤：批量脚本建表时同秒完成的元数据精度不够，跨库迁移时第三方系统表的创建时间字段也不具备参考价值，完全不适合作为排序依据。
你当前定义的Table类结构完全可以支撑这个排序逻辑，不需要额外修改字段——每个外键数组的索引1位置就是被引用的表名，刚好可以直接用来构建依赖关系。

具体实现步骤 #

整个排序逻辑可以通过Kahn算法实现，时间复杂度和表的数量、外键的数量线性相关，对大学场景的数据库规模来说性能完全没有问题：

第一步：构建依赖关系图 #

• 先把你收集到的所有Table对象转成以表名为key的Map，实现O(1)的表对象查找，方便后续排序完成后直接取出对应的表生成建表语句。
• 定义图的边规则：遍历每一个Table实例的foreignKeys列表，每个外键数组里存的被引用表名就是当前表的强制前置依赖——创建当前表之前，必须先把它外键引用的表创建完成。
• 维护两个核心结构：
  • 邻接表：key是被依赖的表名，value是所有引用了该表的下游表名列表，用来记录每个表被哪些表依赖。
  • 入度表：记录每个表有多少个未处理的前置依赖，初始值全部设为0。
• 遍历所有外键条目完善图结构：
  1. 取出外键条目里的被引用表名refTableName，先检查这个表是否在当前迁移的表集合内（如果是跨schema、系统表这类不在建表流程内的引用，直接跳过即可）
  2. 如果被引用表在集合内，就把当前表名加到邻接表中refTableName对应的下游列表里
  3. 把当前表的入度值+1，代表当前表有一个必须先创建的前置依赖

自引用的外键（比如表的外键引用自身的主键）不需要特殊处理，算法可以正常完成排序：这类依赖会给当前表的入度加1，等所有其他前置依赖处理完成后，自引用对应的入度值会被正常减去，不会出现排序卡死的问题。

举个实际的结构示例：
假设你有三张表：无外键的user、外键引用user的order、外键引用order的order_item，构建完成后：

• 邻接表关系：user的下游是order，order的下游是order_item
• 入度数值：user入度为0，order入度为1，order_item入度为1

第二步：执行拓扑排序 #

• 初始化处理队列，把所有入度为0的表名先加入队列——这些是没有任何外键依赖、可以最先创建的表。
• 循环处理队列中的元素：
  1. 取出队首的表名，把对应的Table对象加入最终的排序结果列表
  2. 遍历所有依赖当前表的下游表，把每个下游表的入度值减1
  3. 如果某个下游表的入度减为0，说明它的所有前置依赖都已经处理完成，直接把它加入处理队列
• 排序完成后校验：如果最终结果列表的长度和初始收集的表总数不一致，说明存在循环外键依赖（比如A表引用B表，B表又反过来引用A表，没有可以最先创建的0入度节点）。

循环依赖的兜底处理 #

针对存在循环外键的场景，不要硬卡建表顺序，用数据库迁移工具通用的两阶段方案即可规避错误：

• 第一阶段：按照拓扑排序能生成的顺序，创建所有不带外键约束的表结构
• 第二阶段：等所有表都创建完成后，再逐个遍历所有表的外键定义，通过ALTER TABLE语句统一添加外键约束
  这个方案可以完全绕开循环依赖的问题，毕竟外键约束的添加本来就不需要在建表语句中立刻执行。

为什么不推荐通过SQL查询系统表完成排序 #

虽然MySQL、PostgreSQL的INFORMATION_SCHEMA都提供了外键依赖查询能力，但用SQL递归实现拓扑排序会受数据库递归深度限制，长依赖链下很容易报错；而且双向迁移场景下，还需要分别针对两个数据库的系统表结构写两套查询逻辑，反而不如在Java端基于已读取的元数据统一处理来得高效，也不需要额外发送SQL请求查询元数据。

内容的提问来源于stack exchange，提问作者Christian Kammerer