從網上去搜數據庫優化基本都是從SQL層次進行優化的,不多有說起到數據庫自己的實例優化。就算有也都是基於某個特定數據庫的實例優化,本文涵蓋目前市面上全部主流數據庫的實例優化(Oralce、MySQL、POSTGRES、達夢),按照文章的配置可以將你數據庫性能用到80%或以上。數據庫
這部分爲理論知識,不感興趣的同窗能夠直接跳到後面參數配置部分。緩存
根據角色的不一樣,數據庫優化分爲如下幾個目標:安全
在進行數據庫優化的時候可能會有如下幾個誤區:服務器
完整的數據庫優化流程以下:微信
首先須要儘量的瞭解優化問題,收集問題期間系統信息並作好存檔。根據當前系統問題表現制定優化目標並與客戶溝通目標達成一致;經過一系列工具分析系統問題,制定優化方案,方案評審完成後由各負責人員進行實施。若達到優化目標則編寫優化報告,不然須要從新制定優化方案。session
數據庫實例優化遵循三句口訣:日誌不能小、緩存足夠大、鏈接要夠用。架構
數據庫事務提交後須要將事務對數據頁的修改刷( fsync)到磁盤上,才能保證數據的持久性。這個刷盤,是一個隨機寫,性能較低,若是每次事務提交都要刷盤,會極大影響數據庫的性能。數據庫在架構設計中都會採用以下兩個優化手法:運維
因此日誌跟緩存對數據庫實例尤爲重要。而鏈接若是不夠用,數據庫會直接拋出異常,系統沒法訪問。工具
主流數據庫架構都有以下的共同點:性能
接下來咱們根據不一樣的數據庫調整參數以使數據庫達到最佳性能。
參數分類 | 參數名 | 參數值 | 備註 |
---|---|---|---|
數據緩存 | SGATAGET、MEMORYTARGET | 物理內存70-80% | 越大越好 |
數據緩存 | DBCACHESIZE | 物理內存70-80% |
越大越好 |
SQL解析 | SHAREDPOOLSIZE |
4-16G |
不建議設置過大 |
監聽及鏈接 | PROCESSES、SESSIONS、OPEN_CURSORS | 根據業務需求設置 |
通常爲業務預估鏈接數的120% |
其餘 | SESSIONCACHEDCURSORS | 大於200 |
軟軟解析 |
參數分類 | 參數名 | 參數值 | 備註 |
---|---|---|---|
數據緩存 | INNODBBUFFERPOOL_SIZE | 物理內存50-80% | 通常來講越大性能越好 |
日誌相關 | Innodblogbuffer_size | 16-32M |
根據運行狀況調整 |
日誌相關 | sync_binlog | 一、100、0 |
1安全性最好 |
監聽及鏈接 | max_connections |
根據業務狀況調整 | 能夠預留一部分值 |
文件讀寫性能 | innodbflushlogattrx_commit | 2 |
安全和性能的折中考慮 |
其餘 | waittimeout,interactivetimeout | 28800 |
避免應用鏈接定時中斷 |
參數分類 | 參數名 | 參數值 | 備註 |
---|---|---|---|
數據緩存 | SHARED_BUFFERS | 物理內存10-25% | |
數據緩存 | CACHEBUFFERSIZE | 物理內存50-60% | |
日誌相關 | wal_buffer | 8-64M |
不建議設置過大太小 |
監聽及鏈接 | max_connections |
根據業務狀況調整 | 通常爲業務預估鏈接數的120% |
其餘 | maintenanceworkmem | 512M或更大 |
|
其餘 | work_mem | 8-16M |
原始配置1M太小 |
其餘 | checkpoint_segments | 32或者更大 |
參數分類 | 參數名 | 參數值 | 備註 |
---|---|---|---|
數據緩存 | MEMROYTARGET、MEMROYPOOL | 物理內存90% | |
數據緩存 | BUFFER | 物理內存60% |
數據緩存 |
數據緩存 | MAX_BUFFER | 物理內存70% |
最大數據緩存 |
監聽及鏈接 | max_sessions |
根據業務需求設置 | 通常爲業務預估鏈接數的120% |
數據庫的優化手法太多太多,有換磁盤陣列升級硬件,有改寫SQL腳本添加索引,還有數據庫參數調整優化性能,甚至還能夠調整數據庫架構。本文從數據庫自己參數進行調優,你們根據上面幾張表中的參數進行調整基本能達到數據庫最佳性能的80%。
獲取更多內容請關注公衆號:JAVA日知錄