MySQL：为什么建议在 int 而不是 varchar 字段上加入？答案

【问题标题】：MySQL: Why it is recommended to JOIN on int instead on varchar field?MySQL：为什么建议在 int 而不是 varchar 字段上加入？
【发布时间】：2016-03-22 08:27:17
【问题描述】：

让我们考虑一下这种奇怪的情况，
索引冗余的地方。

TableA (item_id, code_key, data01, ... data0n)
TableB (item_id, code_key, dataA1, ... dataAn)

item_id 和 code_key 都是唯一的，它们可以是两个表中的主键。 item_id 或 code_key 可以从两个表中删除而不会丢失任何引用/关系。

我知道这是多余的，但这不是问题的重点。考虑一下，两列都被索引了。

Item_id 是 INT，codeKey 是 VARCHAR(100)。

有人建议这样查询更好：

select * from TableA INNER JOIN TableB USING(item_id)

而不是：

select * from TableA INNER JOIN TableB USING(code_key)

我看不出它的意义，因为两列都被索引并且性能是一样的......不是吗？

在 ON 子句中使用 INT 是否会比使用 VARCHAR 更快？即使它们都已编入索引？

【问题讨论】：

Performance of string comparison vs int join in SQL 的副本
在性能方面，差异可以忽略不计 - 除了非常大的数据集。关键因素是codekey在特定情况下能否改变，
与其他问题相反，您的评论与我的想法一致。 Code_key 被插入并且永远不会像 item_id 一样改变。我认为 Mysql 在幕后对这些列进行了索引，因此尽管它们的声明类型不同，但在诸如搜索或连接之类的操作上，它们将具有相同的性能基准测试......
一个房间里有 100 个人。用数字 1 - 100 还是用他们的名字和姓氏更容易记住和称呼他们？这就是你的答案。

标签： mysql performance inner-join

【解决方案1】：

Int 比较比 varchar 比较快，因为比较简单事实上，int 占用的空间比 varchars 少得多。

这对于非索引访问和索引访问都适用。最快的方法 to go 是一个索引 int 列。

-- @罗伯特·蒙泰努

希望对您有所帮助。没有太大区别，但我们看重速度表现。 varchar 越长越慢。

【讨论】：

【解决方案2】：

您似乎在询问是否有两列用于相同的信息。这几乎总是不受欢迎。

继续...您应该有INT 还是VARCHAR...

获取一行的成本（即使已缓存）比处理单个列的成本要高得多。因此，虽然VARCHAR 的成本可能比INT 更高，但仅仅因为这个原因就保证你不遗余力地做出改变是不够的。

同样的论点也适用于表达式的复杂性。

在相关方面，使用ENUM 而不是 VARCHAR 在适当的时候有多种原因。（将VARCHAR 更改为TINYINT 也是如此。）

更小 --> 更快，尤其是在 I/O 受限的情况下。
如果已编入索引，则索引也会更小。
更少的磁盘空间

“规范化”是故意尝试将VARCHAR 替换为某种大小的INT。但这有多种原因。

只有一个地方可以更改字符串，很多表中的行不多。如果存在这个原因，那么它胜过其他考虑。
节省空间。
但它增加了复杂性（现在需要JOIN）。因此，速度可能会或可能不会提高。

在选择INT 时，请始终选择最小的味道。 INT 占用 4 个字节； MEDIUMINT - 3 个字节等。然后根据范围选择它。并且通常使用UNSIGNED。

【讨论】：