昨天，小伙伴们在群里就分库分表方案展开了激烈的讨论，这里我对讨论的结果做了一个总结和补充，希望对各位有所帮助。本文的结论与许多网上观点存在分歧，如果你持不同意见，那以你的为准。

1. 为什么要分库分表
很多文章告诉你，当单表数据达到1000万左右就需要考虑分库分表，实际上但凡用单表记录数去评估是否需要进行分库分表，都是错的。衡量是否需要进行分库分表的标准有且仅有：容量。  这里的容量是指存储容量，性能容量。容量不是瓶颈非要去做分库分表设计，那就是脱裤子放屁，多此一举。当达到性能瓶颈并且核心业务系统才需要精心设计的分库分表方案，即通过分布式架构解决传统单一 Oracle 数据库的瓶颈。

这一结论在星球有专门文章进行详细说明，可参考此文：https://articles.zsxq.com/id_nopqqnz7xpb5.html

2.  如何选定分片键
分布式数据库架构设计的原则是：选择一个适合的分片键和分片算法，把数据打散，并且业务的绝大部分查询都是根据分片键进行访问。对于互联网业务，大多数是To C业务，分片键通常是用户的ID。业务的大多数访问都是基于用户ID进行查询，例如：
.查看某个用户下的微博/短视频；
.查看某个用户的商品信息/购买记录；

.查看某个用户自己的余额信息。

对于其他场景，需要根据具体业务情况进行深入分析。在海量高并发的业务场景中，分片键不仅仅是用于将数据打散，更是实现数据单元化的关键。毫不夸张的说分片键的好坏决定了你分库分表架构方案的好坏。

3. 分库分表后如何方便扩缩容
关于扩缩容，这实际上是一个伪命题，因为数据迁移成本是相当大的，不会有所谓的“方便”。有一个前提原则：如果已经确定要实施分库分表，那么一开始就要预估业务10年的数据量，不要幻想着等业务数据量变大再进行数据迁移，这是得不偿失的。

分布式数据库并不一定要求有很多个实例，最基本的要求是将数据进行打散分片。然后，用户可以根据需要进行扩缩容，以实现数据库性能和容量的伸缩性。这才是分布式数据库真正的吸引之处。

4. 分库分表以后如何对于非Sharding key进行查询
技术是为业务服务的，有时业务也需要妥协于技术，这在这种情况下非常适用。在分库分表后，对非Sharding Key的查询会对所有分片进行查询并合并，效率非常慢。在系统开发时务必避免这种情况，开发负责人和DBA必须严格把关，并提前对SQL进行审核预警。（据我所知，阿里是改写了数据库底层逻辑，对于非Sharding Key的查询直接拒绝。

在不直接使用SQL语句的前提下，要做到非Sharding key的查询，常用的有三种方案：
冗余数据法: （按照另外的维度再做一个分片方案，不推荐使用）
索引法表: （插入数据时维护一张单独的索引表）
基因法: （将分片键的信息保存在想要查询的列中）
这三种方案同样在分库分表专栏有详细的说明并配有相应代码，详见 https://articles.zsxq.com/id_q8z8wdjwsmb8.html

5. 分库分表真的会退出历史舞台吗?
最近有不少文章传播一种观点，声称分库分表将被淘汰，而OceanBase才是未来的主流。实际上，这种说法只是为了引起关注，是OceanBase的一种宣传手段。真正了解情况的人应该不会轻信这种言论。上个月参加了阿里的技术交流，目前OceanBase也只在蚂蚁有大规模使用，淘宝系依然还是使用精心设计的分库分表方案。

事实上，OceanBase也是基于分区实现的，数据查询时也需要根据SQL解析结果路由到对应的分区，如果没有命中分区也会退化成全表扫描。对于关键的业务数据场景，仍然需要实施精细化的分库分表方案，至少在5年内不会退出历史舞台，各位还是需要深入理解并掌握 !

以上，这就是我们最终的讨论结果，你们有何看法呢？欢迎留言交流~