InnoDB存儲引擎介紹-(3)InnoDB緩衝池配置詳解

時間  2019-11-19
標籤 innodb 存儲 引擎 介紹 緩衝 配置 詳解 欄目 MySQL 简体版
原文   原文鏈接

原文連接  http://www.ywnds.com/?p=9886html

1、InnoDB緩衝池

 InnoDB維護一個稱爲緩衝池的內存存儲區域 ，用於緩存內存中的數據和索引。瞭解InnoDB緩衝池的工做原理，並利用它來保存內存中常常訪問的數據，這是MySQL調優的一個重要方面。mysql

1.1 LRU（least recently used）算法

InnoDB將buffer pool做爲一個list管理，基於LRU算法。當有新的頁要讀入到buffer pool的時候，buffer pool就將最近最少使用的頁從buffer pool中驅逐出去，而且將新頁加入到list的中間位置，這就是所謂的「中點插入策略」。通常狀況下list頭部存放的是熱數據，就是所謂的young pages（最近常常訪問的數據），list尾部存放的就是old pages（最近不被訪問的數據）。這個算法就保證了最近常用的page信息會被保存在最近訪問的sublist中，相反的不被常常訪問的就會保存在old sublist，當新數據寫入的時候被old sublist中的page信息會被首先驅逐的。sql

LRU算法有如下的標準算法：shell

1）3/8的list信息是做爲old list，這些信息是被驅逐的對象。數據庫

2）list的中點就是咱們所謂的old list頭部和new list尾部的鏈接點，至關於一個界限。緩存

3）新數據的讀入首先會插入到old list的頭部。服務器

4）若是是old list的數據被訪問到了，這個頁信息就會變成new list，變成young page，就會將數據頁信息移動到new sublist的頭部。數據結構

5）在數據庫的buffer pool裏面，無論是new sublist仍是old sublist的數據若是不會被訪問到，最後都會被移動到list的尾部做爲犧牲者。併發

通常狀況下，頁信息會被查詢語句立馬查詢到而被移動到new sublist，這就意味着他們會在buffer pool裏面保留很長一段時間。表掃描（包括mysqldump或者沒有where條件的select等操做）等操做將會刷入大量的數據進入buffer pool，同時也會將更多的buffer pool當中的信息刷出去，即便這個操做可能只會使用到一次而已。一樣的，若是read-ahead（線性預讀）後臺進程讀入大量數據的狀況下也是會形成buffer pool大量高頻的刷新數據頁，可是這些操做是可控的，下面3，4會說獲得。read-ahead操做簡單說一下就是MySQL的一個後臺預讀進程，可以保證MySQL預讀入數據進入buffer pool當中。

當你作backup或者report的時候，能夠頻繁的往buffer pool裏面讀取數據，不用有太多的顧慮。

InnoDB採用的是一種不是像LRU那麼嚴格的方法來保證將最近訪問的數據寫入到buffer pool裏面，而且最大可能的下降減小數據的帶入量。這個語句是全表掃描或者之後這個數據將不會再被訪問到，可是緩衝數據仍是會寫入到buffer pool裏面。

新寫入的數據會被插入到LRU list的中間位置，默認會插入到從list尾部算起來的3/8的位置，當這些寫入的數據在buffer pool中被第一次訪問的時候，在list中的位置就會向前移動，這樣其實就會在list保留兩個位置，老的位置並不會被當即清除，直到老的LRU list的位置被標記爲OLD的時候，纔會在下一次插入數據的時候被做爲犧牲者清除掉。

咱們自己是能夠指定插入LRU list的位置，而且也能夠設置當索引掃描或者是全表掃描的時候是否是採用這個相同的優化方法。innodb_old_blocks_pct這個參數設置的是插入的位置，默認的值是37，咱們能夠設置的值是5-95之間，其他部分並不用來保存熱數據。可是還有一個嚴重的問題就是當一個全表掃描或者索引的掃描常常被訪問的時候，就會存儲很大的數據到buffer pool裏面，咱們都知道這是很危險的一件事。因此MySQL給咱們如下參數來設置保留在buffer pool裏面的數據在插入時候沒有被改變list位置的時候的保存時間innodb_old_blocks_time，單位是毫秒，這個值的默認值是1000。若是增大這個值的話，就會讓buffer pool裏面不少頁信息變老的速度變快，這個很好理解把，由於這些數據不會很快被內存中擦除的話，就會變成熱數據而擠掉原有緩存的數據。

