如何选主键
选主键其实还挺重要的，选不好就是给未来挖坑。
对于数据量比较小，单机即可的服务，可以无脑考虑自增主键。当然这个前提是，数据量不会特别大，具体就是小于千万级别。也不用考虑网上说的自增主键用完怎么办。因为对于自增主键远远没到用完，就基本该考虑分表了。
主键是自增好处
我们在批判前，可以先说说，主键是自增id的好处。
答案: 性能好，自增 id 在更新时可以，可以顺序插入，避免频繁的页分裂。页分页涉及到更底层的计算机存储，大家有兴趣可以自己查查。
我先从顺序插入，B+树的叶子节点，是顺序排列的，如果主键是自增的，新插入的数据，就会顺序的往后排列。但是如果使用的是无序的业务主键，就会导致每次插入都会重排。而这个重排的过程会导致页分裂。
自增主键+业务id索引
如果像上面说的，自增主键这么好，那方案就设计成自增主键用于性能友好，业务加一个字段，单独建索引呢？
答案是: 性能不一定比拿业务id做主键好。
why?
- 数据库需要多维护一个索引，每次更新，多增加一次索引的更新。
- 只有主键的索引的叶子节点存储了全部节点信息，非主键索引的叶子节点存储的是一个指针。使用非主键查询节点，会涉及一次回表查询（多一次磁盘的i/o）（下一节索引会详细说说回表）。
看到没有，想用好数据库，底层知识少不了。并发低（写数据qps小于200，读数据qps小于1000）的时候其实应该还没有感知。但是并发高了，主键索引的问题就会被放大。
为什么不能自增主键
先回答这个问题: 如上面提到，单机没有任何影响，但是一旦数据量大了，需要分库分表时，自增组件就是一个障碍了。
因为自增主键是数据库自己内部处理的，当数据库分库时，一般主键也是业务id，这个时候，多个数据库就会生成重复的业务id。这个对程序就是需要大动干戈的升级了。
主键几种可选方案
全局唯一uuid
这是一个最简单的方案，但是需要排除。uuid是试用于分布式场景，生成全局唯一id的。
但是他的明显缺点：
- 无序
- 字符串太长，占索引空间
上面2个对性能影响都很大。使用它唯一解决的问题就是分布式数据库下，保证id唯一的功能
snowflake 算法生成id
Twitter 出品
id长下面样子：
详细了解，可以自己查询深入。
它的优点：
- 有序
- 长度比uuid短
- 保证分布式下全局唯一
其他类似snowflake 算法的变种
很多了，大家自己了解~~
总结
当有一天业务发展到需要分库分表时，如果最初就选好了一个合理的主键。能至少省一个通宵的上线+差不多一周方案设计，开发等等。
