阿里内网吵爆了：用分库分表解决扩容问题，我坚决反对！
Posted 启舰杂谈
tags:
篇首语：本文由小常识网(cha138.com)小编为大家整理，主要介绍了阿里内网吵爆了：用分库分表解决扩容问题，我坚决反对！相关的知识，希望对你有一定的参考价值。
大多数公司都是从单体架构开始的，即便现在抗住双十一流量洪峰的淘宝，它最早用的也是LAMP（Linux+Apache+mysql+php）。
对于任何一个刚起步的项目来说，选择简单快速的方式来实现无可厚非。
一旦架构开始变得复杂往往是因为业务的体量越来越大，一旦用户量以及流量开始增加，服务器的性能就会受到挑战。
随着我们手里的数据越来越多，SQL 操作越来越慢，数据库就会成为瓶颈。这个时候我想你一定会想到分库分表，从而突破网络IO、硬件资源、连接数的限制等，然后胸有成竹地拍拍胸脯说：“只要我数据库能无限扩容不就万事大吉了！”
先别太兴奋，你需要想一想，分库分表可能带来的棘手问题，比如：
数据库连接过多，如果每个RPC都要连接所有的库，扩容则会导致连接数增加，需要考虑单元化；
事务一致性问题，解决方案包括2PC、3PC、TCC、消息事务、最大努力通知等；
跨库关联查询问题，我们可以考虑的方案包括全局表、字段冗余、系统层组装、ER表
翻页、排序、函数计算问题，需要先在不同的分片节点中将数据进行排序并返回，然后将不同分片返回的结果集进行汇总和再次排序，最终返回给用户。
全局主键避重问题，常见的主键生成策略包括UUID、结合数据库维护主键ID表、雪花算法Snowflake。
对于大部分程序员来说，MySQL用了很久，但依然会出现面对棘手问题束手无策的状况，大多是因为对数据库出现问题的情况和处理思路模糊不清。
玄姐联手快狗打车CTO沈剑、前58集团高级架构师陈东，结合10多年一线大厂实践经验，打磨了一套《3天挑战架构师级MySQL海量数据设计与实践》在线专栏课。手把手带你深入学习架构师级 MySQL，掌握核心架构技术，并在千亿级企业真实海量数据案例中（电商、微信等），培养你的 MySQL 实战能力。
以上是关于阿里内网吵爆了：用分库分表解决扩容问题，我坚决反对！的主要内容，如果未能解决你的问题，请参考以下文章