CAST函数语法为CAST(expression AS type)，支持CHAR、SIGNED、DATE等类型，不支持VARCHAR/JSON/ENUM；转换失败常静默截断，建议启用严格模式；CAST比CONVERT更灵活，推荐优先使用标准SQL语法。
CAST 函数的基本用法和语法结构
CAST 是 MySQL 中显式类型转换的标准函数，适用于需要把一个表达式强制转为指定数据类型的场景。它的语法是 CAST(expression AS type)，其中 type 必须是 MySQL 支持的类型关键字，比如 CHAR、SIGNED、UNSIGNED、DECIMAL、DATE 等。
注意：不能写成 CAST(col AS VARCHAR) —— MySQL 不支持 VARCHAR 作为 CAST 的目标类型，必须用 CHAR 或带长度的 CHAR(10)；也不支持直接转为 JSON 或 ENUM 类型。
-
CAST('123' AS SIGNED)→ 转成有符号整数 123 -
CAST(123.45 AS CHAR)→ 转成字符串 '123.45' -
CAST('2023-10-01' AS DATE)→ 转成日期值（前提是格式合法）
常见转换失败原因和错误信息
最常遇到的是 Truncated incorrect INTEGER value 或 Incorrect datetime value 这类警告/错误，本质是源数据无法被目标类型安全解析。MySQL 默认在严格模式关闭时会静默截断或转为 0/NULL，容易掩盖问题。
- 字符串含非数字字符时转数值：如
CAST('12a3' AS SIGNED)得到 12（只取前缀数字），但CAST('abc' AS SIGNED)得到 0 - 日期字符串格式不符：如
CAST('01/10/2023' AS DATE)在默认设置下返回NULL，因为 MySQL 期望YYYY-MM-DD - 超长字符串转短
CHAR：如CAST('hello world' AS CHAR(5))截断为 'hello'，无提示
建议在开发环境开启严格 SQL 模式（STRICT_TRANS_TABLES），让转换失败时抛出错误而非静默处理。
CAST 和 CONVERT 的区别与选型建议
CONVERT(expr, type) 是 CAST 的别名形式，功能几乎完全一致，但语法稍简——不过它不支持带长度的类型（如 CONVERT('abc', CHAR(10)) 会报错），而 CAST 支持。
- 需要指定长度（如转固定长度字符串）：必须用
CAST(... AS CHAR(20)) - 做简单类型映射（如字符串转整数）：两个函数效果一样，任选其一即可
- 跨数据库可移植性考虑：标准 SQL 是
CAST，推荐优先使用 - 性能上无差异，都是服务端即时计算，不走索引
实际应用中容易忽略的边界情况
类型转换不是万能的“兜底操作”，尤其在 WHERE 条件或 JOIN 中滥用 CAST 会导致索引失效、隐式转换冲突或结果偏差。
- 在
WHERE中对字段用CAST：如WHERE CAST(create_time AS DATE) = '2023-01-01'，会让create_time上的索引失效 - 数值字段存了带单位的字符串（如 '100kg'）：用
CAST只能提取前缀数字，无法分离单位，应提前清洗数据 -
CAST对NULL输入返回NULL，但不会报错——需确认业务逻辑是否允许空值穿透 - 浮点数转
DECIMAL时精度丢失：如CAST(0.1 + 0.2 AS DECIMAL(10,1))可能得 0.3 或 0.2（取决于浮点计算误差）
真正关键的不是“能不能转”，而是“该不该在这一步转”——多数时候，应在应用层或 ETL 阶段完成类型规整，而不是依赖 SQL 运行时转换。
