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('2023-10-05 14:30' AS DATETIME) 成功，但 CAST('2023/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 压力
类型转换看着简单，但字段是否为空、源格式是否稳定、目标类型精度是否足够、有没有索引可用——这四个点漏掉任何一个，上线后都可能变成慢查询或数据偏差。
