個人的觀點，這種大表的最佳化，不一定上來就要分庫分表，因為表一旦被拆分，開發、運維的複雜度會直線上升，而大多數公司和開發人員是欠缺這種能力的。

所以MySQL中幾百萬甚至小几千萬的表，先考慮做單表的最佳化。

單表最佳化

單表最佳化可以從這幾個角度出發：

1。表分割槽

MySQL在5。1之後才有的，可以看做是水平拆分，分割槽表需要在建表的需要加上分割槽引數，使用者需要在建表的時候加上分割槽引數；

分割槽表底層由多個物理子表組成，但是對於程式碼來說，分割槽表是透明的；

SQL中的條件中最好能帶上分割槽條件的列，這樣可以定位到少量的分割槽上，否則就會掃描全部分割槽。

2。增加快取

主要的思想就是減少對資料庫的訪問，快取可以在整個架構中的很多地方；

比如：資料庫本身有就快取，客戶端快取，資料庫訪問層對SQL語句的快取，應用程式內的快取，第三方快取（如Redis等）；

3。欄位設計

單表不要有太多欄位；

VARCHAR的長度儘量只分配真正需要的空間；

儘量使用TIMESTAMP而非DATETIME；

避免使用NULL，可以透過設定預設值解決。

4。索引最佳化

索引不是越多越好，針對性地建立索引，索引會加速查詢，但是對新增、修改、刪除會造成一定的影響；

值域很少的欄位不適合建索引；

儘量不用UNIQUE，不要設定外來鍵，由程式保證；

5。索引最佳化

儘量使用索引，也要保證不要因為錯誤的寫法導致索引失效；

比如：避免前導模糊查詢，避免隱式轉換，避免等號左邊做函式運算，in中的元素不宜過多等等；

6。NoSQL

有一些場景，可以拋棄MySQL等關係型資料庫，擁抱NoSQL；

比如：統計類、日誌類、弱結構化的資料；事務要求低的場景。

表拆分

資料量進一步增大的時候，就不得不考慮表拆分的問題了：

1。垂直拆分

垂直拆分的意思就是把一個欄位較多的表，拆分成多個欄位較少的表；上文中也說過單表的欄位不宜過多，如果初期的表結構設計的就很好，就不會有垂直拆分的問題了；一般來說，MySQL單表的欄位最好不要超過二三十個。

2。水平拆分

就是我們常說的分庫分表了；分表，解決了單表資料過大的問題，但是畢竟還在同一臺數據庫伺服器上，所以IO、CPU、網路方面的壓力，並不會得到徹底的緩解，這個可以透過分庫來解決。

水平拆分優點很明顯，可以利用多臺資料庫伺服器的資源，提高了系統的負載能力；缺點是邏輯會變得複雜，跨節點的資料關聯效能差，維護難度大（特別是擴容的時候）。

我將持續分享Java開發、架構設計、程式設計師職業發展等方面的見解，希望能得到你的關注；關注我後，可私信傳送數字【1】，獲取學習資料。