【数据库】主键设计原则

一、反范式主键的设计原则 

• 主键应当是对用户没有意义的。业务上的‘主键’可以通过唯一键（Unique Key）或唯一索引（Unique Index）和其它约束条件实现 
• 主键应该是单列的，以便提高连接和筛选操作的效率 
• 不要更新主键。实际上，因为主键除了惟一地标识一行之外再没有其他的用途了，所以也就没有理由去对它更新。另外，主键的值通常不重用，意味着记录被删除后，该主键值不再使用 
• 主键不应包含动态变化的数据，如时间戳、创建时间列、修改时间列等 
• 主键应当由计算机自动生成。

1.1、确保主键的无意义性

       在开发过程中，有意义的字段例如“用户登录信息表”将“登录名”（英文名）作为主键，“订单表”中将“订单编号”作为主键，如此设计主键一般都是没什么问题，因为将这些主键基本不具有“意义更改”的可能性。

      但是，也有一些例外的情况，例如“订单表”需要支持需求“订单可以作废，并重新生成订单，而且订单号要保持原与订单号一致”，那将“订单编号”作为主键就满足不了要求了。

因此在使用具有实际意义的字段作为主键时，需要考虑是否存在这种可能性。

要用代理主键，不要使用业务主键。任何一张表，强烈建议不要使用有业务含义的字段充当主键。我们通常都是在表中单独添加一个整型的编号充当主键字段。

1.2、采用整型主键

主键通常都是整数，不建议使用字符串当主键。（如果主键是用于集群式服务，可以采用字符串类型）

1.3、减少主键的变动

主键的值通常都不允许修改，除非本记录被删除。

1.4、避免重复使用主键

主键的值通常不重用，意味着记录被删除后，该主键值不再使用。

1.5、主键字段定义区分

主键不要直接定义成【id】，而要加上前缀，定义成【表名id】或者【表名_id】

二、主键方案

2.1、 自增ID

优点：

n  数据库自动编号，速度快，而且是增量增长，聚集型主键按顺序存放，对于检索非常有利。

n  数字型，占用空间小，易排序，在程序中传递方便。

缺点：

n  当系统与其他系统集成时，需要数据导入时，很难保证原系统的ID不发生主键冲突。在多个数据库间进行数据的复制时（SQL Server的数据分发、订阅机制允许我们进行库间的数据复制操作），自动增长式字段可能造成数据合并时的主键冲突及表关联关系的丢失。

n  如果其他系统主键不是数字型，会导致修改主键数据类型，导致其他相关表的修改。

n  在数据缓冲模式下，很难预先填写主键与外键的值。

n  自增量的值都是需要在系统中维护一个全局的数据值，每次插入数据时即对此次值进行增量取值。当在产生唯一标识的并发环境中，每次的增量取值都必须为此全局值加锁解锁以保证增量的唯一性。造成并发瓶颈，降低查询性能。每创建一条记录都需要对表加一次锁，在高并发环境下开销较大。

2.2、 UUID

UUID是指在一台机器上生成的数字，它保证对在同一时空中的所有机器都是唯一的。在UUID的算法中，可能会用到诸如网卡MAC地址，IP，主机名，进程ID等信息以保证其独立性。