应使用CAST('123.45' AS DECIMAL(10,2))显式转换，但字符串含空格、逗号、单位等非法字符时会截断或转0；需配合TRIM()、REPLACE()及正则校验预处理。
CAST(varchar 到 DECIMAL) 的基本写法和常见失败原因
直接用 CAST('123.45' AS DECIMAL(10,2)) 是可行的，但只要字符串含不可解析字符（空格、逗号、中文符号、单位如“元”或“%”），就会静默转成 0 或报错（取决于 SQL mode）。MySQL 不做柔性清洗，它只认标准数字格式。
实操建议：
- 先用
TRIM()去首尾空格：CAST(TRIM(col) AS DECIMAL(10,2)) - 确认字段里没有逗号——
REPLACE(col, ',', '')必须显式调用 - 检查是否混入了不可见字符（如 U+200E 零宽空格），可用
HEX(col)辅助排查 - 若列中存在纯非数字值（如
'N/A'、'—'），CAST 会转成0，且不报错；需结合REGEXP '^[0-9]+(\.[0-9]+)?$'过滤或标记异常
为什么 CAST('1,234.56' AS DECIMAL) 得到 1 而不是报错？
MySQL 的 CAST 在遇到非法后缀时，会截断并取前导有效数字部分。例如 '1,234.56' → 取到第一个非数字字符（逗号）就停，结果是 1；'abc123.45' 则得 0（无前导数字）。这不是 bug，是 MySQL 的隐式转换规则。
避免误判的方法：
- 用
CONVERT(col USING utf8mb4)确保编码一致，防止乱码干扰识别 - 优先用
SAFE_CAST？不行——MySQL 没这个函数，得自己模拟：用CASE WHEN col REGEXP '^[[:space:]]*[+-]?[0-9]*\.?[0-9]+([eE][+-]?[0-9]+)?[[:space:]]*$' THEN CAST(TRIM(col) AS DECIMAL(15,4)) ELSE NULL END - 小数点只能有一个，且不能开头或结尾（除非是
'.5'或'5.'，但后者 CAST 后为5，精度丢失）
DECIMAL(p,s) 中的 p 和 s 设太小会怎样？
如果源字符串是 '12345.6789'，而你写 CAST(... AS DECIMAL(5,2))，MySQL 会四舍五入截断为 999.99（超出精度上限时静默饱和），而不是报错或扩容。
关键判断点：
-
p是总位数（含小数点前后的所有数字），s是小数位数；DECIMAL(5,2)最大能存999.99 - 整数部分最多占
p - s位，所以处理金额类数据建议至少用DECIMAL(12,2) - 如果原始字符串小数位超过
s，MySQL 默认四舍五入（非截断），例如CAST('1.235' AS DECIMAL(3,2))→1.24
替代方案：不用 CAST，用 + 0 或 0 + col 行不行？
可以，但更危险。col + 0 会触发隐式转换，行为与 CAST 类似，但错误容忍度更低：遇到空字符串转成 0，'-' 转成 0，甚至 '1e2' 这种科学计数也能转，但业务上往往不该接受。
真正可控的做法：
- 用
CAST+ 显式清洗，比依赖隐式转换更可维护 - 批量转换前，先跑
SELECT col, CAST(TRIM(REPLACE(col,',','')) AS DECIMAL(12,2)) AS val FROM t WHERE col NOT REGEXP '^[+-]?[0-9]*\.?[0-9]+$';找出脏数据 - 注意：MySQL 8.0.17+ 支持
VALIDATE_JSON()类思路，但对数字无直接验证函数，仍需正则兜底
最易被忽略的是：CAST 不校验语义合理性。比如把 '1000000000000'（13 位整数）转成 DECIMAL(12,2)，它不会提示溢出，而是返回 9999999999.99 —— 看似成功，实则数据已损毁。
