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
• MySQL 5.7+/PostgreSQL 12+ 可建生成列：ALTER TABLE t ADD created_date DATE GENERATED ALWAYS AS (CAST(created_at AS DATE)) STORED，再对生成列加索引
• 真正麻烦的不是语法写不对，而是转换逻辑藏在 WHERE 条件里，上线后才发现慢查询暴增，却查不出原因