我最近遇到了一个查询导致全表扫描的问题，归结为一个列的定义与我认为的不同，它是 VARCHAR 而不是 INT。当使用“string_column = 17”查询时，查询运行了，只是无法使用索引。这真的让我大吃一惊。
所以我去搜索并发现发生了什么，我看到的行为与 MySQL's documentation 一致说:
In all other cases, the arguments are compared as floating-point (real) numbers.
所以我的问题是……为什么要 float ？
我可以看到尝试将数字转换为字符串(尽管上面链接的 MySQL 页面中的要点是不这样做的充分理由)。我也能理解抛出某种错误，或生成警告(我的偏好)。相反，它会愉快地运行。
那么为什么要将所有内容都转换为 float 呢？这是来自 SQL 标准，还是基于其他原因？谁能为我阐明这个选择？
最佳答案
我感受到了你的痛苦。我们的数据库中有一个列，其中包含公司众所周知的“订单号”。但它并不总是一个数字，在某些情况下它也可以有其他字符，所以我们将它保存在一个 varchar 中。对于 SQL Server 2000，这意味着选择“order_number = 123456”是错误的。 SQL Server 有效地将谓词重写为 "CAST(order_number, INT) = 123456"，这有两个不良影响:
- 索引作为 varchar 在
order_number上，因此它开始全面扫描 - 这些非数字订单号最终会导致向用户抛出转换错误，并显示一条毫无帮助的消息。
在某种程度上，我们拥有那些非数字“数字”是件好事，因为至少将参数作为数字传递的编写糟糕的查询会被困住，而不仅仅是吸收资源。
我认为没有标准。我似乎记得 PostgreSQL 8.3 删除了一些数字和文本类型之间的默认转换，因此这种情况会在计划查询时抛出错误。
大概“float”被认为是范围最广的数字类型，因此所有数字都可以悄无声息地提升到这种类型？
哦，当你有 varchar 列和一个将所有字符串文字作为 nvarchar 传递的 Java 应用程序时，还有类似的问题(但没有转换错误)......突然你的 varchar 索引不再被使用，祝你好运找到它的出现发生。当然，您可以告诉 Java 应用程序以 varchar 的形式发送字符串，但现在我们只能使用 windows-1252 中的字符，因为这就是 5-6 年前创建数据库的原因，当时它只是一个“权宜之计” , 啊哈。
关于sql - MySQL 类型转换 : Why is float the lowest common denominator type?，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/889792/