資料庫最佳化處理

標籤：str   使用者需求   緩衝機制   常量   互連網   建表   bsp   容災   重要   

資料庫的最佳化程度影響了一個程式的執行力和使用者的體驗感，所以資料庫的最佳化顯得格外重要。

一、架構

　　根據業務需求選擇合適的開發架構，不近對資料庫的最佳化有協助，而且對於程式後期的維護也很有協助，根據項目的需求，看項目需要滿足多少人的訪問量，並發量到多少。不是說小公司就不需要分布式、大資料這些，考慮長期的問題。

　　將一些固定不常變化的值，設定為常量；採用緩衝機制，減少對於資料庫的訪問（串連池）；伺服器的最佳化（隊列）；

二、資料庫本身

　1.表結構的設計

　　　表的設計來源於需求，同時表的建立也會影響需求的實現，一般建表採用第三範式（確保每列都和主鍵列直接相關,而不是間接相關）,但是也是根據需求進行選擇。

　　　　【解釋：第三範式】

　　　　比如在設計一個訂單資料表的時候，可以將客戶編碼作為一個外鍵和訂單表建立相應的關係。而不可以在訂單表中添加關於客戶其它資訊（比如姓名、所屬公司等）的欄位。如下面這兩個表所示的設計就是一個滿足第三範式的資料庫表。

　　    【例子：登入表】

　　    一般項目都會有登入功能，而且也是比較經常訪問的，我見過的大部分的系統，表的設計是將使用者登入的密碼放在使用者個人資訊表中，一個使用者資訊表可能會有二三十個欄位，甚至包含手機號、郵箱等一些比較隱私的資訊。像這種也是能實現需求的，不過以後使用者多的時候，達到百萬千萬級時，一條記錄這麼多欄位，這麼多的使用者那一個表的資料也是蠻大的，僅僅是實現登入功能，就可能會查詢好久，可能有人會說，這不怕，可以分庫分表啊，將一半的資料分到令一個資料表甚至資料庫中，這確實是個辦法，不過其實登入也就僅僅是使用者名稱和密碼、驗證碼，何必搞那麼多呢，而且將使用者名稱密碼和個人私人資訊放在一起也不安全，萬一哪天被盜，那就把個人資訊透露完了，如果只把使用者名稱、密碼、驗證碼只與登入有關的放在一個表，那可能自動就會少一些，個人資訊泄露的風險也會降低一點。

2.欄位的設計

　　還是拿使用者表來說，帳戶圖片也是比較常見的吧，可能有的是直接把頭像放入資料庫中，映像占的空間也是比較大的，可能所有的個人資訊還沒一個頭像占的空間大，這也導致了資料庫容量的增大，其實將頭像專門放到一個檔案伺服器，資料庫中只儲存一個url也是一種對資料庫的最佳化。

三、資料庫結構描述方面

上面對資料庫的最佳化是從單個資料庫來說的，也是可以滿足一定的使用者需求的，如果使用者量比較大，訪問比較多，資料量也比較大，我們可以對資料庫結構描述進行最佳化，比如讀寫分離、分庫分表。

1.讀寫分離

我們都知道二八原則，其實在互連網中也能體現二八原則，使用者操作中大部分是瀏覽，讀的操作，一小部分是寫的操作，所以讀比較頻繁，寫就相對不頻繁，可以將資料庫設計成一主多從或多主多從，這樣就能減少對一個資料庫伺服器的壓力，同樣有利有弊，資料庫增多也會帶來一些新的問題，比如資料同步的問題，資料庫節點變化的問題，增加一個資料庫或減少一個資料庫可能就會導致一部分使用者映射不到。

2.分庫分表

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

3.容災防災

容災防災也是對資料庫的最佳化，主要是對資料冗餘，可能常見的就是日誌、備份，定時定期做備份，防止資料丟失，通過日誌也可以防止資料庫異常，防止資料丟失。我們可以將資料和日誌分開，放在不同的磁碟上，這樣也是一種方法來進行資料庫最佳化。還有一種備份是主從備份，這種有熱備份和冷備份，我們可能聽過異地多活，其實這種我們可以把對資料庫的操作增加訊息，讓多個地方來接收訊息，這樣就可以實現資料同步，達到異地多活的目的。

四、硬體方面

硬體方面也有很多，比如網路頻寬、伺服器記憶體、作業系統、CPU還有上面說的SSD固態硬碟等。

資料庫最佳化處理