触发器执行顺序由定义顺序决定，但不能动态干预
MySQL 中同一事件（如
INSERT）和同一时机（
BEFORE或
AFTER）下多个触发器的执行顺序，**严格按创建时间先后（即
CREATED时间戳）升序执行**。你无法用
ORDER BY、权重字段或执行优先级语法控制它——MySQL 不提供此类机制。 若需特定顺序，必须按目标顺序依次
CREATE TRIGGER；先建的先执行，后建的后执行
DROP再重建会改变
CREATED时间，从而影响顺序，慎用 不同表的触发器互不影响，不存在跨表排序问题
BEFORE 和 AFTER 触发器之间有强制时序，不可颠倒
BEFORE触发器总在语句实际执行前运行，
AFTER触发器总在语句成功执行后（且事务未提交前）运行。这个时序是硬性规则，不受触发器定义顺序影响。
BEFORE INSERT可修改
NEW值，影响最终插入内容；
AFTER INSERT读到的是已写入的值 若
BEFORE触发器中抛出异常（如
SIGNAL SQLSTATE '45000'），整个语句中止，
AFTER触发器不会执行 在事务中，
AFTER触发器看到的是当前事务的中间状态，不是最终提交结果
同一张表上多个 BEFORE INSERT 触发器怎么排？看 CREATE 时间
假设对表
orders创建了两个
BEFORE INSERT触发器：
CREATE TRIGGER tr_orders_before_1 BEFORE INSERT ON orders FOR EACH ROW SET NEW.created_at = NOW(); CREATE TRIGGER tr_orders_before_2 BEFORE INSERT ON orders FOR EACH ROW SET NEW.status = 'pending';
只要
tr_orders_before_1先建，它就一定先执行；
NEW.created_at被设好后，
tr_orders_before_2才能读到该值（如果它需要）。但注意： 它们彼此隔离，不能直接访问对方对
NEW的修改“中间态”——所有修改都在同一个
NEW对象上累积 没有“返回值”或“链式传递”，只是先后调用，共享同一份
NEW可通过
SELECT TRIGGER_NAME, CREATED FROM INFORMATION_SCHEMA.TRIGGERS WHERE EVENT_OBJECT_TABLE = 'orders' AND ACTION_TIMING = 'BEFORE'查看真实顺序
替代方案：用存储过程封装逻辑，避免依赖触发器顺序
当业务逻辑强依赖执行先后（比如先校验、再补默认值、再记录日志），靠多个触发器拼顺序容易失控。更稳的做法是：
只保留一个BEFORE INSERT触发器，内部调用自定义存储过程
proc_handle_order_insert()把所有子逻辑写进该存储过程，用明确的语句顺序控制流程 便于调试、加日志、加事务控制，也规避了触发器元数据时间戳不可控的问题
触发器本质是“钩子”，不是流程引擎。复杂顺序依赖，交给存储过程更可靠。
