MySQL 8.0+ 不支持外键引用分区表，无论主表子表是否分区，创建外键会报错；PostgreSQL 10+ 支持但要求主表为声明式分区根表且外键列有唯一索引；MySQL 可用触发器+应用层校验替代。

外键指向分区表时，MySQL 8.0+ 会拒绝创建

mysql 不支持外键引用分区表（无论 partition by range 还是 list），哪怕主表和子表都分区。执行 alter table child add foreign key (pid) references parent(id) 会直接报错：error 1503 (hy000): a key must be defined for each partition —— 这其实是误导性错误信息，真实原因是 mysql 根本不实现该功能。

常见错误现象：你反复确认主表有主键、字段类型完全一致、字符集相同，但外键始终加不上；或者在低版本（如 5.7）误以为能用，升级后突然失效。

根本原因不是配置或语法问题，而是 MySQL 的设计限制：分区表的元数据与外键约束的锁机制、一致性校验路径存在冲突，官方明确不支持。

• 别试图用 SET FOREIGN_KEY_CHECKS=0 绕过，它只跳过检查，不解决创建失败
• 不要在主表上加 UNIQUE KEY 或补全每个分区的索引，这无法触发外键支持
• 如果业务强依赖外键级联行为（如 ON DELETE CASCADE），必须放弃分区，或改用应用层模拟

PostgreSQL 中外键引用分区表，需确保主表是声明式分区根表

PostgreSQL 10+ 支持外键引用分区表，但前提是被引用的主表必须是「声明式分区根表」（CREATE TABLE parent (...) PARTITION BY ...），且子表外键列必须落在分区键上或有独立索引。

典型使用场景：订单主表按时间分区，订单项表通过 order_id 外键关联，要求插入订单项时强制校验订单是否存在。

关键参数差异：REFERENCES parent 指向的是根表名，不是具体分区名；PostgreSQL 会自动路由到对应分区做约束检查。

• 主表分区键字段（如 created_at）本身不能是外键列，否则无法满足分区约束条件
• 外键列（如 order_id）必须在主表根表上有唯一索引或主键 —— 分区表的主键默认在根表上建，但需确认索引未被意外删除
• 若主表是继承式分区（INHERITS），外键不生效，必须迁移到声明式分区

外键校验慢？检查 PostgreSQL 分区剪枝是否生效

即使外键语法合法，插入/更新子表时校验主表分区可能极慢，表现为你看到 INSERT INTO child ... 卡住几秒，EXPLAIN 显示扫描了全部分区而非目标分区。

性能影响根源在于：外键检查本质是一次隐式 SELECT 查询，若查询条件无法触发分区剪枝（partition pruning），就会遍历所有子分区。

• 确保外键列（如 order_id）在主表上有索引；仅靠分区键索引不够
• 避免在 WHERE 条件中对分区键使用函数，比如 WHERE date_trunc('month', created_at) = '2024-01-01' 会禁用剪枝
• 检查 postgresql.conf 中 enable_partition_pruning = on（默认开启，但某些云厂商镜像可能关掉）

MySQL 替代方案：用触发器 + 应用层校验兜底

当必须用 MySQL 分区表又需要参照完整性时，只能放弃外键，改用组合策略控制一致性。

核心思路是把外键逻辑拆成两层：触发器做快速存在性检查（轻量），应用层在事务中显式查主表（可靠）。

• 在子表 BEFORE INSERT/UPDATE 触发器里写 SELECT 1 FROM parent WHERE id = NEW.pid LIMIT 1，查不到就 SIGNAL SQLSTATE '45000'
• 触发器无法替代外键的级联动作，ON DELETE CASCADE 必须由应用在删除主记录前，先删干净所有子记录
• 注意触发器中查询分区表仍可能慢，务必给外键列加全局索引（非分区局部索引）

最易被忽略的一点：触发器里的 SELECT 不走查询缓存，也不受 READ COMMITTED 隔离级别保护，高并发下可能漏判——真正强一致，还得靠应用层加锁或重试逻辑。