Decimal能有效避免0.1 + 0.2 = 0.30000000000000004这类计算误差
Float和Double采用二进制近似方式存储十进制小数——0.1在二进制中是一个无限循环小数，存储时即产生失真。在MySQL中，对FLOAT执行SELECT 0.1 + 0.2，结果常常显示为0.30000000000000004；而使用DECIMAL(10,2)严格按十进制方式计算，结果准确为0.30。
这并非显示层面的问题，底层存储与运算逻辑完全不同：Float依赖CPU浮点单元处理，Decimal则由MySQL采用定点算法逐位计算。一个是硬件近似，一个是软件精确——取舍方向非常清晰。
Decimal(M,D)中的M和D必须显式指定，切勿依赖默认值
DECIMAL若不设置参数，默认值为DECIMAL(10,0)——小数位为0。这意味着INSERT INTO t(amount) VALUES(99.99)会被直接截断成99，金额凭空减少两位。踩过这个坑的开发人员都深知其痛。
- 电商价格、订单金额：推荐使用
DECIMAL(10,2)（最大值为99999999.99） - 对精度要求更高的场景（如汇率、分润）：可选用
DECIMAL(12,4)或DECIMAL(15,6) - M最大为65，D最大为30，但切勿盲目设大——
DECIMAL(65,30)实际占用约33字节，远超DECIMAL(10,2)的5字节，性能开销会成倍增加。
Float插入时会悄然四舍五入，且不受控制
请看以下实际操作对比：
CREATE TABLE t1 (f FLOAT(10,2), d DECIMAL(10,2)); INSERT INTO t1 VALUES (1234567.23, 1234567.23);
查询结果f列为1234567.25，d列才是1234567.23。原因：Float的FLOAT(10,2)只是显示格式，并不约束存储精度；而Decimal的DECIMAL(10,2)是硬性约束，超出范围会直接报错Out of range value for column 'd'。
更危险的是，Float在WHERE条件中使用=匹配时可能失败——WHERE amount = 99.99查不到刚刚插入的99.99，因为实际存储的是99.98999786376953。这类问题排查起来令人非常头疼。
Decimal性能略低，但对金额场景的影响微乎其微。Decimal比Float慢，主要源于存储和计算方式的差异：
- 存储：Decimal按每9位数字占用4字节，内部以字符串或压缩BCD编码存储；Float固定占用4或8字节
- 计算：Decimal由MySQL自研定点运算处理，Float则依赖CPU原生指令
但在真实交易系统中，单条金额字段的读写开销微乎其微。真正拖慢数据库性能的是索引设计、JOIN逻辑以及未走索引的WHERE条件——而不是多花几纳秒运算一次加法。用精度换取性能，在金融场景中属于本末倒置。
真正容易被忽视的一点是：Decimal的精度定义一旦上线便难以轻易更改。例如从DECIMAL(10,2)扩展到DECIMAL(12,2)需要锁表并重写数据，而Float修改精度几乎无感。因此建表时必须提前规划好业务未来3到5年的金额上限和精度需求，避免上线后再懊悔。
