本文共 2606 字，大约阅读时间需要 8 分钟。
在数据库设计时，主要就是对实体和关系的设计，实体表现出来就是表，关系表现出来就是外键。而对于一个表，由两部分组成：主键和属性。主键的简单定义就是表中为每一行数据的唯一标识。其实更准确的说法，每一行数据的唯一标识是候选键（Candidate Key），一个表中可以有很多个候选键，主键是候选键中的一个，主要用于更方便的检索和管理数据。一个表中可以有多个候选键，但是只有一个主键。由于主键常常用于检索数据，也用于表之间的关联，所以主键的设计的好坏将会严重影响数据操作的性能。下面来介绍下主键设计的几个考虑因素。
最常见的主键数据类型是数字类型、固定长度的字符类型和GUID类型。通常情况下，RDBMS会在主键上建立聚集索引（SQL Server默认都这么做），由于我们使用B-Tree的数据结构来存储索引数据，所以一般对主键有以下两个要求：
越短越好是为了查询的速度快，顺序增长是为了插入速度快。
有了这两个要求，我们再来分析下各个数据类型：
通过上面的比较，我们知道使用数字类型是更好的方式，那么我们为什么还会有人使用GUID和字符串来当主键呢？那是因为：
相对于数字类型，字符类型更易读易记，在检索关联的数据时，更方便直接。
GUID的优势是全球唯一，也就是说同样的系统，如果部署了多套环境，那么里面的数据的主键仍然是唯一的，这样有助于数据的集成。典型的例子就是一个系统在全国每个省份都部署一套，每个省份的数据各种录入，互不干扰，然后再把每个省的数据集成起来为总部做分析。
前面说到一个表可能有很多个唯一标识的候选键，那么这么多候选键中，哪个应该拿来做主键呢？一种方案是再新建一个独立的字段作为主键，该字段并没有业务含义，只是一个自增列或者流水号，用于唯一标识每一行数据，这是数据库主键。另外一种方案是选择其中较短较常用的属性作为主键，这是业务主键。个人建议是不要使用任何有业务含义的字段作主键，而是使用一个自增的（或者系统生成的）没有实际业务意义的字段作为主键。为什么呢？主要是出于以下考虑：
具有业务意义的字段很可能是用户从系统录入的，不要信任用户的任何输入，只要是用户自己录入的，那么就很有可能录错了，如果发现录入错误，这个时候再对主键进行修改，将会涉及到大量关联的外键表的修改，是很麻烦的一件事情。比如在做人员表的时候，就不要使用员工号或者身份证号做主键。
具有业务意义的字段虽然在当前阶段是唯一的，是不变的，但是并不能保证随着公司政策变动、业务调整等原因，导致该业务字段需要修改，以满足新的业务要求，这个时候要修改主键也是很麻烦的事情。比如部门表，我们以部门Code作为主键，但是后来部门变动，Code修改，则系统部门表的主键也得更改。
还有一个原因是业务主键在数据录入的时候不一定是明确知道的，有时我们会在不知道业务主键的情况下，就录入其他相关信息，这个时候，如果使用业务主键做数据库的主键，那么数据将无法录入。比如员工表把员工号作为主键，那么员工还没有入职，没有员工号的时候，HR需要先维护一些该预入职员工的信息是不可能的。
联合主键就是以多个字段来唯一标识每一行数据。前面已经说到主键应该越短越好，而且是建议是一个没有意义的自增列，那么是不是就不会再需要联合主键呢？答案是否定的，我们仍然可能会使用到联合主键。联合主键主要使用在多对多的关系时，中间表就需要使用联合主键。在简单的多对多关系中，我们不需要为中间的关联建立实体，所以中间表可能就只需要两列，分别是两个实体表的主键。
主键值的生成可以参考NHibernate的配置，概况下来主要有这么几种生成方式：
更详细的主键生成，我们可以参见：
在概念和作用上，主键与索引是完全两个不同的东西，但是由于我们大部分情况下都是使用主键检索数据，所以大部分数据库的默认实现，在建立主键时会自动建立对应的索引。
以SQL Server为例，默认情况下，建立主键的列，就会建立聚集索引，但是实际上，我们可以在建立主键时不使用聚集索引。另外还有一个唯一约束（索引）的概念，该索引中的数据必须是唯一不能重复的，感觉和主键的意义一样，但是还是有一点点区别。
主键是只能由一个，而唯一约束（索引）在一个表中可以有多个。
主键不能为空，而唯一约束（索引）是可以为空的。
本文转自深蓝居博客园博客，原文链接：http://www.cnblogs.com/studyzy/p/3309350.html，如需转载请自行联系原作者