數據庫優化之結構設計

設計好處

• 良好的數據庫邏輯設計和物理設計師數據庫得到高性能的基礎
• 範式化設計和反範式化設計（減小冗餘、減小異常、讓數據組織的更加和諧）

• 優化目的

  - 減小數據冗餘（儘可能）
  - 儘可能避免數據維護中出現更新、插入和刪除等異常
      - 插入：若是表中的某個實體隨着另外一個實體而存在
      - 更新：若是更改表中的某個實體的單獨屬性時，須要對多表進行更新
      - 刪除：若是刪除表中的某一時則會致使其餘實體的消失

設計過程

• 需求分析

  • 全面瞭解產品設計的需求
  • 存儲需求（好比一對多，多對一等）
  • 數據處理需求
  • 數據的安全性和完整性

• 邏輯分析

  • 設計數據的邏輯存儲結構
  • 數據實體以前的邏輯關係，解決數據冗餘和數據維護異常

• 物理設計

  • 根據所使用數據特色設計表結構

• 維護優化

  • 對索引、存儲結構等進行優化

• 範式化

  • 設計沒有數據冗餘和數據維護異常的數據庫結構

• 反範式化

  • 針對範式化而言的，在前面介紹了數據庫設計的範式，所謂的反範式化就是爲了性能和讀取效率的考慮而適當的對數據庫設計範式的要求進行違法，而容許存在少許的數據冗餘，換句話來講反範式化就是使用空間來換取時間

本篇重點解釋物理設計、範式化與反範式化化各自優缺點；其餘將在文章《數據庫優化》系列一一講明；

範式化與反範式化

• 範式化設計的優缺點

  • 優勢

    • 儘可能減小數據冗餘
    • 範式化的更新操做比反範式化更快
    • 範式化的表一般比反範式更小

  • 缺點

    • 對於查詢須要對多個表進行關聯（mysql限制不能超過10張表）
    • 更難進行索引優化

• 反範式化設計的優缺點

  • 優勢

    • 減小表的關聯
    • 更好的進行索引優化

  • 缺點

    • 存在數據冗餘及數據庫維護異常
    • 對數據修改須要更多的成本

設計範式化要求的三範式：
第一範式

• 數據庫表中的全部字段都只具備單一屬性
• 單一屬性的列是由基本的數據類型所構成的
• 設計及出來的表都是簡單的二維表

第二範式

• 要求一個表中只具備一個業務主鍵，也就是說符合第二範式的表中不能存在非主鍵列對只對部分主鍵的依賴關係

第三範式

• 數據不能存在傳遞關係，即每一個屬性都跟主鍵有直接關係而不是間接關係

物理設計

• 物理設計的內容

  • 定義數據庫、表及字段的命名規範
  • 選擇合適的存儲引擎
  • 爲表中的字段選擇合適的數據類型
  • 創建數據庫結構

• 定義數據庫、表及字段的命名規範

  • 可讀性原則
  • 表意行原則
  • 長名原則
• 選擇合適的存儲引擎

存儲引擎	事務	鎖粒度	主要應用	忌用
MyISAM	不支持	支持併發插入的表級鎖	SELECT、INSERT	讀寫操做頻繁
MRG_MYISAM	不支持	支持併發插入的表級鎖	分段歸檔，數據倉庫	全局查找過多的場景
Innodb	支持	支持MVCC的行級鎖	事務處理	無
Archive	不支持	行級鎖	日誌記錄，只支持insert，select	須要隨機讀取，更新，刪除
Ndb cluster	支持	行級鎖	高可用性	大部分應用

• 爲表中的字段選擇合適的數據類型（數據頁）

  • 當一個列能夠選擇多種數據類型時，應該優先考慮數字類型，其次是日期或二進制類型，最後是字符類型。對於相同級別的數據類型，應該優先選擇佔用空間小的數據類型

• 如何爲Innodb選擇主鍵

  • 主鍵應該儘量的小
  • 主鍵應該是順序增加的
  • Innodb的主鍵和業務主鍵能夠不一樣；

---

相關連接
《數據庫優化之實例和故事》、《 數據庫優化之什麼影響性能》

做者：不動峯
博客園： http://www.cnblogs.com/mylly/ 版權全部，歡迎保留原文連接進行轉載：)