寫在前面
本系列文章基於5.7.12 版本講述MySQL的新特性。從安裝，檔案結構，SQL ,最佳化，運維層面複製，GITD等幾個方面展開介紹5.7 的新特性和功能。同時也建議大家跟蹤官方blog和官方文件，以儘快知悉其新的變化。前面寫了一篇文章介紹 innodb 的特性，囿於相關知識點比較多，本文繼續介紹5.7版本的innodb 新特性。
4.1 innodb buffer dump 功能增強
5.7.5 新增加innodb_buffer_pool_dump_pct引數，來控制每個innodb buffer中轉儲活躍使用的innodb buffer pages的比例。之前的版本預設值是100%，當觸發轉儲的時候會全量dump innodb buffer pool中的pages。如果啟用新的引數比如40 ，每個innodb buffer pool instance中有100個，每次轉儲每個innodb buffer 例項中的40個pages。
注意:當innodb發現innodb 後臺io資源緊張時，會主動降低該引數設定的比例。

4.2 支援多執行緒刷髒頁
MySQL 5.6.2版本中，MySQL將刷髒頁的執行緒從master執行緒獨立出來，5.7.4版本之後，MySQL系統支援多執行緒刷髒頁，程式的數量由innodb_page_cleaners引數控制，該引數不能動態修改，最小值為1 ，最大值支援64，5.7.7以及之前預設值是1 ，5.7.8版本之後修改預設引數為4。當啟用多執行緒刷髒也，系統將重新整理innodb buffer instance髒頁分配到各個空閒的刷髒頁的執行緒上，如果設定的innodb_page_cleaners>innodb_buffer_pool_instances,系統會自動重置為innodb_buffer_pool_instances大小。

4.3 動態調整 innodb buffer size
從5.7.5版本, MySQL支援在不重啟系統的情況下動態調整innodb_buffer_pool_size。resize的過程是以chunk(每個chunk的大小預設為128M)的為單位遷移pages到新的記憶體空間，遷移進度可以透過Innodb_buffer_pool_resize_status 檢視。記住整個resize的大小是以chunk為單位的。innodb_buffer_pool_chunk_size的大小,計算公式是innodb_buffer_pool_size / innodb_buffer_pool_instances,新調整的值必須是 innodb_buffer_pool_chunk_size*innodb_buffer_pool_instances的整數倍。如果不是整數倍，則系統則會調整值為大於兩者乘積的最大值。
例子

