所谓武功再高也怕菜刀-分区、分库、分表和分布式的优劣

    我相信做过数据库对以上的都不陌生。基本上主流数据库都支持分区。分区是一种对应用透明的管理表方式。尽管可以在网上找不到不少黑MySQL分区的，但是时至今日我用MySQL分区没发现一点问题，当然PostgreSQL和Oracle的我也没发现问题。我猜测那些问题应该来自于使用上的不规范。我以前做公安系统由于单表几十亿上百亿，还采用过二级分区，效果非常好。

    分区一般使用都是按照时间，基本是按照月。比如我一个月一个分区，我有5年数据，那么就是60个分区。这个时候如果想把最早的一个月数据归档。我们可以采用交互分区等技术，秒导出。然后把这些数据迁移或者压缩，达到归档和给在线数据库瘦身的效果。如果没有分区会怎么样？苦啊，那只能按照条件逻辑导出了，这个效率低下。导出以后delete这些导出的数据，但是delete不释放空间呀，又要做碎片整理。好在部分数据库做起来也不影响业务。我有个数据以前有一个库Oracle。20多T，碎片有880G。RAID10的阵列，磁盘是15k转速的。直接在线做碎片整理，不影响业务的条件下做了55个小时。另外一个同事的阵列较差，他悲剧的做了550个小时（快一个月了）。可见分区是多么重要。而很多表设计的时候，由于缺乏设计和规划，没有建立成分区。那么就要将非分区的表转换成分区表。怎么转换我在之前的公众号写过了，感兴趣的可以往前翻几天。但是如果时间不是日期型，这就没办法了。可见设计是多么重要，设计糟糕的前提一下，一切优化都无能为力。

   分区不好的地方，比如分区到了最后一个月，忘记加新的分区就报错了。这点上Oracle做到了自动分区，永远不会出问题。这个特性的确避免了很多故障。不过drop分区的时候要带上update global index，不带也会出故障。哎，我一直想给官方提，咱们不能drop的时候隐性的带上吗？这样真的能避免故障。

  分区另外一个不好的地方就是，我分了60个月的区，结果你查询的时候不按照时间查，比如前后%，或者不带条件。那么等于还是查了60个月。假设这个表不分区是600G，分区以后总量还是600G。那么一个SQL查600G，该慢还是慢。分区的快是这的是在一个分区内查询会好一点点（不过我实测基本感知不到），也就是说你带上时间限定在一个分区中检索，不要跨分区。其实这个和不分区时候带上一个月的时间差不多的。所以分区最大的贡献我觉得还是生命周期管理。

   分库一般伴随着微服务和中台，原来单体运行挺好的。现在就开始拆，我在老白的一篇微服务数据库选型中看到，开发一时爽，运维两行泪。我真实感觉是，开发两行泪，运维两行泪。一旦分库数据交互要么靠接口要么靠同步。接口嘛，我接触的效率都不高，一定比不分库低。同步嘛，任何CDC使用成本都不低，一点没问题的没见过。只能说有的工具做的好，问题少。问题其实大多数也是使用不当造成的。按照一个维度分库以后，那么按照其他维度就无法查询了。和分区一样的道理。如果查所有等于跨所有节点。也和分区一样，该全部还是全部，加上网络更慢了。虽然MySQL和PG以及Oracle这三大主流数据库在门派上有纷争，但是对于分库是一致的看法就是不要分。

  分表必然涉及分库，分库不一定涉及分表。就是一个表分成N份，分散在N个节点上。每个节点上存储N分之一的数据。千万别相信水平扩展，至少我不信。1000万数据存100个节点。现在数据到2000万了，要增加100个节点怎么办？那是要200个节点数据重新打散。如果做过redis的cluster的就知道，reblance时候是卡主的。所以分表的再平衡要停机的。然后如果也来一个前后%，效果一样，分开全表扫。（当然这个并行扫能快N倍）

 分布式，我认为MySQL的MGR是分布式，Oracle的RAC也是。TiDB Oceanbase polardb TDSQL这些带上paxos和raft的都是。当超过单机能力时候，考虑分布式。那么如果在分布式上是不是可以胡来？比如前后%，答案是否定的。一样会把分布式搞死。

  总结：分区、分库、分表、分布式都怕不按照规范开发，比如全表。所谓武功再高也怕菜刀。分区和分布式可取。但凡做分布式的都是单机玩的好的，比如阿里、腾讯等。单机玩不好的，我绝对不相信能用好分布式。比如单刀都能划到自己的，双刀说不定是还没砍到人，自己已经血流了一地了。分库 分表，不可取，同样遇到前后%，就是雪上加霜。