直接用CAST(x AS DECIMAL)可能出错，是因为源值若是FLOAT/DOUBLE类型，其二进制浮点表示已存在固有精度误差（如1.23实际存为1.22999999999999998），CAST仅忠实地转换该不精确值，导致结果不稳定（如返回1.22而非1.23）；只有原始数据为字符串（如'1.23'）时，CAST才能保证十进制字面量精度。
为什么直接用 CAST(x AS DECIMAL) 可能出错
MySQL 的 CAST 和 CONVERT 对浮点数（FLOAT、DOUBLE）转 DECIMAL 时，会先按二进制浮点精度存储原始值，再截断或四舍五入——这意味着你看到的 1.23 在内存里可能是 1.22999999999999998，CAST 后变成 1.22 而非预期的 1.23。这不是 MySQL Bug，而是 IEEE 754 浮点表示的固有缺陷。
- 常见错误现象：
SELECT CAST(1.23 AS DECIMAL(10,2));有时返回1.22或1.23，结果不稳定 - 根本原因：源列本身是
FLOAT或DOUBLE，已丢失精度；转换只是“忠实地”转那个不精确的值 - 安全前提：只有当原始数据以字符串形式存在（如来自 CSV 导入、JSON 解析或用户输入），才能真正保证精度
正确做法：先转字符串，再转 DECIMAL
绕过浮点中间表示，强制走字符串解析路径，让 MySQL 按十进制字面量解析，从而保留书写精度。
- 对字段操作：
CAST(CAST(your_float_col AS CHAR) AS DECIMAL(10,2)) - 对字面量操作：
CAST('1.23' AS DECIMAL(10,2))—— 注意引号，必须是字符串字面量 - 在 INSERT/UPDATE 中常用：
INSERT INTO t (dec_col) VALUES (CAST(CAST(@f AS CHAR) AS DECIMAL(10,2))); - 性能影响：多一次字符串转换，但对绝大多数 OLTP 场景可忽略；批量处理时建议在应用层做（如 Python 用
str(f)再传参）
ALTER TABLE 时如何安全迁移 FLOAT 列到 DECIMAL
直接 MODIFY COLUMN x DECIMAL(10,2) 会触发隐式 CAST，重蹈浮点误差覆辙。必须显式经过字符串中转。
- 分三步操作（不可省略）：
ALTER TABLE t ADD COLUMN x_dec DECIMAL(10,2); UPDATE t SET x_dec = CAST(CAST(x_float AS CHAR) AS DECIMAL(10,2)); ALTER TABLE t DROP COLUMN x_float, CHANGE COLUMN x_dec x DECIMAL(10,2);
- 如果表很大，UPDATE 可能锁表或慢；建议在低峰期执行，或用 pt-online-schema-change
- 验证是否成功：
SELECT x_float, x, ABS(x_float - x) > 0.005 FROM t LIMIT 10;—— 若有1，说明仍有明显偏差，需检查原始数据是否真为字符串来源
应用层配合更可靠
数据库只是最后一步；真正可控的精度起点在应用写入时。
- PHP：
number_format($f, 2, '.', '')再作为字符串传入 SQL - Python：
str(Decimal(str(f)).quantize(Decimal('0.01')))，避免str(f)因浮点打印规则出错（如0.1 + 0.2 → '0.30000000000000004'） - Java：始终用
BigDecimal(String)构造器，绝不用BigDecimal(double) - 关键提醒：MySQL 的
DECIMAL类型本身是精确的，但“怎么把数送进去”决定了它精不精确 —— 这个环节最容易被忽略
