MySQL 5.7.2+ 支持单表多个同类型触发器，需用FOLLOWS/PRECEDES显式指定执行顺序；5.6及更早版本严格限制每类事件时机仅允许一个触发器，报错ERROR 1235即为此限制。
MySQL 实际上**支持**在一个表上创建多个同类型的触发器——但仅限于 MySQL 5.7.2 及之后版本；如果你遇到报错，大概率是版本低于 5.7，或语法/命名没处理对。
ERROR 1235 报错说明你还在用 MySQL 5.6 或更早版本
这个错误信息 ERROR 1235 (42000): This version of MySQL doesn't yet support 'multiple triggers with the same action time and event for one table' 是 MySQL 5.6 及之前版本的硬性限制。它不允许同一张表存在两个 BEFORE INSERT、两个 AFTER UPDATE 等同类型触发器。
- 检查当前版本：
SELECT VERSION();—— 若返回5.6.x或更低，升级才是根本解法 - 不要试图“合并逻辑”来迁就老版本，那只是掩盖问题
- 5.6 下唯一 workaround 是把所有逻辑塞进一个触发器，用
IF分支判断，但可维护性差、调试困难
已是 5.7.2+ 却仍报错？大概率是触发器名冲突或缺 FOLLOWS/PRECEDES
MySQL 5.7.2 起解除单触发器限制，但要求显式声明执行顺序。不写 FOLLOWS 或 PRECEDES，第二个同类型触发器就会直接报错（哪怕名字不同）。
- 先建第一个：
CREATE TRIGGER t1_after_update AFTER UPDATE ON orders FOR EACH ROW BEGIN ... END; - 再建第二个时必须指定位置：
CREATE TRIGGER t2_after_update AFTER UPDATE ON orders FOR EACH ROW FOLLOWS t1_after_update BEGIN ... END; -
FOLLOWS和PRECEDES只能引用**已存在且同类型**的触发器名，否则报ERROR 3814 (HY000): Unknown trigger 'xxx' - 触发器名必须全局唯一：不能在
db1.users和db2.users上都建叫tr_log的触发器
MySQL 8.0+ 表面支持多触发器，但执行顺序不可靠
MySQL 8.0 并没有提供类似 PostgreSQL 的优先级机制。官方文档明确说明：同类型触发器（如多个 BEFORE INSERT）的执行顺序是 未定义的，仅依赖创建顺序，且不保证稳定。
- 不要依赖
SHOW TRIGGERS输出顺序来推断执行流，那只是元数据查询的自然排序 - 如果两个
BEFORE UPDATE触发器分别负责「更新时间戳」和「校验状态」，谁先谁后不确定 → 校验可能读到旧值 - 真正可控的方式只有一个：合并为单个触发器，用清晰的
IF/CASE分段，加注释标明逻辑区块 - 性能上，多个空壳触发器也会增加解析开销，尤其在高频 DML 场景下
为什么你总在触发器里改本表？那是 MySQL 明令禁止的
这不是“不支持多触发器”的问题，而是另一个高频陷阱：ERROR 1442 (HY000)。哪怕只建了一个触发器，只要它在 BEFORE 或 AFTER 中对当前表做 INSERT/UPDATE/DELETE，就会立刻失败。
- 典型误用：
BEFORE INSERT ON orders里查MAX(id)再赋值给NEW.id；或AFTER UPDATE里又去UPDATE orders设置updated_at - 无法绕过：子查询、临时表、事务控制都无效，MySQL 在解析阶段就拒绝
- 正确做法：改用日志表（
orders_log）、应用层补全、或INSERT ... ON DUPLICATE KEY UPDATE合并语义
真正难的不是语法能不能写出来，而是当多个触发器共存时，你根本没法确定哪段逻辑先跑、哪段看到的是新值还是旧值——这种不确定性，在生产环境里比报错更危险。
