【資料庫】分庫分表

本質

　　當業務的增長導緻資料庫瓶頸的時候，一種解決瓶頸的手段。分庫分表的核心是建立一個對業務透明的邏輯大表，隔離存儲的負載度，進而實作在業務應用眼裡的無限存儲！

　　分表

　　分表解決的是：過大的資料表影響計算速度的問題，比如單表上億，那麼拆成十個表，必然會比一個表更快，用了一部分計算落表時間，來換取單表計算的時間。

　　分庫

　　分庫更多解決的是機器局限的問題，單機容量有限，單機容量實際上是由機器硬體決定，比如網卡打滿、cpu打滿、機器磁盤寫滿等case，必須将計算分布到其他機器上解決。先拆分程序，随後将程序拆分到不同的機器上。

索引

　　對于資料庫來說，強行提升了儲存，而索引就是需要付出的代價。

　　當存儲分布之後，單機的索引是無法滿足對索引的要求，而sql是對索引更上一層的封裝，會有一定程度的限制，比如：分庫分表最多能滿足兩個次元的拆分，join表這種操作就變得異常困難。如何解決呢？方法就是，簡單索引邏輯靠中間件建構虛拟索引，複雜索引靠其他方式建構外置索引。

　　所有的分庫分表的中間件的工作，無非是在資料源和業務應用之間封裝一層虛拟的滿足基本需要的索引。業務應用發送請求到中間件，中間件起到一部分索引的作用，判定需要到哪個庫，哪個表來執行，這其實就是單機資料庫，選擇表過程的外置。中間件還有一個作用是，對涉及邏輯表的部分，進行一部分sql邏輯改寫，來最終判定到某些部分執行。

　　對于更複雜的查詢要求，應用方需要單獨建構另外的索引，即把索引單獨拆出來做成一個系統，來滿足檢索需要。作為代價來說，外置的索引會比内置的索引相對慢些，這是在系統架構上需要注意的地方。但是作為大原則，盡量把計算邏輯放置在索引外進行。

一緻性

　　分庫分表還好的地方在于，資料最終存儲是一份的；

　　因為分庫分表把需要操作的資料源分散了，操作的原子性在保障起來是有損耗了核心問題就在于，如何保障跨資料庫、跨程序、跨機器的操作原子性。方法就是：外置保證一緻性的方式

　　通過柔性分布式事務的方式來實作最終一緻性，方式就是外置檢查，某一動作失敗時，往前復原，不一定完全復原資料狀态，復原到不影響發生其它業務邏輯的業務狀态。

　

--------------------------------

優秀、是一種習慣

、、、、、、、、、、、、、、、