前面我们在讲解存储的时候，有提到过主键，它可以唯一标识表中的某一条记录，对数据表来说非常重要。当我们需要查询和引用表中的一条数据记录的时候，最好的办法就是通过主键。只有合理地设置主键，才能确保我们准确、快速的找到所需要的数据记录。

下面我们借助超市项目的实际需求，来讲解一下怎么正确设置主键？

在超市项目中，店家想进行会员营销，相应的，我们就需要处理会员信息。

会员信息表（demo.membermaster）的设计大体如下：

为了能够唯一的标识一个会员的信息，我们需要为会员信息表设置一个主键，那么，怎么为这张表设置主键，才能达到我们理想的目标呢？

其实，设置主键一共有三种思路：业务字段做主键、自增字段做主键和手动赋值字段做主键。

针对这个需求，我们最容易想到的是选择表中跟业务相关的字段做主键。

那么在这张表中，哪个字段比较合适呢？

会员卡号（cardno）看起来比较合适，因为会员卡号不能为空，而且有唯一性，可以用来标识一条会员记录，OK，那我们尝试一下：

我们在创建表的时候，设置字段cardno为主键：

会员卡号做主键有什么问题呢？我们插入2条数据来验证一下：

插入成功后，我们来看看表中的内容：

可以看到，不同的会员卡号对应不同的会员，字段cardno唯一标识某一个会员。

如果都是这样的话，会员卡号与会员一一对应，系统是可以正常运行的。但是实际情况是，会员卡号是存在重复使用的情况的。这个很好理解，比如，张三因为工作变动搬离了原来的地址，不再到商家的门店消费了（退还了会员卡），于是张三就不再是这家商店的会员了，于是商家为了不让会员卡空着，就把卡号10000001的会员卡发给了王五。

从系统设计的角度看，这个变化只是修改了会员信息表的卡号10000001这个会员信息，并不会影响到数据的一致性。也就是说，修改会员卡号10000001的会员信息，系统的各个模块，都会获取到修改后的会员信息，不会出现“有的模块获取到修改之前的会员信息，有的模块获取到修改后的会员信息，而导致系统内部数据不一致”的情况。因此，从信息系统层面上看是没问题的。

但是从使用系统的业务层面来看，就有很大的问题了，会对商家造成影响。

比如，我们有一个销售流水表，记录了所有的销售流水明细。2020 年 12 月 01 日，张三在门店购买了一本书，消费了 89 元。那么，系统中就有了张三买书的流水记录，如下所示：

因为需要引用会员信息和商品信息，所以销售流水表需要包括商品编号字段和会员卡号字段：

创建表之后，我们来插入一条销售流水：

接着，我们来查询2020年12月01日的会员销售记录：

我们得到的查询结果是：张三，在 2020 年 12 月 01 日买了一本书，花了 89 元。

需要注意的是，这里我用到了 JOIN，也就是表的关联，目的是为了引用其他表的信息，包括会员信息表（demo.membermaster）和商品信息表（demo.goodsmaster）。

有关关联表查询的具体细节，后面文章会讲到，这里我们只要知道，通过关联查询，可以从会员信息表中获取会员信息，从商品信息表中获取商品信息，就可以了。

下面，我们假设会员卡“10000001”又发给了王五，我们需要更改会员信息表：

会员记录改好了，我们再次运行之前的会员消费流水查询：

这次得到的结果是：王五在 2020 年 12 月 01 日，买了一本书，消费 89 元。很明显，这个结果把张三的消费行为放到王五身上去了，肯定是不对的。

这里的原因就是，我们把会员卡号是“10000001”的会员信息改了，而会员卡号是主键，会员消费查询通过会员卡号关联到会员信息，得到了完全错误的结果。

所以，千万不能把会员卡号当做主键。那么，会员电话可以做主键吗？不行的。在实际操作中，手机号也存在被运营商收回，重新发给别人用的情况。那身份证号行不行呢？好像可以。因为身份证决不会重复，身份证号与一个人存在一一对应的关系。可问题是，身份证号属于个人隐私，顾客不一定愿意给你。对门店来说，顾客就是上帝，要是强制要求会员必须登记身份证号，会把很多客人赶跑的。其实，客户电话也有这个问题，这也是我们在设计会员信息表的时候，允许身份证号和电话都为空的原因。

