首先需要把话题引到主键生成上，如果接触过使用分库分表的项目，那么在简历和项目介绍的时候一定要提及分库分表关键词，后面等面试官主动问你主键是如何生成的。
面试过程中被问到了数据库自增主键相关的问题，那么要主动提起自增主键不适用于分库分表场景，然后面试官自然就会追问分库分表场景下主键的生成问题。
准备工作：
- 深入理解市面上常见的主键生成策略
- 准备一个有亮点、微创新的主键生成方案
- 记住一些可行的优化方案
常见主键生成策略
UUID
最简单粗暴的方案，也是面试的时候必须要回答出来的一种策略。如果想要拉开差距，即使是最简单的UUID方案也需要下一番功夫，首先需要详细地解释UUID的两个弊端。
- 过长：这个弊端在面试里讨论的比较少，毕竟采用UUID的地方就不会在意它的长度
- UUID不是递增的：要重点描述的，并且要尝试刷出亮点
亮点1：页分裂
UUID不是递增的这个弊端，要想讲清除，就要先描述为什么会希望在数据库里面使用自增主键。那么可以引用数据库为什么使用自增主键的知识点来回答这个问题，关键词就是页分裂。
如果你尝试往23之后插入一个25，这个叶子节点已经放不下了，不得已需要分裂成(20,21)和(22,23,25)两个节点。原本的(10,20,30)多了一个元素之后变成了(10,20,22,30)，即页分裂这个东西是可能引起连锁反应的，从叶子节点沿着树结构一路分裂到根节点。
可以这样回答
UUID最大的缺陷是它产生的ID不是递增的。一般来说，我们倾向于在数据库中使用自增主键，因为这样可以迫使数据库的数朝着一个方向增长，而不会造成中间叶节点分裂，这样插入性能最好。而整体上UUID生成的ID可以看作是随机，那么就会造成导致数据往页中间插入，引起更加频繁地页分裂，在糟糕的情况下，这种分裂可能引起连锁反应，整棵树的树形结构都会受到影响。所以我们普遍倾向于采用递增的主键。
