触发器中不应直接编写复杂公式，而应将计算逻辑封装为函数调用；函数需显式声明返回类型、处理NULL和异常，并避免查表写表；仅强一致性场景才用触发器，其余计算应放应用层或物化视图。
触发器里别直接写复杂公式
SQL 触发器不是计算器，硬塞 ROUND((a * b - c) / d + e, 2) 这类嵌套运算，可读性差、调试难、还容易因 NULL 或除零崩掉。真正该做的是把计算逻辑抽出去——用函数封装。
- 所有涉及多步运算、条件分支、精度控制的逻辑，一律移到
CREATE FUNCTION中（PostgreSQL/MySQL 8.0+/SQL Server 均支持） - 触发器里只调用一次函数，比如
UPDATE orders SET total = calculate_order_total(new.quantity, new.price, new.discount) - 函数必须显式声明
RETURNS类型，并处理NULL输入（例如用COALESCE或NULLIF） - 避免在函数里查表或写表——否则触发器执行时可能引发递归或死锁
MySQL 中触发器调用自定义函数的坑
MySQL 对触发器内函数调用限制多，尤其老版本（5.7 及以前）不支持函数里含 SELECT，且函数必须是 DETERMINISTIC 或明确标为 READS SQL DATA，否则建触发器会报 ERROR 1418。
- 建函数时必须加
DETERMINISTIC（如果结果仅取决于输入参数），哪怕你心里清楚它不会变 - 若函数真要查配置表（比如税率表），得改成
READS SQL DATA，但触发器仍可能因隔离级别问题读到旧值 - MySQL 不允许触发器里调用包含
INSERT/UPDATE/DELETE的函数，否则直接报错ERROR 1422 - 函数返回类型务必和字段类型严格匹配，比如字段是
DECIMAL(10,2)，函数就不能只写RETURNS DECIMAL，得写全RETURNS DECIMAL(10,2)
PostgreSQL 触发器函数如何安全处理除零和溢出
PostgreSQL 允许在触发器函数（PL/pgSQL）里做异常捕获，这是比 MySQL 更可控的方式。但默认除零会抛 division_by_zero 异常，导致整个事务回滚——这通常不是你想要的。
- 用
BEGIN ... EXCEPTION WHEN division_by_zero THEN ... END捕获，返回默认值（如0.0）或NULL - 大数运算前用
pg_typeof()或范围检查（如ABS(x) > 1e13）预判溢出，避免numeric field overflow - 不要依赖
ON EXCEPTION兜底所有错误：像空指针（NULL参与运算）需提前用COALESCE(x, 0)处理 - 函数末尾记得加
RETURN NEW（行级触发器），漏了就等于没更新数据
触发器 vs 应用层计算：什么必须放数据库里
不是所有数学运算都该进触发器。核心判断标准只有一个：这个值是否必须在数据库层面强一致性保证？比如库存扣减后的可用量、财务系统中的借贷平衡校验。
- 需要原子性保障的场景才用触发器：如
UPDATE inventory SET available = available - 1 WHERE id = 123同时要更新last_modified和version字段 - 纯展示类计算（如“折后价”“年化收益率”）放应用层更灵活，改个公式不用动数据库结构
- 涉及跨表聚合（如订单总金额 = SUM(items.price * items.qty)）绝不能放触发器里实时算——应走物化视图或定时任务更新汇总表
- 哪怕用了触发器，也得在应用层做二次校验——数据库不是银弹，网络中断或主从延迟可能导致应用看到旧值
最麻烦的从来不是写对一个公式，而是当业务要求“把折扣率从固定值改成按会员等级动态取”时，你得同时改函数定义、触发器逻辑、历史数据补救脚本，还不能锁表太久。
