浅谈关系型数据库主键设置策略

几乎大多数的应用都会使用关系型数据库进行数据存储，而主键一定是标配。那么，在您的应用中，通常使用什么方案来满足业务扩张呢？下面简单介绍普遍做法以及改进之道。

第一层：业务布局之初。众所周知，企业业务刚开始，需要进行快速试错，而彼时的数据量不会太多，而且暂时不会存在瓶颈，主要是快速打开市场，提供可运行的软件系统，此时不会太多的去关注存储。（言外之意：创业之初会有技术欠债，随着企业发展壮大，会比较痛）。

这时，数据一般采用自增型主键，比如mysql或者sqlserver、postgresql的自增型主键，oracle的序列等都可以很好的满足初期技术架构。当然，如果想用UUID等唯一值做主键也是可以的。不过需要注意的是，使用uuid的可读性会比较差，同时使用字符串做主键，其索引比较大，检索效率稍差。推荐用long类型主键。第一层数据库存储如下图所示：

第二层：快速扩张期。业务经过几轮迭代，数据量也在极度飞升，单机较难满足业务增长，数据库连接常常第一时间产生瓶颈。因此为了提升数据的存储速度，还有快速扩张，技术会选择分库分表。彼时第一阶段会根据业务内容进行垂直分库，比如电商中常见的按照用户、订单、交易、评论等进行拆分。这时的架构也还是当个数据库，只是按照具体业务内容拆分，其主键依然可以采用第一层次的方案。

而随着交易、订单的进一步增长，单库也无法满足性能要求。只能从水平方向上拆分，简单的评估方案是，未来数据存储需要按一亿来计算，单表支撑1千万条数据，最起码需要10张表进行存储。此时会将单库扩张成多张表。此时未考虑到数据库之间的主键不能同步，并同时兼容数据查询高效性。其主键通常会采用分布式ID生成策略，经典有的雪花算法等。此时，单库的自动生成已不再满足业务要求，而uuid等字符型主键因为性能瓶颈也不适合。此时的数据存储架构如下：

第三层：未来扩展期。通过良好的分库分表可以友好的解决存储问题，但是使用这种方案对于数据库的前移工作量比较大。如果是比较新的应用，可以采用newsql的方式解决这种方式，业界比较常见的有TiDB，这种数据存储模式避免了分库分表的一些坑，对于上层应用来说就是单体的存储。业务进行到这个地步，主键推荐采用long类型的主键生成器，避免采用字符型主键。

综上所述，文章简单说明了应用迭代中，主键的一些选型推荐及选择依据。朋友们目前处于什么阶段，当前阶段你们的主键采用什么方式进行生成，欢迎交流。