cast()语法必须写成cast(expr as type)，as不可省略；mysql不支持int而需用signed/unsigned，不支持varchar而需用char；字符串转数字时首非数字返回0，无效日期返回null，where中对字段用cast会导致索引失效。
CAST() 语法必须写成 CAST(expr AS type)，不能省略 AS
MySQL 的 CAST() 不接受 CAST(expr, type) 这种逗号分隔写法——那是 CONVERT() 的旧式语法。写错直接报错：ERROR 1064 (42000): You have an error in your SQL syntax。
常见错误包括：
- 误写
CAST('123' INT)：MySQL 不认INT，必须用SIGNED或UNSIGNED - 误写
CAST('2023-01-01' DATE)：漏掉AS，语法不合法 - 误用
CAST(col AS VARCHAR)：MySQL 不支持裸VARCHAR，应写CHAR或CHAR(20)
字符串转数字时，首字符非数字会静默得 0，不是报错
CAST() 对非法输入不抛异常，而是按规则截断或归零，容易掩盖数据质量问题。
-
CAST(' 123abc' AS SIGNED)→123（跳过前导空格，读到a停止） -
CAST('abc123' AS SIGNED)→0（开头不是数字，直接返回 0） -
CAST('' AS SIGNED)→0（空字符串也得 0） -
CAST('2023-02-30' AS DATE)→NULL（无效日期不报错，只返回 NULL）
真正需要校验时，得前置判断：WHERE col REGEXP '^[0-9]+\.?[0-9]*$' 或用 STR_TO_DATE() 配合 IS NOT NULL。
在 WHERE 或 ORDER BY 中对字段用 CAST() 会失效索引
比如 phone 是 BIGINT 类型且有索引，但写成 WHERE CAST(phone AS CHAR) LIKE '138%'，MySQL 就无法走索引，退化为全表扫描。
- 根本原因：函数作用于列上，优化器无法利用索引的有序结构
- 替代方案：确保比较双方类型一致，例如把参数转成数字：
WHERE phone >= 13800000000 AND phone - 排序同理：
ORDER BY CAST(score_str AS DECIMAL(5,2))会强制 filesort，应提前建生成列或改存储类型
CAST() 和 CONVERT() 选哪个？看场景
功能高度重叠，但关键差异很实际：
- 要转字符集（如
utf8mb4→gbk），只能用CONVERT(col USING gbk)，CAST()不支持USING - 想兼容 PostgreSQL / SQL Server，优先用
CAST()，它是 SQL 标准语法 - 写
DECIMAL(10,2)这类带精度的类型，两者都支持，但CAST()语义更清晰，不易和CONVERT(expr, type)的旧写法混淆 -
CONVERT('123', SIGNED)虽可用，但建议统一写成CONVERT('123', SIGNED INTEGER)或直接切到CAST()
真正难处理的从来不是语法，而是隐式转换边界和索引失效时机——这两处不检查，查着查着就慢了，还找不到原因。
