隨著系統不斷的執行，當資料庫的資料開始超過千萬、上億時，mysql資料庫將承受更大的壓力。資料是企業生存的根本，資料庫的健康狀況將直接決了定企業的競爭力。
為了更好的緩解資料庫壓力，使得系統更高效的執行，落地的解決方案有：1、分庫（也叫垂直拆分，即：每個模組對應乙個單獨的資料庫）。2、分表（也叫水平拆分，即：一張表的資料拆分儲存到多張表裡）。
1、資料庫分離的同時，也引入了分布式事物的問題。2、表的水平拆分的同時，也帶來了很多的挑戰，比如：分頁查詢、表資料的後續擴充套件、資料的儲存和檢索策略。
1、分布式事物的解決方案也有很多，比如：tcc、mq事物訊息等。這裡提出方案的是事物補償，且僅有事務補償沒有回滾。具體做的時候需要注意：將執行乙個操作所涉及到的所有校驗條件全部提到服務編排層的最前面（包括試算）。若所有的校驗條件都通過了，則認為後續執行的業務邏輯一定是通過的。如果執行報錯，那麼，通過訊息佇列做三次補償，補償仍然失敗，手工介入處理。
2、rpc呼叫、事物補償引入了併發場景下的介面冪等性問題，這裡給出三種解決方案是：a.樂觀鎖，id和版本號，update version … where version3、分表的同時帶來了資料的儲存和檢索問題，這裡給的解決方案是：a.根據業務組id（全域性分配唯一）取模運算，比如：10張表，那麼，就是取10的模來決定儲存的表編號，並存入路由表。業務組的id是指乙個更大的管理單位，比如：某個商戶的id、企業的id。b.增加路由表，根據業務組id查詢路由表，找到表編號。c.對於沒有業務組關聯的資訊，例如：使用者資訊，也是直接採用取模的計算方式。對於一些特殊場景的userid，也可以儲存到路由表裡，檢索的時候，優先檢索路由表。這裡有兩個重要的概念第乙個是按照業務組id為單位操作，第二個是根據路由表來查詢表編號。
分庫分表的解決方案
思路 1 完整閱讀分庫 分表策略，注意區分分庫與分表的不同，撰寫閱讀筆記。2 試驗基於ibatis spring2.0的分庫原始碼，注意思考路由的規則。3 試驗分表的原始碼實現，一般採用ibatis2.0以後的動態表名實現。以長春市教育公共服務平台管理軟體為例，在master庫中設定一張表，記錄每個...
分庫分表下分頁查詢解決方案
不管是隨著業務量的增大 還是隨著使用者數量的增長，在單一表中無法承受大量大資料，導致查詢速度極慢甚至拖垮資料庫。所以分庫分表的策略隨之應用，但是如何在分庫分表的情況下，進行分頁查詢，目前仍是業界難題。本文記錄了三種情況下，對於分庫分表下的分頁查詢優化方案。不管是目前的一些資料庫中介軟體例如mycat...
資料庫分庫分表事務解決方案
隨著時間和業務的發展，資料庫中表的資料量會越來越大，相應地，資料操作，增刪改查的開銷也會越來越大。因此，把其中一些大表進行拆分到多個資料庫中的多張表中。另一方面，在分庫分表以後還需要保證分庫分表的和主庫的事務一致性。這片文章介紹一下 本篇文章是基於非事務訊息的非同步確保的方式來完成分庫分表中的事務問...