mysql+join+分库分表_MySQL分库分表篇

传统项⽬结构

数据库性能瓶颈：

1、数据库连接数有限

MySQL数据库默认100个连接、单机最⼤1500连接。

2、表数据量

1)表数量多，成百上千

2)单表数据，千万级别

3)索引，命中率问题，索引存磁盘，占空间

3、硬件问题

性能指标：单表QPS、TPS

数据库性能优化

1、参数优化

2、缓存、索引

3、读写分离

4、分库分表

分库分表介绍

使⽤背景

当【表的数量】达到了⼏百上千张表时，众多的业务模块都访问这个数据库，压⼒会⽐较⼤，考虑对其进⾏分库。

当【表的数据】达到了⼏千万级别，在做很多操作都⽐较吃⼒,所以，考虑对其进⾏分库或者分表

数据切分(sharding)⽅案

数据的切分(Sharding)根据其切分规则的类型，可以分为两种切分模式：

垂直切分：按照业务模块进⾏切分，将不同模块的表切分到不同的数据库中。

⽔平切分：将⼀张⼤表按照⼀定的切分规则，按照⾏切分成不同的表或者切分到不同的库中。

⽔平切分规则

常⽤的切分规则有以下⼏种：

按照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