MySQL触发器中禁止使用START TRANSACTION、COMMIT、ROLLBACK等事务控制语句，状态变更需依赖BEFORE触发器+SIGNAL实现一致性校验，且须严格枚举合法状态转移路径并避免复杂查询。
触发器里不能用事务控制语句
MySQL 的 BEFORE 和 AFTER 触发器中，START TRANSACTION、COMMIT、ROLLBACK 全部被禁止。想靠触发器内部“回滚一部分操作来维持状态一致性”是行不通的。
常见错误现象：ERROR 1305 (42000): SAVEPOINT does not exist 或直接报语法错误——只要触发器体里出现 COMMIT 就会炸。
- 状态更新逻辑必须是原子的：要么整条 INSERT/UPDATE 成功，状态跟着改；要么主操作失败，触发器根本不会执行
- 如果业务要求“状态变更失败则拒绝原操作”，得用
BEFORE触发器 +SIGNAL抛异常（MySQL 5.5+） - PostgreSQL 没这个限制，但要注意触发器函数里显式开启事务会隐式结束当前事务上下文，反而更难控
状态字段必须有明确的合法值集合
别让 status 字段变成自由文本字段。否则触发器判断分支会失控，比如 'pending'、'PENDING'、'pendng' 都算“待处理”，但数据库不认。
使用场景：标签状态机常用于工单、审批流、数据同步任务等，每个环节只允许进入有限几个下游状态。
- 建表时用
ENUM('draft','pending','approved','rejected')或外键关联status_types表 - 触发器里用
CASE WHEN OLD.status = 'pending' AND NEW.status = 'approved' THEN ...显式枚举转移路径，别写IF NEW.status != OLD.status THEN ... - 漏掉某个状态组合？比如允许
draft → rejected但没写对应逻辑，就会静默跳过状态校验
避免在触发器里调用存储过程或复杂查询
触发器执行是在主 SQL 语句的同一事务内，任何慢查询或锁表操作都会拖垮整个 DML 性能。尤其当表日均写入超万级时，SELECT ... FROM another_table WHERE tag_id = NEW.id 很容易成为瓶颈。
性能影响：一次 UPDATE tags SET name='x' WHERE id=123 可能因触发器里的关联查而从 2ms 涨到 150ms。
- 状态转移规则尽量静态化：把前置条件（如“只有 creator 可以撤回”）拆到应用层或用检查约束（CHECK constraint）
- 真要查其他表，确保被查字段有索引，且只查必要列，禁用
SELECT * - 不要在触发器里调用含
INSERT/UPDATE的存储过程——可能引发递归触发或死锁
UPDATE 触发器必须区分“谁改的”和“改了什么”
很多状态机依赖操作人角色或上下文，比如“只有审核人能将状态设为 approved”，但触发器看不到应用层传来的用户 ID，只能靠字段推断。
容易踩的坑：把 updated_by 字段当成可信输入，结果应用层没填或填错，触发器照单全收，状态就乱了。
- 在触发器里加校验：
IF NEW.updated_by IS NULL OR NEW.updated_by NOT IN (SELECT id FROM users WHERE role = 'reviewer') THEN SIGNAL SQLSTATE '45000' SET MESSAGE_TEXT = 'Only reviewers can approve'; - 更稳妥的做法是：状态变更由专用接口驱动，触发器只负责副作用（如写日志、更新统计字段），主状态流转走应用层 + 乐观锁
- MySQL 不支持行级上下文变量，别试图在触发器里存“上一步操作类型”，它没有调用栈
状态机越靠近数据库层，就越难调试。线上出问题时，你看到的往往只是 UPDATE tags SET status='approved' WHERE id=456 执行成功，但没人知道触发器中途悄悄改了 updated_at 还是删了缓存——这些都得靠日志或额外审计字段兜底。
