mysql資料庫緩衝池學習筆記,資料庫緩衝池大小

本文目錄一覽：

• 1、MySQL innodb引擎深入講解
• 2、mysql有基於LRU緩衝池，其它輔助緩存如memcached和redis的意義應該就不需要了，還是有其它需要的理由？
• 3、MySQL性能調優 – 你必須了解的15個重要變數
• 4、資料庫緩衝池有什麼作用

MySQL innodb引擎深入講解

表空間(ibd文件),一個MySQL實例可以對應多個表空間，用於存儲記錄，索引等數據。

段，分為數據段、索引段、回滾段，innodb是索引組織表，數據段就是B+Tree的葉子節點，索引段為非葉子節點，段用來管理多個區。

區，表空間的單元結構，每個區的大小為1M,默認情況下，innodb存儲引擎頁大小為16K，即一個區中一共有64個連續的頁。

頁，是innodb存儲引擎磁碟管理的最小單元，每個頁的大小為16K，為了保證頁的連續性，innodb存儲引擎每次從磁碟申請4~5個區。

行，innodb存儲引擎數據是按行進行存儲的。Trx_id 最後一次事務操作的id、roll_pointer滾動指針。

i nnodb的內存結構 ，由Buffer Pool、Change Buffer和Log Buffer組成。

Buffer Pool : 緩衝池是主內存中的一個區域，裡面可以緩存磁碟上經常操作的真實數據，在執行增刪改查操作時，先操作緩衝池中的數據(若緩衝池么有數據，則從磁碟載入並緩存)，然後再以一定頻率刷新磁碟，從而減少磁碟IO，加快處理速度。

緩衝池以page頁為單位，底層採用鏈表數據結構管理page，根據狀態，將page分為三種類型:

1、free page 即空閑page，未被使用。

2、clean page 被使用page，數據沒有被修改過。

3、dirty page 臟頁，被使用page，數據被修改過，這個page當中的數據和磁碟當中的數據 不一致。說得簡單點就是緩衝池中的數據改了，磁碟中的沒改，因為還沒刷寫到磁碟。

Change Buffer ：更改緩衝區(針對於非唯一二級索引頁)，在執行DML語句時，如果這些數據page沒有在Buffer Pool中，不會直接操作磁碟，而會將數據變更存在更改緩衝區Change Buffer中，在未來數據被讀取時。再將數據合併恢復到Buffer Pool中，再將合併後的數據刷新到磁碟中。

二級索引通常是非唯一的，並且以相對隨機的順序插入二級索引頁，同樣，刪除和更新可能會影響索引樹中不相鄰的二級索引頁。如果每一次都操作磁碟，會造成大量磁碟IO，有了Change Buffer之後，我們可以在緩衝池中進行合併處理，減少磁碟IO。

Adaptive Hash Index： 自適應hash索引，用於優化對Buffer Pool數據的查詢，InnoDB存儲引擎會監控對錶上各索引頁的查詢，如果觀察到hash索引可以提升速度，則建立hash索引，稱之為自適應hash索引。無需人工干預，系統根據情況自動完成。

參數：innodb_adaptive_hash_index

Log Buffer: 日誌緩衝區，用來保存要寫入到磁碟中的log日誌數據(redo log、undo log)，默認大小為16M，日誌緩衝區的日誌會定期刷新到磁碟中，如果需要更新，插入或刪除許多行的事務，增加日誌緩衝區的大小可以節省磁碟IO。

參數: innodb_log_buffer_size 緩衝區大小

innodb_flush_log_at_trx_commit 日誌刷新到磁碟時機

innodb_flush_log_at_trx_commit=1 表示日誌在每次事務提交時寫入並刷新到磁碟

2 表示日誌在每次事務提交後寫入，並每秒刷新到磁碟一次

0 表示每秒將日誌寫入並刷新到磁碟一次。

InnoDB 的磁碟結構，由系統表空間(ibdata1)，獨立表空間(*.ibd),通用表空間，撤銷表空間(undo tablespaces), 臨時表空間(Temporary Tablespaces), 雙寫緩衝區(Doublewrite Buffer files), 重做日誌(Redo Log).

