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