MySQL使用CAST/CONVERT转换类型时无法命中varchar索引原因

这个问题是MySQL 8.0优化器对不同函数返回值的类型推导逻辑不一致导致的，和你加了前置int列num1直接相关：

• 对于CONCAT(1, '')：只要CONCAT的入参包含字符串，优化器会直接将返回值判定为和当前会话字符集匹配的字符串常量，常量折叠阶段直接算出结果为'1'，和num字段的varchar类型、字符集、排序规则完全对齐，因此可以正常走ref级别的索引访问。
• 对于CAST(1 AS CHAR)、CONVERT(1, CHAR)：如果写CHAR时不指定长度，MySQL默认会将返回值推导为长度1的定长CHAR类型。当表中存在其他整数类型列时，优化器的类型优先级判断会出现偏差，错误认为右侧返回值数值优先级更高，触发隐式转换规则——逐行把num列的varchar值转成浮点数再做比较，一旦对索引列做逐行函数计算，就无法命中B+树索引，只能走全表扫描。

你之前单列场景测不出问题，是因为没有其他类型列干扰时，优化器会直接把CAST/CONVERT的结果识别为字符串常量，自然能命中索引；加了前置int列后，类型推导路径被干扰，才复现了索引失效的现象。

你可以直接做两个测试验证这个结论：

• 给CAST/CONVERT明确指定字符长度，比如写成CAST(1 AS CHAR(1))、CONVERT(1, CHAR(1))，优化器就能正确识别返回值为字符串类型，此时可以正常命中num索引。
• 调整列顺序把varchar类型的num列放到int类型的num1列前面，同样的CAST/CONVERT语句会恢复索引命中，这也能佐证是多列场景下的类型推导优先级判断偏差导致的问题。

日常写SQL如果需要做显式类型转换命中索引，注意给CHAR类型明确指定长度，不要用无长度参数的AS CHAR写法，避免触发优化器的类型推导bug。

内容的提问来源于stack exchange，提问作者alalalala