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