以上的兩個參數都是能夠動態設置的，固然也能夠在my.cnf裏面設置。固然設置這些前必定要對機器配置，表信息，負載狀況有充分的瞭解才能進行設置，生產庫儘可能不要隨便修改。若是OLTP系統中有大量的大查詢的話，設置innodb_old_blocks_time可以較大的提供系統的穩定性。若是當一個大查詢很大不足夠存儲到buffer pool當中的時候，咱們能夠指定innodb_old_blocks_pct的值小一點，以保證這些數據只會被讀取一次，好比說設置爲5的時候，就限制了一次讀取數據最多隻能被讀取到buffer pool當中5%。固然一些小表而且是常常訪問到的數據的話就能夠適當設置較大的值，好比50。固然設置這兩個值的時候必定要創建在你充分了解你的數據負載的基礎上，否則千萬不要亂改。

2.2 Buffer Pool

InnoDB緩衝池將表的索引和數據進行緩存，緩衝池容許從內存直接處理頻繁使用的數據，這加快了處理速度。在專用數據庫服務器上，一般將多達80％的物理內存分配給InnoDB緩衝池。由於InnoDB的存儲引擎的工做方式老是將數據庫文件按頁讀取到緩衝池，每一個頁16k默認（innodb_page_size=16k），在MySQL 5.7中增長了32KB和64KB頁面大小的支持，以前版本是不容許大於16k的；但你只能在初始化MySQL實例以前進行配置，一旦設置了一個實例的頁面大小，就不能改變它，具體看innodb_page_size參數。

而後按最近最少使用（LRU）算法來保留在緩衝池中的緩存數據。若是數據庫文件須要修改，老是首先修改在緩存池中的頁（發生修改後，該也即爲髒也），而後再按照必定的頻率將緩衝池的髒也刷新到文件中。能夠經過show engine innodb status來查看innodb_buffer_pool的具體使用狀況（默認是8個緩衝池實例），以下:

mysql> show engine innodb status\G
Per second averages calculated from the last 38 seconds（如下信息來之過去的38秒）
----------------------
BUFFER POOL AND MEMORY
----------------------
Total memory allocated 1098907648; in additional pool allocated 0
Dictionary memory allocated 59957
Buffer pool size   65536
Free buffers  65371
Database pages  165
Old database pages  3
Modified db pages  9
..........

在Buffer pool size中能夠看到內存池的使用狀況：

Total memory allocated：爲緩衝池分配的總內存（以字節爲單位）。

Dictionary memory allocated：分配給InnoDB數據字典的總內存（以字節爲單位）。

Buffer pool size：分配給緩衝池的頁面總數量（數量*頁面大小=緩衝池大小），默認每一個Page爲16k。

Free buffers：緩衝池空閒列表的頁面總數量（Buffer pool size -Database pages）。

Database pages：緩衝池LRU LIST的頁面總數量（能夠理解爲已經使用的頁面）。

Old database pages：緩衝池舊LRU SUBLIST的頁面總大小（能夠理解爲不常常訪問的頁面，即將可能被LRU算法淘汰的頁面）。

Modified db pages：在緩衝池中已經修改了的頁數，所謂髒數據。

因此這裏一共分配了63336*16/1024=1G內存的緩衝池，空閒65371個頁面，已經使用了165個頁面，不常常修改的數據頁有3個（通常佔用內存的1/3），髒頁的頁面有2個，這些數據能分析當前數據庫的壓力值。

2、配置InnoDB緩衝池大小

你能夠配置InnoDB緩衝池的各個方面來提升性能。

  • 理想狀況下，你將緩衝池的大小設置爲儘量大的值（70%-80%）。緩衝池越大，InnoDB內存數據庫的行爲越多，從磁盤讀取數據一次，而後在後續讀取期間從內存訪問數據。
  • 對於具備大內存的64位系統，你能夠將緩衝池拆分紅多個實例（默認8個），以最大限度地減小併發操做中內存結構的爭用。

2.1 在線配置InnoDB緩衝池大小

緩衝池支持脫機和聯機兩種配置方式，當增長或減小innodb_buffer_pool_size時，操做以塊（chunk）形式執行。塊大小由innodb_buffer_pool_chunk_size配置選項定義，默認值128M。

在線配置InnoDB緩衝池大小，該innodb_buffer_pool_size配置選項能夠動態使用設置SET聲明，讓你調整緩衝池無需從新啓動服務器。例如：

mysql> SET GLOBAL innodb_buffer_pool_size=8589934592;

