mysql 简述pk uk fk 的区别和对数据库性能的影响_数据库pk fk ak

概念 您误解了一些基本概念，因此而造成了困难。我们必须首先解决概念，而不是您认为的问题，因此，您的问题将消失。

自动递增的ID，当然是主键。

不，他们不是。这是一个普遍的误解。并保证了随之而来的问题。

一个ID字段不能作为主键中英文或技术或关系的感觉。

当然，在SQL中，您可以将任何字段声明为PRIMARY KEY，但这并不能从英语，技术或关系意义上将其神奇地转换为主键。您可以将吉娃娃命名为“ Rottweiller”，但这并不能将其转换为Rottweiller，它仍然是吉娃娃。像任何一种语言一样，SQL只是执行您提供的命令，它不能理解PRIMARY KEY为某种关系，它只是在列(或字段)上重击唯一索引。

问题是，既然你已经宣布的ID是一个PRIMARY KEY，你认为它作为一个主键，你可以期望它有一些主键的特质。除了ID 值的唯一性，它没有任何好处。它没有主键的质量，也没有任何关系密钥的质量。它不是英语，技术或关系意义上的关键。通过将非密钥声明为密钥，您只会混淆自己，并且您将发现只有当用户抱怨表中的重复项时，才出现严重错误。

关系表必须具有行唯一性 字段PRIMARY KEY上的A ID不提供行唯一性。因此，它不是包含行的关系表，如果不是，则它是包含记录的文件。它不具有关系数据库中的表所具有的任何完整性，功能(在此阶段，您仅会意识到联接功能)或速度。

执行此代码(MS SQL 2008)并向自己证明。请不要简单地阅读并理解它，然后继续阅读本答案的其余部分，必须在进一步阅读之前执行此代码。具有治疗价值。

CREATE TABLE dumb_file (

id INT NOT NULL IDENTITY PRIMARY KEY,

name_first CHAR(30) NOT NULL,

name_last CHAR(30) NOT NULL

)

INSERT dumb_file VALUES ( "Mickey", "Mouse" ) -- succeeds

INSERT dumb_file VALUES ( "Mickey", "Mouse" ) -- succeeds, but not intended

INSERT dumb_file VALUES ( "Mickey", "Mouse" ) -- succeeds, but not intended

SELECT * FROM dumb_file

请注意，您有重复的行。关系表必须具有唯一的行。进一步证明您没有关系表或任何关系表。

请注意，在您的报告中，唯一的唯一ID字段是没有用户关心，没有用户看到的字段，因为它不是数据，这是一些非常愚蠢的“老师”告诉您在每个字段中输入的内容。文件。您具有记录唯一性，但没有行唯一性。

就数据而言(实际数据减去多余的加法)，数据可以不存在字段name_