系統表空間(ibdata1)： 系統表空間是更改緩衝區的存儲區域，如果表是在系統表空間而不是每個表文件或者通用表空間中創建的，它也可能包含表和索引數據。

參數為: innodb_data_file_path

獨立表空間(*.ibd): 每個表的文件表空間包含單個innodb表的數據和索引，並存儲在文件系 統上的單個數據文件中。 參數: innodb_file_per_table

通用表空間: 需要通過create tablespace 語法創建，創建表時 可以指定該表空間。

create tablespace xxx add datafile ‘file_name’ engine=engine_name

create table table_name …. tablespace xxx

撤銷表空間(undo tablespaces): MySQL實例在初始化時會自動創建兩個默認的undo表空間(初始大小16K，undo_001,undo_002)，用於存儲undo log 日誌

臨時表空間(Temporary Tablespaces)： innodb使用會話臨時表空和全局表空間，存儲用 戶創建的臨時表等數據。

雙寫緩衝區(Doublewrite Buffer files)： innodb引擎將數據頁從Buffer Pool刷新到磁碟前，先將數據頁寫入緩衝區文件中，便於系統異常時恢複數據。

重做日誌(Redo Log)： 是用來實現事務的持久性，該日誌文件由兩部分組成，重做日誌緩衝區(redo log buffer)以及重做日誌文件(redo log)，前者是在內存中，後者在磁碟中，當事務提交之後會把修改信息都會存儲到該日誌中，用於在刷新臟頁到磁碟時，發送錯誤時，進行數據恢復使用。以循環方式寫入重做日誌文件，涉及兩個文件ib_logfile0,ib_logfile1。

那內存結構中的數據是如何刷新到磁碟中的? 在MySQL中有4個線程負責刷新日誌到磁碟。

1、Master Thread， mysql核心後台線程，負責調度其它線程，還負責將緩衝池中的數據異 步刷新到磁碟中，保持數據的一致性，還包括臟頁的刷新，合併插入緩衝、undo頁的回 收。

2、IO Thread，在innodb存儲引擎中大量使用了AIO來處理IO請求，這樣可以極大地提高數 據庫的性能，而IO Thead主要負責這些IO請求的回調。

4個讀線程 Read thread負責讀操作

4個寫線程write thread負責寫操作

1個Log thread線程 負責將日誌緩衝區刷新到磁碟

1個insert buffer線程 負責將寫入緩衝區內容刷新到磁碟

3、Purge Thread，主要用於回收事務已經提交了的undo log，在事務提交之後，undo log 可能不用了，就用它來回收。

4、Page Cleaner Thread， 協助Master Thread 刷新臟頁到磁碟的線程，它可以減輕主線程 的壓力，減少阻塞。

事務就是一組操作的集合，它是一個不可分割的工作單位，事務會把所有的操作作為一個整體一起向系統提交或撤銷操作請求，即這些操作要麼同時成功，要麼同時失效。

事務的4大特性分為:

如何保證事務的4大特性，原子性，一致性和持久性是由innodb存儲引擎底層的兩份日誌來保證的，分別是redo log和undo log。對於隔離性是由鎖機制和MVCC(多版本並發控制)來實現的。

redo log，稱為重做日誌，記錄的是事務提交時數據頁的物理修改，是用來實現事務的持久性。該日誌文件由兩部分組成: 重做日誌緩衝redo log buffer及重做日誌文件redo log file，前者是在內存中，後者是在磁碟中，當事務提交之後會把所有修改信息都存到該日誌文件中，用於在刷新臟頁到磁碟，發送錯誤時，進行數據的恢復使用，從而保證事務的持久性。

具體的操作流程是：

1、客戶端發起事務操作，包含多條DML語句。首先去innodb中的buffer pool中的數據頁去查找有沒有我們要更新的這些數據，如果沒有則通過後台線程從磁碟中載入到buffer pool對應的數據頁中，然後就可以在緩衝池中進行數據操作了。