緩衝池大小配置必須始終等於innodb_buffer_pool_chunk_size*innodb_buffer_pool_instances的倍數。若是配置innodb_buffer_pool_size爲不等於innodb_buffer_pool_chunk_size*innodb_buffer_pool_instances的倍數，則緩衝池大小將自動調整爲等於或不小於指定緩衝池大小的innodb_buffer_pool_chunk_size*innodb_buffer_pool_instances的倍數。

在如下示例中， innodb_buffer_pool_size設置爲8G，innodb_buffer_pool_instances設置爲16，innodb_buffer_pool_chunk_size是128M，這是默認值。8G是一個有效的innodb_buffer_pool_size值，由於它是innodb_buffer_pool_instances=16乘以innodb_buffer_pool_chunk_size=128M的倍數。

mysql> select 8*1024 / (16*128);
+-------------------+
| 8*1024 / (16*128) |
+-------------------+
|            4.0000 |
+-------------------+
1 row in set (0.00 sec)

 若是innodb_buffer_pool_size設置爲9G，innodb_buffer_pool_instances設置爲16，innodb_buffer_pool_chunk_size是128M，這是默認值。在這種狀況下，9G不是innodb_buffer_pool_instances=16*innodb_buffer_pool_chunk_size=128M的倍數 ，因此innodb_buffer_pool_size被調整爲10G，這是不小於指定緩衝池大小的下一個innodb_buffer_pool_chunk_size*innodb_buffer_pool_instances的倍數。

2.2 監控在線緩衝池調整大小進度

該Innodb_buffer_pool_resize_status報告緩衝池大小調整的進展。例如：

mysql> SHOW STATUS WHERE Variable_name ='InnoDB_buffer_pool_resize_status';
+----------------------------------+-------+
| Variable_name                    | Value |
+----------------------------------+-------+
| Innodb_buffer_pool_resize_status |       |
+----------------------------------+-------+
1 row in set (0.01 sec)

2.3 配置InnoDB緩衝池塊（chunk）大小

 innodb_buffer_pool_chunk_size能夠在1MB（1048576字節）單位中增長或減小，但只能在啓動時，在命令行字符串或MySQL配置文件中進行修改。

[mysqld]
innodb_buffer_pool_chunk_size = 134217728

修改innodb_buffer_pool_chunk_size時適用如下條件：

  • 若是新innodb_buffer_pool_chunk_size值乘以innodb_buffer_pool_instances大於初始化緩衝池大小時， innodb_buffer_pool_chunk_size則截斷爲innodb_buffer_pool_size / innodb_buffer_pool_instances。

例如，若是緩衝池初始化大小爲2GB（2147483648字節）， 4個緩衝池實例和塊大小1GB（1073741824字節），則塊大小將被截斷爲等於innodb_buffer_pool_size / innodb_buffer_pool_instances，值爲：

mysql> select 2147483648 / 4;
+----------------+
| 2147483648 / 4 |
+----------------+
| 536870912.0000 |
+----------------+
1 row in set (0.00 sec)
  • 緩衝池大小必須始終等於或不小於innodb_buffer_pool_chunk_size * innodb_buffer_pool_instances的倍數。若是更改innodb_buffer_pool_chunk_size，innodb_buffer_pool_size則會自動調整爲等於或不小於當前緩衝池大小的innodb_buffer_pool_chunk_size * innodb_buffer_pool_instances的倍數。緩衝池初始化時會發生調整。

更改時應當心innodb_buffer_pool_chunk_size，由於更改此值能夠增長緩衝池的大小，如上面的示例所示。在更改innodb_buffer_pool_chunk_size以前，計算innodb_buffer_pool_size以確保生成的緩衝池大小是可接受的。

2.4 在線調整緩衝池內部大小機制

調整大小的操做由後臺線程執行，當增長緩衝池的大小時，調整大小操做：

  • 添加頁面chunks（chunks大小由innodb_buffer_pool_chunk_size定義）。
  • 覆蓋哈希表，列表和指針以在內存中使用新的地址。
  • 將新頁面添加到空閒列表中。

PS：當這些操做正在進行時，阻止其餘線程訪問緩衝池。

當減少緩衝池的大小時，調整大小操做：

  • 對緩衝池進行碎片整理並提取空閒頁面。
  • 刪除頁面chunks（chunks大小由innodb_buffer_pool_chunk_size定義）。
  • 轉換哈希表，列表和指針以在內存中使用新的地址。

在這些操做中，只有對緩衝池進行碎片整理和撤銷頁面才容許其餘線程同時訪問緩衝池。

