什麼是最好的mysql分庫分表方案？我想到的有：
應用層切分？
mysql**層切分？
提供查詢資料庫分片的中心服務？
你們知道任何這方面有趣的專案或者工具嗎？
當你寫乙個應用時，你通常都想要最快的開發速度。只有必要時，你才開始優化延時，提高吞吐量，
你切分資料庫的原因無非因為資料庫的讀或者寫：
只有這時，你才需要考慮做資料庫切分。
當你開始切分後，你開始以下面幾種方式支付代價：
一般的，你用sql語句告訴資料庫你要什麼資料，然後讓優化器優化sql，並將sql轉化成資料獲取程式。
這很棒，因為它非常靈活，而且寫這些轉化程式很無聊，嚴重影響開發速度。
分布式環境下，你將a節點的表和b節點的表進行join，甚至有些表的資料大到超過乙個節點，
在a節點和b節點將資料join起來,然後將b節點和c節點join後的資料再次聚合。
你開始寫單方面的hash應用程式來解決這個問題（或者你可以再造mysql的集群），
這表示結果你得到一大堆的非宣告式的sql，而且讓程式以一種面向過程的方式開始工作。
一般的，一條sql查詢語句可以本地解決並且通過優化器以最小的耗時解決這個查詢問題。
在分布式環境下，查詢語句必須要通過kv對映，訪問多個網路節點（希望是批量訪問，
而不是每個key都來一次網路往返），或者將where條件放在他們將被執行的節點上。
但是即使在最好的情況下，涉及到多個網路訪問都會更加複雜。特別是mysql的優化器完全不知道網路延時的情況。
好吧，這或許沒那麼重要，但是外來鍵約束，其他保證資料完整性的sql機制，對於跨多個節點是無能為力的。
當相同型別的資料存放在多個節點上（比如使用者資料存放在a,b,c節點上），水平查詢需要訪問所有節點，
資料訪問時間直接因以節點數線性增長。除非多個節點是以並行方式訪問，然後再以map-reduce的方式聚合。
前提是需要提供非同步通訊的api，但這並不存在於mysql提供的功能中。可選的方案是在子程序中增加很多的forking和連線。
當你開始做資料庫分庫分表，資料結構和網路拓撲明顯影響到應用的效能。
為了執行良好，你的應用需要當心這些事情，所以只有應用層的切分才有意義。
如果需要自動切分，問題會更多（比如決定那個節點的那個列作為hash主鍵），或者
你想要手動進行切分，xyz使用者去這個主庫上，abc去和def去到那個主庫上。
業務功能上的切分有些好處，如果做對了，這對絕大部分開發人員是透明的。因為所有相關的表都存放在本地。
這讓程式的透明性可以從宣告式的sql中盡量受益，並且有更少的網路延時，因為跨節點的網路訪問被保持到最小化。
業務功能上的切分的缺點是：它不能准許單個表的資料膨脹過大，這需要設計者的特別注意。
業務功能切分的好處是：針對乙個並沒有太多改變的**庫，它相對而言非常簡單。
booking.com在過去幾年進行過幾次業務功能上的分庫分表，並且一直工作的很好。
Mysql分庫分表方案
1.為什麼要分表 當一張表的資料達到幾千萬時，你查詢一次所花的時間會變多，如果有聯合查詢的話，我想有可能會死在那兒了。分表的目的就在於此，減小資料庫的負擔，縮短查詢時間。mysql中有一種機制是表鎖定和行鎖定，是為了保證資料的完整性。表鎖定表示你們都不能對這張表進行操作，必須等我對錶操作完才行。行鎖...
mysql分庫分表方案
分庫分表的幾種方式 1 把乙個例項中的多個資料庫拆分到不同的例項 2 把乙個庫中的表分離到不同的資料庫中 3 對乙個庫中的相關表進行水平拆分到不同的例項資料庫中 如何選擇分割槽鍵 1 分割槽鍵要能盡量避免跨分片查詢的發生 2 分割槽鍵要能盡量使各個分片中的資料平均 如何儲存無需分片的表 1 每個分片...
MySQL分庫分表方案
不管是io瓶頸，還是cpu瓶頸，最終都會導致資料庫的活躍連線數增加，進而逼近甚至達到資料庫可承載活躍連線數的閾值。在業務service來看就是，可用資料庫連線少甚至無連線可用。接下來就可以想象了吧 併發量 吞吐量 崩潰 1 io瓶頸 第一種 磁碟讀io瓶頸，熱點資料太多，資料庫快取放不下，每次查詢時...