如下面的create table中所示，可以在Id上创建一个UNIQUE索引，足以使id成为主键吗？更具体地说，你能说下表有一个主键吗？
test` (
`id` bigint(20) unsigned NOT NULL AUTO_INCREMENT,
`role` varchar(32) NOT NULL,
`resources_name` varchar(32) NOT NULL,
`access_name` varchar(32) NOT NULL,
`allowed` int(3) NOT NULL,
UNIQUE KEY `id` (`id`),
UNIQUE KEY `roles_name` (`role`,`resources_name`,`access_name`)
) ENGINE=InnoDB AUTO_INCREMENT=32 DEFAULT CHARSET=utf8
您可以使用什么查询来证明这有或没有PK？
答案 0 :(得分：1)
从逻辑上讲，如果关系表中至少有一个候选键被强制执行（最低限度唯一且不可空），那么事实上它有一个＆＃34; primary＆＃34;键。没有绝对需要使用特殊的＆＃34; primary＆＃34;来挑出任何一个密钥。标签因为原则上所有键都是相同的（历史上术语＆＃34;主键＆＃34;曾用于任何和所有候选键而不是每个表只有一个键）。
SQL中存在一个称为PRIMARY KEY约束的约束。从逻辑上讲，SQL PRIMARY KEY不仅仅是语法糖，因为NOT NULL UNIQUE语法实现了基本相同的功能。从技术上讲，PRIMARY KEY约束不必引用与＆＃34;主键＆＃34;的关系概念相同的东西。但很明显，如果您要将任何一个键指定为主键，并且如果您觉得需要一种表示该选择的语法方式，则PRIMARY KEY约束是公认的方法。
所以也许最好的答案是＆＃34;它取决于＆＃34;。这在很大程度上取决于您首先定义主键的动机。如果您打算向数据库的开发人员和用户单独输出一个密钥，那么NOT NULL UNIQUE语法可能无法为您实现。如果你没有发现需要使用SQL语法，那么也许NOT NULL UNIQUE就像PRIMARY KEY约束那样定义你的密钥一样好。
答案 1 :(得分：0)
评论太长或太短：不。
主键和唯一键 - 虽然相似 - 不一样。所以，没有你的桌子没有主键。最大的功能差异是主键不能是NULL，而唯一键可以是。{/ p>
主键通常也是群集的（如果底层存储引擎支持聚簇索引）。这意味着数据实际上按主键的顺序物理存储在页面上。唯一键只是另一个索引，具有没有重复值的特征。
编辑：
有趣。 SHOW COLUMNS documents此行为：
如果UNIQUE索引不能包含NULL，则它可能会显示为PRI 值，表中没有PRIMARY KEY。
我没有意识到这一点。