mysql分庫分表策略

2021-10-22 22:50:36 字數 836 閱讀 4637

一、分表

1、垂直拆分:根據表的字段數量

2、水平拆分規則:根據特定欄位取模,範圍,hash

二、分庫

1、垂直拆分:根據業務拆分

訂單資料過多時可給訂單單獨建立資料庫

2、水平拆分: 垂直拆分後的資料庫根據規則進行水平拆分

如:訂單資料庫表的設計

不知道哪些查詢,拆分時可能規則不合理,會造成拆分後效能越來越低

查詢規則:

1、根據使用者查詢訂單

2、根據商家查詢訂單

拆分規則:

1、資料盡量平均拆分

2、事務邊界---sql的查詢資料量,盡量避免極端查詢(超過30%,50%就屬於比較多的查詢)

如果一條sql可以根據規則進行準確定位,查詢效果好。如果根據規則不能完全定位,

可能需要篩選一部分庫,根據庫,再根據規則篩選一部分表。篩選完錶後還需要進行資料的

篩選過濾,過濾的量越多意味著查詢的速率越慢 。牽扯到事務邊界,盡量避免極端查詢。

不能避免需要全表掃瞄的資料,如做統計之類的查詢,100%查詢。

統計整個平台訂單量,我們可以物化檢視,建立統計表,定期更新統計表資料,也同樣避免極端查詢(資料量多的查詢)

3、冷熱的業務查詢

三、多少資料量分表

5000w,索引的極限

理論500w或資料量5g可分表(分表後比較快)

實際1000w-2000w左右分表

不能超過5000w才分表,5000w是索引極限

時間根據ip和cpu實際判斷分表資料量

mysql分庫分表的常見策略

0mysql集群,將sql請求分發到多個資料庫去,減少sql執行的等到時間 l拆分大資料表位若干表,比如事先建立n張結構相同的表,表名可以按照某種業務hash進行對映。缺點是規則的變化帶來的影響 2利用merge儲存引擎來實現分表 create table if not exists user1 i...

mysql分表分庫實現 MySql分表分庫思路

一.資料庫瓶頸 1.1io瓶頸 第一種 磁碟讀io瓶頸,熱點資料太多,資料庫快取放不下,每次查詢時會產生大量的io 分庫和垂直分表 第二種 網路io瓶頸,請求的資料太多,網路頻寬不夠 分庫 1.2cpu瓶頸 第一種 sql問題,如sql中包含join,group by,order by,非索引字段條...

MySQL範圍分表分庫 mysql 分表分庫策略

唯一id的生成 下面列舉幾種常見的唯一id生成方案,需要滿足兩大核心需求 1.全域性唯一 2趨勢有序 1.用資料庫的auto increment 自增id 來生成,每次通過寫入資料庫一條記錄,利用資料庫id自增的特性獲取唯一,有序的id。優點 使用資料庫原有的功能,相對簡單 能夠保證唯一 能夠保證遞...