mysql的cast()不支持int类型，应改用signed或unsigned；float需换为decimal或double；boolean实为tinyint(1)别名；字符串转数字前须过滤空值与非法字符；函数操作字段会导致索引失效；日期转换推荐str_to_date()而非cast()。
CAST 报错是因为用了 INT 而不是 SIGNED 或 UNSIGNED
MySQL 的 CAST() 不认 INT 这个类型名，写 CAST('123' AS INT) 必报错：Truncated incorrect INTEGER value。它只接受官方明确列出的类型，比如 SIGNED、UNSIGNED、DECIMAL(10,2)、DATE 等。
常见错误写法和对应修正：
-
CAST(col AS INT)→ 改成CAST(col AS SIGNED)（正数或带符号整数）或CAST(col AS UNSIGNED)（非负整数） -
CAST(col AS FLOAT)→ MySQL 不支持FLOAT作为目标类型，改用DECIMAL(p,s)或DOUBLE -
CAST(col AS BOOLEAN)→ 实际是别名，MySQL 内部转为TINYINT(1)，但语义上可用；更稳妥写法是CAST(col AS SIGNED) != 0
字符串转数字失败：空值、空格、字母混入导致静默截断或报错
像 CAST('abc' AS SIGNED) 得 0，CAST('' AS DECIMAL(10,2)) 直接报 Incorrect DECIMAL value: ''。这不是函数问题，而是数据本身不满足转换前提。
安全做法不是硬套 CAST，而是前置过滤：
- 先用
TRIM(col) = ''或col IS NULL排掉空值 - 用正则粗筛数字格式：
col REGEXP '^[[:space:]]*[+-]?[0-9]*\.?[0-9]+([eE][+-]?[0-9]+)?[[:space:]]*$' - 再组合使用：
WHERE TRIM(col) != '' AND col REGEXP '^[0-9.+-]+$' AND CAST(col AS SIGNED) IS NOT NULL - 迁移场景下，宁可丢弃脏数据也不让整条 INSERT 失败，加
INSERT IGNORE或拆成两步（先查出异常行再人工清洗）
在 WHERE 或 ORDER BY 中用 CAST 导致索引失效
写 WHERE CAST(phone AS CHAR) LIKE '138%' 看似合理，但只要对字段做函数操作，MySQL 就无法走 phone 列上的索引，变成全表扫描。
替代方案取决于场景：
- 如果
phone原本是整数型，想按前缀查，不如存成字符串并建前缀索引：INDEX(phone_str(4)) - 如果必须从整数转字符串比对，提前生成冗余字段（如
phone_str VARCHAR(20) AS (CAST(phone AS CHAR)) STORED），再对该字段建索引 - 排序时避免
ORDER BY CAST(name AS SIGNED)，改用ORDER BY name+0（隐式转换仍可能失效，但比 CAST 更轻量）或业务层排序
日期字符串转换失败却不报错，结果为 NULL
CAST('06/15/2026' AS DATE) 在 MySQL 中返回 NULL，不是报错，容易被忽略。ISO 格式 '2026-06-15' 是唯一跨库安全的写法；其他格式必须先清洗或改用 STR_TO_DATE() 显式指定模式。
关键点：
-
CAST('2026-13-01' AS DATE)→NULL（非法日期，不报错） -
CAST('2026-06-15 14:30:00' AS DATE)→'2026-06-15'（自动截断时间部分） - 想兼容非 ISO 日期，不用
CAST，改用：STR_TO_DATE(col, '%m/%d/%Y')或STR_TO_DATE(col, '%d-%m-%Y') - 批量导入时，建议在应用层或 ETL 工具中统一标准化日期格式，数据库层只接收已校验的 ISO 字符串
