报错“Cannot delete or update a parent row”说明外键约束阻止删除被子表引用的父表记录，即当前记录正被其他表（如orders、profiles等）的外键列实际引用，数据库为防止孤儿数据而强制保护参照完整性。
报错“Cannot delete or update a parent row”说明什么
这不是语法错误，是数据库在强制保护参照完整性——你删的那条记录，正被其他表的外键列（比如 user_id、order_id）实实在在地引用着。数据库拦住操作，是为了防止留下孤儿数据。
如何快速定位哪个子表在挡路
错误信息从不告诉你具体是哪张表、哪个约束在起作用，必须主动查：
- 先确认你要删的主表名和主键值，例如想删
users表中id = 123 - 用
INFORMATION_SCHEMA.KEY_COLUMN_USAGE查所有引用：SELECT TABLE_NAME, COLUMN_NAME, CONSTRAINT_NAME FROM INFORMATION_SCHEMA.KEY_COLUMN_USAGE WHERE REFERENCED_TABLE_NAME = 'users' AND REFERENCED_COLUMN_NAME = 'id'; - 如果用的是 SQL Server，换查
sys.foreign_keys和sys.foreign_key_columns；DM8 则查sys.dba_constraints
结果可能返回 orders、profiles、addresses 等多个表——意味着删一个用户，得处理至少三层关联数据。
已有表补 ON DELETE CASCADE 的实操步骤
MySQL 不支持直接 ALTER TABLE ... ADD FOREIGN KEY ... ON DELETE CASCADE，必须三步走：
- 查外键名：
SELECT CONSTRAINT_NAME FROM INFORMATION_SCHEMA.KEY_COLUMN_USAGE WHERE TABLE_NAME = 'orders' AND COLUMN_NAME = 'user_id'; - 删旧约束：
ALTER TABLE orders DROP FOREIGN KEY fk_orders_user_id;（把上一步查到的名字填进去） - 重建带级联的约束：
ALTER TABLE orders ADD CONSTRAINT fk_orders_user_id FOREIGN KEY (user_id) REFERENCES users(id) ON DELETE CASCADE;
注意：ON DELETE CASCADE 不会触发触发器、不写审计日志、也不通知下游服务——它只管删，不管业务逻辑是否允许。执行前务必用 SELECT COUNT(*) 逐层模拟影响范围，比如先查 SELECT COUNT(*) FROM orders WHERE user_id = 123，再查子表数量。
别碰 SET FOREIGN_KEY_CHECKS = 0 这个开关
临时关外键检查不是解决方案，是埋雷：
- 关了之后
DELETE FROM users WHERE id = 123能跑通，但所有子表记录全留在原地，变成孤儿数据 - 后续如果重新启用约束，可能因数据不一致而无法启用成功
- 仅限测试环境做一次性清理，且必须提前备份
真正容易被忽略的点是：级联删除、手动分步删、逻辑删除这三种路径，本质对应三种业务假设——你默认按哪种方式删，就等于默认接受了它的副作用。比如开了 CASCADE 却没意识到它会递归删掉 inventory_logs，或者手动删时忘了包事务，导致只删了一半。
