可以，但需函数声明为DETERMINISTIC、READS SQL DATA或NO SQL，禁止MODIFIES SQL DATA；跨库调用需权限，函数应仅作纯计算，避免查表或写操作，以防死锁和复制不一致。
MySQL 触发器里能直接调用自定义函数吗
可以，但有严格限制。MySQL 允许在 BEFORE 和 AFTER 触发器中调用存储函数（FUNCTION），前提是该函数被声明为 DETERMINISTIC 或带有 READS SQL DATA / NO SQL 特性，并且不包含非确定性操作（如 NOW()、RAND()、用户变量赋值等）。
常见错误现象：ERROR 1418 (HY000): This function has none of DETERMINISTIC, NO SQL, or READS SQL DATA in its declaration —— 这不是语法错，是安全机制拦截。
- 必须在创建函数时显式声明特性，例如：
CREATE FUNCTION calc_score(...) RETURNS INT DETERMINISTIC READS SQL DATA ... - 触发器内不能调用含
MODIFIES SQL DATA的函数（哪怕函数体只更新一张表也不行） - 若函数内部执行
INSERT/UPDATE/DELETE，即使加了MODIFIES SQL DATA，在触发器中调用仍会报错 - 跨库调用需用
db_name.func_name()格式，且当前用户要有对应库的EXECUTE权限
实际项目中常见的组合场景：订单状态自动计算
典型需求：当 order_items 表插入新行时，自动更新主表 orders.total_amount，并根据金额触发 VIP 等级重算逻辑。
这里不能在触发器里直接写复杂 SQL 更新 users.vip_level（会引发“同一语句中不能修改被触发表之外的表”错误），但可封装成函数供触发器调用 —— 实际上更推荐用函数做纯计算，把写操作留在触发器主体中。
- 函数只负责计算：
GET_VIP_LEVEL(total_amount)返回TINYINT，不查表也不改表 - 触发器负责写入：
AFTER INSERT ON order_items中先调用函数得等级，再UPDATE users SET vip_level = ... - 避免在函数里查
users表——否则可能因锁序导致死锁（尤其高并发下单时） - 函数返回值类型要和触发器中接收变量类型一致，否则隐式转换可能出错（比如函数返回
DECIMAL(10,2)，但触发器里用INT变量接，小数部分直接截断）
为什么不能在触发器里调用含 UPDATE 的函数
MySQL 的触发器执行处于语句级事务上下文中，而函数若标记为 MODIFIES SQL DATA，意味着它可能改变数据；MySQL 为防止不可预测的嵌套修改，禁止在触发器中调用这类函数。这不是性能限制，是事务一致性保护机制。
错误示例：CALL update_user_cache(user_id) 包含 UPDATE user_cache SET ... → 即使这个函数本身可独立执行，一旦被 BEFORE UPDATE ON orders 调用，就会报 ERROR 1422 (HY000): Explicit or implicit commit is not allowed in stored function or trigger。
- 解决方案一：把写逻辑从函数中移出，放到触发器主体里（最常用）
- 解决方案二：改用存储过程（
PROCEDURE），但触发器中无法直接CALL存储过程 —— 必须用事件或应用层协调 - 解决方案三：用
INSERT ... ON DUPLICATE KEY UPDATE替代函数内的INSERT/UPDATE，并确保函数只读或仅写临时表（但临时表在触发器中不可见）
生产环境要注意的隐蔽坑
函数+触发器组合看似简洁，但在分库分表、主从复制、备份恢复等环节容易暴露问题。
- 基于语句的复制（
binlog_format=STATEMENT）下，若函数含UUID()或USER()，从库执行结果可能和主库不一致 → 必须用ROW格式 - 函数定义未导出：mysqldump 默认不导出函数/触发器，恢复库时若缺失函数，触发器会编译失败，后续所有相关 DML 都报错
- ALTER TABLE 时若字段名和函数参数名冲突（如函数参数叫
status，表里也有status字段），触发器内引用易混淆，建议统一加前缀如in_status - 调试困难：触发器内函数调用无日志，出错只能靠
SELECT插桩或开启general_log（但线上慎开）
真正难的不是写出来，而是让这套逻辑在批量导入、主从延迟、长事务共存时不悄悄坏掉。
