MySQL性能調優(yōu) – 你必須了解的15個重要變量

前言:

MYSQL 應該是最流行了 WEB 后端數(shù)據(jù)庫。雖然 NOSQL 最近越來越多的被提到，但是相信大部分架構師還是會選擇 MYSQL 來做數(shù)據(jù)存儲。本文作者總結梳理MySQL性能調優(yōu)的15個重要變量，又不足需要補充的還望大佬指出。

1.DEFAULT_STORAGE_ENGINE

如果你已經(jīng)在用MySQL 5.6或者5.7，并且你的數(shù)據(jù)表都是InnoDB，那么表示你已經(jīng)設置好了。如果沒有，確保把你的表轉換為InnoDB并且設置default_storage_engine為InnoDB。

為什么？簡而言之，因為InnoDB是MySQL(包括Percona Server和MariaDB)最好的存儲引擎 – 它支持事務，高并發(fā)，有著非常好的性能表現(xiàn)(當配置正確時)。這里有詳細的版本介紹為什么

2.INNODB_BUFFER_POOL_SIZE

這個是InnoDB最重要變量。實際上，如果你的主要存儲引擎是InnoDB，那么對于你，這個變量對于MySQL是最重要的。

基本上，innodb_buffer_pool_size指定了MySQL應該分配給InnoDB緩沖池多少內(nèi)存，InnoDB緩沖池用來存儲緩存的數(shù)據(jù)，二級索引，臟數(shù)據(jù)(已經(jīng)被更改但沒有刷新到硬盤的數(shù)據(jù))以及各種內(nèi)部結構如自適應哈希索引。

根據(jù)經(jīng)驗，在一個獨立的MySQL服務器應該分配給MySQL整個機器總內(nèi)存的80%。如果你的MySQL運行在一個共享服務器，或者你想知道InnoDB緩沖池大小是否正確設置，詳細請看這里。

3.INNODB_LOG_FILE_SIZE

InnoDB重做日志文件的設置在MySQL社區(qū)也叫做事務日志。直到MySQL 5.6.8事務日志默認值innodb_log_file_size=5M是唯一大的InnoDB性能殺手。從MySQL 5.6.8開始，默認值提升到48M,但對于許多稍繁忙的系統(tǒng)，還遠遠要低。

根據(jù)經(jīng)驗，你應該設置的日志大小能在你服務器繁忙時能存儲1-2小時的寫入量。如果不想這么麻煩，那么設置1-2G的大小會讓你的性能有一個不錯的表現(xiàn)。這個變量也相當重要，更詳細的介紹請看這里。

在進入下一個變量之前，讓我們來快速提及一下innodb_log_buffer_size?！翱焖偬峒啊笔且驗樗３２缓美斫獠⑶彝贿^度關注了。事實上大多數(shù)情況下你只需要使用小的緩沖 – 在事務被提交并寫入到硬盤前足夠保存你的小事務更改了。

當然，如果你有大量的大事務更改，那么，更改比默認innodb日志緩沖大小更大的值會對你的性能有一定的提高，但是你使用的是autocommit，或者你的事務更改小于幾k，那還是保持默認的值吧。

4.INNODB_FLUSH_LOG_AT_TRX_COMMIT

默認下，innodb_flush_log_at_trx_commit設置為1表示InnoDB在每次事務提交后立即刷新同步數(shù)據(jù)到硬盤。如果你使用autocommit，那么你的每一個INSERT, UPDATE或DELETE語句都是一個事務提交。

同步是一個昂貴的操作(特別是當你沒有寫回緩存時)，因為它涉及對硬盤的實際同步物理寫入。所以如果可能，并不建議使用默認值。

兩個可選的值是0和2:

* 0表示刷新到硬盤，但不同步(提交事務時沒有實際的IO操作)

* 2表示不刷新和不同步(也沒有實際的IO操作)

所以你如果設置它為0或2，則同步操作每秒執(zhí)行一次。所以明顯的缺點是你可能會丟失上一秒的提交數(shù)據(jù)。具體來說，你的事務已經(jīng)提交了，但服務器馬上斷電了，那么你的提交相當于沒有發(fā)生過。

顯示的，對于金融機構，如銀行，這是無法忍受的。不過對于大多數(shù)網(wǎng)站，可以設置為innodb_flush_log_at_trx_commit=0|2，即使服務器最終崩潰也沒有什么大問題。畢竟，僅僅在幾年前有許多網(wǎng)站還是用MyISAM，當崩潰時會丟失30s的數(shù)據(jù)(更不要提那令人抓狂的慢修復進程)。

