Mysql架构演变之分表分库_分表表结构变化了

究竟是分库还是分表？

究竟是分库还是分表，首先要有个概念，就是当业务发展到一定量级之后，一般是需要先垂直分库的，再垂直分表，再进行水平分库，如果首先进行了水平分库，数据就被分散到了各个库中，后续再分就非常麻烦；所以需要对系统的实际场景进行调研，看能达到一个什么量级，看系统是否会达到哪些瓶颈，再确定分库分表方式。

数据库有哪些瓶颈？

IO瓶颈

• 1.磁盘读IO瓶颈，热点数据太多，数据库缓存放不下，每次查询时会产生大量的IO，降低查询速度
  解决方法：分库和垂直分表
• 2.网络IO瓶颈，请求的数据太多，网络带宽不够
  解决方法：分库

CPU瓶颈

• 1.单表数据量太大，查询时扫描的行太多，SQL效率低，增加CPU运算的操作
  解决方法：水平分库或水平分表
• 2.SQL问题，如SQL中包含join，group by，order by，非索引字段条件查询等，增加CPU运算的操作
  解决方法：优化SQL，增加或优化索引，把该这些场景剥离出来在应用层进行关联或计算。

垂直分库

概念：

以表来划分，按照业务场景的不同，将不同的表拆分到不同的库中。

场景：

当写负载达到瓶颈时，只能进行分库，高并发场景下，垂直分库一定程度的提升IO、数据库连接数、降低单机硬件资源的瓶颈，但是不能有效解决单表数据量过大而造成的CUP瓶颈问题，还需要对此业务进一步水平分库或水平分表。

举例：

在电商网站中，有浏览商品、下单、积分兑换等操作，按照业务可垂直分拆为商品库、定单库、积分库。这样拆分后整个业务就更加清晰了，如果再对应用进行拆分就是微服务化了，后面商品库数据量过大，再进行水平分库也更简单一些了。

总结：

1. 每个库的结构都不一样。
2. 每个表的数据也不一样，没有交集。
3. 所有库的并集是全量数据。
4. 注意：拆分后，跨库事务跟join性能都难以保证，jion关联查询可查出数据后，在应用层用关联字段得到对应数据来解决，跨库事务则要尽量避免出现，避免不了需先想好夸库事务的解决方案。

水平分库

概念：

水平分库，根据分库策略（哈希法和分段法等），将一个库中的数据拆分到不同的库中。

场景：

从业务的角度来看，当不能再对系统以业务进行垂直切分时，同时整个库数据量极大或单表数据量极大，存在IO或CPU瓶颈，这时就需要进行水平分库了，库多了，io和cpu的压力自然可以成倍缓解。

举例：

有一个订单库，数据量有1亿，查询时很慢，IO和CPU性能问题严重，以一定规则策略分到10个库中，分完后每个库只有1000万，这时查询效率提高明显，io和cpu的压力明显降低。

总结：

1. 每个库的结构都一样。
2. 每个表的数据也不一样，没有交集。
3. 所有库的并集是全量数据。
4. 拆分时还需考虑到数据量持续增长，后续再进行分库扩展问题，以及热点数据问题。

垂直分表

概念：

在同一个数据库中，以字段来划分，按照业务需求（是否主要字段、是否热点字段等），将一个表的字段拆分到多个表中。

场景：

适用于系统中并发量不高，当前表的记录数不多，但是查询频率很高，字段很多，单行数据所需存储空间较大。需要注意的是，垂直分表后所有的分表都在同一个数据库实例中，所以并不能减小单库的IO压力。

举例：

在电商网站中，有商品列表页和详情页，垂直分表拆分时，可以把商品表拆分为商品列表表（热点数据字段，列表中的字段也是查询频率最高的数据字段）和商品详情表，这是按照页面所需数据划分的，能保证商品列表页以最快的速率查出，如果网站流量比较大，其实商品详情页面压力也比较大，所以还可以把商品详情表进一步拆分，拆分为商品简介表和商品参数表等，这是在一个页面中按功能来划分，进入详情页会查询商品简介表，点击参数才会查商品参数表。拆分原则是将热点数据按照业务模块、业务页面、业务功能来拆分。拆了之后，要想获得全部数据就需要关联表来取数据。

总结：

1. 每个表的结构都不一样，每个表存储原表的一部分字段。
2. 每个表的数据也不一样，一般每个表的字段至少有一列交集，一般是主键，用于关联数据。
3. 所有表的并集是全量数据。
4. 拆分后的表的数据都在一个数据库实例上，如果数据库压力还很大，则需要考虑再进行分库操作。如果资金充足，建议查出后在应用层用关联字段关联得到全部数据，尽量少用jion，应用的扩展比数据库的扩展简单，并且风险远低于对数据库的架构变动。

水平分表

概念：

在同一个数据库中，以字段来划分，按照分表策略（哈希法和分段法等），将一个表中的数据拆分到多个表中。

场景：

适用于系统中并发量不高，单表的数据量太多，SQL查询效率很低，这种查询增大了CPU开销，CPU性能成了瓶颈。需要注意的是，水平分表后所有的分表数据都在同一个数据库实例中，该方式能增加查询性能，但是单库还会是存在IO瓶颈。

举例：

有一个订单表，数据量有1000万，查询时很慢，性能问题严重，使用水平分表可以把该表的数据，以一定规则策略分到10个表中，分完后每个表只有100万，这时查询效率提高明显，性能压力减小不少，这样就能满足系统需求了。分表时还需考虑到数据量持续增长，后续再进行分库扩展问题，以及热点数据问题。

总结：

1. 每个表的结构一样。
2. 每个表的数据不一样，查询时需要根据规则确定查哪张表。
3. 所有表的并集是全量数据。
4. 拆分后的表的数据都在一个数据库实例上，在使用该方式前需要认真进行调研，看是否能满足系统需求，是否能满足持续增长的业务需求，如果业务并发量比较稳定，增长不大，可以使用该方式；如果使用该方式进行水平分表后，单库不能满足需求了，后续再分库会很麻烦；所以在使用该水平分表前需要考虑清楚到底是分表还是分库。