CAST并非万能类型转换，仅在表达式可求值、目标类型合法且格式严格匹配时安全；语法必须为CAST(expr AS type)，漏括号或AS即报错；各数据库类型名、容错机制、日期解析规则差异大，滥用会导致报错、静默错误或索引失效。
CAST 不是类型转换的万能开关，用错地方会直接报错、静默出错，或者让索引彻底失效——它只在表达式可求值、目标类型合法、格式严格匹配时才安全工作。
CAST(expression AS target_type) 写法必须带括号和 AS
漏掉括号或 AS 关键字是硬性语法错误，数据库不会容忍。比如 CAST col AS INT 或 CAST(col INT) 都非法；唯一合法写法是 CAST(col AS INTEGER)（注意 PostgreSQL 要用 INTEGER，不是 INT）。
-
CAST('123' AS SIGNED)在 MySQL 中合法，CAST('123' AS INT)在 SQL Server 中合法，但在 PostgreSQL 中必须写INTEGER -
CAST(NULL AS VARCHAR(10))合法，结果仍是NULL；但CAST('' AS INTEGER)在几乎所有库中都报错 - 目标类型带精度时写法不统一：
DECIMAL(5,2)通用，VARCHAR(20)可行，但CHAR(10)在 SQLite 中会被忽略长度
字符串转数字最容易踩静默归零坑
MySQL 对非法输入太宽容：把 'abc' 转成整数得 0，' 123xyz' 得 123，全程不报错——这种“静默归零”会导致 SUM、AVG 等聚合结果严重失真。
- SQL Server 推荐改用
TRY_CAST('abc' AS INT)，失败时返回NULL而非中断 - PostgreSQL 没内置容错函数，得组合写：
CAST(NULLIF(REGEXP_REPLACE(col, '[^0-9.-]', '', 'g'), '') AS NUMERIC) - 空字符串
''和纯空格' '都会被 MySQL 当作0，务必先TRIM() -
CAST('12.34' AS SIGNED)截断为12，要保留小数得用DECIMAL(10,2)
日期字符串转换依赖格式与库默认规则
不是所有看起来像日期的字符串都能被 CAST 成功。ISO 格式 '2026-08-12' 安全，但 '12/08/2026' 或 '20260812' 几乎必然失败，且各库行为差异极大。
- PostgreSQL 默认按 MDY 解析
'03/08/2026'→ 3月8日；SQL Server 受SET DATEFORMAT DMY控制；MySQL 建议直接用STR_TO_DATE(col, '%d/%m/%Y') - 含毫秒（
'2026-08-12 14:30:00.123'）、时区（'2026-08-12T14:30:00+08:00'）或非标准分隔符（'08-12-2026'）的字符串，不要硬刚CAST - 想兜底避免查询中断：SQL Server 用
TRY_CAST(col AS DATE)，PostgreSQL 用TO_DATE(col, 'YYYY-MM-DD')（需格式匹配）
WHERE 或 JOIN 中对字段用 CAST 会让索引失效
写成 WHERE CAST(created_at AS DATE) = '2026-08-12'，哪怕 created_at 上有索引，也会触发全表扫描——因为数据库无法将索引 B-Tree 的原始值映射到转换后的结果。
- 替代方案是改用范围查询：
WHERE created_at >= '2026-08-12' AND created_at < '2026-08-13' - MySQL 5.7+/PostgreSQL 12+ 可建生成列：
ALTER TABLE t ADD created_date DATE GENERATED ALWAYS AS (CAST(created_at AS DATE)) STORED，再对生成列加索引 - 真正麻烦的不是语法写不对，而是转换逻辑藏在 WHERE 条件里，上线后才发现慢查询暴增，却查不出原因