mysql> SHOW STATUS WHERE Variable_name='InnoDB_buffer_pool_resize_status';
+----------------------------------+----------------------------------------------------------------------+
| Variable_name | Value |
+----------------------------------+----------------------------------------------------------------------+
| Innodb_buffer_pool_resize_status | Size did not change (old size = new size = 268435456. Nothing to do. |
+----------------------------------+----------------------------------------------------------------------+
1 row in set (0.00 sec)
mysql> set global innodb_buffer_pool_size=128*1024*1024;
Query OK, 0 rows affected (0.00 sec)
mysql> SHOW STATUS WHERE Variable_name='InnoDB_buffer_pool_resize_status';
+----------------------------------+----------------------------------------------------+
| Variable_name | Value |
+----------------------------------+----------------------------------------------------+
| Innodb_buffer_pool_resize_status | Completed resizing buffer pool at 160702 23:53:51. |
+----------------------------------+----------------------------------------------------+
1 row in set (0.00 sec)
mysql> set global innodb_buffer_pool_size=256*1024*1024;
Query OK, 0 rows affected (0.00 sec)
mysql> SHOW STATUS WHERE Variable_name='InnoDB_buffer_pool_resize_status';
+----------------------------------+----------------------------------------------------+
| Variable_name | Value |
+----------------------------------+----------------------------------------------------+
| Innodb_buffer_pool_resize_status | Completed resizing buffer pool at 160702 23:54:19. |
+----------------------------------+----------------------------------------------------+
1 row in set (0.00 sec)

online調整bp size的log 記錄大致過程
a 計算要調整的bpsize
b 禁止AHI，清理所有的索引快取
c Withdrawing block是遍歷freelist 確定可以使用的空閒block
d 鎖住整個buffer pool
e 遷移重新分配chunk/刪除可以釋放的chunk
f 設定innodb_buffer_pool_size為新的值
g 重新開啟AHI

2016-07-02T15:40:44.724495Z 0 [Note] InnoDB: Resizing buffer pool from 134217728 to 268435456 (unit=134217728).
2016-07-02T15:40:44.724546Z 2 [Note] InnoDB: Resizing buffer pool from 134217 (new size: 268435456 bytes)
2016-07-02T15:40:44.724559Z 0 [Note] InnoDB: Disabling adaptive hash index.
2016-07-02T15:40:44.724979Z 0 [Note] InnoDB: disabled adaptive hash index.
2016-07-02T15:40:44.725029Z 0 [Note] InnoDB: Withdrawing blocks to be shrunken.
2016-07-02T15:40:44.725040Z 0 [Note] InnoDB: Latching whole of buffer pool.
2016-07-02T15:40:44.725210Z 0 [Note] InnoDB: buffer pool 0 : resizing with chunks 1 to 2.
2016-07-02T15:40:44.735439Z 0 [Note] InnoDB: buffer pool 0 : 1 chunks (8192 blocks) were added.
2016-07-02T15:40:44.735511Z 0 [Note] InnoDB: Completed to resize buffer pool from 134217728 to 268435456.
2016-07-02T15:40:44.735561Z 0 [Note] InnoDB: Re-enabled adaptive hash index.
2016-07-02T15:40:44.735586Z 0 [Note] InnoDB: Completed resizing buffer pool at 160702 23:40:44.

這個特性是最令眾多MySQL DBA 期待的特性之一。以後線上動態擴容，縮容就無需做資料庫切換了，間接增強了系統的穩定性和DBA的生活幸福感。當然本文中介紹的略顯粗略。詳細內容請參考《官方文件》

4.4 支援全域性表空間
全域性表空間可以被所有的資料庫的表共享,而且相比於 file-per-table tablespaces. 使用共享表空間可以節約後設資料方面的記憶體。(需要更深入的瞭解共享表空間主要是大小收縮問題)

mysql> CREATE TABLESPACE `youzan_com`
-> ADD DATAFILE 'youzan_com.ibd' FILE_BLOCK_SIZE = 16k;
Query OK, 0 rows affected (0.02 sec)
mysql> use yang
Database changed
mysql> create table yztb(id int primary key not null ,val char(10)) engine=innodb default charset=utf8 TABLESPACE youzan_com ;
Query OK, 0 rows affected (0.04 sec)
mysql> create database youzan default charset utf8;
Query OK, 1 row affected (0.02 sec)
mysql> use youzan
Database changed
mysql>
mysql> create table yztb(id int primary key not null ,val char(10)) engine=innodb default charset=utf8 TABLESPACE youzan_com ;
Query OK, 0 rows affected (0.03 sec)

4.5 行格式預設為DYNAMIC
從MySQL 5.7.9 開始,行格式DYNAMIC 取代COMPACT 成為innodb儲存引擎預設的行格式，MySQL提供了新的引數innodb_default_row_format來控制Innodb 行格式，詳細的資訊請參考《Specifying the Row Format for a Table》

4.6 支援原生的分割槽表
在MySQL 5.7.6之前的版本中,建立分割槽表時MySQL為每個分割槽建立一個ha_partition handler，自MySQL 5.7.6之後，MySQL支援原生的分割槽表並且只會為分割槽表建立一個partition-aware handler，這樣的分割槽表功能增強節約分割槽表使用的記憶體。對於老版本建立的分割槽表在升級到新的版本之後怎麼處理呢？莫慌，5.7.9之後，MySQL提供瞭如下升級方式解決這個問題：

ALTER TABLE ... UPGRADE PARTITIONING.

當然友情提示:從我個人的理解來看，在沒有合適的自動化維護分割槽表系統的基礎上，不推薦使用分割槽表。四年的工作經歷已經數次在分割槽表上掉坑裡了。

4.7 支援truncate undo logs
MySQL 5.7.5版本開始支援truncate undo 表空間中的undo log。啟用該特性必須設定innodb_undo_log_truncate=[ON|1]。大致原理是系統必須設定至少兩個undo 表空間(初始化的時候設定 innodb_undo_tablespaces=2 ) 用於清理undo logs的切換。該特性的好處是解決了 ibdata 檔案一直增大的問題，減輕系統的空間使用。詳細資訊參考《官方文件》

小結
到這裡 innodb 部分算是基本完成，但是依然有很多其他的特性需要"探索" ，自己在寫《MySQL 5.7 新特性》系列文章的時候，或深入或簡單閱讀官方文件，深刻的感覺到5.7 有很多新的變化，同時也感到自己對於5.6版本的官方文件並未閱讀透徹，並沒有之前學習Oracle的時候的學習方式---官方文件是最好的教材。在這裡僅以過來人 DBA 老司機的角度給MySQL DBA新人的建議多閱讀官方文件，勝過市面上99%的書籍。
後面會繼續探索MySQL 5.7 新特性。
參考文章
[1] 《MySQL 5.7 官方文件》
[2] 《MySQL 5.7 初探》
[3] 《MySQL 5.7新特性之一》
[4] 《MySQL 5.7新特性之二》
[5] 《MySQL 5.7新特性之三》

【MySQL】5.7新特性之四

相關文章