那么，0和2之間的實際區(qū)別是什么？性能明顯的差異是可以忽略不計，因為刷新到操作系統(tǒng)緩存的操作是非?？斓摹Ｋ院苊黠@應該設置為0，萬一MySQL崩潰(不是整個機器)，你不會丟失任何數(shù)據(jù)，因為數(shù)據(jù)已經(jīng)在OS緩存，最終還是會同步到硬盤的。

5.SYNC_BINLOG

已經(jīng)有大量的文檔寫到sync_binlog，以及它和innodb_flush_log_at_trx_commit的關系，下面我們來簡單的介紹下：

a) 如果你的服務器沒有設置從服務器，而且你不做備份，那么設置sync_binlog=0將對性能有好處。

b) 如果你有從服務器并且做備份，但你不介意當主服務器崩潰時在二進制日志丟失一些事件，那么為了更好的性能還是設置為sync_binlog=0.

c) 如果你有從服務器并且備份，你非常在意從服務器的一致性，以及能及時恢復到一個時間點(通過使用最新的一致性備份和二進制日志將數(shù)據(jù)庫恢復到特定時間點的能力)，那么你應該設置innodb_flush_log_at_trx_commit=1，并且需要認真考慮使用sync_binlog=1。

問題是sync_binlog=1代價比較高 – 現(xiàn)在每個事務也要同步一次到硬盤。你可能會想為什么不把兩次同步合并成一次，想法正確 – 新版本的MySQL(5.6和5.7，MariaDB和Percona Server)已經(jīng)能合并提交，那么在這種情況下sync_binlog=1的操作也不是這么昂貴了，但在舊的mysql版本中仍然會對性能有很大影響。

6.INNODB_FLUSH_METHOD

將innodb_flush_method設置為O_DIRECT以避免雙重緩沖.唯一一種情況你不應該使用O_DIRECT是當你操作系統(tǒng)不支持時。但如果你運行的是Linux，使用O_DIRECT來激活直接IO。

不用直接IO，雙重緩沖將會發(fā)生，因為所有的數(shù)據(jù)庫更改首先會寫入到OS緩存然后才同步到硬盤 – 所以InnoDB緩沖池和OS緩存會同時持有一份相同的數(shù)據(jù)。特別是如果你的緩沖池限制為總內(nèi)存的50%，那意味著在寫密集的環(huán)境中你可能會浪費高達50%的內(nèi)存。如果沒有限制為50%，服務器可能由于OS緩存的高壓力會使用到swap。

簡單地說，設置為innodb_flush_method=O_DIRECT。

7.INNODB_BUFFER_POOL_INSTANCES

MySQL 5.5引入了緩沖實例作為減小內(nèi)部鎖爭用來提高MySQL吞吐量的手段。

在5.5版本這個對提升吞吐量幫助很小，然后在MySQL 5.6版本這個提升就非常大了，所以在MySQL5.5中你可能會保守地設置innodb_buffer_pool_instances=4，在MySQL 5.6和5.7中你可以設置為8-16個緩沖池實例。

你設置后觀察會覺得性能提高不大，但在大多數(shù)高負載情況下，它應該會有不錯的表現(xiàn)。

對了，不要指望這個設置能減少你單個查詢的響應時間。這個是在高并發(fā)負載的服務器上才看得出區(qū)別。比如多個線程同時做許多事情。

8.INNODB_THREAD_CONCURRENCY

你可能會經(jīng)常聽到應該設置innodb_thread_concurrency=0然后就不要管它了。不過這個只在低負載服務器使用時才正確。然后，如果你的服務器的CPU或者IO使用接受飽和，特別是偶爾出現(xiàn)峰值，這時候系統(tǒng)想在超載時能正常處理查詢，那么強烈建議關注innodb_thread_concurrency。

InnoDB有一種方法來控制并行執(zhí)行的線程數(shù) – 我們稱為并發(fā)控制機制。大部分是由innodb_thread_concurrency值來控制的。如果設置為0，并發(fā)控制就關閉了，因此InnoDB會立即處理所有進來的請求(盡可能多的)。

