MySql分库分表

1.mysql问题

IO问题:

磁盘读IO瓶颈:热点数据太多,数据库缓存放不下 -> 分库和垂直分表

网络IO瓶颈:请求数据太多,网络带宽不够 -> 分库

cpu问题:

SQL问题:SQL中包含join group by order by 非索引字段查询,增加cpu运算的操作->SQL优化

单表数据量太大,SQL效率低,cpu先出现瓶颈->水平分表


2.分库和分表操作

水平分库:

以字段为依据,按照一定策略(hash、range等),将一个库中的数据拆分到多个库中。

  特点:每个库结构相同,数据不同,没有交集。

系统绝对并发量上来了,分表难以根本上解决问题,并且还没有明显的业务归属来垂直分库。

分析:库多了,io和cpu的压力自然可以成倍缓解。

水平分表:

以字段为依据,按照一定策略(hash、range),将一个表中的数据拆分到多个表中。

 特点:表结构相同,数据不同,没有交集。

系统绝对并发量并没有上来,只是单表的数据量太多,影响了SQL效率,加重了CPU负担,以至于成为瓶颈。

分析:表的数据量少了,单次SQL执行效率高,自然减轻了CPU的负担。

垂直分库:

以表为依据,按照业务归属不同,将不同的表拆分到不同的库中

每个库的结构不一样,数据不同,没有交集

分析:随着业务的发展孵化出了一套业务模式,这时可以将相关的表拆到单独的库中,甚至可以服务化。

垂直分表:

操作数据库中某张表,把这张表中一部分字段数据存到一张新表里面,再把这张表另一 部分字段数据存到另外一张表里面 。

以字段为依据,按照字段的活跃性,将表中字段拆分到不同的表(主表和扩展表)中。

表的结构不同,数据不同

分析:不能使用join,因为join不仅会增加CPU负担并且会讲两个表耦合在一起(必须在一个数据库实例上)。关联数据,应该在业务Service层,分别获取主表和扩展表数据然后用关联字段关联得到全部数据。

端上除了partition key只有一个非partition key作为条件查询

  1. 端上除了partition key只有一个非partition key作为条件查询映射法
    基因法注:写入时,基因法生成user_id,如图。关于xbit基因,例如要分8张表,2 3=8,故x取3,即3bit基因。根据user_id查询时可直接取模路由到对应的分库或分表。根据user_name查询时,先通过user_name_code生成函数生成user_name_code再对其取模路由到对应的分库或分表。id生成常用 snowflake算法。
  2. 端上除了partition key不止一个非partition key作为条件查询映射法
    冗余法注:按照order_id或buyer_id查询时路由到db_o_buyer库中,按照seller_id查询时路由到db_o_seller库中。感觉有点本末倒置!有其他好的办法吗?改变技术栈呢?
  3. 后台除了partition key还有各种非partition key组合条件查询NoSQL法
    冗余法

扩容问题:

  1. 水平扩容库(升级从库法)注:扩容是成倍的。
  2. 水平扩容表(双写迁移法)
    第一步:(同步双写)应用配置双写,部署;第二步:(同步双写)将老库中的老数据复制到新库中;第三步:(同步双写)以老库为准校对新库中的老数据;第四步:(同步双写)应用去掉双写,部署;

注: 双写是通用方案。

  • 0
    点赞
  • 1
    收藏
    觉得还不错? 一键收藏
  • 0
    评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值