触发器里调用函数会不会改变执行逻辑
会，但只在函数有副作用时才实际影响数据或流程。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()，但要注意该库权限是否对当前触发器上下文开放 函数本身不改变 MySQL 的语句生命周期阶段，但它把不确定性带进了原本应该“可预测”的触发器环节。最常被忽略的是：函数里一次
INSERT INTO audit_log看似无害，却让审计日志脱离主事务控制——主语句回滚了，日志还留着。
