mysql触发器调用存储函数报function不存在，因上下文不继承数据库作用域，须用全限定名并确保definer有execute权限；new/old不可在函数内访问，需传参；postgresql中before触发器禁止写操作，应改用after或异步方案；sql server标量函数易致n+1性能问题，建议改用内联表值函数。
触发器里调用存储函数会报错：FUNCTION xxx does not exist
常见于 MySQL，尤其是跨数据库调用或函数定义在非当前默认库时。触发器执行时的上下文不自动继承创建时的数据库作用域，DEFINER 用户权限和函数可见性容易脱节。
实操建议：
- 函数必须显式用
database_name.function_name全限定名调用，不能只写function_name - 确保触发器所在表的数据库与函数所在数据库一致，或函数已用
CREATE FUNCTION mydb.myfunc显式指定库前缀 - 检查
DEFINER用户是否对函数所在库有EXECUTE权限（不只是select） - 避免在函数里写
INSERT/UPDATE/delete—— MySQL 不允许触发器中调用修改同表的函数，会直接报Can't update table 'xxx' in stored function/trigger
MySQL 触发器 + 存储函数无法读取 NEW/OLD 的字段值
不是语法错误，而是作用域问题：函数体里拿不到触发器上下文中的 NEW 或 OLD 别名。它们只在触发器主体内有效，进不了函数内部。
实操建议：
- 把需要参与计算的字段值作为参数传给函数，例如：
SET @result = my_calc_func(NEW.amount, NEW.currency); - 不要在函数里尝试访问
NEW.id—— 这会报Unknown column 'NEW.id' in 'field list' - 如果逻辑复杂且需复用，优先考虑把核心计算逻辑抽成函数，但所有输入必须“拍平”为标量参数，别指望函数能感知触发器上下文
PostgreSQL 中 trigger 调用 function 时提示：cannot execute INSERT in a read-only transaction
这是 PostgreSQL 的严格事务模型导致的：BEFORE 触发器函数默认运行在只读事务段，而你写的函数里可能隐含了 INSERT INTO log_table 这类写操作。
实操建议：
- 改用
AFTER触发器 —— 它允许写操作，且能安全访问NEW/OLD - 若必须在 BEFORE 阶段写日志，改用
PERFORM+ 临时表或pg_notify异步通知，避开事务限制 - 确认函数定义用了
LANGUAGE plpgsql且声明为volatile（默认），而非STABLE或IMMUTABLE—— 后两者禁止副作用
SQL Server 里 trigger 调用 scalar function 导致性能暴跌
不是 bug，是执行计划陷阱：每个被触发的行都会单独调用一次函数，如果函数里有查表、循环或字符串处理，就会变成 N+1 查询模式，尤其在批量 INSERT ... SELECT 场景下放大明显。
实操建议：
- 优先用内联表值函数（
ITVF）替代标量函数（SVF）—— SQL Server 能把它“展开”进主查询执行计划 - 若必须用 SVF，检查是否开启了
QUERY_OPTIMIZER_HOTFIXES或兼容级别 ≥ 150，新版优化器对 SVF 内联有一定支持 - 更彻底的解法：把函数逻辑直接写进触发器的
UPDATE/INSERT语句中，用CASE、ISNULL等原生表达式代替调用
最常被忽略的是函数的“可见性边界”和“执行上下文隔离”——它不像普通代码那样共享变量或作用域，每次调用都是干净的新上下文。跨数据库、跨权限、跨事务阶段时，这点特别容易翻车。