2、此時緩衝池中的數據頁發生了變更，還沒刷寫到磁碟，這個數據頁稱為臟頁。臟頁不是實時刷新到磁碟的，而是根據你配置的刷寫策略進行刷寫到磁碟的（innodb_flush_log_at_trx_commit，0,1,2三個值）。如果臟頁在往磁碟刷新的時候出現了故障，會丟失數據，導致事務的持久性得不到保證。為了避免這種現象，當對緩衝池中的數據進行增刪改操作時，會把增刪改記錄到redo log buffer當中，redo log buffer會把數據頁的物理變更持久化到磁碟文件中(ib_logfile0/ib_logfile1)。如果臟頁刷新失敗，就可以通過這兩個日誌文件進行恢復。

undo log，它是用來解決事務的原子性的，也稱為回滾日誌。用於記錄數據被修改前的信息，作用包括:提供回滾和MVCC多版本並發控制。

undo log和redo log的記錄物理日誌不一樣，它是邏輯日誌。可以認為當delete一條記錄時，undo log中會記錄一條對應的insert記錄，當update一條記錄時，它記錄一條對應相反的update記錄，當執行rollback時，就可以從undo log中的邏輯記錄讀取到相應的內容並進行回滾。

undo log銷毀: undo log 在事務執行時產生，事務提交時，並不會立即刪除undo log，因為這些日子可能用於MVCC。

undo log存儲: undo log 採用段的方式進行管理和記錄，存放在前面介紹的rollback segment回滾段中，內部包含1024個undo log segment。

mvcc(multi-Version Concurrency Control),多版本並發控制，指維護一個數據的多個版本，使得讀寫操作沒有衝突，快照讀為MySQL實現MVCC提供了一個非阻塞讀功能，MVCC的具體實現，還需要依賴於資料庫記錄中的三個隱式欄位，undo log日誌、readView。

read committed 每次select 都生成一個快照讀

repeatable read 開啟事務後第一個select語句才是快照讀的地方

serializable 快照讀會退化為當前讀。

mvcc的實現原理

DB_TRX_ID: 最近修改事務ID，記錄插入這條記錄或最後一次修改該記錄的事務ID

DB_ROLL_PTR: 回滾指針，指向這條記錄的上一個版本，用於配合undo log，指向上一個 版本

DB_ROW_ID: 隱藏主鍵，如果表結構沒有指定主鍵，將會生成該隱藏欄位。

m_ids當前活躍的事務ID集合

min_trx_id: 最小活躍事務id

max_trx_id: 預分配事務ID，當前最大事務id+1，因為事務id是自增的

creator_trx_id: ReadView創建者的事務ID

版本鏈數據訪問規則:

trx_id: 表示當前的事務ID

1、trx_id == creator_trx_id? 可以訪問讀版本–成立的話,說明數據是當前這個事務更改的

2、trx_id 成立,說明數據已經提交了。

3、trx_idmax_trx_id？不可用訪問讀版本- 成立的話，說明該事務是在ReadView生成後才開啟的。

4、min_trx_id

mysql有基於LRU緩衝池，其它輔助緩存如memcached和redis的意義應該就不需要了，還是有其它需要的理由？

1、首先明確是不是一定要上緩存，當前架構的瓶頸在哪裡，若瓶頸真是資料庫操作上，再繼續往下看。

2、明確memcached和redis的區別，到底要使用哪個。前者終究是個緩存，不可能永久保存數據（LRU機制），支持分散式，後者除了緩存的同時也支持把數據持久化到磁碟等，redis要自己去實現分散式緩存（貌似最新版本的已集成），自己去實現一致性hash。因為不知道應用場景，不好說一定要用memcache還是redis，說不定用mongodb會更好，比如在存儲日誌方面。

3、緩存量大但又不常變化的數據，比如評論。

4、思路是對的，清晰明了，讀DB前，先讀緩存，如果有直接返回，如果沒有再讀DB，然後寫入緩存層並返回。

