分库分表汇总

<?php
    1、IO瓶颈   2、CPU瓶颈

示例1：
  https://xuliugencn.blog.csdn.net/article/details/82836694
  随着公司业务增长，如果每天1000多万笔订单的话，3个月将有约10亿的订单量，之前数据库采用单库单表的形式已经不满足于业务需求，数据库改造迫在眉睫。
  订单数据如何划分：
  1.将订单数据划分成两大类型：分别是热数据和冷数据。
    热数据：3个月内的订单数据，查询实时性较高;

    冷数据A：3个月 ~ 12个月前的订单数据，查询频率不高;

    冷数据B：1年前的订单数据，几乎不会查询，只有偶尔的查询需求;

    可能这里有个疑惑为什么要将冷数据分成两类，因为根据实际场景需求，用户基本不会去查看1年前的数据，如果将这部分数据还存储在db中，那么成本会非常高，而且也不便于维护。另外如果真遇到有个别用户需要查看1年前的订单信息，可以让用户走离线数据查看。

 2.对于这三类数据的存储，目前规划如下：

    热数据： 使用mysql进行存储，当然需要分库分表；

    冷数据A: 对于这类数据可以存储在ES中，利用搜索引擎的特性基本上也可以做到比较快的查询；

    冷数据B: 对于这类不经常查询的数据，可以存放到Hive中

 3.将不同的业务放到不同的库中，将原来所有压力由同一个库中分散到不同的库中，提升了系统的吞吐量。

 4.因为分表的实质还是在一个数据库上进行的操作，很容易受数据库IO性能的限制。



示例2：
  https://blog.csdn.net/Dinosaur_1117/article/details/89839745
 日均5亿查询量的京东到家订单中心，为什么舍MySQL用ES?

示例3：
https://blog.csdn.net/weixin_34010949/article/details/94212809
 方案一、按照订单号来做hash分散订单数据

 方案二、按照用户id打散订单数据。

 示例4:
     https://blog.csdn.net/ftcool/article/details/108480754

    利用MyCat，KingShard这种代理中间件分库分表。好处是和业务代码耦合度很低，只需做一些配置即可，接入成本低。缺点是这种代理中间件需要单独部署，所以从调用连路上又多了一层。而且分库分表逻辑完全由代理中间件管理，对于程序员完全是黑盒，一旦代理本身出问题（比如出错或宕机），会导致无法查询和存储相关业务数据，引发灾难性的后果。如果不熟悉代理中间件源码，排查问题会非常困难。曾经有公司使用MyCat，线上发生故障后，被迫修改方案，三天三夜才恢复系统。CTO也废了！

    利用Sharding-Jdbc，TSharding等以Jar包形式呈现的轻量级组件分库分表。缺点是，会有一定的代码开发工作量，对业务有一些侵入性。好处是对程序员透明，程序员对分库分表逻辑的把控会更强，一旦发生故障，排查问题会比较容易

示例5：
    https://hollis.blog.csdn.net/article/details/121091988

    分库：是为了解决数据库连接资源不足问题，和磁盘IO的性能瓶颈问题

    分表：是为了解决单表数据量太大，sql语句查询数据时，即使走了索引也非常耗时问题。此外还可以解决消耗cpu资源问题

    分库分表：可以解决 数据库连接资源不足、磁盘IO的性能瓶颈、检索数据耗时 和 消耗cpu资源等问题