資料庫中的資料量不一定是可控的，在未進行分庫分表的情況下，隨著時間和業務的發展，庫中的表會越來越多，表中的資料量也會越來越大，相應地，資料操作，增刪改查的開銷也會越來越大；另外，由於無法進行分散式式部署，而一臺伺服器的資源（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：