典型现象是字符串按字典序排序导致'10'排在'2'前；根本原因是MySQL默认逐字符ASCII比较，而非数值大小比较。
MySQL中字符串转整型排序失败的典型现象
直接对含数字的字符串字段（如 varchar 类型的 order_no）用 ORDER BY 排序，结果是按字典序而非数值大小：比如 '10' 会排在 '2' 前面。这不是 bug，是 MySQL 对混合类型隐式转换的默认行为——它把整个字段当字符串比，逐字符 ASCII 比较。
常见错误写法：ORDER BY order_no（没转类型）、ORDER BY order_no + 0（看似能转，但遇到非数字字符如 'A123' 会静默转成 0，排序错乱且无提示）。
用 CAST 转整型并控制截断逻辑
CAST 是 SQL 标准函数，在 MySQL 中稳定支持，适合显式、可控的类型转换。关键在于理解它对非法字符的处理方式：遇到开头是数字的字符串（如 '123abc'），只取前缀数字部分；遇到纯非数字（如 'abc123'），返回 0。
-
ORDER BY CAST(order_no AS SIGNED)：转为有符号整型，适用于大多数正负整数场景 -
ORDER BY CAST(order_no AS UNSIGNED)：强制无符号，若原字符串含负号（如'-42'）会报错Truncated incorrect INTEGER value - 如果字段可能含空格或前导零（如
' 007 '），CAST会自动 trim 并忽略前导零，结果仍是7
CONVERT 函数的等价写法与兼容性注意
CONVERT 和 CAST 在整型转换上功能一致，语法略有不同：CONVERT(order_no, SIGNED)。区别在于：CONVERT 支持字符集转换（如 CONVERT(str USING utf8mb4)），而 CAST 不支持；但就数值转换而言，二者生成的执行计划和结果完全相同。
注意点：
- 不要写
CONVERT(order_no, INT)—— MySQL 不识别INT作为类型名，必须用SIGNED或UNSIGNED - 在旧版本 MySQL（如 5.6）中，
CONVERT(..., SIGNED)对超大数值（如超过2^63-1）可能溢出为负数，而CAST行为更一致 - 两者都不做异常抛出，而是静默降级（如转
'abc'得0），所以排序前建议先用WHERE order_no REGEXP '^[0-9]+$'过滤脏数据
性能与索引失效风险
无论用 CAST 还是 CONVERT，只要出现在 ORDER BY 或 WHERE 条件左侧，MySQL 就无法使用该字段上的普通 B-tree 索引——因为函数改变了原始值，优化器没法直接查索引树。
真实影响比想象中严重：
- 表有百万行，
ORDER BY CAST(order_no AS SIGNED)可能触发 filesort，耗时从几毫秒跳到秒级 - 如果排序字段固定是数字字符串，更优解是建生成列：
ALTER TABLE t ADD order_no_int INT AS (CAST(order_no AS SIGNED)) STORED，再给order_no_int加索引 - 临时方案可用
ORDER BY order_no+0，但仅限确认字段 100% 全数字；否则'A1'和'B1'都变0，彻底打乱顺序
真正麻烦的是那些历史表：字段定义是 varchar，业务已写死用字符串存编号，又不能改结构。这时候 CAST/CONVERT 是最轻量的补救手段，但得接受它不走索引的事实。
