sql server外键默认no action，删主表需显式设on delete cascade；加级联须三步：查名、删旧约束、重建带cascade；级联删除不可逆且绕过应用层，建议优先用逻辑删除。
直接删主表数据报错“Cannot delete or update a parent row”？不是语法错，是外键默认拦着你——SQL Server 默认用 NO ACTION，必须显式改用 ON DELETE CASCADE 才能自动清理子表。
为什么 DELETE FROM parent 报错“foreign key constraint fails”
这不是数据库坏了，而是外键的默认行为在起作用。SQL Server 对没声明 ON DELETE 的外键，一律按 NO ACTION 处理：主表一删，只要子表里还有引用记录，立刻回滚并抛出错误。
- 错误典型提示：
DELETE statement conflicted with the REFERENCE constraint - 哪怕子表只有一行关联数据，也会被拦住
-
FOREIGN_KEY_CHECKS = 0在 SQL Server 里不存在（那是 MySQL 的），别套用 - 别手动先删子表再删主表——业务逻辑复杂时极易漏删、顺序错、事务不一致
给已有表加 ON DELETE CASCADE 的三步实操
SQL Server 不支持 ALTER TABLE ... ADD FOREIGN KEY ... ON DELETE CASCADE 一步到位。必须查名 → 删旧 → 建新。
- 先查外键名：
SELECT name FROM sys.foreign_keys WHERE parent_object_id = OBJECT_ID('UserMessages') AND referenced_object_id = OBJECT_ID('Users') - 再删约束：
ALTER TABLE UserMessages DROP CONSTRAINT FK_UserMessages_Users（把上步查到的名字填进去） - 最后重建：
ALTER TABLE UserMessages ADD CONSTRAINT FK_UserMessages_Users FOREIGN KEY (UserId) REFERENCES Users(Id) ON DELETE CASCADE - 注意：如果子表外键列（如
UserId）定义为NOT NULL，就不能选SET NULL；CASCADE本身不要求可空
级联删除的真实影响范围远超直觉
删一个 Users.Id = 123，可能触发多层连锁删除：从表 → 孙表 → 曾孙表。而这些过程完全绕过应用层，也不走触发器、不写审计日志、不发消息。
- 务必提前估算影响行数：
SELECT COUNT(*) FROM UserMessages WHERE UserId = 123，再查更下层（如MessageAttachments是否也外键指向UserMessages.Id） - timestamp 列不能参与任何
CASCADE操作，否则建约束失败 - 跨 schema 外键在 SQL Server 中允许，但必须写全名：
REFERENCES dbo.Users(Id)，不能省略 schema - 如果已存在数据不一致（比如
UserMessages.UserId有值但Users.Id里没有），建约束会直接失败，得先清洗
比级联更稳的替代方案：逻辑删除 + 应用层清理
真正容易被忽略的点不是怎么删，而是“该不该物理删”。级联删除一旦执行就不可逆，且彻底脱离业务控制流。
- 常见做法：主表加
IsDeleted BIT DEFAULT 0，查询默认加WHERE IsDeleted = 0，删操作只更新标记 - 子表同步标记或走后台任务异步归档，保留完整链路可追溯性
- 若必须物理删，建议封装成存储过程，开头加
IF EXISTS (SELECT 1 FROM UserMessages WHERE UserId = @id)检查并返回影响行数，由应用决定是否继续
级联删除不是银弹。它快，但哑；它自动，但不可见。上线前没跑过逐层 COUNT(*) 验证，没确认 timestamp 和 NULL 性约束，没评估审计/下游依赖——这时候点下 DELETE，就不是删数据，是删确定性。
