触发器余额计算出错主因是类型精度缺失、NULL未处理、并发读写不一致；需显式声明DECIMAL精度、用COALESCE兜底NULL、避免FLOAT转换，并发场景须应用层加锁而非依赖触发器。
直接说结论：触发器里算余额出错，90%不是逻辑写错了，而是类型精度、NULL处理、并发读取这三件事没对齐。
DECIMAL 精度没显式声明，小数直接被截断
比如源表金额字段是 DECIMAL(19,4)，你在触发器里写 CAST(@input AS DECIMAL)——SQL Server 默认变成 DECIMAL(18,0)，MySQL 也类似。'123.4567' 一转就变 123，差额全丢了。
- 必须查
sys.columns（SQL Server）或INFORMATION_SCHEMA.COLUMNS（MySQL）确认原字段的precision和scale，然后照搬声明变量：DECLARE @amt DECIMAL(19,4) - 字符串输入先
TRIM()再转，否则空格或CHAR(160)会导致Conversion failed when converting the varchar value ' 123.45 ' to data type decimal. - 绝对避免从
FLOAT或REAL转：二进制表示误差会让CAST(12.34 AS FLOAT)再转回DECIMAL得到12.339999999999999
NULL 参与运算导致整行结果为 NULL
触发器里写 SET NEW.balance = OLD.balance - NEW.delta，只要 OLD.balance 或 NEW.delta 是 NULL，结果就是 NULL，而不是 0。线上对账时这笔记录就“消失”了。
- 所有参与计算的字段都得用
COALESCE()显式兜底：COALESCE(OLD.balance, 0) - COALESCE(NEW.delta, 0) - 别依赖触发器外层默认值——
DEFAULT 0只影响 INSERT 缺失值，UPDATE 时字段本身为 NULL 就是真的 NULL - 在
BEFORE UPDATE里做校验时，用IF OLD.balance IS NULL OR NEW.delta IS NULL THEN SIGNAL SQLSTATE '45000' SET MESSAGE_TEXT = 'balance or delta missing';主动报错，比静默出错更容易定位
并发更新下触发器无法锁住“读-判-写”原子性
两个事务同时执行 UPDATE accounts SET balance = balance - 100 WHERE id = 1，都先读到 balance = 500，都判断够扣，都写入 400——最终余额是 400 而不是 300。触发器对此完全无能为力。
- MySQL 触发器不支持
SELECT ... FOR UPDATE，也不能开新事务，所以不能在触发器里加锁校验 - 真正能防超扣的只有应用层：先
SELECT balance FROM accounts WHERE id = ? FOR UPDATE，再判断、再UPDATE ... WHERE balance >= ? - 如果必须用触发器（比如多系统直连数据库），只能退一步做事后校验：
AFTER UPDATE里检查NEW.balance ，然后写日志或发告警，但无法阻止已发生的负余额
最麻烦的不是某一行算错，而是这些误差会跨触发器、跨语句、跨事务层层累积——比如一个 BEFORE INSERT 触发器把金额转成 DECIMAL(18,0)，另一个 AFTER UPDATE 又拿这个值去算手续费，最后对账时差几分钱，查三天才发现第一处 CAST 没写精度。
