MYSQL 分佈式自己「搞」，還是中間件（答題愛可生送書活動）

1 分庫分表，我們使用業務邏輯 + 業務程序的方式來進行，並期根據實際的環境將系統中的一些表分割到不同的MYSQL 服務器上存儲，達到以下兩個關鍵問題的解決。

1 受制於MYSQL本身的單表的存儲能力，這樣處理將擴展MYSQL的單表的存儲能力。

2 受制於MYSQL 單機（包括基於 MGR集群 , MHA高可用）本身數據吞吐能力，將數據打散後，提高了數據庫的存儲速度，和數據的提取速度。

這恐怕是分庫分表中最重要的需求。

2 分庫分表，使用中間件的方式，進行分表的操作，這是另一種分表的方式，與上邊的方式相比，這樣的方式更加的通用，通過中間件的方式將數據流自動分割到不同的MYSQL 數據庫服務器上，以達到和上邊使用特定邏輯達到同樣的效果，滿足數據的存儲擴展和更大吞吐量的需求。

那1 和 2 兩種分表的方案，之間的區別，個人理解 1 方案更貼近業務，並且如果是自己的公司來研發方案，則出錯，排錯，都比較方便。但如果自己定義的方案出現問題，並且已經上了一段生產，如果反悔修改上成本就比較高了。

方案2 採用中間件的方式來說，是大部分，或者說需要快速上線，業務方面方向比較靈活，而且需要分表的表，有點多的情況下，採用的一種方式。

從成本上看1 方案要投入的人力，物力會比較多，方案2 投入的人力，物力比較少，由於中間件是根據很多業務的需求而來所產生的，所以通用性比較強，適應力也比較高。方案1 那就看各家自己的開發水平和經驗了。

但為什麼方案2在成本較低的情況下，有些公司沒有用也總結了以下幾點

1 中間件的使用，牽扯整體關鍵業務（分表的表一般都是業務中的主力）自己研發分庫分表的方案更有底。

2 中間件的某些設計上的問題，對複雜的查詢語句執行，數據的返回，事務下發後，失敗的處理等等，都要複雜與單庫系統，所以怕後期出現問題，無法解決，所以不使用。

這裡從邏輯的角度來看中間件

1 中間件的自帶的主鍵生成的邏輯，是否能滿足企業業務中設想的邏輯，滿足開發的對於主鍵設計的需求。

2 中間件對於支持的MYSQL的語法的標準，以及是否可以承受一些複雜語句的查詢，降低開發人員在設計系統時的難度。

3 中間件在不使用後，數據的遷移，維護，改變分庫分表的更改的成本的問題。

基於上面的幾點考慮，標準化，穩定性，有相關支持等等是應該被考慮在使用中間件的基礎上的一個考量。

在細節方面，使用中間件考慮的範圍會更多一些

比如對於學習成本的需求，中間件的加入不應該提高使用數據庫的成本，無論是從人員還是技術方面，與原有的數據庫的使用方式越貼近越好。

支持原生的數據庫協議，這也是降低學習成本，提高使用的方便感的一個應該由的標準。

當然對中間件的要求中看似沒有特點，但很難做到的部分，就是事務的回滾，在一個MYSQL 數據庫中進行事務的回滾，是在正常不過的事情，而將一個事務下發到多台MYSQL 並且在進行事務回滾，這就不是一件簡單的事情。

1 對於多個MYSQL 節點中，某個節點的失敗如何處理

2 對於執行計劃如何打散到多個節點執行，並且保持執行效率

3 整體事務在操作失敗後，如何進行事務的回滾

4 對複雜SQL 的拆分，將複雜的查詢拆分為基本的關係代數查詢樹，在下發到各個節點，然後返回數據在進行合併等等。

5 對於複雜的SQL的執行後的數據返回的正確性。

基於中間件的複雜，以及要求，其實我們可以使用的中間件並沒有太多的選擇大部分都是在使用mycat，更加清晰的了解和理解MYSQL中間件的定義，則是如何搞好分庫分表的第一步，實際上也是有其他的中間件可以選擇。

下面是三道關於數據庫中間件的問題，希望喜歡那本書的同學能夠拿到，繼續提高我們的處理MYSQL的能力。

當然為了更多的同學能拿到這本書，我也放放水， DBLE 在中間件特性中的，透明性，兼容性，性能，安全，運維性方面均相對有了很大的提升，例如某些在mycat中無法解析的語句，返回結果有誤的問題，都在DBLE中解決了。同時基於與mycat基礎上修改，則運維方面的成本都沒有提高。