系統效能調優(2)—-資料庫設計最佳化

1、邏輯設計的正常化

所謂邏輯設計的正常化就是使得資料庫的邏輯更加合理。說白了就是我們平時所說的三範式。具體內容可以參考筆者之前的文章。

現在總結如下：

第一範式：原子不可再分

第二範式：只能依賴主鍵

第三範式：不能依賴其他

其實三範式說到底就是方便尋找、防止冗餘，比如第一範式中原子性，就是把資訊單元化，方便使用者的查詢，試想如果資料不容易查詢還要資料庫幹什嗎？第二範式和第三範式是從不同的方面來描述其他非主鍵的欄位，第二和第三範式保證了資料庫的不冗餘。這使得資料庫在新增和更新的時候效率大大提高。

資料庫範式中一共有五個，這裡就只介紹三個。因為在實際項目中會發現真正能遵守三範式的項目很少，有很多項目為了提高尋找效率不得不讓資料庫存在冗餘，下面將詳細介紹。

2、合理的冗餘

任何事物都有兩面性，三範式也不例外，達到一個平衡就好。就像前面文章中提到的系統效能的瓶頸都是相對的，原則就一條：誰影響整個系統的效能就解決誰。上面已經提到了三範式在一定程度上提高了資料庫的查詢效率，同時減少不必要的冗餘，但是如果資料量大需要大量聯集查詢的時候那麼影響查詢效率的就是三範式了。

例如User表中的name欄位，如果按照三範式的要求name欄位就應該放在User表中其他地方只存User的ID。但是如果在另一張表訂單表（Order）中需要User表的name欄位這時就不得不將兩個表進行關聯，在資料量小的時候採用聯集查詢的方式是沒有問題的。一旦資料量超過百萬千萬甚至更大的時候聯集查詢對效能的影響就顯現出來了，這時完全就可以將name欄位冗餘的放在Order表中。需要注意的時候再在戶修改姓名（一般很少有人修改）的時候需要修改兩個地方Order表和User表，適當的冗餘提高了效率。

“放棄”三範式導致一定的資料冗餘，減少了聯集查詢，但最終目的還是提高效率。

3、索引的設計

在設計階段，可以根據功能和效能的需求進行初步的索引設計，這裡需要根據預計的資料量和查詢來設計索引，可能與將來實際使用的時候會有所區別。

關於索引的選擇，應改主意：

A、根據資料量決定哪些表需要增加索引，資料量小的可以只有主鍵。

B、根據使用頻率決定哪些欄位需要建立索引，選擇經常作為串連條件、篩選條件、彙總查詢、排序的欄位作為索引的候選欄位。

C、把經常一起出現的欄位組合在一起，組成複合式索引，複合式索引的欄位順序與主鍵一樣，也需要把最常用的欄位放在前面，把重複率低的欄位放在前面。

D、一個表不要加太多索引，因為索引影響插入和更新的速度

索引不單單是需要在設計資料庫時候需要考慮，在系統維護解決效能瓶頸的時候同樣是一把屢試不爽的絕招。關於索引在系統後期維護中的最佳化後面文章將詳細敘述。

總結：

系統效能的提高是為了提高系統的執行速度和準確的處理資料。往往系統效能的調優是等到遇到系統瓶頸的時候再去做，這無可厚非誰也不是Crowdsourced Security Testing，但是我們可以根據自己或者他人已有的經驗把調優的的過程放在開始設計的階段。在得到需求的時候要考慮系統將會遇到哪些瓶頸，（當然不要過分設計，過分設計的後果就是增大系統的開銷）然後根據預估的瓶頸進行有效預防（比如合理的索引、高效的主鍵設計等等）。總之效能的最佳化絕不是遇到瓶頸才開始做的，從設計階段就考慮效能問題才是明智之舉。