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 隔离级别保护，高并发下可能漏判——真正强一致，还得靠应用层加锁或重试逻辑。
