數據庫優化 - 實例優化

從網上去搜數據庫優化基本都是從SQL層次進行優化的，不多有說起到數據庫自己的實例優化。就算有也都是基於某個特定數據庫的實例優化，本文涵蓋目前市面上全部主流數據庫的實例優化（Oralce、MySQL、POSTGRES、達夢）,按照文章的配置可以將你數據庫性能用到80%或以上。

數據庫優化方法論

這部分爲理論知識，不感興趣的同窗能夠直接跳到後面參數配置部分。

數據庫優化目標

目標

根據角色的不一樣，數據庫優化分爲如下幾個目標：

• 業務角度（關鍵用戶）： 減小用戶頁面響應時間
• 數據庫角度（開發）： 減小數據庫SQL響應時間
• 數據庫服務器角度（運維）： 充分使用數據庫服務器物理資源 減小數據庫服務器CPU使用率 減小數據庫服務器IO使用率 減小數據庫服務器內存使用率

指標

• SQL平均響應時間變短
  • 優化前：數據庫平均響應時間500ms
  • 優化目標：數據庫平均響應時間200ms
• 數據庫服務器CPU佔用率變少
  • 優化前：數據庫高峯期CPU使用率70%
  • 優化目標：數據庫高峯期CPU使用率50%
• 數據庫服務器IO使用率變低
  • 優化前：數據庫IO WAIT爲30%
  • 優化目標：數據庫IO WAIT低於10%

數據庫優化誤區

在進行數據庫優化的時候可能會有如下幾個誤區：

• 優化以前必定要深刻了解數據庫內部原理 優化是有「套路」的，照着這些「套路」你也能夠很好的完成數據庫優化
• 不斷調整數據庫參數就能夠最終實現優化 有時候設計不合理怎麼調整參數都不行
• 不斷調整操做系統參數就能夠最終實現優化 同上
• 數據庫性能由應用、數據庫架構決定，與應用開發關係不大 偏偏相反，應用開發的關係很大
• 必需要作讀寫分離，必需要弄分庫分表 數據量級只有達到必定的比例纔有必要作讀寫分離，分表分庫，不然徒增複雜度。通常來講Oracle的單表量級能夠達到1億，MySQL到1000萬~2000萬

數據庫優化流程

完整的數據庫優化流程以下：

首先須要儘量的瞭解優化問題，收集問題期間系統信息並作好存檔。根據當前系統問題表現制定優化目標並與客戶溝通目標達成一致；經過一系列工具分析系統問題，制定優化方案，方案評審完成後由各負責人員進行實施。若達到優化目標則編寫優化報告，不然須要從新制定優化方案。

數據庫實例優化

數據庫實例優化遵循三句口訣：日誌不能小、緩存足夠大、鏈接要夠用。

數據庫事務提交後須要將事務對數據頁的修改刷（ fsync）到磁盤上，才能保證數據的持久性。這個刷盤，是一個隨機寫，性能較低，若是每次事務提交都要刷盤，會極大影響數據庫的性能。數據庫在架構設計中都會採用以下兩個優化手法：

• 先將事務寫到日誌文件RedoLog（WAL），將隨機寫優化成順序寫
• 加一層緩存結構Buffer，將每次寫優化成順序寫

因此日誌跟緩存對數據庫實例尤爲重要。而鏈接若是不夠用，數據庫會直接拋出異常，系統沒法訪問。

數據庫參數優化

主流數據庫架構都有以下的共同點：

• 數據緩存
• SQL解析區
• 排序內存
• REDO及UNDO
• 鎖、LATCH、MUTEX
• 監聽及鏈接
• 文件讀寫性能

接下來咱們根據不一樣的數據庫調整參數以使數據庫達到最佳性能。

ORACLE

參數分類	參數名	參數值	備註
數據緩存	SGA_TAGET、MEMORY_TARGET	物理內存70-80%	越大越好
數據緩存	DB_CACHE_SIZE	物理內存70-80%	越大越好
SQL解析	SHARED_POOL_SIZE	4-16G	不建議設置過大
監聽及鏈接	PROCESSES、SESSIONS、OPEN_CURSORS	根據業務需求設置	通常爲業務預估鏈接數的120%
其餘	SESSION_CACHED_CURSORS	大於200	軟軟解析

MYSQL（INNODB）

參數分類	參數名	參數值	備註
數據緩存	INNODB_BUFFER_POOL_SIZE	物理內存50-80%	通常來講越大性能越好
日誌相關	Innodb_log_buffer_size	16-32M	根據運行狀況調整
日誌相關	sync_binlog	一、100、0	1安全性最好
監聽及鏈接	max_connections	根據業務狀況調整	能夠預留一部分值
文件讀寫性能	innodb_flush_log_at_trx_commit	2	安全和性能的折中考慮
其餘	wait_timeout，interactive_timeout	28800	避免應用鏈接定時中斷

POSTGRES

參數分類	參數名	參數值	備註
數據緩存	SHARED_BUFFERS	物理內存10-25%
數據緩存	CACHE_BUFFER_SIZE	物理內存50-60%
日誌相關	wal_buffer	8-64M	不建議設置過大太小
監聽及鏈接	max_connections	根據業務狀況調整	通常爲業務預估鏈接數的120%
其餘	maintenance_work_mem	512M或更大
其餘	work_mem	8-16M	原始配置1M太小
其餘	checkpoint_segments	32或者更大

達夢數據庫

參數分類	參數名	參數值	備註
數據緩存	MEMROY_TARGET、MEMROY_POOL	物理內存90%
數據緩存	BUFFER	物理內存60%	數據緩存
數據緩存	MAX_BUFFER	物理內存70%	最大數據緩存
監聽及鏈接	max_sessions	根據業務需求設置	通常爲業務預估鏈接數的120%

總結

數據庫的優化手法太多太多，有換磁盤陣列升級硬件，有改寫SQL腳本添加索引，還有數據庫參數調整優化性能，甚至還能夠調整數據庫架構。本文從數據庫自己參數進行調優，你們根據上面幾張表中的參數進行調整基本能達到數據庫最佳性能的80%。

歡迎關注個人我的公衆號：JAVA日知錄