数据表设计之主键自增、UUID或联合主键

最近在做数据库设计的时候(以MySQL为主)，遇到不少困惑，因为之前做数据库表设计，基本上主键都是使用自增的形式，最近因为这种做法，被领导指出存在一些不足，于是我想搞明白哪里不足。

一、MySQL为什么建议使用自增？

通过网上查阅资料，得出一个这样的结论:
表的主键一般都要使用自增 id，不建议使用业务id ，是因为使用自增id可以避免页分裂。

按照我过去的实践:
选择使用自增可以避免很多麻烦，主要体现是数据的唯一性(从1到xxx，肯定不会重复的)。

1.什么是页分裂？

这块我没看太明白，我主要参考如下链接:
一看就懂的：MySQL数据页以及页分裂机制

为什么?mysql不推荐使用uuid或者雪花id作为主键?

二、UUID作为主键的优劣势是什么？以及它的应用场景是什么？

1.UUID和自增int型作为主键的比较,有哪些优势和劣势？

(1)优势

• UUID值在不同的表、数据库、甚至是服务器中都是全局唯一的，所以你可以合并来自不同数据库，甚至是不同服务器上不同数据库上的数据行；
• UUID值不会在URL中暴露你的数据信息。例如，一个客户可以通过 id10来访问他的账号地址 http://www.example.com/c/10/ ，他可以很轻松地猜到会有 id 11, 12等等的客户，这可能被拖库，或被别人猜到你的用户量；
• UUID值生成的时候不需要查一遍数据库，并且它还简化了应用层的逻辑。例如，当你要给父表和子表插入数据时，一般你要先把数据插到父表里，然后才能插到子表里。但是如果你用UUID的话，你可以直接生成父表的主键，然后在一个事务里同时把数据插到父表和子表里。

专业名词解释

拖库:指黑客通过各种社工手段、技术手段将数据库中敏感信息非法获取，一般这些敏感信息包括用户的账号信息如用户名、密码；身份信息如真实姓名、证件号码；通讯信息如电子邮箱、电话、住址等。

(2)劣势

• 存储UUID值（16字节）需要的存储空间比INT型（4字节）甚至是 BIGINT型（8字节）都要大;
• 调试起来会更难一些，你可以想象一下平时你只需要 WHERE id = 10 现在你要写 WHERE id = ‘df3b7cb7-6a95-11e7-8846-b05adad3f0ae’;
• UUID 值通常会因为它的大小和未被排序的问题导致性能问题。

参考链接:
MySQL主键应该用UUID还是INT类型

一分钟让你了解拖库、洗库和撞库

2.哪些应用场景应该使用UUID作为主键？

简要概括UUID的适用场景:主要适合用在大型项目微服务架构中，保证全局ID唯一性(大型项目微服务架构集成各式各样的子系统，避免ID冲突)。

起初我在数据表设计的时候就与项目经理争论过，挺类似这个链接的对话:UUID与数字ID的区别与适用场景

三、什么是联合主键？联合主键的适用场景又是什么？

1.什么是联合主键

指用2个或者是2个以上的字段组成的主键，用这个主键包含的字段作为主键，这个组合在数据表中是唯一，且附加上了主键索引。

2.联合主键的适用场景是什么？

我能想到一个用户信息，针对某个一个区域如果用用户ID或用户ID+用户姓名作为主键，难以保持数据的唯一性，因为这一个地区不仅仅是有一个小马哥，可能有七八个人，如此，前面提到的用户ID或用户ID+用户姓名显然是行不通的，这时可以把SFZ加入主键，变成了用户ID+用户姓名+SFZ(形成了一个联合主键)，这样一来该用户数据的唯一性得到了验证。当然了，联合主键的场景不仅仅是这个，关键看业务场景。

四、数据表设计心得分享

从外包公司->创业公司->教育公司->现在所在公司，回过头来看过去我的数据表设计方面，存在的一个最大不足，即着重考虑技术实现难易层面，而轻视业务场景适用性、扩展性、稳定性等。