文章目录
早期都是单库单表
读多写少——主库用来写，从库用来读
主库写完了之后，同步到从数据库，通过从数据库分担压力
中小公司完全OK
单库的写压力太大——数据库的垂直和水平拆分
垂直拆分——比如微服务架构，根据不同业务我们拆分微服务应用，数据库的表也要按照业务分开。
水平拆分——虽然拆分成单表，如果一张表的量超过500万或1000万，数据的增量太快，这里假如到达4000万，就要把一张订单表拆成多张表。
垂直分库，水平分表
分表怎么分呢？
hash分表
hash分表的方式有个问题——假如分的四张表又快满了，还要再拆表，那总共八张表了，按照以前的**id%(表的个数)**的办法落在其他表中，以前的算法落得表和现在不一是同一个表了，查不到了，所以必须要把老数据做一次迁移。
数据迁移扩容痛苦
range分表
就是把数据按照范围顺序放，这样根据id算一下在什么范围，即使扩容了也可以找到。
当订单id在1000万以内，操作同一张表，如果并发特别大，压力特别大，那各种修改，新增，加大量的锁，性能肯定受影响。
这个问题就叫热点的问题
多数据源操作与分布式事务问题
其实市面上有很多很好的分库分表框架，直接用
ShardingSphare分库分表（京东开源）
非常轻量，
内部有很多的组件，Sharding-jdbc组件，其实就是帮我们做分库分表的，做好分库分表的配置文件，按照什么字段，什么规则配置好。
关联查询怎么办？跨多个库，多张表怎么办？——要考虑业务场景
从用户端思考，对于一个用户，我们尽量让他的数据落在一个库，一张表，这样查起来容易得多。用userId来分，这样插用户信息免费，那查订单呢？在orderId后面拼接上serId（后四位）
商家端：用商家的id作为分库分表的字段合适，上面的规则不适用了啊？查商家的订单就要跨库了呀，在互联网公司，商家端的数据会单独再存一份。按照商家端的id做路由分库分表。
运营管理端：要查全量数据，怎么办？
如果非实时的情况，可以把全量的数据放到数据仓库中（大数据），查的比较慢，可以走数据仓库；
如果要求实时的话（elasticsearch），一般需求是定好的，我们根据要查询的几个维度的字段，建立索引到ES的大宽表，这时候查起来就很快了。
线上单库如何迁移到多库多表
一般都是不停机迁移，但前段不断有新的增删改查操作来修改数据，我们的迁移是把数据复制过去，这时候要是来了一条修改已迁移的数据，怎么办？难道重头扫一遍吗？
监听binlog
数据库的binlog日志，
数据库有很多日志的，面试的时候很经常问。
binlog用来记录数据库的所有修改操作，
后端虽然在做全量的迁移，实时的增删改的操作，我们可以拿出来写进我们的新系统（多库多表），这样就同步了。
依旧有问题——临界的时候
insert一条语句，sql执行了一次，在迁移完成后，binlog在新数据库又执行了一次，会逐渐冲突（不过这个问题不大）。
update语句和delete语句问题大了。
假设update语句修改了单库单表，还没更新的时候，这时候被迁移查到了，准备写到多库多表，还没写成功的时候，这时候binlog更新了多库多表，查不到就更新为空，这时候老库的数据迁移过来了，实际写入多库多表的数据是旧数据。
delete同样在临界的时候会有问题。
过一段时间把binlog的执行失败的sql语句从新做一遍
binlog执行失败的sql丢到队列中去，过一段时间重新执行。
又有问题了——数据达到一致后，直接上线吗？——灰度发布
搞一小部分流量先打过来，看数据能不能进入到我们的多库多表，试探一下数据是不是正确，没问题了再全部上线。
灰度发布时间不能太长，否则会造成很多的报错，比如有个请求打到单库单表，而这个数据在多库多表中，这就报错啦。所以不能太长时间。
无损发布
就是把单库单表的数据断掉，直接把多库多表全流量切换上线。
这要是有问题的话，回退比较麻烦
所以一般采用的是灰度发布
既想要解决数据热点的问题，又想不做数据迁移
我们设计一套分库分表方案，并且解决热点问题？
TiDB 分布式数据库
这就不用做分库分表了，很多事情他帮我们做了。
后面就是卖课广告了