MySQL中CAST(字符串 AS SIGNED)返回0是因为其采用左对齐贪婪解析：若字符串首字符非数字、+或-，直接返回0；仅当开头为有效数字序列时才截取并转换，如'abc123'→0、'123abc'→123。
CAST(字符串 AS SIGNED) 转数字时为什么有时返回 0？
MySQL 的 CAST 在转换非法数字字符串（如 'abc'、'123xyz'）时不会报错，而是静默转成 0 —— 这是默认行为，不是 bug，但极易掩盖数据问题。
- 只取开头连续数字部分：
CAST('123abc' AS SIGNED)→123；CAST('abc123' AS SIGNED)→0 - 带空格或符号需谨慎：
CAST(' -45 ' AS SIGNED)→-45（可处理首尾空格和单个符号），但'- 45'会变成0 - 浮点转整型会截断，不四舍五入：
CAST('3.9' AS SIGNED)→3
用 CAST 转小数或高精度数字该选 DECIMAL 还是 DOUBLE？
取决于精度要求和后续计算场景。两者底层行为差异明显：
-
CAST('123.456789' AS DECIMAL(10,6))保留指定小数位，适合金额、统计等需要精确比较的场景 -
CAST('123.456789' AS DOUBLE)可能引入浮点误差，比如CAST('0.1' AS DOUBLE) + CAST('0.2' AS DOUBLE)≠0.3 - 若源字符串含多余小数位（如
'1.23456789'），DECIMAL(5,2)会直接截断为1.23，不进位
字符串转日期失败时，CAST 和 STR_TO_DATE 哪个更可靠？
CAST 对日期格式极其敏感，仅支持标准格式（如 '2023-01-01'、'20230101'），遇到 '01/01/2023' 或 '2023年1月1日' 直接返回 NULL。
- 必须用
STR_TO_DATE处理非标准格式：STR_TO_DATE('01/01/2023', '%m/%d/%Y') -
CAST('2023-01-01 10:20:30' AS DATE)→'2023-01-01'（自动截断时间部分） -
CAST('2023-01-01' AS DATETIME)→'2023-01-01 00:00:00'（补零填充）
在 WHERE 条件里隐式转换比显式 CAST 更快吗？
不一定。MySQL 有时会因字段类型与参数类型不匹配而放弃索引，即使你写了 CAST，也可能触发全表扫描。
- 如果
phone是VARCHAR字段，写WHERE phone = 13800138000会让 MySQL 把所有字符串转数字再比对 —— 索引失效 - 显式写
WHERE CAST(phone AS SIGNED) = 13800138000同样无法走索引（函数作用于字段） - 真正高效的做法是统一存储类型：手机号这类纯数字但有前导零或超长的值，应存为
VARCHAR，查询也用字符串：WHERE phone = '13800138000'
实际中多数“类型转换需求”背后是建表设计或导入逻辑的偏差，CAST 是临时补救手段，不是替代规范的数据类型选择。