InnoDB在調整緩衝池大小以前，應完成經過API執行的活動事務和操做。啓動調整大小操做時，在全部活動事務完成以前，操做都不會啓動。一旦調整大小操做進行中，須要訪問緩衝池的新事務和操做必須等到調整大小操做完成，可是容許在緩衝池進行碎片整理時緩衝池的併發訪問。緩衝池大小減小時頁面被撤銷，容許併發訪問的一個缺點是在頁面被撤回時可能會致使可用頁面暫時不足。

3、配置多個緩衝池實例

對於具備多GB級緩衝池的系統，將緩衝池劃分爲單獨的實例能夠經過減小不一樣線程讀取和寫入緩存頁面的爭用來提升併發性。此功能一般適用於緩衝池大小在千兆字節範圍內的系統。使用innodb_buffer_pool_instances配置選項配置多個緩衝池實例，你也能夠調整該 innodb_buffer_pool_size值。

當InnoDB緩衝池大時，能夠經過從內存檢索來知足許多數據請求。你可能會遇到多個請求一次訪問緩衝池的線程的瓶頸。你能夠啓用多個緩衝池以最小化此爭用。使用散列函數，將緩衝池中存儲或讀取的每一個頁面隨機分配給其中一個緩衝池。每一個緩衝池管理本身的空閒列表，刷新列表，LRU和鏈接到緩衝池的全部其餘數據結構，並由其本身的緩衝池互斥鎖保護。

要啓用多個緩衝池實例，請將innodb_buffer_pool_instances配置選項設置爲大於1（默認值）高達64（最大值）的值。此選項僅在設置innodb_buffer_pool_size爲1GB或更大的大小時生效。你指定的總大小在全部緩衝池之間分配，爲了得到最佳效率，指定的組合innodb_buffer_pool_instances和innodb_buffer_pool_size，使得每一個緩衝池實例是至少爲1GB。

4、配置InnoDB緩衝池預讀

InnoDB在io的優化上有個比較重要的特性爲預讀，預讀請求是一個i/o請求，它會異步地在緩衝池中預先回遷多個頁面，預計很快就會須要這些頁面，這些請求在一個範圍內引入全部頁面。InnoDB以64個page爲一個extent，那麼InnoDB的預讀是以page爲單位仍是以extent？

這樣就進入了下面的話題，InnoDB使用兩種預讀算法來提升I/O性能：線性預讀（linear read-ahead）和隨機預讀（randomread-ahead）

爲了區分這兩種預讀的方式，咱們能夠把線性預讀放到以extent爲單位，而隨機預讀放到以extent中的page爲單位。線性預讀着眼於將下一個extent提早讀取到buffer pool中，而隨機預讀着眼於將當前extent中的剩餘的page提早讀取到buffer pool中。

線性預讀（linear read-ahead）：它能夠根據順序訪問緩衝池中的頁面，預測哪些頁面可能須要很快。經過使用配置參數innodb_read_ahead_threshold，經過調整觸發異步讀取請求所需的順序頁訪問數，能夠控制Innodb執行提早讀操做的時間。在添加此參數以前，InnoDB只會計算當在當前範圍的最後一頁中讀取整個下一個區段時是否發出異步預取請求。

線性預讀方式有一個很重要的變量控制是否將下一個extent預讀到buffer pool中，經過使用配置參數innodb_read_ahead_threshold，能夠控制Innodb執行預讀操做的時間。若是一個extent中的被順序讀取的page超過或者等於該參數變量時，Innodb將會異步的將下一個extent讀取到buffer pool中，innodb_read_ahead_threshold能夠設置爲0-64的任何值，默認值爲56，值越高，訪問模式檢查越嚴格。

mysql> show global variables like '%innodb_read_ahead_threshold%';
+-----------------------------+-------+
| Variable_name               | Value |
+-----------------------------+-------+
| innodb_read_ahead_threshold | 56    |
+-----------------------------+-------+
1 row in set (0.00 sec)

 

例如，若是將值設置爲48，則InnoDB只有在順序訪問當前extent中的48個pages時才觸發線性預讀請求，將下一個extent讀到內存中。若是值爲8，InnoDB觸發異步預讀，即便程序段中只有8頁被順序訪問。你能夠在MySQL配置文件中設置此參數的值，或者使用SET GLOBAL須要該SUPER權限的命令動態更改該參數。

在沒有該變量以前，當訪問到extent的最後一個page的時候，Innodb會決定是否將下一個extent放入到buffer pool中。

