应使用 decimal 而非 float/double 存储精度敏感数据，因后者基于 ieee 754 二进制浮点，无法精确表示十进制小数（如 0.1+0.2≠0.3），导致金融场景对账错误；decimal 以定点数字符串方式存储，需合理设置 m（总位数）和 d（小数位数），并注意函数、表达式及应用层的精度保持。
为什么直接用 FLOAT 或 DOUBLE 会出错
MySQL 中 FLOAT 和 DOUBLE 是二进制浮点类型，底层按 IEEE 754 存储，无法精确表示很多十进制小数（比如 0.1 + 0.2 不等于 0.3）。金融、计费、精度敏感场景下，这类误差会导致对账不平、金额偏差等线上问题。
根本原因不是函数的问题，而是数据类型本身就不适合——再怎么用 ROUND() 或 FORMAT() 也只是“掩盖”误差，不是消除。
-
FLOAT约 7 位有效数字，DOUBLE约 15–16 位，但这是二进制精度，不是十进制精度 - 插入
99.99可能被存成99.98999999999999，后续SUM()或比较操作就不可靠 -
DECIMAL(M,D)才是真正以字符串方式存储的定点数，M 是总位数，D 是小数位数（如DECIMAL(10,2)最多存 99999999.99）
DECIMAL 字段定义的常见误区
很多人以为只要用了 DECIMAL 就万事大吉，但字段定义不当照样翻车。关键在 M 和 D 的取值是否覆盖业务最大值和精度需求。
- 别写
DECIMAL(10,2)存交易金额后突然发现要支持亿级订单——溢出时 MySQL 会静默截断或报错（取决于 SQL mode），不是四舍五入 -
D不是“保留两位小数”的意思，而是“固定保留 D 位小数”，哪怕存100也会变成100.00；计算时也按这个精度对齐 - 如果要做除法（如单价=总价/数量），建议
D多留 2–4 位（如DECIMAL(15,4)），避免中间结果被截断 - 注意：MySQL 8.0+ 支持
DECIMAL最大M=65，但过大的M会影响排序和索引效率
DECIMAL 上的数学函数怎么用才不丢精度
MySQL 对 DECIMAL 的内置函数基本保持精度，但部分函数会隐式转为 DOUBLE，必须警惕。
-
ROUND(x, d)、TRUNCATE(x, d)、CEIL()、FLOOR()都原生支持DECIMAL，结果仍是DECIMAL，安全 -
POWER(x, y)如果y是小数（如POWER(100, 0.5)），结果强制转为DOUBLE，精度丢失 —— 此时应避免，或改用整数幂运算+手动缩放 -
SQRT()同样返回DOUBLE，若需高精度开方，得在应用层用 BigDecimal 或 Python decimal 处理 - 聚合函数如
SUM()、AVG()对DECIMAL字段默认保持精度，但AVG()结果的小数位数由 MySQL 自动推导（通常为D+4），可显式CAST(AVG(x) AS DECIMAL(15,4))控制
实际建表与查询中的典型写法
别只改字段类型，从建表到查询都要配合。下面是一个电商价格字段的合理示例：
CREATE TABLE orders ( id BIGINT PRIMARY KEY, amount DECIMAL(15,4) NOT NULL COMMENT '订单金额，单位元，保留4位小数防除法误差', discount DECIMAL(15,4) DEFAULT 0.0000, final_amount DECIMAL(15,4) AS (amount - discount) STORED );
查询时也注意表达式精度：
- ✅ 安全：
SELECT ROUND(amount * 1.08, 2) AS tax_included FROM orders;——1.08是DECIMAL字面量，全程定点运算 - ❌ 危险：
SELECT amount * 1.08E0 FROM orders;——1.08E0是科学计数法，MySQL 当作DOUBLE处理 - ⚠️ 注意：
WHERE amount >= 99.99没问题，但WHERE amount = 99.9900要确保比较值字面量带足小数位，否则可能因隐式转换失败
最常被忽略的是：应用代码读取 DECIMAL 字段时，ORM 或驱动是否把值当字符串/decimal 类型返回。PHP mysqli 默认返回字符串，Python PyMySQL 默认转 float —— 这一步就可能把精度搞没了。
