17370845950

CAST与CONVERT功能基本等价，均用于显式类型转换，但语法不同：CAST(expr AS type)符合SQL92标准，CONVERT(expr, type)为MySQL扩展；CONVERT还支持CONVERT(expr USING charset)字符集转换，CAST不支持。

CAST 和 CONVERT 在 MySQL 中的等价性与语法差异

MySQL 中 CAST 和 CONVERT 功能基本一致，都用于显式类型转

换，但语法结构不同：CAST(expr AS type) 更标准（SQL92），CONVERT(expr, type) 是 MySQL 扩展写法。二者在绝大多数场景下可互换，但 CONVERT 支持额外的字符集转换形式：CONVERT(expr USING charset)，这是 CAST 不具备的。

• CAST('123' AS UNSIGNED) 和 CONVERT('123', UNSIGNED) 效果相同
• CONVERT('hello' USING utf8mb4) 合法，CAST('hello' AS utf8mb4) 会报错
• 目标类型名大小写不敏感，INT、int、Integer 均可
• 若转换失败（如 CAST('abc' AS SIGNED)），MySQL 默认返回 0 或空字符串，取决于上下文和 SQL 模式

常见类型转换场景与安全写法

实际开发中，多数转换发生在字符串与数字之间、日期格式标准化、以及字段对齐时。直接用 CAST/CONVERT 隐含风险：无校验、静默失败。建议结合 IF 或正则预判。

• 字符串转整数：优先用 CAST(str_col AS SIGNED)，但需确认 str_col 只含数字前缀；否则用 REGEXP '^[0-9]+$' 过滤
• 时间字符串转日期：CAST('2025-10-05 14:30' AS DATETIME) 成功，但 CAST('2025/10/05' AS DATE) 失败（格式不符），应先用 STR_TO_DATE()
• 数字转字符串：用 CAST(num_col AS CHAR)，比隐式拼接（如 CONCAT('', num_col)）更明确，且避免自动截断
• 二进制数据转十六进制显示：CONVERT(bin_col USING latin1) 不适用，应改用 HEX(bin_col)

NULL、空值与错误处理的实际表现

CAST(NULL AS type) 总是返回 NULL，这点可靠；但非 NULL 输入一旦无法解析，行为取决于 sql_mode。默认宽松模式下返回 0 或空，严格模式（如启用 STRICT_TRANS_TABLES）则报错。

SELECT 
  CAST('' AS SIGNED) AS empty_to_int,
  CAST('abc' AS SIGNED) AS invalid_to_int,
  CAST('12.34' AS SIGNED) AS float_trunc;
-- 结果：0, 0, 12（小数部分被截断，不四舍五入）

• 空字符串 '' 转数值 → 0；转日期 → '0000-00-00'（若允许）
• CAST('12.99' AS DECIMAL(5,2)) 得 12.99；但 CAST('12.99' AS DECIMAL(3,1)) 会截为 13.0（精度溢出自动调整）
• 想捕获转换失败？MySQL 原生不支持 TRY_CAST，需用存储函数封装或应用层判断

性能与索引影响必须注意

在 WHERE 子句中对字段使用 CAST 或 CONVERT（如 WHERE CAST(id_str AS SIGNED) = 123）会导致该字段无法走索引——因为转换是在运行时逐行计算的。

• 正确做法：确保比较字段类型一致，例如把 id_str 字段改为 INT 类型并加索引
• 临时补救：若必须转换，可建生成列 + 索引：ALTER TABLE t ADD id_num INT AS (CAST(id_str AS SIGNED)) STORED, ADD INDEX(id_num);
• ORDER BY CAST(col AS CHAR) 会强制 filesort，即使 col 本身有索引
• 批量转换（如导入清洗）建议在应用层做，而非依赖 SQL 函数，减少数据库 CPU 压力

类型转换看着简单，但字段是否为空、源格式是否稳定、目标类型精度是否足够、有没有索引可用——这四个点漏掉任何一个，上线后都可能变成慢查询或数据偏差。