mysql分庫分表方案
問題：什麼是最好的mysql分庫分表方案？我想到的有：
應用層切分？
mysql**層切分？
提供查詢資料庫分片的中心服務？
你們知道任何這方面有趣的專案或者工具嗎？
回答：最好的切分mysql的方式就是：除非萬不得已，否則不要去幹它。
當你寫乙個應用時，你通常都想要最快的開發速度。只有必要時，你才開始優化延時，提高吞吐量，
你切分資料庫的原因無非因為資料庫的讀或者寫：
資料庫寫寫操作永久的超過了伺服器的磁碟負載；太多寫入導致副本同步永遠的落後了。
資料庫讀讀取到的資料量太大以至於稱爆記憶體；並且大多數讀操作開始直擊磁碟而不是從記憶體中讀取資料。
只有這時，你才需要考慮做資料庫切分。
當你開始切分後，你開始以下面幾種方式支付代價：
你的sql語句不再是宣告式的(declarative)
一般的，你用sql語句告訴資料庫你要什麼資料，然後讓優化器優化sql，並將sql轉化成資料獲取程式。這很棒，因為它非常靈活，而且寫這些轉化程式很無聊，嚴重影響開發速度。
分布式環境下，你將a節點的表和b節點的表進行join，甚至有些表的資料大到超過乙個節點，在a節點和b節點將資料join起來,然後將b節點和c節點join後的資料再次聚合。你開始寫單方面的hash應用程式來解決這個問題(或者你可以再造mysql的集群)，這表示結果你得到一大堆的非宣告式的sql，而且讓程式以一種面向過程的方式開始工作。
你招致了大量的網路延時
一般的，一條sql查詢語句可以本地解決並且通過優化器以最小的耗時解決這個查詢問題。
在分布式環境下，查詢語句必須要通過kv對映，訪問多個網路節點(希望是批量訪問，而不是每個key都來一次網路往返)，或者將where條件放在他們將被執行的節點上。
但是即使在最好的情況下，涉及到多個網路訪問都會更加複雜。特別是mysql的優化器完全不知道網路延時的情況。
你失去了sql的許多強大能力
好吧，這或許沒那麼重要，但是外來鍵約束，其他保證資料完整性的sql機制，對於跨多個節點是無能為力的。
mysql沒有api保證非同步查詢返回順序結果
當相同型別的資料存放在多個節點上(比如使用者資料存放在a,b,c節點上)，水平查詢需要訪問所有節點，資料訪問時間直接因以節點數線性增長。除非多個節點是以並行方式訪問，然後再以map-reduce的方式聚合。
前提是需要提供非同步通訊的api，但這並不存在於mysql提供的功能中。可選的方案是在子程序中增加很多的forking和連線。
總結當你開始做資料庫分庫分表，資料結構和網路拓撲明顯影響到應用的效能。 為了執行良好，你的應用需要當心這些事情，所以只有應用層的切分才有意義。
如果需要自動切分，問題會更多(比如決定那個節點的那個列作為hash主鍵)，或者你想要手動進行切分，xyz使用者去這個主庫上，abc去和def去到那個主庫上。
業務功能上的切分有些好處，如果做對了，這對絕大部分開發人員是透明的。因為所有相關的表都存放在本地。 這讓程式的透明性可以從宣告式的sql中盡量受益，並且有更少的網路延時，因為跨節點的網路訪問被保持到最小化。
業務功能上的切分的缺點是：它不能准許單個表的資料膨脹過大，這需要設計者的特別注意。
業務功能切分的好處是：針對乙個並沒有太多改變的**庫，它相對而言非常簡單。 booking.com在過去幾年進行過幾次業務功能上的分庫分表，並且一直工作的很好。
什麼是mysql儲存過程 什麼是mysql儲存過程
mysql中的儲存過程指的是儲存在資料庫中的sql語句集合，當建立好儲存過程後在執行時提供所需引數，儲存過程就可以以 指定的方式使用引數執行並返回值 在mysql中提供了建立儲存過程的能力。儲存過程是mysql以及其他資料庫管理系統中的強大功能。接下來在文章中將為大家具體介紹mysql中的儲存過程，...
mysql分庫備份 MySQL分庫備份與分表備份
mysql分庫備份與分表備份 1 分庫備份 要求 將mysql資料庫中的使用者資料庫備份，備份的資料庫檔案以時間命名 指令碼內容如下 root db01 scripts vim backup database.sh bin bash mysql user root mysql pass 123456...
mysql為什麼要分庫分表？
1 基本思想之什麼是分庫分表？從字面上簡單理解，就是把原本儲存於乙個庫的資料分塊儲存到多個庫上，把原本儲存於乙個表的資料分塊儲存到多個表上。2 基本思想之為什麼要分庫分表？單錶運算元據量有最優值，mysql為1000萬左右 可以減輕資料庫的壓力，不用所有執行緒都查同乙個資料庫 資料庫中的資料量不一定...