數據庫性能優化一

這周公司組織的去惠州遊玩，玩得很開心，就是坐車的時間比較長，除了睡覺基本一半時間都在車上，剛回來吃了飯，本來計劃着這周搞點docker的一些知識，不過太累了，就寫點我的總結吧。做爲IT程序員，特別是作了幾年的，三年以上的吧，若是仍是以爲只要能實現功能，就萬事大吉完成任務，只是着眼與功能點的實現，那可就真成搬磚的了，最基本的是實現功能的優化。一個項目都會包含應用服務器和數據服務器，若是說對項目進行優化，那優化的地方有好多，優化的方法也有好多，今天要說的對數據庫的優化也有好幾個方面。

1、系統框架方面

1.框架

首先是要搞清楚業務需求，在知足業務需求的狀況下，合理的技術選型和系統架構不只僅是對數據庫方面有幫助，對後期的開發維護都有幫助，系統框架要考慮長遠，也不是說一個小的企業宣傳網站就搞什麼分佈式、大數據這些，畢竟軟件也有生命週期的，但也不能只顧眼前，能夠根據自身狀況以及對將來五年十年的規劃，最起碼先有一個目標，能知足多人用戶的需求，天天訪問量能達到多少、併發量能到多少，將來五年又是一個目標，不能說軟件用了一兩年數據量一大、人一多就不能用了，擴展性方面要有必定的考慮。

2.業務實現方面

在系統中會進行對數據庫的訪問，訪問的多了超過數據庫的承載能力了，就會影響數據庫的性能。因此咱們能夠從系統業務實現方面來進行數據庫的一些優化，好比緩存，能減小一些訪問次數，好比鏈接池的設計，也是更減小系統的開銷，更好的利用資源，有的項目也會把一些經常使用的不宜改變的數據放在客戶端，這樣也能減小對數據庫的訪問次數。同時一些對應用服務器優化的方法其實也是對數據庫的優化，好比隊列，利用隊列能夠達到錯峯的效果，這樣也能夠防止數據庫崩潰，致使更大的災難,增長數據庫的抗壓能力。還有就是能夠減小返回的數據，數據量小了速度也會提高。

2、數據庫自身方面

1.表結構的設計

業務需求影響表的設計，同時表的設計影響需求的實現。通常項目都會有登陸功能，並且也是比較常常訪問的，我見過的大部分的系統，表的設計是將用戶登陸的密碼放在用戶我的信息表中，一個用戶信息表可能會有二三十個字段，甚至包含手機號、郵箱等一些比較隱私的信息。像這種也是能實現需求的，不過之後用戶多的時候，達到百萬千萬級時，一條記錄這麼多字段，這麼多的用戶那一個表的數據也是蠻大的，僅僅是實現登陸功能，就可能會查詢很久，可能有人會說，這不怕，能夠分庫分表啊，將一半的數據分到令一個數據表甚至數據庫中，這確實是個辦法，不過其實登陸也就僅僅是用戶名和密碼、驗證碼，何須搞那麼多呢，並且將用戶名密碼和我的私人信息放在一塊兒也不安全，萬一哪天被盜，那就把我的信息透露完了，若是隻把用戶名、密碼、驗證碼只與登陸有關的放在一個表，那可能自動就會少一些，我的信息泄露的風險也會下降一點。在作功能時，會有單一原則，在作表的設計時也能夠考慮，可能有的會說，也不能太單一了，不是有三級範式，能夠按照三級範式來進行設計，確實三級範式是一個很好的參考，平時在作表的設計時須要考慮三級範式，不過也有一些狀況比較特殊，因此仍是權衡着選擇。

2.字段的設計

仍是拿用戶表來講，用戶頭像也是比較常見的吧，可能有的是直接把頭像放入數據庫中，圖像佔的空間也是比較大的，可能全部的我的信息還沒一個頭像佔的空間大，這也致使了數據庫容量的增大，其實將頭像專門放到一個文件服務器，數據庫中只保存一個url也是一種對數據庫的優化。

3.sql語句

