MYSQL效能調優概述

2021-06-05 15:48:45 字數 3151 閱讀 2200

1,硬體優化

a>記憶體??大記憶體、大記憶體位寬,盡量不要用swap;

b>硬碟??15000rpm、raid5、raid10

c>cpu??64位、高主頻、高快取,高並行處理能力

d>網路??標配的千兆網絡卡足矣,盡可能在同一區域網內,盡量避免諸如防火牆策略等不必要的開銷

2,架構上的優化

a>縱向拆解

最簡單的一台服務同時負責web、中介軟體、資料庫多個角色;縱向拆解後就是資料庫伺服器專機專用,避免額外的服務可能導致的效能下降和不穩定性;如果將資料庫伺服器專機專用仍然無法滿足需求,可以考慮在資料庫和應用伺服器之間加memcached。

b>橫向拆解

主從同步、負載均衡、高可用性集群,當單個mysql資料庫無法滿足日益增加的需求時,可以考慮在資料庫這個邏輯層面增加多台伺服器,以達到穩定、高效的效果。

3,作業系統級別的優化

a>64位系統可以分給單個程序更多的記憶體、服務調優,禁用不必要啟動的服務,修改檔案描述符限制,留更多的資源給mysql;

b>檔案系統調優,給資料倉儲乙個單獨的檔案系統,推薦使用xfs,一般效率更高、更可靠。

c>可以考慮在掛載分割槽時啟用noatime選項。

4,資料庫服務的優化

a>使用linux/bsd作業系統進行編譯安裝,對編譯引數進行效能優化,精簡不必要啟用的功能

b>合適的應用程式介面。

c>保持每個表都不要太大,可以對大表做橫切和縱切;比如說我要取得某id的lastlogin,完全可以做一張只有「id」和「lastlog」的小表,而非幾

十、幾百列資料的併排大表;另外對乙個有1000萬條記錄的表做更新比對10個100萬記錄的表做更新一般來的要慢

d>myisam引擎,表級鎖,單鎖開銷小,但影響範圍大,適合讀多寫少的表,不支援事物日誌;表鎖定不存在死鎖

e>innodb引擎,行級鎖,鎖定行的開銷要比鎖定全表要大,但影響範圍小,適合寫操作比較頻繁的資料表;行級鎖可能存在死鎖。

5,my.cnf內引數的優化;

優化總原則:給mysql的資源太少,則mysql施展不開;給mysql的資源太多,可能會拖累整個os。

a>總體資源占用的優化;

open_files_limit??mysqld可以開啟的檔案的數量;

max_connections??允許的並行客戶端連線數目;

max_connect_errors??允許的主機的錯誤連線數;

table_cache??每個鏈結允許開啟的表的數量;

max_allowed_packet??從伺服器接收的包的大小;

thread_cache_size??快取多少個待用執行緒;

b>具體buffer的優化

sort_buffer_size??每個執行緒可以分配的緩衝區的大小;

join_buffer_size??不走索引的join操作可分配的緩衝區的大小;

query_cache_size??為查詢分配的快取;

query_cache_limit??不快取大於該限制的查詢結果;

query_cache_min_res_unit??不快取小於該限制的查詢結果;

tmp_table_size??記憶體內的臨時表表超過該限制值,則寫入硬碟;

binlog_cache_size??二進位制日誌檔案的快取大小;

key_buffer_size??myisam引擎的索引塊共用緩衝區;

read_buffer_size??為從資料表順序讀取資料的讀操作保留的快取區的長度;

innodb_additional_mem_pool_size??innodb用來儲存資料目錄資訊&其它內部資料結構的記憶體池的大小。你應用程式裡的表越多,你需要在這裡分配越多的記憶體。

innodb_buffer_pool_size??innodb用來快取它的資料和索引的記憶體緩衝區的大小。理論上來說是越大越好,但要注意不要設定過大,否則,由於物理記憶體的競爭可能導致作業系統的換頁顛簸.

innodb_data_file_path??innodb表空間的指定以及大小,初始表空間大一些可以減少日後自增加表空間的系統開銷。

innodb_thread_concurrency??在innodb核心內的允許執行緒數量;

innodb_log_buffer_size??innodb用來往磁碟上的日誌檔案寫操作的緩衝區的大小。當日誌大小超過該限定時,日誌會被寫入磁碟,比寫入記憶體的i/o開銷大。

innodb_log_file_size??每個日誌檔案的大小。

max_allowed_packet??包服務所能處理的請求包的最大大小以及服務所能處理的最大的請求大小。

6,查詢優化,

a>建表時表結構要合理,每個表不宜過大;在任何情況下均應使用最精確的型別。例如,如果id列用int是乙個好主意,而用text型別則是個蠢辦法;time列酌情使用date或者datetime。

b>索引,所有的查詢都走科學的索引,單個索引命中率低時使用聯合索引;

c>查詢時儘量減少邏輯運算(與運算、或運算、大於小於某值的運算);

d>減少不當的查詢語句,不要查詢應用中不需要的列,比如說select * from 等操作。

e>減小事務包的大小;

f>將多個小的查詢適當合併成乙個大的查詢,減少每次建立/關閉查詢時的開銷;

g>將某些過於複雜的查詢拆解成多個小查詢,和上一條恰好相反

h>建立和優化儲存過程來代替大量的外部程式互動。

7,debug工具:

a>vmstat??vmstat 命令報告關於核心執行緒、虛擬記憶體、磁碟、陷阱和 cpu 活動的統計資訊,

b>iostat??iostat命令報告cpu、硬碟等裝置的輸入輸出情況,可能需要安裝sysstat rpm包

c>top??動態顯示當前系統的資源占用,和上文面的兩個命令相比,top更側重於程序。

d>free??顯示記憶體和swap占用情況。

e>show processlist??顯示當前執行或等待的執行緒,判斷哪些查詢語句總是處於等待狀態

f>explain??「explain + sql語句」檢視索引使用情況。

g>show create table + 「table_name」 ??檢視指定表的表結構

h> select count(distinct  「row_name」) from "table_name";檢視列內資料的唯一性,確定給哪一列建立索引。

i>create index 建立索引,並用 show processlist、top觀察建立索引後的效果。

mysql效能調優

1.對查詢進行優化,應盡量避免全表掃瞄,首先應考慮在 where 及 order by 涉及的列上建立索引。2.應盡量避免在where子句中對字段進行null判斷,否則會導致引擎放棄使用索引而進行全表掃瞄。3.應盡量避免在where子句中使用 或 操作符,否則會導致引擎放棄使用索引而進行全表掃瞄。4...

Mysql效能調優

mysql 效能調優有很多方面,主要是這幾個方面 1 正規化 是指表的列具有原子性,不可再拆分,只要資料庫是線性的,都自動滿足1nf。2 正規化 表中的紀錄是唯一的。3 正規化 表中資料不應該有冗餘,如果通過某個欄位就能得到跟該字段相關的資訊,就沒必要將這些資訊,再存放到該表中。在3nf中,可能會對...

MySQL效能調優

1 經常用來讀的表使用myisam儲存引擎 2 其餘的表都用innodb儲存引擎 1 在select where order by常涉及到的字段上建立索引 2 where子句中不使用 否則將放棄使用索引進行全表掃瞄 3 盡量避免用null值判斷,否則會全表掃瞄 示例 select id from t...