在你有32CPU核心且只有4個請求時會沒什么問題。不過想像下你只有4CPU核心和32個請求時 – 如果你讓32個請求同時處理，你這個自找麻煩。因為這些32個請求只有4 CPU核心，顯然地會比平常慢至少8倍(實際上是大于8倍)，而然這些請求每個都有自己的外部和內(nèi)部鎖，這有很大可能堆積請求。

下面介紹如何更改這個變量，在mysql命令行提示符執(zhí)行：

1. SET global innodb_thread_concurrency=X;

對于大多數(shù)工作負載和服務器，設置為8是一個好開端，然后你可以根據(jù)服務器達到了這個限制而資源使用率利用不足時逐漸增加。可以通過show engine innodb status\G來查看目前查詢處理情況，查找類似如下行：

1. 22 queries inside InnoDB, 104 queries in queue

9.SKIP_NAME_RESOLVE

這一項不得不提及，因為仍然有很多人沒有添加這一項。你應該添加skip_name_resolve來避免連接時DNS解析。

大多數(shù)情況下你更改這個會沒有什么感覺，因為大多數(shù)情況下DNS服務器解析會非?？臁２贿^當DNS服務器失敗時，它會出現(xiàn)在你服務器上出現(xiàn)“unauthenticated connections” ，而就是為什么所有的請求都突然開始慢下來了。

所以不要等到這種事情發(fā)生才更改?，F(xiàn)在添加這個變量并且避免基于主機名的授權。

10.INNODB_IO_CAPACITY, INNODB_IO_CAPACITY_MAX

* innodb_io_capacity：用來當刷新臟數(shù)據(jù)時，控制MySQL每秒執(zhí)行的寫IO量。

* innodb_io_capacity_max: 在壓力下，控制當刷新臟數(shù)據(jù)時MySQL每秒執(zhí)行的寫IO量

首先，這與讀取無關 – SELECT查詢執(zhí)行的操作。對于讀操作，MySQL會盡大可能處理并返回結果。至于寫操作，MySQL在后臺會循環(huán)刷新，在每一個循環(huán)會檢查有多少數(shù)據(jù)需要刷新，并且不會用超過innodb_io_capacity指定的數(shù)來做刷新操作。這也包括更改緩沖區(qū)合并（在它們刷新到磁盤之前，更改緩沖區(qū)是輔助臟頁存儲的關鍵）。

第二，我需要解釋一下什么叫“在壓力下”，MySQL中稱為”緊急情況”，是當MySQL在后臺刷新時，它需要刷新一些數(shù)據(jù)為了讓新的寫操作進來。然后，MySQL會用到innodb_io_capacity_max。

那么，應該設置innodb_io_capacity和innodb_io_capacity_max為什么呢？

最好的方法是測量你的存儲設置的隨機寫吞吐量，然后給innodb_io_capacity_max設置為你的設備能達到的大IOPS。innodb_io_capacity就設置為它的50-75%，特別是你的系統(tǒng)主要是寫操作時。

通常你可以預測你的系統(tǒng)的IOPS是多少。例如由8 15k硬盤組成的RAID10能做大約每秒1000隨機寫操作，所以你可以設置innodb_io_capacity=600和innodb_io_capacity_max=1000。許多廉價企業(yè)SSD可以做4,000-10,000 IOPS等。

這個值設置得不好問題不大。但是，要注意默認的200和400會限制你的寫吞吐量，因此你可能偶爾會捕捉到刷新進程。如果出現(xiàn)這種情況，可能是已經(jīng)達到你硬盤的寫IO吞吐量，或者這個值設置得太小限制了吞吐量。

11.INNODB_STATS_ON_METADATA

如果你跑的是MySQL 5.6或5.7，你不需要更改innodb_stats_on_metadata的默認值，因為它已經(jīng)設置正確了。

不過在MySQL 5.5或5.1，強烈建議關閉這個變量 – 如果是開啟，像命令show table status會立即查詢INFORMATION_SCHEMA而不是等幾秒再執(zhí)行，這會使用到額外的IO操作。

從5.1.32版本開始，這個是動態(tài)變量，意味著你不需要重啟MySQL服務器來關閉它。

12.INNODB_BUFFER_POOL_DUMP_AT_SHUTDOWN & INNODB_BUFFER_POOL_LOAD_AT_STARTUP

