MySQL分庫分表篇

傳統項⽬結構

數據庫性能瓶頸：
一、數據庫鏈接數有限
MySQL數據庫默認100個鏈接、單機最⼤1500鏈接。
二、表數據量
1)表數量多，成百上千
2)單表數據，千萬級別
3)索引，命中率問題，索引存磁盤，佔空間
三、硬件問題
性能指標：單表QPS、TPS
數據庫性能優化
一、參數優化
二、緩存、索引
三、讀寫分離
四、分庫分表

分庫分表介紹

使⽤背景
當【表的數量】達到了⼏百上千張表時，衆多的業務模塊都訪問這個數據庫，壓⼒會⽐較⼤，考慮對其進⾏分庫。
當【表的數據】達到了⼏千萬級別，在作不少操做都⽐較吃⼒,因此，考慮對其進⾏分庫或者分表

數據切分（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