5、考慮是否需要主從，讀寫分離，考慮是否分散式部署，考慮是否後續水平伸縮。

6、想要一勞永逸，後續維護和擴展方便，那就將現有的代碼架構優化，按你說的替換資料庫組件需要改動大量代碼，說明當前架構存在問題。可以利用現有的一些框架，比如SpringMVC，將應用層和業務層和資料庫層解耦。再上緩存之前把這些做好。

7、把讀取緩存等操作做成服務組件，對業務層提供服務，業務層對應用層提供服務。

8、保留原始資料庫組件，優化成服務組件，方便後續業務層靈活調用緩存或者是資料庫。

9、不建議一次性全量上緩存，最開始不動核心業務，可以將邊緣業務先換成緩存組件，一步步換至核心業務。

10、刷新內存，以memcached為例，新增，修改和刪除操作，一般採用lazy load的策略，即新增時只寫入資料庫，並不會馬上更新Memcached，而是等到再次讀取時才會載入到Memcached中，修改和刪除操作也是更新 資料庫，然後將Memcached中的數據標記為失效，等待下次讀取時再載入。

大方向兩種方案：

1、腳本同步：自己寫腳本將資料庫數據寫入到redis/memcached。這就涉及到實時數據變更的問題（mysql row binlog的實時分析），binlog增量訂閱Alibaba 的canal ，以及緩存層數據 丟失/失效 後的數據同步恢復問題。

2、業務層實現：先讀取nosql緩存層，沒有數據再讀取mysql層，並寫入數據到nosql。nosql層做好多節點分散式（一致性hash），以及節點失效後替代方案（多層hash尋找相鄰替代節點），和數據震蕩恢復了。

MySQL性能調優 – 你必須了解的15個重要變數

前言:

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

1.DEFAULT_STORAGE_ENGINE

如果你已經在用MySQL 5.6或者5.7，並且你的數據表都是InnoDB，那麼表示你已經設置好了。如果沒有，確保把你的錶轉換為InnoDB並且設置default_storage_engine為InnoDB。

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

2.INNODB_BUFFER_POOL_SIZE

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

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

根據經驗，在一個獨立的MySQL伺服器應該分配給MySQL整個機器總內存的80%。如果你的MySQL運行在一個共享伺服器，或者你想知道InnoDB緩衝池大小是否正確設置，詳細請看這裡。

3.INNODB_LOG_FILE_SIZE

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

根據經驗，你應該設置的日誌大小能在你伺服器繁忙時能存儲1-2小時的寫入量。如果不想這麼麻煩，那麼設置1-2G的大小會讓你的性能有一個不錯的表現。這個變數也相當重要，更詳細的介紹請看這裡。

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

4.INNODB_FLUSH_LOG_AT_TRX_COMMIT

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

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

兩個可選的值是0和2:

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

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

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

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

那麼，0和2之間的實際區別是什麼？性能明顯的差異是可以忽略不計，因為刷新到操作系統緩存的操作是非常快的。所以很明顯應該設置為0，萬一MySQL崩潰(不是整個機器)，你不會丟失任何數據，因為數據已經在OS緩存，最終還是會同步到硬碟的。

5.SYNC_BINLOG

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

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

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

c) 如果你有從伺服器並且備份，你非常在意從伺服器的一致性，以及能及時恢復到一個時間點(通過使用最新的一致性備份和二進位日誌將資料庫恢復到特定時間點的能力)，那麼你應該設置innodb_flush_log_at_trx_commit=1，並且需要認真考慮使用sync_binlog=1。

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

6.INNODB_FLUSH_METHOD

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

不用直接IO，雙重緩衝將會發生，因為所有的資料庫更改首先會寫入到OS緩存然後才同步到硬碟 – 所以InnoDB緩衝池和OS緩存會同時持有一份相同的數據。特別是如果你的緩衝池限制為總內存的50%，那意味著在寫密集的環境中你可能會浪費高達50%的內存。如果沒有限制為50%，伺服器可能由於OS緩存的高壓力會使用到swap。

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

