web開發者應該瞭解的數據庫優化知識

數據庫軟件是server端數據存儲、查詢的抽象層，是數據與計算分離的設計典範。因爲其實現的專業化和複雜度，如何正確使用或者優化數據庫的訪問對大多數web開發者都是一個極大的挑戰。這裏嘗試從應用程序開發者的角度總結一下數據庫使用和優化須要注意的一些問題，不求大而全，但求準確有效。

數據庫性能影響因素

Five steps to postgres performance 總結概括的很好，從5個層次來分析影響數據庫性能的因素。

服務器應用開發者常常接觸的是application和middleware兩個層面，這也是我關注的重點，其餘簡單涉獵一下。

應用和中間件

這部分其實就是web開發者直接控制的部分，在編程訪問數據庫的時候到底要寫代碼才能作到高效呢？從應用層面，咱們能夠注意如下這些地方：

• 數據庫表的設計要合理
  這是最體驗架構功力的地方，不同的問題不同的設計。這裏無法總結通用法則，只能提醒本身設計出來的表考慮好性能與知足1/2/3NF/BCNF範式作好平衡，具體數據庫的設計範式是個讓人頭大的知識點，貼個連接常常翻翻吧，數據庫範式。儘可能往高級的範式靠攏以達到儘可能小的數據冗餘，這樣常常會致使不少小表的聯合查詢，若是實在影響性能能夠增長冗餘來得到快速的查詢。

• 合理使用索引
  索引是個性能利器，但要用之有度，濫用有害：

  • foreign和unique通常自動索引

  • 查詢語句中出現的域通常加索引

  • 考慮使用不一樣類型的索引：expressions, full text, partial

  • 更新、插入、刪除等寫操做頻繁時慎用索引

  • 小表不必索引

  • 取值範圍小的域加索引意義不大

• 分表、分庫和分區
  分表和分庫相似，只是操做的實體不一樣。策略上分爲水平切分和垂直切分，但都須要application作相應的適配。具體實際操做自行google吧。分區仍是保持單個表的存在，只是把表分紅不少小塊，而後能夠把這些塊存在不一樣的硬盤區域。分區通常是DBA作的，對應用開發透明，不須要應用來適配。

• sql操做的優化

  • 儘可能合併操做

  • 慎用外鍵，看是否程序保持關聯更高效

  • 拒絕select *,指定須要的列名

  • 用in代替or

  • 若是使用ORM (object relational mapping)框架，能夠轉成sql語句再調性能

• 使用cache
  cache用的好能夠極大的提升服務響應速度，減輕數據庫的壓力，由於你根本沒去查數據庫。cache說開了去，不少地方均可以應用，這裏單看一下server應用程序這一塊。

  • 應用程序大量使用cache，減小訪問db，能夠cache整個頁面、函數或單個對象或數據

  • 使能數據庫cache

• 控制管理數據庫的鏈接數
  每一個進程與數據庫server通訊都經過一個獨佔的鏈接，鏈接是有開銷的，再多進程編程中要注意控制這個開銷。

數據庫、操做系統和硬件層面的優化

大多數狀況下，web開發者不關心或者也不必涉及到這部份內容。做爲一個完整的總體，瞭解這部份內容有助於理解整個系統是怎樣工做的。

• 硬件
  web服務器軟件和數據庫軟件，對於硬件資源的消耗主要是CPU、RAM、本地IO和網絡方面。在搭建本身的服務器時，根據本身的可提供的服務規模能夠大致估算出須要什麼型號和多大的CPU、RAM、磁盤、網絡帶寬。知足定義的最大容量的基礎上，考慮多一些冗餘。從性能上講，要考慮CPU IO在各級的性能表現，貼一個大概的IO表現。

• 操做系統和文件系統
  通常的web服務器程序不用考慮對操做系統和文件系統作特殊的調整或優化，但有些重度依賴數據的應用好比數據倉庫會考慮作這方面的工做。

  • 文件系統選XFS & JFS或者Ext3, 減小log 「-data=writeback, noatime, nodiratime」

  • 數據庫log文件使用單獨的文件路徑甚至磁盤

  • 調大shmmax/shmall in kernel以得到更多共享內存

  • OS版本2.6.9的表現很差

  • 設置開啓性能監控，監控CPU/ram/disk/network的使用狀況

• 數據庫配置
  這是DBA(數據庫管理員)的本職工做，不一樣的數據庫配置也不盡相同。其實這部分過於複雜，直接跳過。通常狀況下使用默認的推薦配置，有問題再查資料調整。隨手貼個oracle的架構，幫助我理解一次數據讀寫大概怎樣完成的。

數據庫優化方法論

有必要強調一下方法論，避免頭痛醫腳、南轅北轍的笑話。你走到數據庫優化這一步，務必肯定是你benchmark並分析過認定數據庫的操做是瓶頸，不然不要想固然的認爲這裏有問題，極可能只是你的想象，並不真正解決問題。這種事情一直再發生，我本身也常常犯這樣的混。
若是確實是數據庫的瓶頸，咱們以postgresql爲例看有哪些有效的方法呢。

benchmark->分析->修改嘗試->benchmark->...不斷的重複這個閉環。最重要的是第一步，postgresql performance monitoring這裏總結了不少方法。

數據庫高性能若干規則

前面提到了很多建議和規則，更多的能夠參考閱讀：
Best Practices for Speeding Up Your Web Site
20 database design rules
Database optimization techniques you can actually use
面向程序員的數據庫訪問性能優化法則
high-performance-mysql