目录
介绍
在如今人人都参与互联网的年代，对于数据的存储来说，所面临的挑战也是越来越大。尤其对传统的关系型数据库 比如Mysql、Oracle来说，当数据越来越多，所面临的存储容量和执行效率也越来越慢的问题也越来越需要考虑。即使加的索引非常的合理，但随着表的量级越来越大，索引的容量也越来越大，效率始终还是下降。
为了应对这种问题，如今主流的方案有分布式数据库和分库分表两种方案存在
分布式数据库的优点是上手简单，和正常的数据库用法相同，无需考虑分库分表、分片键、分片算法的问题，但目前的分布式数据对服务器的性能要求比较高，对于预算紧张的公司来说，不太适合。另外目前来说 分布式数据库的稳定性还不是如传统的Mysql、Oracle。
另一种就是常说的分库分表，其实分库分表是由 分库 和 分表 这两个独立概念组成的，只不过通常分库与分表的操作会同时进行，以至于我们习惯性的将它们合在一起叫做 分库分表。
为什么分库
第一个就是连接数的问题，虽然现在服务连接数据库都使用了数据源这种池化的缓存方案，但每个数据库的连接数始终是有上限的，当并发量突增，很快就会将数据库的连接全部用掉，其他的请求就会失败
第二个就是容量的问题，每台机器给数据库分配的磁盘容量是有限的，随着数据量的增加，依旧存在容量会被占满的问题
为什么分表
对于表来说，最需要考虑的问题就是sql的执行效率，导致sql执行效率慢的原因有很多，没命中索引、like 扫全表、用了函数计算等等。这些在数据量不大的时候以及用上索引问题都不是很大，但一旦表中的数据量很大的话，假如是一亿数据量，就算用上索引效率也不是很高，原因是InnoDB 存储引擎，聚簇索引结构的 B+树的层级变高，磁盘 IO 变多查询性能变慢。
索引的计算
首先，InnoDB存 储引擎最小储存单元是页，一页大小是 16k，B+树的叶子节点存的是每行完整的数据，非叶子节点存的是键值和指针。
索引查找的过程
- 利用二分查找法在非叶子节点中查找，最终落到叶子节点，也就是落到页中
- 进而去页中找到需要查找的数据
计算
-
假设表中每行的记录数据大小是
1k，则每个叶子节点能存储的记录数为；16K / 1K = 16 -
主键使用
bigint类型，长度为8字节，指针的大小在InnoDB中占用6字节，所以一共是 14字节。则每个非叶子节点的记录数为
我们假设这颗B+树的高度为3，那么这棵B+树的存放总记录数 = 根非叶子节点保存记录数 * 根节点下每个记录数的非叶子节点记录数 * 单个叶子节点记录行数
将数据代理计算：1170 * 1170 * 16 = 21902400 ，也就是说在表中每行记录大小为1k的情况下，高度为 3 的B+树所存储的记录大概为 2千万 左右。
所以分表要根据表的记录和每行记录的大小来解决是否分表。在Alibaba的开发规范手册中给出了建议：
单表行数超 500 万行或者单表容量超过 2GB，推荐分库分表
垂直拆分
垂直分库
在开始规模比较小的单体项目来说，所有的业务都是放在同一个数据库中，比如产品、订单、用户、支付都是在同一个库中，但随着项目越来越庞大，数据量也越来越大，就需要按照不同的业务来拆分成多个库
垂直分表
垂直分表适用于字段非常多的表，对于很多的查询来说，其实不需要一次将所有的字段全都查询出来，这样很浪费性能，影响效率，那么就将经常查询的字段单独拆分出一个表，将另外的字段单独拆分成另一个表，拆分后的表通过某个字段关联起来，这样既可以减少表的容量大小，又可以提升查询效率
水平拆分
水平分库
水平分库是把同一个表按一定规则拆分到不同的数据库中，每个库可以位于不同的服务器上，每个数据库的库和表结构都是相同的，只有表中的数据不同。可以实现水平扩展，有效缓解单裤的性能瓶颈
水平分表
水平分表是在同一个数据库内，对大表进行水平拆分，分割成多个表结构相同的表
支持的中间件
目前对分库分表支持的中间件比较多，但在社区热度和发展规模以及使用的程序来看，能用的差不多有 ShardingSphere 和 Mycat
如果在这两者中进行选型的话，无论在使用和完善以及热度上， ShardingSphere 可以说是降维打击 Mycat 了
🌸🌸🌸 完结撒花 🌸🌸🌸
博主WX：g2279605572 欢迎大家与我交流！
扫一扫
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
