CAST转DECIMAL必须显式指定精度和标度，否则默认DECIMAL(10,0)导致小数截断；浮点数转DECIMAL存在固有精度误差，无法靠CAST修复；WHERE中对列用CAST会导致索引失效。
CAST 转 DECIMAL 时小数位丢失？先看精度和标度怎么填
MySQL 的 CAST 转定点数不是“转成 DECIMAL 就完事”，必须显式指定精度（总位数）和标度（小数位数），否则默认是 DECIMAL(10,0)，所有小数全被截断为整数。
比如 CAST(3.14159 AS DECIMAL) 实际等价于 CAST(3.14159 AS DECIMAL(10,0))，结果就是 3 —— 不是四舍五入，是直接截断小数部分。
- 要保留 4 位小数：用
CAST(3.14159 AS DECIMAL(10,4))→3.1416（注意：DECIMAL 默认四舍五入，不是截断） - 精度（第一个数字）必须 ≥ 整数位数 + 小数位数，否则超出部分会被静默截断或报错（取决于 SQL mode）
- 标度（第二个数字）不能为负，也不能大于精度值，否则语句会报错：
Truncated incorrect DECIMAL value
浮点数（FLOAT/DOUBLE）直接 CAST 到 DECIMAL 有隐式误差
像 CAST(0.1 + 0.2 AS DECIMAL(10,2)) 得到的可能是 0.30，也可能是 0.31，取决于底层二进制浮点表示的累积误差。这不是 CAST 的问题，而是源值本身就不精确。
真实场景中，如果原始数据来自 FLOAT 字段或计算表达式，别指望靠 CAST “修复”精度 —— 它只是按当前不精确的值做定点转换。
面向 CRM 系统的 MySQL 8 数据库模式设计。当用户需要为客户关系管理（CRM）系统设计、评审、优化或生成数据库模式时，应使用此项技能。
- 安全做法：源头就用
DECIMAL存储金额、比例等需精确计算的字段 - 临时补救：先用字符串中转，比如
CAST(CAST(0.1 + 0.2 AS CHAR) AS DECIMAL(10,2))，但依赖 MySQL 对字符串的解析逻辑，不推荐用于关键业务 - 验证方法：用
SELECT 0.1 + 0.2;看实际值，再对比CAST后结果，就能确认误差来源
WHERE 条件里用 CAST 做数值比较？小心索引失效
写 WHERE CAST(price AS DECIMAL(10,2)) > 99.99 这类条件，哪怕 price 是 FLOAT，MySQL 也无法使用 price 字段上的索引 —— 因为函数作用于列会导致索引不可用。
更糟的是，如果 price 本就是 DECIMAL 类型，还多套一层 CAST，纯属增加无谓开销。
- 优先改表结构：把
FLOAT列改为DECIMAL(m,n)，然后直接比较 - 若无法改表，且查询频繁，考虑加生成列（Generated Column）并建索引：
ALTER TABLE t ADD price_dec DECIMAL(10,2) STORED AS (CAST(price AS DECIMAL(10,2))); CREATE INDEX idx_price_dec ON t(price_dec); - 避免在 WHERE 中对列使用任何函数，
CAST也不例外
CAST 和 CONVERT 的行为差异很小，但语法习惯影响可读性
MySQL 中 CAST(expr AS type) 和 CONVERT(expr, type) 在数值转换上几乎完全等价，都支持 DECIMAL(m,n) 语法。区别只在语法风格和兼容性：
-
CAST是 SQL 标准写法，跨数据库迁移时更稳妥（如 PostgreSQL、SQL Server 都支持） -
CONVERT支持额外的字符集转换（如CONVERT('abc' USING utf8mb4)），但数值转换场景下没优势 - 团队已有规范用哪个，就统一用哪个；没规范时，优先选
CAST，因为语义更清晰，且AS关键字明确分隔表达式与目标类型
事情说清了就结束。真正麻烦的从来不是怎么写 CAST，而是得想清楚：这个值本来该不该是浮点？它在入库时有没有被悄悄“污染”？要不要在应用层就卡死精度？
