1、邏輯設計的規範化
所謂邏輯設計的規範化就是使得資料庫的邏輯更加合理。說白了就是我們平時所說的三正規化。具體內容可以參考筆者之前的文章
。 現在總結如下：
第一正規化：原子不可再分
第二正規化：只能依賴主鍵
第三正規化：不能依賴其他
其實三正規化說到底就是方便查詢、防止冗餘，比如第一正規化中原子性，就是把資訊單元化，方便使用者的查詢，試想如果資料不容易查詢還要資料庫幹什麼？第二正規化和第三正規化是從不同的方面來描述其他非主鍵的字段，第二和第三正規化保證了資料庫的不冗餘。這使得資料庫在新增和更新的時候效率大大提高。
資料庫正規化中一共有五個，這裡就只介紹三個。因為在實際專案中會發現真正能遵守三正規化的專案很少，有很多專案為了提高查詢效率不得不讓資料庫存在冗餘，下面將詳細介紹。
2
、合理的冗餘
任何事物都有兩面性，三正規化也不例外，達到乙個平衡就好。就像前面文章中提到的系統效能的瓶頸都是相對的，原則就一條：誰影響整個系統的效能就解決誰。上面已經提到了三正規化在一定程度上提高了資料庫的查詢效率，同時減少不必要的冗餘，但是如果資料量大需要大量聯合查詢的時候那麼影響查詢效率的就是三正規化了。
例如user表中的name欄位，如果按照三正規化的要求name欄位就應該放在user表中其他地方只存user的id。但是如果在另一張表訂單表（order）中需要user表的name欄位這時就不得不將兩個表進行關聯，在資料量小的時候採用聯合查詢的方式是沒有問題的。一旦資料量超過百萬千萬甚至更大的時候聯合查詢對效能的影響就顯現出來了，這時完全就可以將name欄位冗餘的放在order表中。需要注意的時候再在戶修改姓名（一般很少有人修改）的時候需要修改兩個地方order表和user表，適當的冗餘提高了效率。
「放棄」三正規化導致一定的資料冗餘，減少了聯合查詢，但最終目的還是提高效率。
3
、索引的設計
在設計階段，可以根據功能和效能的需求進行初步的索引設計，這裡需要根據預計的資料量和查詢來設計索引，可能與將來實際使用的時候會有所區別。
關於索引的選擇，應改主意：
a、根據資料量決定哪些表需要增加索引，資料量小的可以只有主鍵。
b、根據使用頻率決定哪些字段需要建立索引，選擇經常作為連線條件、篩選條件、聚合查詢、排序的字段作為索引的候選字段。
c、把經常一起出現的字段組合在一起，組成組合索引，組合索引的字段順序與主鍵一樣，也需要把最常用的字段放在前面，把重複率低的字段放在前面。
d、乙個表不要加太多索引，因為索引影響插入和更新的速度
索引不單單是需要在設計資料庫時候需要考慮，在系統維護解決效能瓶頸的時候同樣是一把屢試不爽的絕招。關於索引在系統後期維護中的優化後面文章將詳細敘述。
總結：
系統效能的提高是為了提高系統的執行速度和準確的處理資料。往往系統效能的調優是等到遇到系統瓶頸的時候再去做，這無可厚非誰也不是先知，但是我們可以根據自己或者他人已有的經驗把調優的的過程放在開始設計的階段。在得到需求的時候要考慮系統將會遇到哪些瓶頸，（當然不要過分設計，過分設計的後果就是增大系統的開銷）然後根據預估的瓶頸進行有效的預防（比如合理的索引、高效的主鍵設計等等）。總之效能的優化絕不是遇到瓶頸才開始做的，從設計階段就考慮效能問題才是明智之舉。
系統效能調優 2 資料庫設計優化
1 邏輯設計的規範化 所謂邏輯設計的規範化就是使得資料庫的邏輯更加合理。說白了就是我們平時所說的三正規化。具體內容可以參考筆者之前的文章 現在總結如下 第一正規化 原子不可再分 第二正規化 只能依賴主鍵 第三正規化 不能依賴其他 其實三正規化說到底就是方便查詢 防止冗餘，比如第一正規化中原子性，就是...
系統效能調優
系統效能調優 效能測試分析人員經過對結果的分析以後，有可能提出系統存在效能瓶頸。這時相關開發人員 資料庫管理員 系統管理員 網路管理員等就需要根據效能測試分析人員提出的意見同效能分析人員共同分析確定更細節的內容，相關人員對系統進行調整以後，效能測試人員繼續進行第二輪 第三輪 的測試，與以前的測試結果...
系統效能調優
系統效能調優 效能測試分析人員經過對結果的分析以後，有可能提出系統存在效能瓶頸。這時相關開發人員 資料庫管理員 系統管理員 網路管理員等就需要根據效能測試分析人員提出的意見同效能分析人員共同分析確定更細節的內容，相關人員對系統進行調整以後，效能測試人員繼續進行第二輪 第三輪 的測試，與以前的測試結果...