如何為MySQL分片

第一部分：

   關系型資料庫随時間的流逝慢慢的不能滿足現在每秒大量的操作、很多打開的連接配接、大量的資料和非常高的寫比率。為避免這種情況的出現，很多大型站點和SaaS的應用開始使用sharding技術和他們的關系型資料結合。

   怎樣對應用分片？下面列出的四點很簡單：

   1、分析表schema得出分片該如何設定

   2、開啟多個MySQL 執行個體

   3、根據shard配置，導入導出資料

   4、更新程式代碼來支援shard配置

   分析資料：

   為了得到一個shard 配置，你需要做下面三步：

   1、列出表名和表的大小。 大表時最需要進行分片的，因為很多SQL指令經常在表上執行。

   2、列出外鍵（如果有的話）外鍵幫助我們了解表之間的關系，這樣的表需要很明智的劃分，否則你的表将失去一緻性

   3、分析涉及到的SQL語句  一些SQL語句在shard環境下是難以執行的。是以需要整理一份SQL語句來決定哪些表時不需要shard的。我們還能得出哪些表時通路頻率很高，哪些不是。

   表劃分規則：

   在實施shard的時候，需明白并不是所有的表都會被分片。因為sharding會限制SQL的書寫（不允許在表之間進行join，表的唯一性，自增字段），你必須強制修改應用代碼。通常情況下一些表被shard，另一些表被複制到其他shard上。

   确定哪些表時需要被分片的；

   對表進行shard的算法像下面描述的一樣簡單：

   1、尋找最大的表，很多表結構中都有幾張大表，其餘并不是。

   2、分析sql語句：

      是否表之間使用了join查詢？

      a、是，讓其中較小的表作為一個全局表

      b、如果不是，還要根據sql語句來分析通路頻率分析

         i、如果這些表通路不頻繁，讓他們成為全局表

         ii、找出通路頻繁的表尤其是那些寫入比較嚴重的進行shard，然後跳到第2步确定他們真的可以被shard（無join操作）

    一旦你确定了哪些表是将被shard的，那麼下一步就是選擇sharding keys ,多數情況下回使用表的primary key作為shard key。如果某些表之間存在外鍵關系，那麼使用外鍵作為shard key 也是可以考慮的。

    和資料庫分區一樣，sharding也有很多算法：hash，list，range等。一般情況下使用 list或者 hast算法來應對多個選擇條件的情況。通過不同的DB來儲存不同的使用者資訊。hash往往能夠對資料更加平均的進行配置設定。

    下一步呢？

    如果你是一個新的環境，那麼可以跳過這一步啦。

    1、在所有的shard上對資料進行克隆，複制實體檔案或者mysqldump都行

    2、對于每個shard（shard上的每個表）

        a、删除所有的索引

        b、删除所有多餘的資料（腳本搞定）

           這個操作會産生很多的碎片，可以考慮建立一張臨時表，隻插入相關的記錄，最後删除原表，再重命名。

        c、添加索引 

    在不适用ORM架構層的情況下：

    如果你沒有使用ORM(Object/Relational Mapping Tool)來實作的話，那麼恭喜你！這個時候sharding會更容易控制SQL語句。

    更新一下連接配接池：

    你的第一個任務是寫一個支援sharding的連接配接池，這個類應該像下面這個樣子：   

    需要在特定shard上執行的sql語句需要調用 getConnecttion 方法，該方法邏輯放包含基于shard key的連接配接号。在全局表上執行的sql使用getAnyConnection 方法。

    設計的這些連接配接方法必須在session級别實作來實作事務隔離。

    Query 語句修改規則：

    1、轉到響應查詢

    2、對于每個查詢确定踏實通路全局表，還是shard中的表

       a、如果通路全局表，那麼使用getAnyConnecttion方法

       b、如果通路某個shard中的表，檢測語句中是否包含shard key

          i、如果包含，那麼使用這個keyd 調用 getConnecttion方法

             如果查詢還要通路其他的表，那麼把它拆分成多個語句

          ii、如果不包含key，那那麼将其拆分成多個查詢來得到shard key

        c、確定代碼能合并所有分開查詢的資料。

    當使用ORM的情況下：

    由于很多的ORM不支援sharding，那隻能重寫ORM code，隻能通過自己寫SQL來尋找操作對象，這不是一個簡單的任務！

    現在你已經知道如何進行shard操作，那麼你知道為什麼這麼做嗎？

    這個問題并不是很難，我長話短說，如果你的資料都在一台機器上并且已經超出了你的記憶體的容量，那麼你可以考慮分片。如果你的寫入很多導緻IO很忙，那你可以考慮分片

    為什麼呢？這個問題很好解釋：

    資料庫一般情況下更傾向于将常用資料放到記憶體中，供應商已經開發了很多高校的緩存算法，比如：query cache，buffer pool等等

    如果資料量太大的話，那麼記憶體就會變的緊張。甚至索引頁沒有在記憶體裡面。這個時候越早分片越好。如今很多DB是建立在雲上的，添加記憶體幾乎變的不可能。使用sharding之後，每個機器都有自己的資料和足夠的記憶體可用，我們做的僅僅是添加新的shard！

    其他方面的話可能是最大并發連接配接數，如果到了一個限制值，這個時候也是可以進行分片的。每個shard相比都會有較少的連接配接，更高的命中率！

本文轉自 位鵬飛 51CTO部落格，原文連結：http://blog.51cto.com/weipengfei/1064142，如需轉載請自行聯系原作者