MYSQL效能優化之資料庫的分庫分表
資料庫中的資料量不一定是可控的,在未進行分庫分表的情況下,隨著時間和業務的發展,庫中的表會越來越多,表中的資料量也會越來越大,相應地,資料操作,增刪改查的開銷也會越來越大;另外,由於無法進行分散式式部署,而一臺伺服器的資源(CPU、磁碟、記憶體、IO等)是有限的,最終資料庫所能承載的資料量、資料處理能力都將遭遇瓶頸。
說白了,就是分擔寫負載
分庫分表一
節點:mysql資料庫一主多從的資料庫叢集(資料一致),所以用節點表示
重新對資料庫連線進行配置就行
優點:資料庫拆分比較簡單,尤其適合沒有跨庫查詢的情況下
缺點:如果寫操作主要在訂單表,那就分庫分表的作用不是很大了
分庫分表二
當表所在的伺服器也達到瓶頸時,無法繼續升級
分庫分表三:水平拆分(分片->不同物理節點)
類似分割槽表(不同:一個節點:資料庫),分片很容易出現問題,難以維護,慎重
分片前準備
- 不經常更新的表
- 資料量不大,字典列表
- 使用多寫的方式維護一致性(表更新時,同時更新所有分片的表操作)
- 定期檢查(防止業務邏輯問題)
- 第二種方式優點是資料沒有冗餘問題,查詢效率差一些,因為要關聯,合併
資料量和訪問量的平均,結合業務做分析
- 第一種:分割槽鍵並不總是數值,所有要用模來轉換成數值性資料
- 優點:可以比較平均的分配資料
- 缺點:很難人為控制哪個資料分配到哪個分片中
- 第二種:常用於分割槽鍵是日期型別或者是資料型別的情況
- 優點:很清楚知道資料在哪個分片中
- 缺點:資料(訪問量)分配不平均
- 第三種:
- 靈活對資料在哪些分片進行控制
- 對映表會產生很大的服務壓力,可以使用快取(否則很可能成為系統的瓶頸)
- auto_increment_increment(總分片數) auto_increment_offset(不同的值)
- 只適用於一個節點儲存一套分割槽表
- 全域性節點ID->建表使用auto_increment屬性,生成自增ID->效能瓶頸
- 類似第二種
演示
分片工具(演示,不是很完美)
三個節點:節點1(伺服器節點),節點2(分片資料庫節點),節點3(oneProxy節點)
節點1,節點2新增oneProxy連線使用者
demo.sh 啟動指令碼
- 修改配置
- 新增分片節點
- 通過oneProxy客戶端獲取加密字串密碼 ./demo.sh
- mysql -P4041 -uadmin -pOneProxy -h127.0.0.1;
- passwd “123456” (獲取密碼)
- 修改proxy-user-list 使用者/加密密碼@資料庫名
- peoxy-part-template 分片方式地址
- remote-address 遠端管理地址
設定分片方式
訂單表,訂單商品表,相互關聯,分片鍵一致
- 表名
- 分片鍵
- 鍵型別
- 分片方式
- 分片方式(分片)
- suffix字尾
- 分片組
建表
節點1
節點2
節點3
ps -ef | grep oneproxy
重啟oneProxy
kill -9 1164
./demo.sh
mysql -P4041 -uadmin -pOneProxy -h127.0.0.1;
list backend;
測試
通過oneproxy連線
mysql -utest -p123456 -h127.0.0.1 -p3306
節點1:
節點2: