CAST(expression AS target_type)是唯一合法写法，必须带括号和AS；各数据库对非法输入处理差异大，MySQL静默归零易致逻辑错误，SQL Server支持TRY_CAST容错，PostgreSQL需组合函数；日期转换依赖格式与库默认规则；WHERE中使用CAST会导致索引失效。
CAST(expression AS target_type) 写法必须带括号和AS
不加括号或漏掉 AS 会直接报错，比如 CAST col AS INT 或 CAST(col INT) 都非法。标准写法只有一种：CAST(expression AS target_type)，中间必须有空格和 AS 关键字。
常见错误包括：
-
CAST('123' AS INT)在 PostgreSQL 中失败，得写INTEGER -
CAST('2026-08-03' AS DATETIME)在 MySQL 中可能被截断为日期部分，应明确用DATETIME或TIMESTAMP -
CAST(NULL AS VARCHAR)合法，结果仍是NULL，但CAST('' AS INTEGER)在多数库中报错
字符串转数字时，不同数据库对非法输入行为不一致
MySQL 的 CAST('abc' AS SIGNED) 返回 0，CAST(' 123xyz' AS SIGNED) 返回 123，全程不报错——这种“静默归零”最容易引发聚合逻辑错误。
SQL Server 提供 TRY_CAST('abc' AS INT) 直接返回 NULL；PostgreSQL 没内置容错函数，得组合 NULLIF 和正则：CAST(NULLIF(REGEXP_REPLACE(col, '[^0-9.-]', '', 'g'), '') AS NUMERIC)。
关键点：
- 空字符串
''→CAST('' AS SIGNED)得0，不是NULL - 纯空格
' '→ 同样得0，需先TRIM() - 小数点混入：
CAST('12.34' AS SIGNED)截断为12，要保留精度得用DECIMAL(10,2)
日期字符串转换依赖格式与数据库默认解析规则
CAST('2026-08-03' AS DATE) 在所有主流库中都安全；但 CAST('03/08/2026' AS DATE) 行为差异极大：
- PostgreSQL 默认按 MDY 解析，
'03/08/2026'被当成 3月8日，非8月3日 - SQL Server 受
SET DATEFORMAT DMY控制，未设置时可能误判 - MySQL 更建议用
STR_TO_DATE(col, '%d/%m/%Y')替代CAST，可控性强
含毫秒、时区或非 ISO 分隔符（如 '20260803'）的字符串，几乎必然失败，不要硬刚 CAST。
在 WHERE 或 JOIN 条件里用 CAST 会导致索引失效
写成 WHERE CAST(created_at AS DATE) = '2026-08-03'，哪怕 created_at 上有索引，也会全表扫描。因为数据库无法将索引值直接映射到转换后的结果。
可行替代方案：
- 改用范围查询：
WHERE created_at >= '2026-08-03' AND created_at - 建生成列并索引（MySQL 5.7+/PostgreSQL 12+）：
ALTER TABLE t ADD created_date DATE GENERATED ALWAYS AS (CAST(created_at AS DATE)) STORED - 提前清洗数据，避免查询时转换
真正麻烦的不是语法写不对，而是转换后字段不可索引、不可比较、不可排序——这些隐性成本往往在上线后才暴露。
