背景
很多时候业务架构设计里面最重要的一环就是数据库模型设计, 由于单机MySQL 的限制, 很多业务架构师不得不考虑对大表进行拆分, 通过中间件或者其他手段进行分库分表.
很多业务在快速发展阶段，开始考虑数据拆分的原因其实并不是计算能力遇到了瓶颈，而是海量数据的存储到达了单实例的上限，但是由于最初设计的时候没有考虑到海量数据的使用方式，或是在业务逻辑中，数据无法进行清理或归档。
运维团队要对业务的稳定性负责，随着数据量还是每天上涨，不得不开始考虑数据拆分的问题，由于分库分表的兼容性问题需要业务修改业务的代码, 需要按照分库分表的形式重写SQL，这就要所有开发团队投入到架构改造。但业务团队更多的考虑业务的发展，这个时候是没有精力做这些事情的, 那么拆分只能无限推迟到不得不做的那天，这期间整体系统的稳定性一直运行在风险之下。
当然, 有一些老的DBA 还记得在很早的时候, 坊间流传的是在MySQL里面单表不要超过500万行，其实规定是有其历史背景的。资源方面来说早期服务器IO能力都比较低，单表过大会增加Btree 的高度，导致IO问题；同时磁盘容量也比较低，要考虑到存储上限以及备份空间的问题；运维层面来说旧版本的MySQL（5.5以前）基本不支持online ddl，大表运维时可能导致业务异常。
现在无论是软件还是硬件都有非常显著的提高, 在PolarDB体系中，上述问题已经基本得到解决。目前PolarDB相对MySQL来说，大表已经不再是问题，目前公共云上客户的生产系统表最大已经有几十T的容量，业务都在平稳运行。
那么PolarDB 是如何解决大表场景下PolarDB 遇到的一系列问题呢?
接下来我们有一系列的文章介绍PolarDB 大表场景性能优化.
1 PolarDB 大表插入性能优化 https://yuque.antfin.com/nituizi/pl8ggd/wt4bosugqrnh8pu8?singleDoc# 《PolarDB 大表插入性能优化》
2 PolarDB 大表分页查询优化 https://yuque.alibaba-inc.com/nituizi/lwvag7/lfogogd9ut1vhhrl?singleDoc# 《PolarDB大表分页查询优化》
3 PolarDB 大表DDL 性能优化 https://yuque.antfin.com/nituizi/pl8ggd/bialt83ew8ggpfhm?singleDoc# 《PolarDB 大表DDL优化》
