CAST()在MySQL 8.0中是严格转换器，仅支持官方类型名（如SIGNED、CHAR、DECIMAL），不接受INT/TEXT等非标准名，非法输入会报错或返回不可靠结果，需前置校验与合理建模避坑。
CAST() 在 MySQL 8.0 中不是“宽松转换器”，它只做明确、有限的类型映射，且失败时不静默——写错类型名或传入非法值会直接报错或返回不可靠结果。想用得稳，关键不是“怎么写”，而是“怎么避坑”。
CAST 的 type 参数只能是 MySQL 明确支持的类型名
MySQL 不接受 INT、INTEGER、TEXT 这类常见但非标准的 type 名。写错就报错，比如：CAST('123' AS INT) 会触发 Truncated incorrect INTEGER value: '123'（注意：这不是语法错误，而是类型不被识别导致的隐式截断警告升级为错误）。
必须用官方认可的类型：
-
SIGNED或UNSIGNED替代INT -
CHAR或CHAR(10)替代TEXT（TEXT不能作为 CAST 目标类型） -
DECIMAL(10,2)可用，但FLOAT和DOUBLE仅在 MySQL 8.0.17+ 支持 -
DATE、DATETIME、TIME必须对应严格格式字符串，否则返回NULL而非报错
字符串转数字时，首字符决定成败
MySQL 对前导空格宽容（CAST(' 42abc' AS SIGNED) → 42），但一旦首字符非数字或符号（+/-），就截断为 0：CAST('abc42' AS SIGNED) → 0。这看起来像“成功”，实则是静默失败。
安全做法是前置校验：
- 用
REGEXP '^[+-]?[0-9]'判断是否以数字/符号开头 - 对空字符串
''单独处理——CAST('' AS SIGNED)得0，但业务上往往该算无效 - 避免在
WHERE条件里直接CAST(col AS SIGNED) > 100，除非你确认所有值都合法
日期字符串必须符合标准格式，否则 NULL 不报警
CAST('2026/06/15' AS DATE) 和 CAST('15-06-2026' AS DATE) 都返回 NULL，不报错也不警告。你以为条件没命中，其实是转换失败了。
真正能被接受的只有：
-
DATE：'2026-06-15'（YYYY-MM-DD） -
DATETIME：'2026-06-15 19:22:00'（YYYY-MM-DD HH:MM:SS） -
TIME：'19:22:00' - 数字型时间戳如
20260615会被尝试解析，但依赖系统变量sql_mode，不稳定
建议先用 STR_TO_DATE() 做容错解析，再 CAST；或用 IS_DATE()（MySQL 8.0.23+）预检。
别在 WHERE 或 ORDER BY 里对字段 CAST
对索引列做 CAST(col AS CHAR) 或 CAST(col AS SIGNED)，几乎必然导致全表扫描。例如：
SELECT * FROM users WHERE CAST(phone AS CHAR) LIKE '138%';
即使 phone 是 BIGINT 且有索引，MySQL 也无法利用它。
真正可行的替代方案：
- 建生成列并索引：
ALTER TABLE users ADD phone_str VARCHAR(20) STORED AS (CAST(phone AS CHAR)) INDEX; - 改存储方式：原始数据就存成合适类型（数字存
BIGINT，号码带前缀就存VARCHAR） - 排序场景优先用
CONVERT(col USING utf8mb4)（仅当需转字符集）或原生类型排序
最常被忽略的一点：CAST 的“严格”体现在它不帮你兜底——它只忠实地执行定义好的转换规则，而这些规则本身就有大量边界行为。用之前，先查清源数据质量，比调对函数更重要。
