直接删主表失败是因为子表外键引用，需先定位引用子表；可用information_schema查询或sql server系统视图；解决方式有on delete cascade（需重建约束）、手动分步删除（需事务包裹）或逻辑删除（推荐）。
直接删主表失败，本质是子表还在引用它——不是语法错，是数据库在拦你。
报错 “Cannot delete or update a parent row” 怎么快速定位外键来源
这个错误不会告诉你具体哪个子表在挡路。得自己查：
- 先确认主表名和被删的主键值，比如
DELETE FROM users WHERE id = 123 - 用
SELECT TABLE_NAME, COLUMN_NAME, CONSTRAINT_NAME FROM INFORMATION_SCHEMA.KEY_COLUMN_USAGE WHERE REFERENCED_TABLE_NAME = 'users' AND REFERENCED_COLUMN_NAME = 'id'找出所有引用users.id的子表和外键名 - 如果用的是 SQL Server，改查
sys.foreign_keys和sys.foreign_key_columns视图，别套 MySQL 的 SQL
查出来可能有 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 不会触发触发器、不写审计日志、不通知下游服务——它只管删，不管业务逻辑。如果你依赖这些，就得换方案。
不想改表结构？手动删子表再删主表更可控
适合需要校验、打日志、或子表删除逻辑复杂的场景。关键点是事务包裹 + 显式顺序：
- 先删最深层子表：
DELETE FROM order_items WHERE order_id IN (SELECT id FROM orders WHERE user_id = 123) - 再删中间层：
DELETE FROM orders WHERE user_id = 123 - 最后删主表：
DELETE FROM users WHERE id = 123 - 所有语句必须包在
BEGIN TRANSACTION/COMMIT里，避免只删了一半
别用 SET FOREIGN_KEY_CHECKS = 0 临时关检查——关了之后级联失效，只删主表，子表留孤儿数据，这不是解决，是埋雷。
逻辑删除（soft delete）常被忽略，但实际最安全
多数业务根本不需要物理删除。加个 is_deleted TINYINT DEFAULT 0 字段，删操作变成 UPDATE users SET is_deleted = 1 WHERE id = 123：
- 所有关联查询自动加
WHERE is_deleted = 0过滤 - 外键约束完全不受影响，子表照常引用
- 历史数据可追溯，审计合规压力小得多
真正难的从来不是“怎么删”，而是“删完之后谁来保证关联数据状态一致”。级联快，但黑盒；手动慢，但透明；逻辑删不碰关系，但要改全链路查询。选哪个，取决于你敢不敢为一致性担责。
