達夢跟mysql效能 資料庫優化 例項優化

2021-10-18 08:45:14 字數 1719 閱讀 8930

從網上去搜資料庫優化基本都是從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

mysql(innodb)

postgres

達夢資料庫

總結資料庫的優化手法太多太多,有換磁碟陣列公升級硬體,有改寫sql指令碼新增索引,還有資料庫引數調整優化效能,甚至還可以調整資料庫架構。本文從資料庫本身引數進行調優,大家根據上面幾張表中的引數進行調整基本能達到資料庫最佳效能的80%。

達夢資料庫和mysql索引引擎 達夢資料庫 索引

1.索引的種類和功能 聚集索引 每乙個普通表有且只有乙個聚集索引 唯一索引 索引資料根據索引鍵唯一 函式索引 包含函式 表示式的預先計算的值 位圖索引 對低基數的列建立位圖索引 位圖連線索引 針對兩個或者多個表連線的點陣圖索引,主要用於資料倉儲中 全文索引 在表的文字列上而建的索引。2.何時使用索引...

mysql資料庫遷移達夢資料庫

我們安裝好達夢資料庫之後,便可以在開始 所有工具 達夢資料庫中看到它的結構 我們選擇dm資料遷移工具,然後點選進去 然後在遷移管理裡右鍵新建工程 然後輸入工程名即可,可以隨便起。點選確定 然後選中專案下的遷移,右鍵新建遷移 遷移名稱也是一樣,可以隨便起。點選確定 然後看到該頁面,點選下一步 然後選擇...

達夢資料庫操作

1.安裝 dminstall.bin i接下來是一些設定,比如 語言 key檔案的位置 時區 安裝型別 安裝目錄 略過 2.初始化 進入你剛才設定的安裝目錄的bin目錄下執行 dminit這是我自己的設定 input system dir home dmdba dmdata input db nam...