BEFORE DELETE触发器中禁止SELECT ... FOR UPDATE，因MySQL限制表重复使用；校验需用只读查询或应用层前置；中断唯一方式是SIGNAL，须用标准SQLSTATE如'45000'。
BEFORE DELETE 触发器里不能用 SELECT ... FOR UPDATE
MySQL 的 BEFORE DELETE 触发器中，如果试图对当前正被删除的表做 SELECT ... FOR UPDATE 或任何写锁操作，会直接报错：Can't update table 't' in stored function/trigger because it is already used by statement which invoked this stored function/trigger. 这不是权限问题，是 MySQL 内部的表使用限制。
实操建议：
- 验证逻辑必须绕开「对原表加锁」——改用只读查询（
SELECT不带FOR UPDATE）或查关联表 - 若需强一致性校验（比如检查子记录是否存在），把校验逻辑提前到应用层，或用存储过程封装整个删除流程
- 触发器内禁止调用含写操作的自定义函数，哪怕函数里只更新另一张无关表，也可能触发同样限制
用 SIGNAL 抛出自定义错误中断删除
触发器没法 return 或 throw，唯一可靠中断方式是 SIGNAL。它能让删除语句立刻失败，并返回指定 SQLSTATE 和消息，应用层能捕获这个错误做对应处理。
实操建议：
- 必须用标准 SQLSTATE（5 字符），如
'45000'（通用未定义异常），避免用 MySQL 私有码 -
SIGNAL SQLSTATE '45000' SET MESSAGE_TEXT = 'Cannot delete: referenced by active orders';是安全写法 - 别依赖
SET @var := ...+ 后续判断——BEFORE触发器中变量赋值无法影响执行流，只有SIGNAL有效
触发器里查外键关联数据要小心性能和死锁
虽然 BEFORE DELETE 允许查其他表（比如检查订单表里是否还有指向该用户的记录），但高并发下可能引发隐式锁竞争。尤其当关联查询没走索引，或被查表本身正被大量写入时，延迟明显甚至超时。
实操建议：
- 确保所有关联查询条件字段都有索引，例如
WHERE user_id = OLD.id中user_id必须有索引 - 避免在触发器里做多层 JOIN 或子查询嵌套，尽量单表 + 精确 WHERE
- 不建议在触发器里调用存储函数做复杂校验——函数执行时间不可控，且可能意外持有锁
DELETE 语句本身不触发 BEFORE 触发器的例外情况
不是所有删操作都会进 BEFORE DELETE：比如 TRUNCATE TABLE 完全绕过触发器；DELETE 若带 IGNORE（如 DELETE IGNORE FROM t WHERE id=1），某些 MySQL 版本下 SIGNAL 会被静默吞掉，错误不抛出。
实操建议：
- 强安全逻辑绝不依赖
TRUNCATE，它无法被触发器拦截，必须禁用或替换为显式DELETE - 线上环境避免用
DELETE IGNORE，尤其在有触发器的表上——行为版本差异大，MySQL 5.7 和 8.0 对IGNORE+SIGNAL处理不一致 - 测试时务必覆盖
DELETE单行、多行、带事务、不带事务四种场景，确认触发器响应稳定
真正难的不是写触发器，而是想清楚：哪些校验必须在数据库层硬拦，哪些其实更适合放在应用事务开头做预检。锁、信号、执行顺序这三块，漏掉任意一个细节，安全逻辑就变成幻觉。
