外键约束无法保障自引用完整性，因其不感知软删除、禁止级联循环、要求非空等限制；必须用SELF JOIN或触发器结合业务规则（如is_deleted=0）手动校验。
自引用完整性不能靠外键约束自动保障，必须用 SELF JOIN 配合查询逻辑手动校验。 因为外键只能指向“另一张表”，而自引用（比如员工表里的 manager_id 指向本表的 employee_id）在建表时虽可加外键，但实际运行中常因级联删除、NULL 允许、软删除等场景失效——真正要确认“每个 manager_id 是否真实存在且未被逻辑删除”，得查出来看。
为什么外键不等于自引用完整？
MySQL/PostgreSQL 支持对本表建外键（如 FOREIGN KEY (manager_id) REFERENCES employees(employee_id)），但有硬限制：
- 该外键列不能是主键本身（否则无法设为 NULL，而顶层管理者通常没有 manager）
- 级联操作（
ON DELETE CASCADE）会引发自引用循环，多数引擎直接报错或禁用 - 若用了软删除（
is_deleted = 1），外键不感知业务状态，仍认为记录“存在” - 迁移或分库后，外键可能被主动去掉，约束丢失而不报警
用 SELF JOIN 找出断裂的自引用关系
核心思路：把表当两张表用，左实例查所有含 manager_id 的行，右实例查所有有效 employee_id，再用 LEFT JOIN + IS NULL 暴露缺失项。
例如员工表 employees 含字段 employee_id, name, manager_id, is_deleted：
SELECT e1.employee_id, e1.name, e1.manager_id FROM employees e1 LEFT JOIN employees e2 ON e1.manager_id = e2.employee_id AND e2.is_deleted = 0 WHERE e1.manager_id IS NOT NULL AND e2.employee_id IS NULL;
这个查询返回所有「指定了上级但上级不存在或已被软删除」的员工。关键点：
-
e2.is_deleted = 0必须写在ON子句里，不能放WHERE，否则会把e2为空的行过滤掉 - 如果允许
manager_id为 NULL（合理），则WHERE中需显式排除，避免误报 - 确保
employee_id和manager_id类型一致、字符集相同，否则隐式转换导致索引失效
在 INSERT/UPDATE 触发器里实时拦截（慎用）
若必须在写入时强校验，可在 BEFORE INSERT 或 BEFORE UPDATE 触发器中执行轻量 SELECT，但要注意：
- 只查
employee_id字段，用覆盖索引（如INDEX (employee_id, is_deleted)） - 避免
JOIN，改用EXISTS：IF NOT EXISTS (SELECT 1 FROM employees WHERE employee_id = NEW.manager_id AND is_deleted = 0) THEN SIGNAL SQLSTATE '45000' SET MESSAGE_TEXT = 'manager_id not found or deleted'; END IF; - PostgreSQL 触发器函数结尾必须写
RETURN NEW;，漏写会导致静默丢数据 - 高并发下，此触发器可能成为性能瓶颈，建议仅用于低频管理后台
真正难的不是写出那个 SELF JOIN，而是决定「哪些 manager_id 可以为空、哪些必须存在、软删除算不算失效」——这些是业务规则，SQL 只负责忠实执行。校验逻辑一旦写进触发器，就和表结构耦死，改起来比改应用代码还麻烦。
