////////////////////////////////////////////////////////////
struct buf_pool_struct{
mutex_t zip_mutex; //用于保护压缩page(buf_page_t)
mutex_t zip_free_mutex;
mutex_t zip_hash_mutex; //保护zip_hash
hash_table_t* zip_hash; //hash table of buf_block_t blocks whose frames are allocated to the zip buddy system, indexed by block->frame
ulint n_pend_unzip; //number of pending decompressions
UT_LIST_BASE_NODE_T(buf_block_t) unzip_LRU; //base node of the unzip_LRU list
UT_LIST_BASE_NODE_T(buf_page_t) zip_free[BUF_BUDDY_SIZES_MAX]; //存储buddy allocator的空闲block
}
Innodb采用Binary buddy allocator算法来为compress page（block->page.zip.data）分配内存块（buf/buf0buddy.c）
buf_buddy_alloc_low是分配block的函数，需要持有LRU_list_mutex，不可以持有zip_mutex
buf_buddy_free_low是释放block的函数，需要持有zip_free_mutex，不可以持有zip_mutex
innodb_cmpmem表显示每个bp instance的不同page size的内存分配情况，因此在调用i_s_cmpmem_fill_low时需要持有zip_free_mutex锁
zip_mutex用于保护压缩页在buffer pool中的操作，在如下函数中被调用到：
1.buf/buf0lru.c
buf_LRU_free_block:
buf_LRU_block_remove_hashed_page：该函数会释放zip_mutex
2.buf/buf0buf.c
buf_page_init
buf_page_init_for_read
buf_page_get_gen
buf_get_latched_pages_number_instance
buf_pool_watch_set/buf_pool_watch_unset
buf_pool_validate_instance
buf_get_latched_pages_number_instance
3.include/buf0buf.ic
buf_page_release_zip
zip_hash_mutex用于保护buf_pool->zip_hash，在如下函数中调用
buf/buf0buddy.c：
buf_buddy_block_free
buf_buddy_block_register
——————————————————
buf_block_struct{
UT_LIST_NODE_T(buf_block_t) unzip_LRU; 在解压page LRU list上的节点，当该block的page.state == BUF_BLOCK_FILE_PAGE并且page.zip.data != NULL时会在unzip_lru list上
buf_page_t page;
}
——————————————————-
struct buf_page_struct{
page_zip_des_t zip; //包含压缩页信息
UT_LIST_NODE_T(buf_page_t) zip_list; //zip_clean or zip_free[]
}
从代码来看，zip_list应该是buffer_pool->zip_free链表的节点
——————————————————–
struct page_zip_des_struct{
page_zip_t* data; //压缩Page数据
m_start //debug编译，mlog开始的偏移量
m_end //mlog的结尾偏移量
m_nonempty //为true时表示mlog不为空
n_blobs //该Page上外部存储的列的个数，在一个16kb的page上最大为744
ssize //为0表示非压缩Page，否则压缩page大小为PAGE_ZIP_MIN_SIZE << (ssize – 1)
}