innodb_buffer_pool_dump_at_shutdown和innodb_buffer_pool_load_at_startup這兩個變量與性能無關，不過如果你偶爾重啟mysql服務器(如生效配置)，那么就有關。當兩個都激活時，MySQL緩沖池的內(nèi)容(更具體地說，是緩存頁)在停止MySQL時存儲到一個文件。當你下次啟動MySQL時，它會在后臺啟動一個線程來加載緩沖池的內(nèi)容以提高預熱速度到3-5倍。

兩件事：

第一，它實際上沒有在關閉時復制緩沖池內(nèi)容到文件，僅僅是復制表空間ID和頁面ID – 足夠的信息來定位硬盤上的頁面了。然后它就能以大量的順序讀非?？焖俚募虞d那些頁面，而不是需要成千上萬的小隨機讀。

第二，啟動時是在后臺加載內(nèi)容，因為MySQL不需要等到緩沖池內(nèi)容加載完成再開始接受請求(所以看起來不會有什么影響)。

從MySQL 5.7.7開始，默認只有25%的緩沖池頁面在mysql關閉時存儲到文件，但是你可以控制這個值 – 使用innodb_buffer_pool_dump_pct，建議75-100。

這個特性從MySQL 5.6才開始支持。

13.INNODB_ADAPTIVE_HASH_INDEX_PARTS

如果你運行著一個大量SELECT查詢的MySQL服務器(并且已經(jīng)盡可能優(yōu)化)，那么自適應哈希索引將下你的下一個瓶頸。自適應哈希索引是InnoDB內(nèi)部維護的動態(tài)索引，可以提高最常用的查詢模式的性能。這個特性可以重啟服務器關閉，不過默認下在mysql的所有版本開啟。

這個技術非常復雜，在大多數(shù)情況下它會對大多數(shù)類型的查詢直到加速的作用。不過，當你有太多的查詢往數(shù)據(jù)庫，在某一個點上它會花過多的時間等待AHI鎖和閂鎖。

如果你的是MySQL 5.7，沒有這個問題 – innodb_adaptive_hash_index_parts默認設置為8，所以自適應哈希索引被切割為8個分區(qū)，因為不存在全局互斥。

不過在mysql 5.7前的版本，沒有AHI分區(qū)數(shù)量的控制。換句話說，有一個全局互斥鎖來保護AHI，可能導致你的select查詢經(jīng)常撞墻。

所以如果你運行的是5.1或5.6，并且有大量的select查詢，最簡單的方案就是切換成同一版本的Percona Server來激活AHI分區(qū)。

14.QUERY_CACHE_TYPE

如果人認為查詢緩存效果很好，肯定應該使用它。好吧，有時候是有用的。不過這個只在你在低負載時有用，特別是在低負載下大多數(shù)是讀取，小量寫或者沒有。

如果是那樣的情況，設置query_cache_type=ON和query_cache_size=256M就好了。不過記住不能把256M設置更高的值了，否則會由于查詢緩存失效時，導致引起嚴重的服務器停頓。

如果你的MySQL服務器高負載動作，建議設置query_cache_size=0和query_cache_type=OFF，并重啟服務器生效。那樣Mysql就會停止在所有的查詢使用查詢緩存互斥鎖。

15.TABLE_OPEN_CACHE_INSTANCES

從MySQL 5.6.6開始，表緩存能分割到多個分區(qū)。

表緩存用來存放目前已打開表的列表，當每一個表打開或關閉互斥體就被鎖定 – 即使這是一個隱式臨時表。使用多個分區(qū)絕對減少了潛在的爭用。

從MySQL 5.7.8開始，table_open_cache_instances=16是默認的配置。

網(wǎng)頁名稱：MySQL性能調優(yōu) – 你必須了解的15個重要變量
本文來源：http://www.rwnh.cn/news/98012.html

成都網(wǎng)站建設公司_創(chuàng)新互聯(lián)，為您提供建站公司、外貿(mào)建站、微信小程序、ChatGPT、做網(wǎng)站、自適應網(wǎng)站

廣告

聲明：本網(wǎng)站發(fā)布的內(nèi)容（圖片、視頻和文字）以用戶投稿、用戶轉載內(nèi)容為主，如果涉及侵權請盡快告知，我們將會在第一時間刪除。文章觀點不代表本網(wǎng)站立場，如需處理請聯(lián)系客服。電話：028-86922220；郵箱：631063699@qq.com。內(nèi)容未經(jīng)允許不得轉載，或轉載時需注明來源： 創(chuàng)新互聯(lián)