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

所以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】，獲取學習資料。

總結

以上是生活随笔為你收集整理的oracle单表数据量上亿_MySQL数据库中，数据量越来越大，有什么具体的优化方案么？...的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。