個人的觀點，這種大表的優(yōu)化，不一定上來就要分庫分表，因為表一旦被拆分，開發(fā)、運維的復(fù)雜度會直線上升，而大多數(shù)公司是欠缺這種能力的。所以MySQL中幾百萬甚至小幾千萬的表，先考慮做單表的優(yōu)化。
單表優(yōu)化
單表優(yōu)化可以從這幾個角度出發(fā)：
-
表分區(qū)：MySQL在5.1之后才有的，可以看做是水平拆分，分區(qū)表需要在建表的需要加上分區(qū)參數(shù)，用戶需要在建表的時候加上分區(qū)參數(shù)；分區(qū)表底層由多個物理子表組成，但是對于代碼來說，分區(qū)表是透明的；SQL中的條件中最好能帶上分區(qū)條件的列，這樣可以定位到少量的分區(qū)上，否則就會掃描全部分區(qū)。
-
讀寫分離：最常用的優(yōu)化手段，寫主庫讀從庫；
-
增加緩存：主要的思想就是減少對數(shù)據(jù)庫的訪問，緩存可以在整個架構(gòu)中的很多地方，比如：數(shù)據(jù)庫本身有就緩存，客戶端緩存，數(shù)據(jù)庫訪問層對SQL語句的緩存，應(yīng)用程序內(nèi)的緩存，第三方緩存（如redis等）；
-
字段設(shè)計：單表不要有太多字段；VARCHAR的長度盡量只分配真正需要的空間；盡量使用TIMESTAMP而非DATETIME；避免使用NULL，可以通過設(shè)置默認值解決。
-
索引優(yōu)化：索引不是越多越好，針對性地建立索引，索引會加速查詢，但是對新增、修改、刪除會造成一定的影響；值域很少的字段不適合建索引；盡量不用UNIQUE，不要設(shè)置外鍵，由程序保證；
-
SQL優(yōu)化：盡量使用索引，也要保證不要因為錯誤的寫法導(dǎo)致索引失效；比如：避免前導(dǎo)模糊查詢，避免隱式轉(zhuǎn)換，避免等號左邊做函數(shù)運算，in中的元素不宜過多等等；
-
NoSQL：有一些場景，可以拋棄MySQL等關(guān)系型數(shù)據(jù)庫，擁抱NoSQL；比如：統(tǒng)計類、日志類、弱結(jié)構(gòu)化的數(shù)據(jù)；事務(wù)要求低的場景。
表拆分
數(shù)據(jù)量進一步增大的時候，就不得不考慮表拆分的問題了：
-
垂直拆分：垂直拆分的意思就是把一個字段較多的表，拆分成多個字段較少的表；上文中也說過單表的字段不宜過多，如果初期的表結(jié)構(gòu)設(shè)計的就很好，就不會有垂直拆分的問題了；一般來說，MySQL單表的字段最好不要超過二三十個。
-
水平拆分：就是我們常說的分庫分表了；分表，解決了單表數(shù)據(jù)過大的問題，但是畢竟還在同一臺數(shù)據(jù)庫服務(wù)器上，所以IO、CPU、網(wǎng)絡(luò)方面的壓力，并不會得到徹底的緩解，這個可以通過分庫來解決。水平拆分優(yōu)點很明顯，可以利用多臺數(shù)據(jù)庫服務(wù)器的資源，提高了系統(tǒng)的負載能力；缺點是邏輯會變得復(fù)雜，跨節(jié)點的數(shù)據(jù)關(guān)聯(lián)性能差，維護難度大（特別是擴容的時候）。
