CAST函数需用AS指定MySQL支持的类型（如SIGNED、DATE），禁用INT等非标准名；字符串转数字时首字符须为数字，日期格式须严格；慎用于WHERE/ORDER BY以防索引失效，空字符串转数字得0、转日期得NULL，应前置校验。
CAST 函数怎么写才不会报错
MySQL 的 CAST() 不是万能转换器，它只接受明确支持的目标类型，写错类型名或传入非法值会直接报错，比如 CAST('abc' AS INT) 报 Truncated incorrect INTEGER value: 'abc'，不是静默失败。
实操建议：
-
CAST()后必须跟AS type，type只能是 MySQL 官方支持的类型名，如CHAR、SIGNED、UNSIGNED、DECIMAL(10,2)、DATE、TIME，不能写成INT（得用SIGNED或UNSIGNED） - 字符串转数字时，开头必须是有效数字字符，
CAST(' 123abc' AS SIGNED)得到123，但CAST('abc123' AS SIGNED)得0—— 这容易被当成“转换成功”，其实是隐式截断 - 日期字符串必须符合标准格式（如
'2023-05-01'），CAST('01/05/2023' AS DATE)直接返回NULL，不报错但结果不可靠
什么时候该用 CAST 而不是 CONVERT
CAST() 和 CONVERT() 功能几乎一样，但语法和兼容性有实际差异：前者是 SQL 标准写法，后者是 MySQL 扩展。如果你的 SQL 可能迁移到 PostgreSQL 或 SQL Server，优先用 CAST()；如果要转码（比如 UTF8MB4 → GBK），CONVERT() 支持 USING 子句，CAST() 不支持。
实操建议：
- 纯类型转换（如
VARCHAR→DECIMAL）用CAST()更稳妥，语义清晰，各版本兼容性好 - 需要指定字符集转换时，必须用
CONVERT(col USING utf8mb4)，CAST()不接受USING -
CONVERT(expr, type)是 MySQL 旧写法，等价于CONVERT(expr, TYPE type)，但容易和函数重载混淆，建议统一用显式AS形式
在 WHERE 或 ORDER BY 里用 CAST 的性能陷阱
对字段用 CAST() 做条件过滤或排序，大概率导致索引失效。比如 WHERE CAST(phone AS CHAR) LIKE '138%'，即使 phone 是整数类型且有索引，MySQL 也无法走索引。
实操建议：
- 尽量把转换逻辑前置到应用层，或者建生成列（Generated Column）并为其加索引：
ALTER TABLE users ADD phone_str VARCHAR(20) STORED AS (CAST(phone AS CHAR))，再对phone_str建索引 - 如果必须在 SQL 中转换，确认执行计划：
EXPLAIN SELECT ... WHERE CAST(x AS SIGNED) > 100，看key列是否为NULL -
ORDER BY CAST(created_at AS DATE)会强制 filesort，若只是想按天分组，优先考虑DATE(created_at)—— 它在某些场景下比CAST()更易被优化
CAST 处理 NULL 和空字符串的边界行为
CAST(NULL AS xxx) 永远返回 NULL，没问题；但空字符串 '' 转数字会变成 0，转日期变成 NULL，这个“默认映射”在业务逻辑里极易埋雷。
实操建议：
- 字符串转数字前先用
TRIM()和LENGTH()排查空值：CAST(IF(LENGTH(TRIM(str)) = 0, NULL, str) AS SIGNED) - 日期转换务必配合
STR_TO_DATE()做校验，CAST()对格式宽容度过高：STR_TO_DATE('2023/05/01', '%Y/%m/%d')成功，CAST('2023/05/01' AS DATE)失败 - 聚合场景下，
CAST(col AS DECIMAL)遇到非数字值会转成0，可能拉低平均值，建议先用REGEXP '^[0-9.]+$'过滤再转换
类型转换看着简单，真正麻烦的是那些没报错却悄悄变了的数据——尤其是空字符串、带空格数字、模糊日期格式，它们不会让你的 SQL 报错，但会让结果偏离预期。
