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

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

1、MySQL为何建议使用自增？

经过网上查阅资料，得出一个这样的结论:
表的主键通常都要使用自增 id，不建议使用业务id ，是由于使用自增id能够避免页分裂。

按照我过去的实践:
选择使用自增能够避免不少麻烦，主要体现是数据的惟一性(从1到xxx，确定不会重复的)。

1.什么是页分裂？

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

为何?mysql不推荐使用uuid或者雪花id做为主键?

2、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的区别与适用场景

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

1.什么是联合主键

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

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

我能想到一个用户信息，针对某个一个区域若是用用户ID或用户ID+用户姓名做为主键，难以保持数据的惟一性，由于这一个地区不只仅是有一个小马哥，可能有七八我的，如此，前面提到的用户ID或用户ID+用户姓名显然是行不通的，这时能够把身份证加入主键，变成了用户ID+用户姓名+身份证(造成了一个联合主键)，这样一来该用户数据的惟一性获得了验证。固然了，联合主键的场景不只仅是这个，关键看业务场景。

4、数据表设计心得分享

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