數據庫性能優化

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

限定數據的範圍： 務必禁止不帶任何限制數據範圍條件的查詢語句。好比：咱們當用戶在查詢訂單歷史的時候，咱們能夠控制在一個月的範圍內。；

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

垂直分區：根據數據庫裏面數據表的相關性進行拆分。 例如，用戶表中既有用戶的登陸信息又有用戶的基本信息，能夠將用戶表拆分紅兩個單獨的表，甚至放到單獨的庫作分庫。簡單來講垂直拆分是指數據表列的拆分，把一張列比較多的表拆分爲多張表。

--垂直拆分的優勢： 能夠使得行數據變小，在查詢時減小讀取的Block數，減小I/O次數。此外，垂直分區能夠簡化表的結構，易於維護。

--垂直拆分的缺點： 主鍵會出現冗餘，須要管理冗餘列，並會引發Join操做，能夠經過在應用層進行Join來解決。此外，垂直分區會讓事務變得更加複雜；

水平分區： 保持數據表結構不變，經過某種策略存儲數據分片。這樣每一片數據分散到不一樣的表或者庫中，達到了分佈式的目的。 水平拆分能夠支撐很是大的數據量。 水平拆分是指數據錶行的拆分，表的行數超過200萬行時，就會變慢，這時能夠把一張的表的數據拆成多張表來存放。舉個例子：咱們能夠將用戶信息表拆分紅多個用戶信息表，這樣就能夠避免單一表數據量過大對性能形成影響。水平拆分能夠支持很是大的數據量。須要注意的一點是:分表僅僅是解決了單一表數據過大的問題，但因爲表的數據仍是在同一臺機器上，其實對於提高MySQL併發能力沒有什麼意義，因此水平拆分最好分庫 。水平拆分可以 支持很是大的數據量存儲，應用端改造也少，但 分片事務難以解決 ，跨界點Join性能較差，邏輯複雜。《Java工程師修煉之道》的做者推薦 儘可能不要對數據進行分片，由於拆分會帶來邏輯、部署、運維的各類複雜度 ，通常的數據表在優化得當的狀況下支撐千萬如下的數據量是沒有太大問題的。若是實在要分片，儘可能選擇客戶端分片架構，這樣能夠減小一次和中間件的網絡I/O。

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

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

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