登录
首页 >  数据库 >  MySQL

MySQL分库分表篇

来源:SegmentFault

时间:2023-02-24 15:12:46 290浏览 收藏

大家好,今天本人给大家带来文章《MySQL分库分表篇》,文中内容主要涉及到MySQL、分库分表,如果你对数据库方面的知识点感兴趣,那就请各位朋友继续看下去吧~希望能真正帮到你们,谢谢!

传统项⽬结构

image.png

数据库性能瓶颈:
1、数据库连接数有限
MySQL数据库默认100个连接、单机最⼤1500连接。
2、表数据量
1)表数量多,成百上千
2)单表数据,千万级别
3)索引,命中率问题,索引存磁盘,占空间
3、硬件问题
性能指标:单表QPS、TPS
数据库性能优化
1、参数优化
2、缓存、索引
3、读写分离
4、分库分表

分库分表介绍

使⽤背景
当【表的数量】达到了⼏百上千张表时,众多的业务模块都访问这个数据库,压⼒会⽐较⼤,考虑对其进⾏分库。
当【表的数据】达到了⼏千万级别,在做很多操作都⽐较吃⼒,所以,考虑对其进⾏分库或者分表

数据切分(sharding)⽅案
数据的切分(Sharding)根据其切分规则的类型,可以分为两种切分模式:
垂直切分:按照业务模块进⾏切分,将不同模块的表切分到不同的数据库中。
⽔平切分:将⼀张⼤表按照⼀定的切分规则,按照⾏切分成不同的表或者切分到不同的库中。

image.png

⽔平切分规则
常⽤的切分规则有以下⼏种:
按照ID取模:对ID进⾏取模,余数决定该⾏数据切分到哪个表或者库中
按照⽇期:按照年⽉⽇,将数据切分到不同的表或者库中
按照范围:可以对某⼀列按照范围进⾏切分,不同的范围切分到不同的表或者数据库中。

切分原则
第⼀原则:能不切分尽量不要切分。
第⼆原则:如果要切分⼀定要选择合适的切分规则,提前规划好。
第三原则:数据切分尽量通过数据冗余或表分组(Table Group)来降低跨库 Join 的可能。
第四原则:由于数据库中间件对数据 Join 实现的优劣难以把握,⽽且实现⾼性能难度极⼤,业务读取尽量少使⽤多表 Join。

分库分表需要解决的问题
分布式事务问题
本地事务:ACID
分布式事务:根据百度百科的定义,CAP定理⼜称CAP原则,指的是在⼀个分布式系统中,Consistency(⼀致性)、 Availability(可⽤性)、Partition tolerance(分区容错性)。⼀致性是强⼀致性。CAP理论最多只能同时满⾜两个。
BASE:基本可⽤+软状态+最终⼀致性
强⼀致性事务(同步)
最终⼀致性事务(异步思想) 利⽤记录⽇志等⽅式

分布式主键ID问题
redis incr命令
数据库(⽣成主键)
UUID
snowflflake算法(https://www.sohu.com/a/232008315_453160)

跨库join问题
通过业务分析,将不同库的join查询拆分成多个select
建⽴全局表(每个库都有⼀个相同的表)
冗余字段(不符合数据库三范式)
E-R分⽚(将有ER关系的记录都存储到⼀个库中)
最多⽀持跨两张表跨库的join

跨库count、order by、group by问题

分库分表实现技术
阿⾥的TDDL、Cobar
基于阿⾥Cobar开发的Mycat
当当⽹的sharding-jdbc

今天关于《MySQL分库分表篇》的内容就介绍到这里了,是不是学起来一目了然!想要了解更多关于mysql的内容请关注golang学习网公众号!

声明:本文转载于:SegmentFault 如有侵犯,请联系study_golang@163.com删除
相关阅读
更多>
最新阅读
更多>
课程推荐
更多>
评论列表