CAST 是一类面向跨数据库兼容的标准类型转换函数，写法统一为 CAST(expr AS type)。不过，语法看着一致，真正落到不同数据库里，细节差异一点也不少：比如 MySQL 目标类型通常写 SIGNED/UNSIGNED，而不是 INT；PostgreSQL 在使用 VARCHAR 时往往要求明确长度；SQL Server 遇到非法字符串转数字会直接报错；MySQL 的处理则更“宽松”一些，通常会静默返回 0。

CAST 能强制转换字段类型，但不是所有数据库都支持相同语法，用错会直接报错。

CAST 在不同数据库里的写法差异

MySQL、PostgreSQL、SQL Server 都支持 CAST()，但 SQLite 只支持 CAST()（不支持 CONVERT()），而 Oracle 偏好 TO_NUMBER() 等函数。别照搬别人代码里的写法。

• 标准写法：CAST(column_name AS target_type)，比如 CAST(age AS VARCHAR)
• PostgreSQL 要求指定长度：CAST(price AS DECIMAL(10,2))，否则可能截断或报错
• MySQL 对 VARCHAR 类型可省略长度，但生产环境建议写全：CAST(name AS CHAR(50))
• SQL Server 中 CAST('2024-01-01' AS DATE) 成功，但若字符串格式非法（如 '2024/13/01'）会直接中断查询

SELECT 中 CAST 字段的常见错误

最常踩的坑是类型不兼容或隐式转换干扰结果——CAST 不是万能兜底，它只按你写的规则硬转。

• 把含字母的字符串转数字：CAST('abc' AS INT) → 在 SQL Server 报 Conversion failed，在 MySQL 返回 0（静默失败，极难排查）
• 日期字符串格式不匹配：CAST('01-01-2024' AS DATE) 在 PostgreSQL 可能被当成 MDY 或 DMY，取决于 datestyle 设置
• 对 NULL 值 CAST 没问题，但后续参与计算时要注意：例如 CAST(NULL AS INT) + 5 结果仍是 NULL，不是 5
• 别在 WHERE 条件里对字段 CAST 后再比较，比如 WHERE CAST(created_at AS DATE) = '2024-01-01'，会跳过索引，改用 created_at >= '2024-01-01' AND created_at < '2024-01-02'

什么时候该用 CAST，什么时候该避免

核心判断依据是：是否真的需要改变数据物理表示，还是仅需格式化展示？后者优先用数据库特有函数（如 TO_CHAR()、DATE_FORMAT()）。

• 必须用 CAST 的场景：拼接不同类型的字段，如 SELECT CAST(id AS VARCHAR) + '_item' FROM products（SQL Server）
• 导出前统一类型：导 Excel 时把 DECIMAL 转 VARCHAR 防止科学计数法显示
• 联表时类型不一致：A 表 user_id 是 VARCHAR，B 表是 INT，JOIN 前用 CAST 对齐（但更优解是修复建表类型）
• 避免滥用：SELECT 列里大量 CAST 会影响执行计划，尤其在视图或子查询中嵌套多层 CAST，会让优化器“看不懂”实际数据分布

真正麻烦的不是语法写不对，而是 CAST 后的数据行为和原类型不一致——比如时区丢失、精度截断、排序顺序突变。上线前务必用真实数据测边界值，别只看 '123' 这种理想输入。

《夸克》非常好用的免费AI浏览器

下载APP查看