CAST转换失败时静默返回0或NULL，易导致数据丢失却无报错，是线上事故高发点；转数字时非数字字符串被截断或归零，转日期时无效格式返回NULL，WHERE中对列用CAST会使索引失效。
直接说结论：CAST 本身不报错，但转换失败时静默返回 0 或 NULL，这种“看起来成功了其实丢了数据”的情况，才是线上事故的高发点。
CAST 转数字时，非数字字符串会变成 0
这是最隐蔽的坑。比如字段存着 '123abc'、'--45'、' '，CAST(... AS SIGNED) 不会报错，而是默默转成 0：
SELECT CAST('123abc' AS SIGNED); -- 返回 123（只取前缀数字）
SELECT CAST('--45' AS SIGNED); -- 返回 0（无法解析，不是 -45）
SELECT CAST(' ' AS SIGNED); -- 返回 0如果你正用它做金额汇总或条件过滤，0 就是脏数据源头。
- 真正想过滤“可转为有效数字”的行，得先用正则预判：
WHERE col REGEXP '^[[:space:]]*[+-]?[0-9]+([.][0-9]+)?[[:space:]]*$' - 对已知格式宽松的字段（如带千分位逗号），先
REPLACE(col, ',', '')再CAST - 别依赖
CAST做数据清洗主逻辑，它只是补救手段
CAST 转日期时，无效格式返回 NULL 而非报错
CAST('2025-13-01' AS DATE) 或 CAST('2025-02-30' AS DATE) 都返回 NULL，不会中断 SQL 执行。一旦你写 WHERE CAST(log_time_str AS DATE) = '2025-10-01'，那些非法日期就彻底消失在结果里，还查不出原因。
- 验证前加
STR_TO_DATE(col, '%Y-%m-%d')并检查是否为NULL，比直接CAST更可控 - 如果源数据来自日志或接口，优先在入库阶段用触发器或应用层校验格式，而不是留到查询时靠
CAST救火 -
CAST('20250405' AS DATE)能成功，但CAST('04/05/2025' AS DATE)会失败——MySQL 只认标准 ISO 格式或能自动推断的紧凑格式
WHERE 条件里对列用 CAST，索引百分百失效
写 WHERE CAST(order_no AS CHAR) = 'ORD-123'，哪怕 order_no 是 VARCHAR 索引列，也会全表扫描。因为 MySQL 必须对每一行都执行一次转换才能比较。
- 正确做法永远是转换“值”，不是转换“列”：
WHERE order_no = CAST('ORD-123' AS CHAR)（虽然这例中 CAST 多余，但思路一致） - 如果值来自程序变量，确保传入前就转好类型；如果是用户输入，后端先做类型归一化再拼 SQL
- 用
EXPLAIN看type字段，只要不是ref或range，基本就是索引没用上
CAST 和 CONVERT 到底选哪个
功能几乎一样，但有两处关键差异：
- 跨库迁移时优先用
CAST，它是 SQL 标准语法，PostgreSQL / SQL Server 都认；CONVERT是 MySQL 扩展，CONVERT(expr USING charset)这种字符集转换写法其他库不支持 - 需要做字符集转换（比如 latin1 存的中文转 utf8mb4）必须用
CONVERT(... USING ...)，CAST不支持这个用法 - 性能无差别，不用纠结，但团队统一用一种可读性更高
真正要花时间的，从来不是函数选哪个，而是搞清数据到底长什么样、哪里可能出错、以及有没有更早的环节能堵住问题——CAST 只是最后一道闸，别把它当漏斗用。
