CAST会因输入格式不严格匹配而报错中断，如含空格、字母或非法日期；TRY_CAST则失败返回NULL，实现容错转换，适用于SQL Server 2012+和PostgreSQL（需扩展或16+），MySQL需用REGEXP等前置校验替代。
直接用 CAST 有风险，必须配合容错机制，否则查询可能在遇到非法值时直接报错中断。
为什么 CAST 会突然失败？
它对输入格式零容忍：字符串含空格、字母、多余符号，或日期格式不匹配（比如 '05/20/2025' 对 DATE），都会触发 Conversion failed 类错误。这不是数据“看起来像”就能过，而是严格按目标类型解析。
- MySQL 报错示例：
Truncated incorrect INTEGER value - SQL Server 报错示例：
Conversion failed when converting date and/or time from character string - PostgreSQL 报错示例：
invalid input syntax for type integer
用 TRY_CAST 替代 CAST（SQL Server / PostgreSQL）
TRY_CAST 在转换失败时返回 NULL，而非报错，适合清洗脏数据或兼容多格式字段。
- 只在 SQL Server 2012+ 和 PostgreSQL（需
pg_try_cast扩展或 16+ 的try_cast）中可用；MySQL 不支持 - 示例：
SELECT TRY_CAST(order_date_str AS DATE) FROM orders—— 错误值变NULL，后续可WHERE ... IS NOT NULL过滤 - 注意：
TRY_CAST('' AS INT)返回NULL，但TRY_CAST(' 123 ' AS INT)成功（自动 trim）
MySQL 怎么安全转换？用 CAST + 条件过滤
MySQL 没有 TRY_CAST，只能靠前置校验兜底：
- 数字转换前用
REGEXP判断是否纯数字：SELECT CAST(num_str AS SIGNED) FROM t WHERE num_str REGEXP '^[0-9]+$' - 日期转换前用
STR_TO_DATE配合IS NOT NULL：SELECT CAST(STR_TO_DATE(date_str, '%Y-%m-%d') AS DATE) FROM t WHERE STR_TO_DATE(date_str, '%Y-%m-%d') IS NOT NULL - 避免用
CONVERT(... USING ...)做类型转换——那是字符集转换，不是数据类型转换
隐式转换比显式更危险
别依赖数据库自动转，比如写 WHERE date_col = '2025-08-05'。不同引擎行为不一致：MySQL 可能隐式转成 DATETIME 并加时间部分，SQL Server 可能截断，PostgreSQL 直接报错。这种“省事”写法会让同样 SQL 在不同环境结果不一致，且无法利用索引。
- 明确写
WHERE date_col = CAST('2025-08-05' AS DATE)或WHERE date_col = DATE('2025-08-05') - JOIN 字段类型不一致时，强制统一一边类型，而不是靠隐式转换凑合
真正难的不是写出 CAST，而是在字段存在历史脏数据、多系统混入格式、或跨库迁移时，让转换不崩、不错、不慢。这时候，TRY_CAST 的 NULL 容忍、正则预筛、和显式指定格式三者缺一不可。
