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