隨機預讀（randomread-ahead）：隨機預讀方式則是表示當同一個extent中的一些page在buffer pool中發現時，Innodb會將該extent中的剩餘page一併讀到buffer pool中，因爲隨機預讀方式給Innodb code帶來了一些沒必要要的複雜性，同時在性能也存在不穩定性，在5.5中已經將這種預讀方式廢棄。要啓用此功能，請將配置變量設置innodb_random_read_ahead爲ON。

mysql> show global variables like '%innodb_random_read_ahead%';
+--------------------------+-------+
| Variable_name            | Value |
+--------------------------+-------+
| innodb_random_read_ahead | OFF   |
+--------------------------+-------+
1 row in set (0.01 sec)

在監控Innodb的預讀時候，咱們能夠經過SHOW ENGINE INNODB STATUS命令顯示統計信息，經過Pages read ahead和evicted without access兩個值來觀察預讀的狀況，或者經過兩個狀態值，以幫助您評估預讀算法的有效性。

mysql> show global status like '%Innodb_buffer_pool_read_ahead%';
+---------------------------------------+-------+
| Variable_name                         | Value |
+---------------------------------------+-------+
| Innodb_buffer_pool_read_ahead_rnd     | 0     |
| Innodb_buffer_pool_read_ahead         | 0     |
| Innodb_buffer_pool_read_ahead_evicted | 0     |
+---------------------------------------+-------+
3 rows in set (0.00 sec)

而經過SHOW ENGINE INNODB STATUS獲得的Pages read ahead和evicted without access則表示每秒讀入和讀出的pages：Pages read ahead 1.00/s, evicted without access 9.99/s。

當微調innodb_random_read_ahead設置時，此信息可能頗有用 。

5、配置InnoDB緩衝池刷新

InnoDB會在後臺執行某些任務，包括從緩衝池刷新髒頁（那些已更改但還沒有寫入數據庫文件的頁）。

InnoDB當緩衝池中髒頁的百分比達到定義的低水位設置時，其實就是當緩衝池中的髒頁佔用比達到innodb_max_dirty_pages_pct_lwm的設定值的時候，就會自動將髒頁清出buffer pool，這是爲了保證buffer pool當中髒頁的佔有率，也是爲了防止髒頁佔有率超過innodb_max_dirty_pages_pct的設定值，當髒頁的佔有率達到了innodb_max_dirty_pages_pct的設定值的時候，InnoDB就會強制刷新buffer pool pages。

InnoDB採用一種基於redo log的最近生成量和最近刷新頻率的算法來決定沖洗速度，這樣的算法能夠保證數據庫的沖洗不會影響到數據庫的性能，也能保證數據庫buffer pool中的數據的髒數據的佔用比。這種自動調整刷新速率有助於避免過多的緩衝池刷新限制了普通讀寫請求可用的I/O容量，從而避免吞吐量忽然降低，但仍是對正常IO有影響。

咱們知道InnoDB使用日誌的方式是循環使用的，在重用前一個日誌文件以前，InnoDB就會將這個日誌這個日誌記錄相關的全部在buffer pool當中的數據刷新到磁盤，也就是所謂的sharp checkpoint，和sqlserver的checkpoint很像。當一個插入語句產生大量的redo信息須要記錄的日誌，當前redo log文件不可以徹底存儲，也會寫入到當前的redo文件當中。當redo log當中的全部使用空間都被用完了的，就會觸發sharp checkpoint，因此這個時候即便髒數據佔有率沒有達到innodb_max_dirty_pages_pct，仍是會進行刷新。

內部基準測試顯示，該算法隨着時間的推移能夠顯著提升總體吞吐量。這種算法是經得住考驗的，因此說千萬不要隨便設置，最好是默認值。可是咱們從中也就會知道爲何redo log不可以記錄兩個事物的redo信息了。由於有這麼多的好處，因此innodb_adaptive_flushing的值默認就是true的，默認開啓自適應刷新策略。

6、微調InnoDB緩衝池刷新

配置選項innodb_flush_neighbors， innodb_lru_scan_depth可讓你微調緩衝池刷新過程的某些方面，這些選項主要是幫助寫密集型的工做負載。若是DML操做較爲嚴重，若是沒有較高的值，則刷新可能會降低，會致使緩衝池中的內存過多。或者，若是這種機制過於激進，磁盤寫入將會使你的I/O容量飽和，理想的設置取決於你的工做負載，數據訪問模式和存儲配置（例如數據是否存儲在HDD或SSD設備上）。

