在内存使用方面,使用字符串作为引用其他表的键是否不好?

fva*_*iad 4 mysql mysql-8.0

所以我必须处理以下情况:

我有一个表users,其中包含我的应用程序的所有用户。每个用户都有一个唯一的电子邮件,因此可以是所述表的主键。

现在假设我有第二个表将一些数据与用户相关联。我想到的是让第二个表保存一个电子邮件列,然后我可以用它来将一行与用户相关联。这种方法在内存方面是否不好?MySQL 是否会为每个包含电子邮件列以引用用户表的额外表重复存储上述电子邮件?我是否应该只为每个用户使用一个自动递增的 id 并将其用于整个参考事物,因为整数比足以容纳电子邮件的字符串轻得多?

nbk*_*nbk 6

是的,MySql 和所有其他 rdms 会将完整的电子邮件存储为 varchar,并根据 rdms 为它需要的字节数或最大大小保留空间。

大整数最多 8 个字节的整数将仅使用这些字节,并且在引用时速度更快。

在速度方面,您使用 INTEGER,并在需要时考虑其他类似 varchar(36) 的 uuid,例如不同的服务器必须将数据保存在同一个表中。

电子邮件是唯一的,因此被编入索引以供参考,如果您希望有大表,您应该加倍努力并使用 Integer。


Ric*_*mes 6

如果有一个emailper user,则向users表中添加一列。

一般来说,表之间的 1:1 映射不是一个好主意;简单地组合表格。

UUID 是一个坏主意(出于多种原因),除非您必须以某种分布式方式生成唯一标识符。

AVARCHAR不一定是“坏的”;它甚至可以比添加一个不必要的 auto_increment 节省空间。

当有人使用 4 字节的 INT(自动增量)country_code代替标准的 2 个字母的 country_code时,会让人感到恼火。

  • @Schwern 索引碎片、插入期间的页面拆分、缓存/页面位置(相对于同时查询的其他数据)。如果代理键是单调递增的,那么它是最好的,这就是为什么自动递增是好的而随机是坏的。显然,如果一个自然键很可能被查询,即使它是随机的,也可以作为索引。 (3认同)
  • 您能否详细说明为什么 UUID 是个坏主意? (2认同)