《《MySQL運維內參》節選》要點：
本文介紹了《MySQL運維內參》節選，希望對您有用。如果有疑問，可以聯系我們。

本文上接?InnoDB日志管理機制(一),繼續分析buffer pool：

一個BufferPool實例中的所有控制頭信息連續存儲在一起,所以控制信息存儲完成之后才是真正的緩沖頁面,下圖表示的是一個BufferPool實例的內存分布情況.

對于BufferPool中的所有頁面,都有一個控制頭信息與它對應,從上圖可以看出,每一個ctl都表示了一個屬于自己的page使用情況.初始化實例時當然還需要對每一個控制頭信息進行初始化,也就是每一個buf_block_t結構.初始化一個頁面控制信息是通過buf_block_init函數實現的,buf_block_t結構中包含了很多信息,主要包括如下4部分.

1. 其對應的頁面地址frame.
2. 頁信息結構buf_page_t,這個結構用來描述一個頁面的信息,包括所屬表空間的ID號、頁面號、被修改時產生的LSN(newest_modification及oldest_modification)、使用狀態(現在共有9種狀態)等(上面已經介紹過與buf_block_t的關系).
3. 用來保護這個頁面的互斥量mutex.
4. 訪問頁面時對這個頁面上的鎖lock(read/write)等.

在初始化完每一個頁面之后,需要將每一個頁面加入到上面提到的空閑頁鏈表中,因為這些頁面現在的狀態都是未使用(BUF_BLOCK_NOT_USED).

到現在為止,緩沖池的一個實例就算初始化完成了,在訪問數據庫的時候會通過這些內存頁面來緩存文件數據.

相對于整個Buffer Pool而言,多個Buffer Pool實例之間的關系,需要在這里再講述一下.上面所說的單個實例的初始化,是完全獨立的,多個實例之間沒有任何關系,單獨申請、單獨管理、單獨刷盤,可以從其實現的代碼中看到這一點,代碼如下.

從代碼中可以看出,每一個Buffer Pool實例在整個Buffer Pool中確實是完全獨立的,而在具體使用時,針對不同頁面,通過一個HASH算法,來映射到一個具體的實例中,對應的代碼如下.

通過Buffer Pool多實例的管理機制,可以減少系統運行過程中不同頁面之間一些操作的相互影響,從而很好地解決了由于頁面之間的資源爭搶導致的性能低下的問題,所以在實際的運維過程中,建議要分多實例的管理方式,把MySQL及InnoDB用好,讓業務少一些煩惱.

本文先到這里,下次開始講REDO LOG,那是一大塊…….

文章來自微信公眾號：DBAce

轉載請注明本頁網址：
http://www.snjht.com/jiaocheng/4187.html