SQL CAST 与 CONVERT 类型转换技巧

优先用cast，因其符合sql标准、跨数据库兼容性好；convert仅sql server和mysql支持且行为不一，虽有style参数但移植性差。

CAST 和 CONVERT 用哪个？看数据库和可读性

CAST 是 SQL 标准函数，所有主流数据库（postgresql、SQL Server、MySQL 8.0+、sqlite）都支持；CONVERT 是 SQL Server 和 MySQL 的扩展，语法更灵活但不跨平台。如果你写的是只跑在 SQL Server 上的报表脚本，CONVERT 支持样式参数（比如日期格式化），确实方便；但只要涉及迁移或兼容 PostgreSQL/MySQL，优先用 CAST，避免后期报 Invalid column name 'CONVERT' 这类错误。

• CAST(expr AS type) 更简洁，语义明确，适合类型强转场景（如 CAST(id AS VARCHAR(10))）
• CONVERT(type, expr[, style]) 多一个 style 参数，在 SQL Server 里能控制日期/数字格式（如 CONVERT(VARCHAR, GETdate(), 120) 得到 '2024-05-21 14:30:00'），但 MySQL 的 CONVERT 不支持 style，行为不一致
• 在 PostgreSQL 中用 CONVERT 会直接报错：Error: function convert(unknown, unknown) does not exist

字符串转数字失败？先清理再转

CAST('123abc' AS int) 或 CONVERT(INT, '123abc') 在 SQL Server 和 PostgreSQL 中都会报错：Conversion failed when converting the varchar value '123abc' to data type int. —— 它们不自动截断或忽略非法字符。

• 真实业务中常见字段是 varchar 类型但混着空格、单位、符号（如 '45.6 kg'、' 78 '），不能直接转
• SQL Server 可用 TRY_CAST('123abc' AS INT) 或 TRY_CONVERT(INT, '123abc')，失败返回 NULL 而非报错
• PostgreSQL 没有内置 TRY_CAST，得靠正则预处理：CAST(NULLIF(regexp_REPLACE(col, '[^0-9.-]', '', 'g'), '') AS NUMERIC)，但要注意小数点重复、负号位置等边界
• MySQL 8.0+ 可用 CAST(REPLACE(REPLACE(col, 'kg', ''), ' ', '') AS DECIMAL)，但没容错机制，建议先 WHERE col REGEXP '^[0-9. ]+$' 过滤

日期字符串转 DATE：格式不对就静默出错或错成 1900 年

CAST('21/05/2024' AS DATE) 在 SQL Server 默认语言为 English 时会报错；设成 British 才能认，但部署环境一换就崩。CONVERT(DATE, '21/05/2024', 103) 显式指定样式 103（dd/mm/yyyy）才可靠。

• 样式码必须匹配输入格式：101=mm/dd/yyyy，103=dd/mm/yyyy，120=yyyy-mm-dd hh:mi:ss（ODBC 规范，推荐）
• PostgreSQL 对 CAST('21-05-2024' AS DATE) 会按当前 datestyle 解析，可能误判为 y-m-d 或 d-m-y；稳妥做法是统一用 ISO 格式：CAST('2024-05-21' AS DATE)
• MySQL 的 STR_TO_DATE('21/05/2024', '%d/%m/%Y') 更明确，但不是 CAST/CONVERT 体系，跨库时得重写

隐式转换陷阱：JOIN 或 WHERE 里别指望数据库帮你兜底

写 WHERE varchar_id = 123，数据库会悄悄把 123 转成字符串去比，表面没问题，但会导致索引失效（尤其 varchar 字段建了索引）。同理，JOIN t1 ON t1.code = t2.id，如果一边是 VARCHAR 一边是 INT，执行计划里常出现 CONVERT_IMPLICIT，CPU 升高、扫描变全表。

• 显式转换更可控：WHERE varchar_id = CAST(123 AS VARCHAR(10))，且确保长度足够（别用 CAST(123 AS VARCHAR(2)) 截断）
• SQL Server 执行计划里看到 CONVERT_IMPLICIT 就是警告信号，说明类型不匹配触发了运行时转换
• PostgreSQL 不允许 text = Integer 这种比较，直接报错，反而早暴露问题；但有人会绕成 text::integer = integer，一旦 text 含非数字就崩

类型转换看着简单，真正卡住人的从来不是语法，而是数据质量不可控 + 数据库行为不一致 + 隐式转换藏在执行计划深处。动手前先 select TOP 5 看原始值长什么样，比查文档还管用。