这样看来，任何一个现有的字段都不适合做主键。

所以这里给出的建议是，尽量不要使用业务字段，也就是跟业务有关的字段做主键。

既然业务字段不可以，那么我们试试自增字段。

我们来给会员信息表添加一个字段，比如叫 id，给这个字段定义自增约束，这样，我们就有了一个具备唯一性的，而且不为空的字段来做主键了。

接下来，我们就来修改一下会员信息表的结构，添加一个自增字段做主键。

第一步，修改会员信息表，删除表的主键约束，这样一来，原先的主键字段，就不再是主键了。需要注意的是，删除主键约束，并不会删除字段。

第二步，修改会员信息表，添加字段‘id’为主键，并给它定义自增约束：

第三步，修改销售流水表，添加新的字段menberid，对应会员信息表中的主键：

第四步，我们更新一下销售流水表，给新添加的字段memberid赋值，让它指向对应的会员信息；

这个更新语句包含了 2 个关联的表，看上去有点复杂。虽然复杂一些，但是在实战中更有用。

OK，到这里我们就完成了对数据表的重新设计，让我们来看一下新的数据表demo.membermaster和demo.trans的结构：

现在，如果我们再次面对卡号重用的情况，该如何应对呢（这里我们假设回到修改会员卡 10000001 为王五之前的状态）？

如果张三的会员卡“10000001”不再使用，发给了王五，我们就在会员信息表里面增加一条记录：

我们看看当前的会员信息：

由于字段“cardno”不再是主键，可以允许重复，因此，我们可以在保留会员“张三”信息的同时，添加使用同一会员卡号的“王五”的信息。

现在再来查会员消费，就不会出问题了：

可以看到，结果是 2020 年 12 月 01 日，张三买了一本书，消费 89 元，是正确的。

如果是一个小项目，只有一个 MySQL 数据库服务器，用添加自增字段作为主键的办法是可以的。不过，这并不意味着，在任何情况下你都可以这么做。

举个例子，用户要求把增加新会员的工作放到门店进行，因为发展新会员的工作一般是在门店进行的，毕竟，人们一般都是在购物的同时申请会员。解决的办法是，门店的信息系统添加新增会员的功能，把新的会员信息先存放到本地 MySQL 数据库中，再上传到总部，进行汇总。

可是问题来了，如果会员信息表的主键是自增的，那么各个门店新加的会员就会出现“id”冲突的可能。

比如，A 店的 MySQL 数据库中的 demo.membermaster 中，字段“id”的值是 100，这个时候，新增了一个会员，“id”是 101。同时，B 店的字段“id”值也是 100，要加一个新会员，“id”也是 101，毕竟，B 店的 MySQL 数据库与 A 店相互独立。等 A 店与 B 店都把新的会员上传到总部之后，就会出现两个“id”是 101，但却是不同会员的情况，这该如何处理呢？

为了解决这个问题，我们想了一个办法：取消字段“id”的自增属性，改成信息系统在添加会员的时候对“id”进行赋值。

具体的操作是这样的：在总部 MySQL 数据库中，有一个管理信息表，里面的信息包括成本核算策略，支付方式等，还有总部的系统参数，我们可以在这个表中添加一个字段，专门用来记录当前会员编号的最大值。

门店在添加会员的时候，先到总部 MySQL 数据库中获取这个最大值，在这个基础上加 1，然后用这个值作为新会员的“id”，同时，更新总部 MySQL 数据库管理信息表中的当前会员编号的最大值。

这样一来，各个门店添加会员的时候，都对同一个总部 MySQL 数据库中的数据表字段进行操作，就解决了各门店添加会员时会员编号冲突的问题，同时也避免了使用业务字段导致数据错误的问题。

设置数据表主键的三种方式：数据表的业务字段做主键、添加自增字段做主键，以及添加手动赋值字段做主键。

刚开始使用 MySQL 时，很多人都很容易犯的错误是喜欢用业务字段做主键，想当然地认为了解业务需求，但实际情况往往出乎意料，而更改主键设置的成本非常高。所以，如果你的系统比较复杂，尽量给表加一个字段做主键，采用手动赋值的办法，虽然系统开发的时候麻烦一点，却可以避免后面出大问题。

文章参考：朱晓峰·MySQL必知必会