MySQL是一个流行的关系型数据库管理系统，它的优化器是一个重要的组件，负责对SQL语句进行解析、优化和执行计划的生成。尽管MySQL的优化器在大多数情况下都表现良好，但其不能做智能的类型转换却是一个存在的问题。

在MySQL中，当我们使用某些操作符或函数时，如果操作数的类型不匹配，MySQL会自动执行类型转换以使其兼容。如下代码：

SELECT 1 + '2';

这个查询将返回结果3，因为MySQL将字符型'2'转换为数字型2，然后执行加法运算。这种隐式类型转换看起来很方便，但实际上可能会带来性能问题。

考虑以下示例：

SELECT * FROM mytable WHERE numcol = '123';

假设mytable表中的numcol列是整型，如果我们执行上述查询，则MySQL将强制将字符串'123'转换为整数，然后执行比较操作。这种转换看起来没有什么问题，但是如果该表中有数百万行数据，并且我们使用了索引来加速查询，那么MySQL将不得不对每一行数据进行转换，这将导致显著的性能下降。

尽管MySQL提供了CAST和CONVERT等函数来手动执行类型转换，但是这些函数需要我们手动指定转换的类型，而且也无法解决隐式类型转换问题。此外，在复杂的查询中，手动指定类型转换也非常困难，这进一步增加了查询性能下降的风险。

那么为什么MySQL的优化器不能自动执行智能的类型转换呢？这主要是因为MySQL的优化器设计之初并没有考虑到这个问题。在早期版本的MySQL中，类型转换是作为语义的一部分被硬编码到操作符和函数中的，这也就意味着，MySQL的优化器只需要简单地检查操作数的类型是否匹配即可。

随着时间的推移，MySQL的操作符和函数变得越来越复杂，涉及到更多的类型和语义。此外，MySQL还支持用户自定义函数和存储过程等高级特性，这使得类型转换变得更加复杂和困难。在这种情况下，要使优化器能够智能地处理类型转换，需要对MySQL的内核结构进行重大修改，这需要投入大量的人力和资源，而且可能会对现有的代码和API产生不兼容性影响。

另外，MySQL的开发者们也认为，隐式类型转换虽然可能影响性能，但通常不是性能问题的主要原因。实际上，常见的性能问题通常与查询的结构、索引的使用方式、数据访问模式等相关，而不是隐式类型转换。因此，他们把更多的精力放在解决这些问题上，而不是改善类型转换。

综上所述，MySQL的优化器不能智能地处理类型转换主要是由于历史原因和技术限制。虽然这可能会对查询性能造成一定的影响，但通常不是最关键的问题。如果我们在编写查询时能够合理地使用数据类型和避免隐式类型转换，就可以在不改变MySQL的内核结构的前提下，极大地提高查询性能。