當MySQL單表記錄數過大時，數據庫的CRUD性能會明顯下降，一些常見的優化措施如下：

1：限定數據的范圍
務必禁止不帶任何限制數據范圍條件的查詢語句。比如：我們當用戶在查詢訂單歷史的時候，我們可以控制在一個月的范圍內

2： 讀/寫分離
經典的數據庫拆分方案，主庫負責寫，從庫負責讀

3：垂直分區
根據數據庫里面數據表的相關性進行拆分。 例如，用戶表中既有用戶的登錄信息又有用戶的基本信息，可以將用戶表拆分成兩個單獨的表，甚至放到單獨的庫做分庫。簡單來說垂直拆分是指數據表列的拆分，把一張列比較多的表拆分為多張表。

垂直拆分的優點： 可以使得列數據變小，在查詢時減少讀取的Block數，減少I/O次數。此外，垂直分區可以簡化表的結構，易于維護。

垂直拆分的缺點： 主鍵會出現冗余，需要管理冗余列，并會引起Join操作，可以通過在應用層
進行Join來解決。此外，垂直分區會讓事務變得更加復雜。

4：水平分區
保持數據表結構不變，通過某種策略存儲數據分片。這樣每一片數據分散到不同的表或者庫中，達
到了分布式的目的。 水平拆分可以支撐非常大的數據量。水平拆分是指數據表行的拆分，表的行數超過200萬行時，就會變慢，這時可以把一張的表的數據拆成多張表來存放。舉個例子：我們可以將用戶信息表拆分成多個用戶信息表，這樣就可以避免單一表數據量過大對性能造成影響。

水平拆分可以支持非常大的數據量。需要注意的一點是：分表僅僅是解決了單一表數據過大的問題，但由于表的數據還是在同一臺機器上，其實對于提升MySQL并發能力沒有什么意義，所以 水平拆分最好分庫
水平拆分能夠 支持非常大的數據量存儲，應用端改造也少，但 分片事務難以解決 ，跨節點Join性能
較差，邏輯復雜。《Java工程師修煉之道》的作者推薦 盡量不要對數據進行分片，因為拆分會帶來
邏輯、部署、運維的各種復雜度 ，一般的數據表在優化得當的情況下支撐千萬以下的數據量是沒有
太大問題的。如果實在要分片，盡量選擇客戶端分片架構，這樣可以減少一次和中間件的網絡I/O。

下面補充一下數據庫分片的兩種常見方案：

1：客戶端代理： 分片邏輯在應用端，封裝在jar包中，通過修改或者封裝JDBC層來實現。 當當網的 Sharding-JDBC 、阿里的TDDL是兩種比較常用的實現。

2：中間件代理： 在應用和數據中間加了一個代理層。分片邏輯統一維護在中間件服務中。 我們現在談的 Mycat 、360的Atlas、網易的DDB等等都是這種架構的實現。