MySQL 性能：自然键与单独自然键的 NOT NULL UNIQUE 约束 => 代理键映射（表）

Question

这是一个小设计，在自然键上具有常见的 NOT NULL UNIQUE 约束：

CREATE TABLE 'users' {
    id int(10) NOT NULL AUTO_INCREMENT,
    name NOT NULL UNIQUE,
    email NOT NULL UNIQUE,
    pass NOT NULL,
    PRIMARY KEY ('id')
}

NOT NULL UNIQUE 约束对我来说似乎是 hackish。拥有不相交的候选键对我来说似乎是非规范化的，并且 UNIQUE 约束似乎是一个臃肿的 O(N) 检查功能，所以我倾向于使用与每个自然键都有关系的设计，将自然键映射到代理键在主要关系中。

CREATE TABLE users {
    id int(10) NOT NULL AUTO_INCREMENT,
    pass NOT NULL,
    PRIMARY KEY ('id')
}
CREATE TABLE user_names {
    name NOT NULL,
    user_id NOT NULL,
    PRIMARY KEY ('name')
}
CREATE TABLE user_emails {
    email NOT NULL,
    user_id NOT NULL,
    PRIMARY KEY ('email')
}

这样，我隐含地对用户的电子邮件和用户名强制执行唯一约束，同时提供能够在 O(ln N + ln M) 时间内使用用户的电子邮件或姓名搜索用户信息的奢侈（我非常喜欢欲望）。

我能看到第一个更常见的设计与第二个设计的性能相匹配的唯一方法是，如果 UNIQUE 约束隐式索引表，以便选择自然键并因此检查其唯一性，则可以完成在 O(ln N) 时间内。

我想我的问题是，关于使用自然键的性能插入和选择，处理具有 3 个或更多由代理键索引的自然键的表的最佳方法是什么？

Answer 1

看来你描述的是6th Normal Form。假设您的原始表在 5NF 中，那么由 3 个表组成的新模式在 6NF 中。拥有三个候选键不会违反 5NF，但会违反 6NF。

从数据完整性的角度来看，但是 6NF 有很大的缺点。通常情况下会丢失一些依赖项。例如，您的原始表强制每个用户都有一个名称和密码的约束。您的 6NF 版本无法做到这一点——如果您想允许插入所有表，至少在 SQL 中不会。 6NF 对于某些特定情况（时间数据）很有用，但一般而言，从数据完整性的角度来看，5NF 更有用且更可取。

这并不能回答您的性能问题，但我认为值得指出。

Answer 2

在我看来，你规范化太多了。您不仅会损害插入/更新的性能，还会损害选择的性能，因为您现在要连接 3 个表，而不是在一个表中直接插入/选择/更新/删除。

我不同意 NOT NULL UNIQUE 是骇人听闻的，但我确实觉得奇怪的是 name 列上有这样的约束。