触发器中调用函数不改变执行顺序，但有副作用时会影响逻辑；纯计算函数安全，含DML或状态修改的函数易引发错误、死锁或数据不一致。
触发器里调用函数会不会改变执行逻辑
会，但只在函数有副作用时才实际影响数据或流程。MySQL 触发器中调用的函数本身不改变语句执行顺序，但如果该函数内部执行了 INSERT、UPDATE、DELETE 或修改了用户变量、临时表、全局状态（比如通过 SELECT ... INTO @var），就可能间接干扰触发器上下文甚至引发递归或死锁。
常见错误现象：Can't update table 't' in stored function/trigger because it is already used by statement which invoked this stored function/trigger —— 这是 MySQL 的明确限制，禁止在触发器中修改当前正在被操作的表。
- 纯计算型函数（如
ABS()、CONCAT()、自定义的DELIMITER $$ CREATE FUNCTION f() RETURNS INT ... END $$且只做运算）完全安全 - 含 SQL 语句的函数（哪怕只是
SELECT COUNT(*) FROM log_table）虽不报错，但可能拖慢触发器响应，且若log_table正是触发器所在表，则直接报错 - 函数里调
用存储过程？不允许。MySQL 不允许函数中执行会修改数据的语句，包括调用含 DML 的存储过程
MySQL 中触发器和函数的实际执行顺序
以一条 INSERT INTO t VALUES (1) 为例，完整链路是：语句解析 → 检查 BEFORE INSERT 触发器 → 执行触发器内语句（含函数调用）→ 执行原 INSERT → 检查 AFTER INSERT 触发器 → 执行其内函数调用 → 返回结果。函数调用总嵌套在触发器执行阶段内，不会跳到“外面”去。
关键点在于：函数本身没有独立调度权，它只是触发器代码块中的一条表达式求值步骤。比如 SET NEW.name = UPPER(get_user_name(NEW.id));，get_user_name() 会在 UPPER() 之前执行，但整个赋值动作发生在 BEFORE 触发器的执行期间。
- 函数返回值参与触发器逻辑判断（如
IF validate_email(NEW.email) THEN ...），但函数不决定是否进入触发器 - 触发器执行失败（比如函数抛出异常、或函数返回值导致
INSERT违反约束），整条语句会回滚，函数副作用（如写日志表）若已提交则无法自动回滚——这是典型坑点 - 同一触发器内多次调用同一函数，每次都会重新执行，不会缓存结果（除非函数声明为
READS SQL DATA且你手动加缓存逻辑）
哪些函数在触发器里特别容易出问题
NOW()、UUID()、RAND() 看似无害，但在 BEFORE 触发器中多次调用可能产生不一致值；而 LAST_INSERT_ID() 在触发器中几乎总是返回 0 或上一条语句的 ID，而非当前 INSERT 的 ID（因为自增 ID 尚未分配）。
-
SYSDATE()和NOW()行为不同：SYSDATE()返回函数执行时刻，NOW()返回语句开始时刻，在长事务触发器中可能差几秒 -
USER()、CURRENT_USER()在触发器中有效，但注意权限上下文仍是原连接用户，不是定义者 - 自定义函数若声明为
MODIFIES SQL DATA，根本不能在触发器中调用——MySQL 会直接报错This function has none of DETERMINISTIC, NO SQL, or READS SQL DATA
想安全复用逻辑，该用函数还是存储过程
如果逻辑需要读写数据、调用其他 DML、或必须保证原子性，别用函数，改用存储过程 + 触发器中显式调用 CALL proc_name()。函数只适合纯计算、查只读表（且确认该表不会被当前语句涉及）。
例如：要根据订单金额自动插入积分记录，必须用存储过程；但校验手机号格式、拼接用户名，用函数更轻量也更清晰。
- 函数必须声明特性：
DETERMINISTIC（确定性）、NO SQL（无 SQL）、READS SQL DATA（只读）三选一，否则无法创建 - 触发器中调用函数时，MySQL 不检查函数内部是否真守约，只看声明——声明错了，运行时报错或行为异常
- 跨库调用函数需写全名：
other_db.func_name()，但要注意该库权限是否对当前触发器上下文开放
INSERT INTO audit_log 看似无害，却让审计日志脱离主事务控制——主语句回滚了，日志还留着。
