必须用BEFORE触发器，因其在数据写入表前执行，可借助SIGNAL或RAISE EXCEPTION中断语句并回滚；AFTER触发器中数据已落盘，报错无法撤回，故完全无效。
必须用 BEFORE INSERT 或 BEFORE UPDATE 触发器配合 SIGNAL（MySQL）或 RAISE EXCEPTION（PostgreSQL），才能真正阻止非法数据写入；AFTER 类触发器完全无效——数据早已落盘，报错只是“事后喊停”。
为什么只能用 BEFORE 触发器
MySQL 和 PostgreSQL 的执行顺序是硬约束：BEFORE 阶段在数据写入表前最后一刻运行，此时可读写 NEW 字段，也能用 SIGNAL 或 RAISE 中断整个语句；而 AFTER 触发时，行已提交到磁盘，哪怕抛错也无法撤回这一行。
-
BEFORE INSERT中可对NEW.amount做字符串精度校验（如CAST(NEW.amount AS CHAR)+LOCATE('.', ...)），超 2 位小数就SIGNAL SQLSTATE '45000' SET MESSAGE_TEXT = 'Amount exceeds 2 decimal places' -
BEFORE UPDATE中可用OLD.status和NEW.status判断状态跳转是否合法，比如从'paid'只能到'refunded'，否则SIGNAL - 千万别在 Navicat 或 DBeaver 里建触发器时默认选
AFTER——工具常预设它，必须手动切到BEFORE
MySQL 中 SIGNAL 的写法和避坑点
SIGNAL 是 MySQL 5.5+ 唯一干净的中断方式，低版本只能伪造约束冲突（极不推荐）。
- 错误码必须用
'45000'，别用'HY000'——后者是系统保留码，会和真实数据库错误混淆 - 创建触发器前务必改
DELIMITER，否则SIGNAL后的分号会让 MySQL 提前结束解析，报ERROR 1064 -
NEW.xxx字段名拼错不会在 CREATE 时报错，但运行时抛ERROR 1327 (Undeclared variable)，建议先查表结构确认字段名 - 复制环境（主从）中触发器默认不同步，从库需手动重建，且要确保
log_bin_trust_function_creators=1
PostgreSQL 中 RAISE EXCEPTION 的关键细节
PostgreSQL 用 RAISE EXCEPTION，行为更严格，但也更容易踩坑。
- 不能在触发器里查本事务中前面插入的行（快照隔离），比如先插临时校验表、再在订单触发器里查它——这在 MySQL 可行，在 PG 里查不到
-
COPY导入完全绕过触发器，这是设计使然，不是 bug；想覆盖批量导入，只能换用INSERT INTO ... SELECT ... FROM ...或应用层预清洗 - 正则校验邮箱用
!~*（大小写不敏感否定匹配），比先LOWER()再匹配更高效 - NULL 比较不能直接用
NEW.field != OLD.field，得写成(NEW.field IS NULL) != (OLD.field IS NULL) OR NEW.field != OLD.field
真正难的不是写 SIGNAL，而是让所有写入口都经过它
只要有一个高权限账号（比如运维脚本、旧服务直连、ETL 工具）绕过应用层，直接 INSERT 或 UPDATE 表，触发器就形同虚设。唯一兜底办法是：收回所有账号的直接写权限，只开放给一个受限角色，并确保该角色所有操作都走触发器路径。另外，批量导入（LOAD DATA INFILE、COPY、多值 INSERT）会逐行执行触发器逻辑，性能可能断崖下跌，上线前必须压测。