這個寫過sql的應該都會或多或少的瞭解，查詢一樣的數據有的sql查詢很快，有的就很慢，甚至會有死鎖，特別是本身苦思冥想了半天始終憋不出思路或者可憋出來了查詢數據很慢，等半天還沒結果，另外的小夥伴可能將本身的sql稍微改動改動就會很快查出結果，這種是比較尷尬的。sql語句的優化也有好多注意的，也有好多方法。

4.主鍵、索引、存儲過程等

對錶添加主鍵通常都會有，不論是邏輯主鍵仍是業務主鍵，但有一些查詢可能不是經過主鍵查的，特別是一些條件查詢，好比查詢特定時間段的數據，並且使用的也特別頻繁，這種可使用索引來提升速度，存儲過程也是，存儲過程是預編譯的相比直接sql仍是好一點的。

5.鎖、事務

系統中減小鎖與事務的使用，或者減小鎖的粒度，防止死鎖的發生，對於事務，特別是分佈式事務，使用它們都會下降數據庫的併發量。有的使用不慎，可能致使系統愈來愈慢。

3、數據庫架構方面

上面對數據庫的優化是從單個數據庫來講的，也是能夠知足必定的用戶需求的，若是用戶量比較大，訪問比較多，數據量也比較大，咱們能夠對數據庫架構進行優化，好比讀寫分離、分庫分表。

1.讀寫分離

咱們都知道二八原則，其實在互聯網中也能體現二八原則，用戶操做中大部分是瀏覽，讀的操做，一小部分是寫的操做，因此讀比較頻繁，寫就相對不頻繁，能夠將數據庫設計成一主多從或多主多從，這樣就能減小對一個數據庫服務器的壓力，一樣有利有弊，數據庫增多也會帶來一些新的問題，好比數據同步的問題，數據庫節點變化的問題，增長一個數據庫或減小一個數據庫可能就會致使一部分用戶映射不到。

2.分庫分表

分庫分表也是分而治之的思想，一個表或一個庫的數據比較大，那就放在多個表多個庫中，好比一個1000萬數據庫的表的查詢確定是沒有兩個500萬數據庫的表查詢快，一樣也是有利有弊，可能在系統設計階段進行分庫分表還好分一點，但對數據庫或表的水平擴展那就麻煩了，好比增長一個數據庫或表，那怎麼將原來用戶的數據映射到正確的數據庫或表中呢。這是均分數據，還有一種分庫分表是按時間或者按其餘因素來分，好比新聞類的，時效性比較強，用戶可能關注的也就一週的信息，那能夠將比較熱點的訪問頻率比較高的多放幾個數據庫，或者用SSD來存儲，這樣也會快一點。搶購也是，熱門的能夠專門搞一個數據庫或多部署幾個數據庫，這樣也能防止訪問量太高致使整個項目崩潰。

3.容災防災

容災防災也是對數據庫的優化，主要是對數據冗餘，可能常見的就是日誌、備份，定時按期作備份，防止數據丟失，經過日誌也能夠防止數據庫異常，防止數據丟失。咱們能夠將數據和日誌分開，放在不一樣的磁盤上，這樣也是一種方法來進行數據庫優化。還有一種備份是主從備份，這種有熱備份和冷備份，咱們可能聽過異地多活，其實這種咱們能夠把對數據庫的操做增長消息，讓多個地方來接收消息，這樣就能夠實現數據同步，達到異地多活的目的。

4、硬件方面

硬件方面也有不少，好比網絡帶寬、服務器內存、操做系統、CPU還有上面說的SSD固態硬盤等。

5、我的總結

上面列舉的可能也不是太全面，畢竟我也不是這方面的專家，對數據庫的設計經驗可能也不是太多，也只設計過兩三個項目並且也都是小的項目，並且上面的每一點若是要深刻研究可能又有好多東西要學，均可以單獨展開學習，對數據庫性能的優化也不是單個方面的，可能上面的各個方面都要用到。這是我在這兩天去惠州玩的過程當中的一些思考與總結，歡迎各位指點,或者有好的觀點也能夠多多交流。