CAST数据变NULL主因是源值不可转换且数据库静默处理，应先过滤非法字符再转换，各数据库行为差异大，需针对性选用函数或表达式。
CAST 用法不对，数据直接变 NULL
多数人写 CAST 时只盯着目标类型，却忘了源值本身是否可转换。比如把含字母的字符串 '123abc' 强转成 INT，MySQL 和 PostgreSQL 都会静默返回 NULL（SQL Server 则报错）。这不是语法错，是数据“过不了关”。
实操建议：
- 先用
REGEXP或LIKE过滤掉非法字符再CAST，例如WHERE col REGEXP '^[0-9]+$' - PostgreSQL 可用
TRY_CAST（需 v16+）或自定义函数兜底；MySQL 没原生TRY_CAST，得靠IF+CONVERT组合判断 - 对日期类转换尤其敏感：
CAST('2023-02-30' AS DATE)在 MySQL 中变成NULL，而 PostgreSQL 直接报错
不同数据库里 CAST 的行为差异太大
CAST 看似标准 SQL，但各数据库实现松散。同一句 CAST('1.23' AS DECIMAL(5,2))，在 PostgreSQL 中得手，在 SQL Server 中可能因默认精度截断成 1.20，而在 SQLite 里压根不认 DECIMAL —— 它只认 NUMERIC 且不校验精度。
实操建议：
- MySQL 用
CONVERT(col, DECIMAL(5,2))更稳，它对浮点字符串容忍度略高 - PostgreSQL 记得加显式精度：不写
DECIMAL(5,2)而只写DECIMAL，结果可能是1.2300000000，小数位数远超预期 - SQLite 别依赖
CAST做严格类型控制——它本质是弱类型，CAST('abc' AS INT)返回0，不是NULL
从字符串提取数字/日期时，别硬刚 CAST
想从 'Order_20230415_v2' 里取日期？或者从 'USD123.45' 提纯金额？这时候死守 CAST 是给自己挖坑。正则提取 + 类型转换才是合理路径。
实操建议：
- MySQL 8.0+ 用
REGEXP_SUBSTR(col, '[0-9]{8}')先捞出'20230415'，再CAST(... AS DATE) - PostgreSQL 用
substring(col FROM '(\d{4}\d{2}\d{2})')配合::DATE（注意双冒号是简写，等价于CAST） - SQL Server 推荐
TRY_PARSE替代CAST：比如TRY_PARSE(REPLACE(price_col, 'USD', '') AS DECIMAL(10,2))，失败直接返NULL不中断查询
隐式转换偷偷绕过 CAST，导致结果不可控
你以为写了 CAST(col AS INT) 就万无一失？如果 col 是 VARCHAR，而你在 WHERE 条件里又跟一个整数字面量比大小，比如 WHERE CAST(col AS INT) > 100，某些数据库（如旧版 MySQL）会先触发隐式转换，让 col 自己转成数字——这时如果字段里有 '100abc'，它可能被截成 100，然后 > 100 判断失效。
实操建议：
- 在
WHERE或JOIN中强制统一类型：用CAST(col AS SIGNED)（MySQL）或col::INTEGER（PostgreSQL），避免优化器绕过你的显式转换 - 对关键字段建表达式索引：比如 PostgreSQL 的
CREATE INDEX idx_col_as_int ON t ((col::INTEGER))，否则每次CAST都全表扫 - 测试时务必查执行计划：确认
CAST确实发生在过滤前，而不是被优化器提前合并或忽略
真正麻烦的从来不是语法写不写得对，而是你不知道数据里混着多少“看起来像数字”的脏值，以及数据库在背后悄悄帮你做了什么决定。
