上篇文章讲解了传统数据库的一些设计注意点。
本篇为第二篇，在大数据量的情况下，如何去提前设计这个表结构，来达到一个比较好的效果。对于团队，对于后续的维护和扩展都带来更大的便利。
自增id
还是这条，自增id还是可以有，但是不是必须的了。但是建议还是每张表中有一个自增id。
为什么，还是那句话，做数据查询，迁移，排序的时候，有着天然的一些优势。
唯一标识
这个标识无论是token，还是其他例如订单的订单号或者其他唯一标识都行。
重点是唯一，不只是在单系统中唯一，而是需要在并发的情况，也能够保持唯一。
关于分布式id的生成方案，网上已经有很多了，这里就不重复了。谷歌搜索搜索，自己看下原理，跑跑demo，能够满足自己业务的最大并发情况下的唯一即可。
比如说你未来几年的最大并发也就是100，搞个能支持在几千并发下不会出现标识重复的实现方案即可，什么并发几万，几十万，真的需要吗？
后续如果真的能够达到几万并发，那说明什么，说明业务火爆了啊。难道还抽不出时间，抽不出人来做一个id生成方案的改造？这里有比较重要的一点，不要太过超前设计，没必要，也没那个时间。
创建时间&修改时间
创建时间和修改时间还是要有的，而且建议时间精确到毫秒级别，在上一篇，我没有说精确多少，那是因为并发不高，秒级完全够了。但是在大数据量的情况下，可能一秒有几十、几百、上千、上万的数据新增都是有可能的。那么秒级在这种情况下完全就不够看了，选择毫秒级别是一个比较好的选择。
分库分表
前面的唯一标识/