7.INNODB_BUFFER_POOL_INSTANCES

MySQL 5.5引入了緩衝實例作為減小內部鎖爭用來提高MySQL吞吐量的手段。

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

你設置後觀察會覺得性能提高不大，但在大多數高負載情況下，它應該會有不錯的表現。

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

8.INNODB_THREAD_CONCURRENCY

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

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

下面介紹如何更改這個變數，在mysql命令行提示符執行：

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

9.SKIP_NAME_RESOLVE

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

大多數情況下你更改這個會沒有什麼感覺，因為大多數情況下DNS伺服器解析會非常快。不過當DNS伺服器失敗時，它會出現在你伺服器上出現「unauthenticated connections」 ，而就是為什麼所有的請求都突然開始慢下來了。

所以不要等到這種事情發生才更改。現在添加這個變數並且避免基於主機名的授權。

10.INNODB_IO_CAPACITY, INNODB_IO_CAPACITY_MAX

* innodb_io_capacity：用來當刷新臟數據時，控制MySQL每秒執行的寫IO量。

* innodb_io_capacity_max: 在壓力下，控制當刷新臟數據時MySQL每秒執行的寫IO量

首先，這與讀取無關 – SELECT查詢執行的操作。對於讀操作，MySQL會盡最大可能處理並返回結果。至於寫操作，MySQL在後台會循環刷新，在每一個循環會檢查有多少數據需要刷新，並且不會用超過innodb_io_capacity指定的數來做刷新操作。這也包括更改緩衝區合併（在它們刷新到磁碟之前，更改緩衝區是輔助臟頁存儲的關鍵）。

第二，我需要解釋一下什麼叫「在壓力下」，MySQL中稱為」緊急情況」，是當MySQL在後台刷新時，它需要刷新一些數據為了讓新的寫操作進來。然後，MySQL會用到innodb_io_capacity_max。

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

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

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

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

11.INNODB_STATS_ON_METADATA

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

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

從5.1.32版本開始，這個是動態變數，意味著你不需要重啟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緩衝池的內容(更具體地說，是緩存頁)在停止MySQL時存儲到一個文件。當你下次啟動MySQL時，它會在後台啟動一個線程來載入緩衝池的內容以提高預熱速度到3-5倍。

兩件事：

第一，它實際上沒有在關閉時複製緩衝池內容到文件，僅僅是複製表空間ID和頁面ID – 足夠的信息來定位硬碟上的頁面了。然後它就能以大量的順序讀非常快速的載入那些頁面，而不是需要成千上萬的小隨機讀。

第二，啟動時是在後台載入內容，因為MySQL不需要等到緩衝池內容載入完成再開始接受請求(所以看起來不會有什麼影響)。

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

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

13.INNODB_ADAPTIVE_HASH_INDEX_PARTS

如果你運行著一個大量SELECT查詢的MySQL伺服器(並且已經儘可能優化)，那麼自適應哈希索引將下你的下一個瓶頸。自適應哈希索引是InnoDB內部維護的動態索引，可以提高最常用的查詢模式的性能。這個特性可以重啟伺服器關閉，不過默認下在mysql的所有版本開啟。

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

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

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

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

14.QUERY_CACHE_TYPE

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

如果是那樣的情況，設置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開始，表緩存能分割到多個分區。

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

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

歡迎做Java的工程師朋友們私信我資料免費獲取免費的Java架構學習資料（裡面有高可用、高並發、高性能及分散式、Jvm性能調優、Spring源碼，MyBatis，Netty,Redis,Kafka,Mysql,Zookeeper,Tomcat,Docker,Dubbo,Nginx等多個知識點的架構資料）

其中覆蓋了互聯網的方方面面，期間碰到各種產品各種場景下的各種問題，很值得大家借鑒和學習，擴展自己的技術廣度和知識面。

資料庫緩衝池有什麼作用

其實就是一個存儲轉發的作用，如果你訪問的信息在緩衝池就直接在緩衝裡面拿，這對於降低資料庫壓力，提高資料庫性能和速度有明顯的效果