优先用cast：语法为cast(expression as data_type)，ansi标准、跨库兼容；convert仅sql server支持，语法为convert(data_type, expression[, style])，style专用于日期/数值格式化。
CAST 和 CONVERT 的语法结构不能混用
很多人写 CONVERT('123', CHAR(10)) 会报错，因为 CONVERT() 不支持带括号的类型声明；反过来，CAST('hello' AS utf8mb4) 也非法——CAST() 完全不认 USING 语法。必须严格区分：CAST(expr AS type) 是标准 SQL 写法，CONVERT(expr, type) 是 MySQL 类型转换写法，CONVERT(expr USING charset) 才是字符集转码写法。
字符串转数字时失败不报错，但行为不一致
两者都静默失败：无效输入返回 0 或 NULL，而不是中断查询。但细节有差别：
-
CAST(' 123abc' AS SIGNED)→123（跳过前导空格，截断尾部非数字） -
CAST('abc123' AS SIGNED)→0（开头非数字，直接归零） -
CAST('' AS SIGNED)→0；CAST(NULL AS SIGNED)→NULL -
CONVERT()行为基本一致，但无法通过正则预过滤来兜底——它不支持在type参数里嵌套逻辑
真要校验，得前置加 WHERE col REGEXP '^[0-9]+$' 或用 IF() 包一层再 CAST。
CHAR 长度控制只有 CAST 支持
需要固定宽度输出（比如导出对齐、日志拼接）时，CAST(price AS CHAR(20)) 能确保结果占满 20 字符（不足补空格）；而 CONVERT(price, CHAR) 只能返回变长字符串，且无法指定长度参数。即使写成 CONVERT(price, CHAR(20))，MySQL 会直接报错 ERROR 1064。
跨数据库迁移时 CAST 更可靠
PostgreSQL、SQL Server、Oracle 都原生支持 CAST()，语义和行为高度一致；CONVERT() 是 MySQL/SQL Server 特有，PostgreSQL 完全不识别。如果你的 SQL 未来可能跑在多个引擎上，或者团队统一规范要求兼容标准 SQL，优先用 CAST()。不过注意：MySQL 实际不支持 INTEGER 这个类型名，得写 SIGNED 或 UNSIGNED，否则不管 CAST 还是 CONVERT 都报错。
最常被忽略的是：类型名大小写不敏感，但拼错就失败；字符集转换和类型转换是两套语法，混用必报错；还有——所有转换都发生在查询执行期，WHERE 子句里滥用会导致索引失效，这点和函数本身无关，但后果一样严重。
