数据库结构检查：复合主键与外键字段顺序怎么核对

开始之前

多租户表经常通过 tenant_id 与业务 ID 共同确定一行。只看一根连线容易忽略字段顺序或漏掉租户字段。本例先用图定位关系，再回到字段列表核对。

载入复合键示例

把下面 SQL 放入关系图工具并分析。示例使用显式字段列表，便于审查复合外键的对应顺序。

示例

CREATE TABLE tenants (
  id BIGINT PRIMARY KEY
);
CREATE TABLE products (
  tenant_id BIGINT,
  product_id BIGINT,
  label VARCHAR(80) NOT NULL,
  PRIMARY KEY (tenant_id, product_id),
  FOREIGN KEY (tenant_id) REFERENCES tenants(id)
);
CREATE TABLE order_lines (
  id BIGINT PRIMARY KEY,
  tenant_id BIGINT NOT NULL,
  product_id BIGINT NOT NULL,
  FOREIGN KEY (tenant_id, product_id)
    REFERENCES products(tenant_id, product_id)
);

检查三表两关系

预期 3 张表、2 条关系：products.tenant_id → tenants.id；order_lines 的 tenant_id、product_id → products 的同名两列。products 的两个主键字段都应标记 PK。

按顺序逐列核对

复合外键按位置对应，不能只比较字段集合。若把目标顺序写成 product_id、tenant_id，即使字段都存在，语义也可能错误；本工具不会替你证明业务意图正确。

把图检查与数据库验证分开

检查源目标字段数、字段存在性和名称，再在自己的测试数据库验证 DDL。目标列是否具有适当唯一约束、类型是否兼容、已有数据能否通过约束，仍由数据库判断。

不能从图里判断的事情

UNIQUE、CHECK、索引与表选项可能只显示复核提示，并未完整绘制或验证。图中的 NOT NULL 和 PK 可以辅助阅读，但不提供查询计划、数据分布、索引利用率或迁移锁表评估。

可复现的负面检查

在输入副本中把目标字段 product_id 改成不存在的 missing_id，再分析，应出现“外键字段未找到”。修正后重试。对其他约束的实际合法性仍应使用目标数据库，而不是只依赖这个提示消失。

解析范围与数据库验证

工具只在浏览器解析 CREATE TABLE，不连接数据库也不执行 SQL。支持的外键会用于画图；ALTER TABLE、索引和其他未覆盖语句会提示复核，不能据此认为这些约束在数据库中不存在。每次最多 60 张表、1500 个字段，输入不超过 1 MiB。

https://www.postgresql.org/docs/18/ddl-constraints.html

要点总结

复合键顺序属于约束含义的一部分。
图检查和数据库执行检查应分别记录。
没有提示不代表不存在迁移或性能风险。