update前必须确认源字段和目标字段的decimal精度一致，否则隐式转换会截断小数位；所有中间值需显式声明相同精度，避免money类型、整数除法、浮点比较及null/溢出风险。
UPDATE前必须确认源字段和目标字段的DECIMAL精度一致
很多精度误差不是发生在UPDATE语句里，而是因为源表金额字段是DECIMAL(18,2)，而你UPDATE时用的变量或子查询结果是DECIMAL(18,0)或FLOAT，隐式转换直接截掉小数位。
实操建议：
- 查源字段真实精度：
SELECT COLUMN_NAME, NUMERIC_PRECISION, NUMERIC_SCALE FROM INFORMATION_SCHEMA.COLUMNS WHERE TABLE_NAME = 'orders' AND COLUMN_NAME = 'amount'; - UPDATE中所有中间值（包括变量、JOIN结果、子查询）都显式声明相同精度，例如：
DECLARE @new_amt DECIMAL(18,2)，而不是DECIMAL裸写 - 避免用
MONEY类型接收——SQL Server中MONEY默认四舍五入到千分位，和DECIMAL(18,2)行为不一致，尤其在加减运算后可能差0.01
别让除法或常量触发整数截断
UPDATE orders SET amount = amount / 100看着没问题，但如果amount是整型或没小数位的DECIMAL，结果就是整数除法，直接丢掉小数部分。这不是ROUND能补救的，ROUND接的是已经错的结果。
实操建议：
- 除法至少一个操作数带小数位：
amount / 100.0或CAST(amount AS DECIMAL(18,4)) / 100 - 常量参与计算时别写
1，写1.0或CAST(1 AS DECIMAL(18,4)) - 如果业务允许，更推荐用“分”为单位存整数（如
amount_cents INT），UPDATE时直接SET amount_cents = amount_cents * 120 / 100，全程无小数
WHERE条件里别混用浮点比较
用WHERE amount = 99.99更新某笔订单，但若该字段实际是FLOAT或从CSV导入未转DECIMAL，99.99可能存成99.98999999999999，条件永远不匹配；或者反过来，误匹配多行。
实操建议：
- UPDATE前先
SELECT amount, CAST(amount AS CHAR) FROM orders WHERE id = 123，看存储值是否“所见即所得” - 条件中涉及金额比较，一律转DECIMAL：
WHERE CAST(amount AS DECIMAL(18,2)) = 99.99 - 优先用主键或唯一业务码做定位，金额只作校验字段，例如：
WHERE order_no = 'ORD20260811001' AND CAST(amount AS DECIMAL(18,2)) BETWEEN 99.98 AND 100.00
触发器里更新金额字段要防NULL和溢出
UPDATE触发器中读INSERTED.amount再赋给变量，如果原字段允许NULL，而你声明的是DECIMAL(18,2)非空变量，SQL Server会报错；MySQL可能静默转成0，导致逻辑错乱。
实操建议：
- 所有金额变量声明加
NULL属性：DECLARE @old_amt DECIMAL(18,2) = NULL - 做运算前先判NULL：
ISNULL(@new_amt, 0) - ISNULL(@old_amt, 0)，别直接减 - 加溢出保护：
IF @new_amt > 9999999999.99 OR @new_amt - 日志里记原始
INSERTED.amount类型和值，别只记转换后的数字——调试时这是唯一能还原问题的线索
真正卡住人的，往往不是“怎么写UPDATE”，而是没意识到：同一笔金额，在表定义、变量声明、计算表达式、WHERE条件、触发器上下文里，可能被当成5种不同精度/类型的值在流转。漏掉其中一环，误差就悄悄进来了。