InnoDB對於具備不斷繁重工做負載的系統或者工做負載波動很大的系統，可使用下面幾個配置選項來調整表的刷新行爲：

  • innodb_adaptive_flushing_lwm：默認值10，指定重作日誌容量的「 低水位 」百分比，當該閾值越過期，InnoDB即便沒有開啓innodb_adaptive_flushing選項也會自動啓用自適應刷新。
  • innodb_max_dirty_pages_pct_lwm：默認值0，InnoDB嘗試從緩衝池中刷新數據，以使髒頁面的百分比不超過該值innodb_max_dirty_pages_pct。默認值爲75。該innodb_max_dirty_pages_pct_lwm選項是用來指定「 低水位 」值，其表示使用預沖洗來控制髒頁比例的百分比，防止髒頁的百分比達到innodb_max_dirty_pages_pct的值，innodb_max_dirty_pages_pct_lwm默認0，禁用「 預沖洗」行爲。
  • innodb_io_capacity_max，默認2000，若是刷新動做遠遠落後，InnoDB能夠比指定的innodb_io_capacity刷新動做更積極。innodb_io_capacity_max表示在這種緊急狀況下使用的I/O容量的上限，以便I/O中的尖峯消耗不到服務器的全部容量。
  • innodb_flushing_avg_loops，默認30；定義了innodb保留先前計算的刷新狀態快照的迭代次數, 它控制了自適應刷新對此前負載更改的響應速度。爲innodb_flushing_avg_loops設置高值意味着innodb保留之前計算的快照的時間更長，所以自適應刷新的響應速度更慢，高值還能夠減小前臺和後臺工做之間的正面反饋。可是，在設置高值時，確保innodb重作日誌利用率不達到75% (異步刷新開始時的硬編碼限制) 和innodb_max_dirty_pages_pct設置將髒頁的數量保持爲適合於工做負荷的級別是很重要的。

上面提到的大多數選項最適用於長時間運行寫入繁重工做負載的服務器。

7、保存和恢復緩衝池狀態

7.1 在關閉時保存緩衝池狀態並在啓動時恢復緩衝池狀態

能夠配置在MySQL關閉以前，保存InnoDB當前的緩衝池的狀態，以免在服務器從新啓動後，還要經歷一個預熱的暖機時間。經過innodb_buffer_pool_dump_at_shutdown（服務器關閉前設置）來設置，當設置這個參數之後MySQL就會在機器關閉時保存InnoDB當前的狀態信息到磁盤上。

當啓動MySQL服務器時要恢復服務器緩衝池狀態，請在啓動服務器時開啓innodb_buffer_pool_load_at_startup參數。我的認爲這個值仍是須要配置一下的，MySQL 5.7.6版本以前這兩個值默認是關閉的，但從MySQL 5.7.7版本開始這兩個值就默認爲開啓狀態了。這些數據是從磁盤從新讀取到buffer pool當中的，這會花費一些時間，而且恢復時新的DML操做是不可以進行操做的。這些數據是怎麼恢復呢？其實INNODB_BUFFER_PAGE_LRU表（INFORMATION_SCHEMA）會記錄緩存的tablespace ID和page ID，經過這個來恢復。另外緩衝池狀態保存文件默認在數據目錄下，名爲」ib_buffer_pool」，可使用innodb_buffer_pool_filename參數來修改文件名和位置。

7.2 配置緩衝池頁面保存的百分比

在加載數據進入buffer pool以前，能夠經過設置innodb_buffer_pool_dump_pct參數來決定恢復buffer pool中多少數據。MySQL 5.7.6版本以前的默認值是100，恢復所有，從MySQL 5.7.7版本以後默認調整爲25了。能夠動態設置此參數：

mysql> SET GLOBAL innodb_buffer_pool_dump_pct = 40;

7.3 在線保存和恢復緩衝池狀態

要在運行MySQL服務器時保存緩衝池的狀態，請發出如下語句：

mysql> SET GLOBAL innodb_buffer_pool_dump_now=ON;

要在MySQL運行時恢復緩衝池狀態，請發出如下語句：

相關文章
相關標籤/搜索
每日一句
    每一个你不满意的现在，都有一个你没有努力的曾经。
本站公眾號
   歡迎關注本站公眾號,獲取更多信息
聯繫我們 最近搜索 最新文章 沪ICP备13005482号-10 MyBatis教程 SQL 教程 MySQL教程 Java 教程 Thymeleaf 教程 Hibernate教程 Spring教程 Redis教程