MySQL如何分库分表

数据库分库分表估计不少伙伴都没有实践过，就是由于本身公司的业务不是不少，没有那么多数据。假若有一天项目的人数上来了，你写的系统支撑不住了，但愿这篇文章带给你一丝丝的思路。”

前言

在面试过程当中你是否是会常常遇到对于数据库分库分表你有什么方案啊！

在平时看博客时你是否是也常常刷到MySQL如何分库分表。

然而你是否是点进去看了不到10秒就直接退出窗口。

那是由于写的文章不是什么水平切分，就是垂直切割，在一个自身所在的公司根本使用不到。

若是你只知道分库分表可是不知道怎么弄的话，花个五分钟看完你会收获到不同的思路。

1、初始架构

公司的规模小，项目针对的用户群体属于小众。日活就几千、几万的用户这样的数据天天的数据库单表增长通常不会超过10万。并发更不沾边了。

这种项目规模，咱们就是认真、快速开发业务逻辑，提高用户体验，从而提高项目的用户粘度并达到收纳更多用户的准备。

这个时候咱们项目一台16核32G的服务器就彻底能够了，能够将数据库单独放一个服务器，也能够都放在一个服务器。

这个时候项目架构图是这个样子的。

2、用户开始激增解决方案

在经历了第一阶段后，因为项目的用户体验度极高，项目又吸引了大量的用户。

这时咱们项目日活达到了百万级别，注册用户也超过了千万。这个数据是根据以前公司项目数据推算的。

这时天天单表数据新增达到了100万，并发请求每秒也达到了上万。这时单系统就扛不住了。

假设天天就固定新增100万，每个月就是3000万 ，一年就是接近5亿数据。

数据库以这种速度运行下去，数据到2000W到3000W还能勉强撑住，可是你会发现数据库日志会出现愈来愈多的慢查询。

虽然说并发1W，可是咱们能够部署个10台机器或者20台机器，平均每台机器承担500到1000的请求，仍是绰绰有余的。

可是数据库方面仍是用一台服务器支撑着每秒上万的请求，那么你将会遇到如下问题。

• 数据库所在的服务器磁盘IO、网络带宽、CPU负载、内存消耗都会很是高

• 单表数据已经很大，SQL性能已经已经出现下坡阶段，加上数据库服务器负载过高致使性能降低，会直接致使SQL性能更差

• 这个时候最明显的感受，就是用户获取一个数据可能须要10s以上的时间才会返回。

• 若是前期服务器配置不是很高的话，你就会面临数据库宕机的状况

那么这个时候咱们要怎么对项目进行架构的优化呢！

根据大佬们的经验是数据库的链接数每秒控制在2000便可、那么咱们1W并发的状况下部署5台机器，每台机器都部署一个一样结构的数据库。

此时在5台数据库拥有一样的数据库。表名规则能够这样设置。

这时每一个project库都有一个相同的表，好比db_project1有tb_play_recode一、db_project2有tb_play_recode2......

这样就实现了一个基本的分库分表的思路，从原来一台数据库服务器变成了5台数据库服务器，从原来一个库变成了5个库，原来的一张表变成了5张表。

这时咱们就须要借助数据库中间件来完成写数据，例如mycat。

这个时候就须要使用播放记录表的自增ID进行取模5，好比天天播放记录新增100W数据。此时20W数据会落到db_project1的db_play_recode1，其它的四个库分别也会落入20W数据。

查询数据时就根据播放记录的自增ID进行取模5，就能够去对应的数据库，从对应的表里查询数据便可。

实现了这个架构后，咱们在来分析一下。

原来播放记录就一张表，如今变成了5张表，那么每一个表就变成了1/5

按照原项目的推算，一年若有1亿数据，每张表就只有2000w数据。

按照天天新增50W数据，每张表天天新增10W数据，这样是否是就初步缓解了单表数据量过大影响系统性能问题了。

另外每秒1W的请求，这时每台服务器平均就2000，瞬间就把并发请求下降到了安全范围了。

3、保证查询性能

在上边的数据库架构会遇到一个问题，就是单表数据量仍是很大，按照每一年1亿的数据，单表就会有2000W数据，仍是太大了。

好比能够将播放记录表拆分为100张表，而后分散到5台数据库服务器，这时单表的数据就只有100W，那查询起来还不是洒洒水的啦！

在写数据时就须要通过俩次路由，先对播放记录ID取模数据库数量，这时能够路由到一台数据库上，而后再对那台数据库上的表数量进行取模，最终就会路由到数据上的一个表里了。

经过这个步骤就可让每一个表的数据都很是少，按照100张表，1亿数据，落到每一个表的数据就只有100W。

这时的系统架构是这个样子的。

4、配置读写分离来按需扩容

以上的架构总体效果已经很不错了，假设上边分了100张表仍是不知足需求，能够经过用户增量计算来配置合理的表。同时还能够保证单表内的SQL执行效率。

这时还会遇到一个问题，假如每台服务器承载每秒2000的请求，其中就400是写入，1600是查询。

也就是说，增删改查中增删改的SQL才占到了20%的比例，80%的请求都是查询。

安装以前的推理，如今全部数据进行翻倍计算，每台服务器并发达到了4000请求了。

那么其中800请求是写入，3200请求是查询，若是说安装目前的状况来扩容，就只须要增长一台数据库服务器便可。可是就会涉及到表的迁移，由于须要迁移一部分表到新的数据库上，那是很麻烦的事情了。

其实没有这个必要的，可使用读写分离来解决这个问题，也就是主从复制。

写的时候走主库，读数据时走从库，这样就可让一个表的读写请求分开落到不一样的数据库上去执行。

这样的设计后，咱们在推算一下，假如写入主库的请求是400/s ,查询从库的请求是就是1800/s，只须要在主库下配置俩台从库便可。

这时的架构是以下的。

实际的生产环境，读请求的增加速度远远高于写的请求，因此读写分离以后，大部分就是扩容从库支撑更高的读请求就能够了。

并且另一个点，对同一个表，若是既写数据，还读数据，可能会牵扯到锁冲突问题，不管读仍是写性能都会有影响。

因此一旦读写分离以后，对主库的表就仅仅是写入，没任何查询会影响主库。对从库就仅仅是查询了。

5、并发数据库结构总结

关于并发场景下，数据库层面的架构是须要进行精心的设计的。

而且在配置主复制时，也会有不少的问题来等着去解决。

本文就是从一个大的角度来梳理一个思路给你们，能够根据本身公司的业务和项目来考虑本身的系统如何分库分表。

分库分表的落地须要借助mycat或者其余数据库中间件来实现。

---

更多学习内容能够访问【对标大厂】精品PHP架构师教程目录大全，只要你能看完保证薪资上升一个台阶（持续更新）

以上内容但愿帮助到你们，不少PHPer在进阶的时候总会遇到一些问题和瓶颈，业务代码写多了没有方向感，不知道该从那里入手去提高，对此我整理了一些资料，包括但不限于：分布式架构、高可扩展、高性能、高并发、服务器性能调优、TP6，laravel，YII2，Redis，Swoole、Swoft、Kafka、Mysql优化、shell脚本、Docker、微服务、Nginx等多个知识点高级进阶干货须要的能够免费分享给你们，须要的能够点击连接获取进阶PHP月薪30k>>>架构师成长路线【视频、面试文档免费获取】