必须用decimal(m,d)而禁用float，因float二进制浮点存储导致精度误差（如0.1+0.2≠0.3），decimal按十进制精确保存；建表须显式声明如amount decimal(12,2) not null。
DECIMAL 是唯一能保证金额计算精确的数据类型，FLOAT 和 DOUBLE 会因二进制浮点表示导致 0.1 + 0.2 ≠ 0.3 这类误差，金融场景必须禁用。
为什么必须用 DECIMAL(M,D) 而不是 FLOAT
浮点类型在底层用二进制近似存储十进制小数，DECIMAL 则按十进制逐位保存。哪怕只是插入 19.99，FLOAT 可能存成 19.98999977，后续求和、比较、导出报表都会漂移。
-
DECIMAL(10,2)表示最多 10 位数字、小数点后固定 2 位，适合常规商品价格（最大 99999999.99） - 跨境或高精度场景（如汇率、手续费）建议用
DECIMAL(15,4)或DECIMAL(18,6) - 建表时必须显式声明，例如：
amount DECIMAL(12,2) NOT NULL，不能依赖隐式转换
SUM() 和 AVG() 在金额字段上的行为差异
聚合函数本身对 DECIMAL 是安全的，但写法直接影响业务逻辑是否正确：
-
SUM(price * quantity)：先逐行算出每笔订单金额，再加总 —— 正确 -
SUM(price) * SUM(quantity)：分别把单价和数量各自加总后再相乘 —— 数学上不等价，常见于错误的“平均单价 × 总数量”估算 -
AVG(price / 100)和AVG(price) / 100结果数值相同，但前者每行都做除法（可能触发中间精度截断），后者只除一次；若price是DECIMAL(10,2)，前者实际计算的是DECIMAL(12,4)再平均，后者是先平均再缩放，极端情况下四舍五入位置不同
WHERE 条件里做金额运算的三个坑
看似简单的 WHERE amount * 0.9 > 100 很容易出错：
- 隐式类型提升：如果
amount是DECIMAL(10,2)，乘法后变成DECIMAL(12,3)，但 MySQL 在某些版本中会临时转成DOUBLE比较，引入浮点误差 - 索引失效：表达式
amount * 0.9无法使用amount字段上的普通索引，除非你建了函数索引（MySQL 8.0.13+ 支持：CREATE INDEX idx_discounted ON orders ((amount * 0.9))） - 推荐写法是把运算移到右侧：
WHERE amount > 100 / 0.9，保持左侧为纯字段引用，既可走索引，又避免中间类型转换
四舍五入和格式化输出要分清场景
ROUND(amount, 2) 是计算环节必须用的，而 FORMAT(amount, 2) 只适合最终展示 —— 因为它返回字符串，不能再参与后续数学运算。
- 折扣计算必须用
ROUND(price * 0.8, 2)，否则19.99 * 0.8 = 15.992直接存入DECIMAL(10,2)会被截断为15.99，而不是四舍五入的15.99（此处刚好一致，但29.99 * 0.8 = 23.992 → 23.99，ROUND才能确保是23.99） - 聚合后需要补零显示（如
100.00）才用FORMAT，例如：SELECT FORMAT(SUM(amount), 2) FROM orders - 注意：所有涉及金额的中间计算，只要结果还要参与下一步运算（比如算税费、分润），一律保持
DECIMAL类型，不要提前转字符串
真正容易被忽略的是：金额字段的精度定义一旦上线就很难变更，DECIMAL(10,2) 存不下超千万订单的总金额（上限约一亿），而 DECIMAL(15,2) 占用更多存储且影响索引大小。设计阶段就要预估峰值，别等报表跑出 NULL 或溢出错误才回头改表。
