mysql触发器无内置执行次数限制，每次满足条件的语句执行即触发一次；需通过状态字段、应用层幂等或改用before触发器修改new值等方式实现“仅执行一次”。
触发器本身不提供执行次数限制机制
MySQL 触发器（BEFORE INSERT、AFTER UPDATE 等）在满足触发条件时**每次语句执行都会触发一次**，不会自动去重或限频。它没有类似 MAX_EXECUTIONS=1 这样的内置参数，也不能像存储过程那样加循环控制来“主动跳过”。所谓“控制执行次数”，实际要靠外部逻辑兜底。
常见误判场景：级联更新引发的重复触发
当触发器内执行了会再次激活同个触发器的 DML 操作（比如 AFTER UPDATE 里又 UPDATE 同一张表），就可能形成递归调用——这不是“执行次数可控”，而是**意外触发链**，MySQL 默认允许最多 255 层嵌套（由 max_sp_recursion_depth 控制），超限会报错 ERROR 1456 (HY000): Recursive limit 255 was exceeded。
- 避免在
AFTER触发器中修改当前表，尤其不要用UPDATE t SET ... WHERE id = NEW.id - 如必须更新，改用
BEFORE触发器直接修改NEW值，不发额外语句 - 检查是否有外键
ON UPDATE CASCADE与触发器共存，二者叠加易导致隐式多次触发
人工实现“仅执行一次”的可行路径
若业务真需要某逻辑只跑一遍（例如插入后发一次通知），不能依赖触发器自身节流，得借助状态标记：
- 在目标表加一个
processed TINYINT DEFAULT 0字段，在BEFORE INSERT或BEFORE UPDATE中设为 1 - 触发器开头加判断：
IF OLD.processed = 1 THEN LEAVE proc_label; END IF;（需配合标签使用） - 更稳妥的做法是把核心逻辑移到应用层，用数据库唯一约束 + 应用重试幂等性来代替触发器“防重”
注意：INSERT ... ON DUPLICATE KEY UPDATE 这类语句可能让 BEFORE INSERT 和 BEFORE UPDATE 都触发，需按实际语句类型分别设计守卫逻辑。
执行策略本质是语句粒度，不是行粒度
一个 UPDATE t SET x=1 WHERE y>100 语句影响 1000 行，BEFORE UPDATE 和 AFTER UPDATE 各触发 **1 次**（语句级），但其中的 OLD/NEW 是逐行可用的。如果你看到“触发了 1000 次”，大概率是用了客户端循环执行单行语句，或者触发器里又发了新语句导致扩散。
真正容易被忽略的是：MySQL 8.0+ 支持触发器中调用存储函数，但函数内若含 SELECT 或 INSERT，仍可能间接拉起更多触发器——这种隐式链条比显式 UPDATE 更难排查。
