signal sqlstate '45000' 是唯一能真正阻止物理删除的方式，其他写日志、赋值、伪报错全无效；before delete 触发器必须用 signal 中断，否则删操作照常执行；校验须基于 old 字段直判，禁用子查询与函数；truncate 和 drop 不触发触发器，需权限管控兜底。
SIGNAL SQLSTATE '45000' 是唯一能真正阻止物理删除的方式，其他写日志、赋值、伪报错全无效。
BEFORE DELETE 触发器必须用 SIGNAL 中断，否则删操作照常执行
MySQL 的 BEFORE DELETE 触发器不会自动拦截——它只是“在删之前跑一段代码”，跑完不管结果，默认继续删。
常见无效写法包括：
• SELECT 1/0 或 SELECT 'blocked' —— 语法合法但 MySQL 当作普通语句执行，删仍完成
• INSERT INTO audit_log ... —— 日志写了，数据也删了
• SET @msg = 'no' —— 变量设了，无任何阻断效果
• RAISERROR（SQL Server 风格）—— MySQL 不识别，直接报语法错误，但可能已删部分行
真正起效的只有一行：SIGNAL SQLSTATE '45000' SET MESSAGE_TEXT = '禁止删除系统账户';
这个错误码是 MySQL 5.5+ 原生支持的通用自定义错误，客户端会收到明确报错（如 ERROR 1644 (45000): 禁止删除系统账户），事务自动回滚，本行不删。
校验必须基于 OLD，且不能查表或调函数
OLD 是触发器里唯一可用的待删数据快照，所有判断只能靠它字段直判：
• 正确： IF OLD.role IN ('admin', 'system') THEN SIGNAL ... END IF;
• 正确： IF OLD.is_protected = 1 THEN SIGNAL ... END IF;
• 正确： IF OLD.id IN (1, 100, 999) THEN SIGNAL ... END IF;
禁止行为：
• 子查询校验，如 SELECT COUNT(*) FROM orders WHERE user_id = OLD.id —— 易死锁、拖慢主操作、甚至触发锁等待超时
• 调用自定义函数（哪怕只读）—— 函数内若含 SELECT 或访问其他表，同样风险
• 查 deleted 表 —— 这是 SQL Server 的临时表，MySQL 里不存在
TRUNCATE TABLE 和 DROP TABLE 完全不触发该触发器
这是最常被忽略的盲区：
• TRUNCATE TABLE users 是 DDL 操作，不走任何 BEFORE/AFTER DELETE 触发器，也不记 binlog 的 DELETE 事件，不可回滚
• DROP TABLE users 同理，触发器机制完全不监听
• 即使你建了十个 BEFORE DELETE 触发器，对这两个命令也毫无反应
可行兜底手段只有：
• REVOKE DELETE ON prod_db.users FROM 'dev_user'@'%';
• REVOKE DROP ON prod_db.* FROM 'app_user'@'%';
• 对高危表启用软删除字段（如 is_deleted TINYINT DEFAULT 0），把物理删变成带条件的 UPDATE
批量删、分批删、ORM 批量操作都可能绕过触发器逻辑
触发器是逐行触发的，OLD 每次只代表一行，但它无法感知上下文：
• DELETE FROM users WHERE id IN (1,2,3) —— 触发器会跑三次，每次判断一行；只要其中一行不触发 SIGNAL，其余两行照样删掉
• ORM 如 Django 的 QuerySet.delete() 或 MyBatis 的 deleteBatch —— 底层仍是标准 SQL，触发器生效，但应用层可能忽略错误或吞掉异常
• IGNORE 语法（如 DELETE IGNORE FROM users...）会压制部分错误，SIGNAL 报错可能被跳过（取决于 MySQL 版本和 sql_mode）
更可靠的防线不是靠触发器单点拦截：
• 开启 sql_safe_updates=ON，让没带 WHERE 条件的 DELETE 直接报错
• 所有删除请求强制走审批流程，DBA 账号启用二次认证
• 生产库禁用 sql_log_bin = 0，防止绕过 binlog 审计
