CAST和CONVERT在字符串转数字排序中行为完全一致，均按MySQL隐式规则截取前导数字；性能差因无法用索引，应建生成列索引优化。
MySQL 字符串转数字排序时，CAST 和 CONVERT 本质一样，但写法和可读性有差别
直接说结论：两者在数值转换行为上完全一致，都是按 MySQL 的隐式类型转换规则截取前导数字；选哪个主要看团队规范或 SQL 风格偏好。CAST(expr AS type) 更标准（SQL92），CONVERT(expr, type) 是 MySQL 自己的写法，兼容性略广但不够通用。
字符串含非数字前缀时，CAST 和 CONVERT 都只取开头连续数字部分
比如字段值是 "v2.5"、"abc123"、" 42px"，转换结果全是 42 —— 因为 MySQL 在转数字时会跳过开头空格和非法字符，直到遇到第一个数字，然后一直取到下一个非数字字符为止。
常见错误现象：ORDER BY CAST(version_str AS SIGNED) 对 "2.10" 和 "2.2" 排序结果是相等的（都转成 2），根本无法实现语义化版本排序。
- 要用语义化版本排序，得用
ORDER BY SUBSTRING_INDEX(version_str, '.', 1)+0, SUBSTRING_INDEX(SUBSTRING_INDEX(version_str, '.', 2), '.', -1)+0, ... -
SIGNED和UNSIGNED足够应付整数场景；需要小数就用DECIMAL(10,2)，但注意精度丢失风险 - 如果字符串全为非数字（如
"N/A"），转换结果统一为0，不是报错 —— 这点容易误判数据质量
排序性能差？别在 ORDER BY 里直接用 CAST 或 CONVERT
对字符串字段做 CAST(col AS SIGNED) 排序，MySQL 无法使用该字段上的普通索引（B+Tree 索引只存原始字符串值），相当于全表扫描 + 内存排序，大数据量下明显变慢。
- 真实优化方案：加生成列（Generated Column）并建索引，例如：
ALTER TABLE t ADD COLUMN num_val INT AS (CAST(str_col AS SIGNED)) STORED;<br>CREATE INDEX idx_num_val ON t(num_val);
- 如果不能改表结构，至少把转换逻辑提到
SELECT子句中，避免在ORDER BY中重复计算（虽然对排序本身没提速，但利于阅读和后续扩展） -
CONVERT(str_col, SIGNED)和CAST(str_col AS SIGNED)在执行计划里表现完全一致，别指望换函数能提升性能
真正要注意的坑：空字符串、NULL、带单位的数字字符串
这些情况看似简单，但线上常出问题：
-
""（空字符串）→ 转成0；NULL→ 还是NULL，而NULL在ORDER BY中默认排最前（ASC）或最后（DESC），可能打乱预期顺序 -
"123kg"→123；"-45.6m"→-45（小数点后被截断，因为SIGNED不支持小数） - 想安全转换又不想丢数据？先用
REGEXP '^[+-]?[0-9]+\.?[0-9]*$'过滤，再转；或者用STR_TO_DATE()处理日期类字符串更稳妥
复杂点在于：转换行为由 MySQL 版本和 sql_mode 共同决定。比如开启 STRICT_TRANS_TABLES 后，非法转换会报错而非静默变 0，但 CAST/CONVERT 本身不受影响 —— 真正起作用的是插入/更新时的校验，不是查询时的转换。
