CAST('str' AS SIGNED)静默返回0，因MySQL采用前缀解析策略：只取字符串开头连续数字部分，非法开头或空字符串均默认转为0，不报错却掩盖数据问题。
CAST('str' AS SIGNED) 为什么会静默返回 0
MySQL 对字符串转数字的容错机制极强，CAST('abc' AS SIGNED) 不报错，直接返回 0；CAST('123xyz' AS SIGNED) 返回 123；而 CAST('' AS SIGNED) 也返回 0。这种“伪成功”最危险——它掩盖了数据污染问题，后续计算或条件判断可能全错。
根本原因是 MySQL 采用「前缀解析」策略：只取开头连续数字部分，其余丢弃；空字符串、纯空格、非法字符开头一律视为 0。
- 用
TRIM()去首尾空格，再判断是否为空：TRIM(col) = '' - 用正则校验合法性：
col REGEXP '^[+-]?[0-9]*\.?[0-9]+$'（注意：不支持科学记数法） - 转换后加范围检查：
CAST(col AS SIGNED) BETWEEN -2147483648 AND 2147483647
WHERE 条件里写 col = '123' 而不是 col = 123 的后果
表面看结果一样，但类型混用会触发隐式转换，代价是索引失效。当 col 是 INT 类型时，WHERE col = '123' 会让 MySQL 把整列都转成字符串比对，无法使用 col 上的索引，百万级表查询可能从毫秒变秒级。
更隐蔽的问题在应用层：MyBatis 用 ${xxx} 拼接参数，若传入的是数字 123，生成 SQL 是 com_code = 123，但字段是 VARCHAR，就会报 operator does not exist: character varying = integer。
- 始终让比较双方类型一致：数值字段就用数字字面量，字符串字段就用带引号的字符串
- 查字段真实类型：
DESCRIBE table_name或SHOW COLUMNS FROM table_name - 避免在
WHERE、JOIN、ORDER BY中对字段做CAST(col AS ...)，这几乎必然导致索引失效
空字符串和 NULL 在 DECIMAL 转换中表现完全不同
CAST('' AS DECIMAL(10,2)) 不是返回 NULL 或 0，而是直接报错：Incorrect DECIMAL value: '0'（注意错误信息里写的其实是 '0'，不是空串）。这是 MySQL 最反直觉的行为之一。
而 CAST(NULL AS DECIMAL(10,2)) 是合法的，返回 NULL；CAST(' ' AS DECIMAL(10,2)) 也会报同样错误，因为 TRIM(' ') 后变成空串。
- 必须前置
TRIM()：CAST(NULLIF(TRIM(col), '') AS DECIMAL(10,2)) - 用
IF或CASE包裹容错：IF(TRIM(col) = '', NULL, CAST(TRIM(col) AS DECIMAL(10,2))) - 别依赖
IFNULL(CAST(...), 0)——CAST 还没执行就已报错，IFNULL根本没机会生效
安全转换的推荐写法（含容错）
没有万能方案，但可组合出鲁棒性高的表达式。核心原则：先清洗，再校验，最后转换。
例如将 price_str 安全转为 DECIMAL(10,2)：
CAST(
IF(
TRIM(price_str) REGEXP '^[+-]?[0-9]*\.?[0-9]+$',
TRIM(price_str),
NULL
) AS DECIMAL(10,2)
)
这个写法覆盖了空格、空字符串、非法字符三种常见污染源。但要注意：正则不匹配科学记数法（如 '1e5'），也不处理千分位逗号（如 '1,234.56'），这类场景需额外 REPLACE 预处理。
真正容易被忽略的点是：**所有这些校验逻辑都发生在单行内，无法复用；一旦字段多、规则杂，SQL 很快变得难以维护。生产环境建议把清洗逻辑下沉到应用层或封装为 MySQL 函数。**
