MySQL 触发器语法统一，但 MyISAM 与 InnoDB 因锁机制、事务支持、外键、崩溃恢复及全文索引等差异导致行为迥异：MyISAM 表级锁、无事务、无外键、无 WAL、全文索引异步且中文支持差；InnoDB 行级锁、支持事务回滚、外键联动、WAL 保障原子性、全文索引事务一致。
触发器本身不区分引擎，但执行效果受锁机制制约
MySQL 的 TRIGGER 语法本身对 MyISAM 和 InnoDB 是统一的，创建、删除、触发逻辑完全一样。真正造成差异的，是底层引擎的并发控制方式——MyISAM 表级锁会让触发器“卡住整个表”，而 InnoDB 行级锁只锁涉及行，这点在高并发写入时尤为明显。
- 比如一个
BEFORE INSERT触发器里调用了SELECT COUNT(*) FROM other_table：若other_table是 MyISAM，该 SELECT 会加表读锁；若同时有其他线程正往该表写入，就会被阻塞 - InnoDB 下同操作通常只加行级意向锁或间隙锁，不影响其他无关行的写入
- 更隐蔽的问题：MyISAM 不支持事务，所以触发器中发生的错误（如除零、字段超长）无法回滚主语句——
INSERT失败了，但触发器里已执行的UPDATE却不可逆
InnoDB 支持外键 + 触发器联动，MyISAM 完全不支持
这是实际开发中最容易踩坑的一点：如果你在触发器里试图维护引用完整性（例如子表插入前校验父表主键是否存在），InnoDB 可以靠外键约束自动拦截非法操作，再配合触发器做扩展逻辑；MyISAM 没有外键，只能全靠触发器手动检查——但它的触发器又不能抛出带语义的错误（MySQL 5.7+ 才支持 SIGNAL），往往只能靠 INSERT INTO error_log 记日志，业务层还得额外查日志判断是否成功。
- MyISAM 触发器中执行
INSERT INTO parent VALUES (999)后立刻SELECT id FROM parent WHERE id = 999，结果为空？别怀疑，它真不会报错，也不会阻止后续逻辑 - InnoDB 下同样操作若违反外键约束，直接报错
ERROR 1452 (23000): Cannot add or update a child row，且整个事务可回滚 - 注意：即使你没显式定义外键，InnoDB 表的触发器在修改关联字段时，仍可能因二级索引更新引发隐式锁等待（如
UPDATE t1 SET status=1 WHERE user_id IN (SELECT user_id FROM t2)）
崩溃恢复场景下，触发器行为稳定性差异极大
MyISAM 触发器执行过程没有 WAL（预写日志）保护。如果服务器在触发器中间崩溃（比如刚写完日志表、还没改主表），重启后数据状态就可能不一致——主表没变，日志表多了一条记录。InnoDB 则不同：所有 DML（包括触发器内语句）都记入 ib_logfile*，崩溃后通过重放日志保证原子性。
- 典型故障现象：MyISAM 表 A 上有个
AFTER UPDATE触发器，向日志表 B 写入变更记录。某次更新中途断电，结果 A 表数据未变，B 表却多了一条“本不该存在的”日志 - InnoDB 下这种分裂状态不会出现：要么 A 和 B 都更新成功，要么都回滚
- 额外限制：MyISAM 不支持
XA分布式事务，因此含触发器的跨库操作无法保证一致性；InnoDB 支持，但需应用层显式开启XA START
全文索引 + 触发器组合在 MyISAM 中看似可用，实则危险
MyISAM 支持 FULLTEXT 索引，而 InnoDB 直到 5.6.4 才支持——这曾让部分老系统坚持用 MyISAM 做搜索表。但一旦配上触发器，问题就来了：MyISAM 的全文索引更新是异步的（REPAIR TABLE 或 OPTIMIZE TABLE 才强制刷新），而触发器执行是同步的。这意味着触发器里读取 MATCH …… AGAINST 可能返回过期结果。
- 示例：触发器在插入新文章后立即执行
SELECT id FROM articles WHERE MATCH(title) AGAINST('MySQL')，但刚插入的那条记录可能尚未被全文索引收录，查询不到 - InnoDB 全文索引虽也非实时，但其更新与事务强绑定，只要在同一个事务内，
MATCH查询一定能看到刚插入的数据 - 更现实的坑：MyISAM 全文索引默认忽略小于 4 字符的词，且不支持中文分词——所谓“全文搜索”在中文场景基本等于摆设，触发器还为此多一次无意义查询
