本文是基于MySQL-5.7.7-rc版本,未來可能 還會發(fā)生更多變化。
a.?默認啟用 STRICT_TRANS_TABLES 模式;
b. 對 ONLY_FULL_GROUP_BY 模式實現(xiàn)了更復(fù)雜的特性支持,并且也被默認啟用;
c. 其他被默認啟用的sql mode還有 NO_ENGINE_SUBSTITUTION;
對廣大MySQL使用者而言,以往不是那么嚴格的模式還是很方便的,在5.7版本下可能會覺得略為不適,慢慢習(xí)慣吧。比如向一個20字符長度的VARCHAR列寫入30個字符,在以前會自動截斷并給個提示告警,而在5.7版本下,則直接拋出錯誤了。個人認為這倒是一個好的做法,避免各種奇葩的寫法。
-- 查看默認的 sql_mode
[yejr@imysql.com]>?select @@sql_mode;
+-----------------------------------------------------------------------------------+
| @@sql_mode |
+-----------------------------------------------------------------------------------+
| ONLY_FULL_GROUP_BY,STRICT_TRANS_TABLES,NO_AUTO_CREATE_USER,NO_ENGINE_SUBSTITUTION |
+-----------------------------------------------------------------------------------+
-- 插入50個字符
[yejr@imysql.com]> insert into t_char select 0, repeat('x',50);
ERROR 1406 (22001): Data too long for column 'uname' at row 1
-- 修改本 session 的 sql_mode
[yejr@imysql.com]> set sql_mode = 'ONLY_FULL_GROUP_BY,NO_AUTO_CREATE_USER,NO_ENGINE_SUBSTITUTION';
Query OK, 0 rows affected (0.00 sec)
-- 去掉 STRICT_TRANS_TABLES 模式后
[yejr@imysql.com]>?select @@sql_mode;
+---------------------------------------------------------------+
| @@sql_mode |
+---------------------------------------------------------------+
| ONLY_FULL_GROUP_BY,NO_AUTO_CREATE_USER,NO_ENGINE_SUBSTITUTION |
+---------------------------------------------------------------+
[yejr@imysql.com]> insert into t_char select 0, repeat('x',50);
Query OK, 1 row affected, 1 warning (0.00 sec) -- 提示有告警信息
Records: 1 Duplicates: 0 Warnings: 1
[yejr@imysql.com]> show warnings;
+---------+------+--------------------------------------------+
| Level | Code | Message |
+---------+------+--------------------------------------------+
| Warning | 1265 | Data truncated for column 'uname' at row 1 |
+---------+------+--------------------------------------------+
因為 uname 字段的長度為 40 個字符。
例如修改buffer pool、修改索引名(非主鍵)、修改REPLICATION FILTER、修改MATER而無需關(guān)閉SLAVE線程?等眾多特性。
可以在線修改buffer pool對DBA來說實在太方便了,實例運行過程中可以動態(tài)調(diào)整,避免事先分配不合理的情況,不過?innodb_buffer_pool_instances?不能修改,而且在?innodb_buffer_pool_instances 大于 1 時,也不能將 buffer pool 調(diào)整到 1GB 以內(nèi),需要稍加注意。
如果是加大buffer pool,其過程大致是:
1、以innodb_buffer_pool_chunk_size為單位,分配新的內(nèi)存pages;
2、擴展buffer pool的AHI(adaptive hash index)鏈表,將新分配的pages包含進來;
3、將新分配的pages添加到free list中;
如果是縮減buffer pool,其過程則大致是:
1、重整buffer pool,準(zhǔn)備回收pages;
2、以innodb_buffer_pool_chunk_size為單位,釋放刪除這些pages(這個過程會有一點點耗時);
3、調(diào)整AHI鏈表,使用新的內(nèi)存地址。
實際測試時,發(fā)現(xiàn)在線修改 buffer poo 的代價并不大,SQL命令提交完畢后都是瞬間完成,而后臺進程的耗時也并不太久。在一個并發(fā)128線程跑tpcc壓測的環(huán)境中,將 buffer pool 從32G擴展到48G,后臺線程耗時 3秒,而從 48G 縮減回 32G 則耗時 18秒,期間壓測的事務(wù)未發(fā)生任何鎖等待。
-- 演示1:從 1G 擴大到 16G
[yejr@imysql.com]> SET GLOBAL innodb_buffer_pool_size = 51539607552;
Query OK, 0 rows affected (0.00 sec)
-- 看看日志記錄
09:21:19.460543Z 0 [Note] InnoDB: Resizing buffer pool from 1073741824 to 17179869184\. (unit=134217728)
09:21:19.468069Z 0 [Note] InnoDB: disabled adaptive hash index.
09:21:20.760724Z 0 [Note] InnoDB: buffer pool 0 : 60 chunks (491511 blocks) were added.
09:21:21.922869Z 0 [Note] InnoDB: buffer pool 1 : 60 chunks (491520 blocks) were added.
09:21:21.935114Z 0 [Note] InnoDB: buffer pool 0 : hash tables were resized.
09:21:21.947264Z 0 [Note] InnoDB: buffer pool 1 : hash tables were resized.
09:21:22.203031Z 0 [Note] InnoDB: Resized hash tables at lock_sys, adaptive hash index, dictionary.
09:21:22.203062Z 0 [Note] InnoDB: Completed to resize buffer pool from 1073741824 to 17179869184.
09:21:22.203075Z 0 [Note] InnoDB: Re-enabled adaptive hash index.
-- 演示2:從 16G 縮減到 1G
[yejr@imysql.com]> SET GLOBAL innodb_buffer_pool_size = 1073741824;
Query OK, 0 rows affected (0.00 sec)
-- 看看日志記錄
09:22:55.591669Z 0 [Note] InnoDB: Resizing buffer pool from 17179869184 to 1073741824\. (unit=134217728)
09:22:55.680836Z 0 [Note] InnoDB: disabled adaptive hash index.
09:22:55.680864Z 0 [Note] InnoDB: buffer pool 0 : start to withdraw the last 491511 blocks.
09:22:55.765778Z 0 [Note] InnoDB: buffer pool 0 : withdrew 489812 blocks from free list. Tried to relocate 1698 pages (491510/491511).
09:22:55.774492Z 0 [Note] InnoDB: buffer pool 0 : withdrew 0 blocks from free list. Tried to relocate 1 pages (491511/491511).
09:22:55.782745Z 0 [Note] InnoDB: buffer pool 0 : withdrawn target 491511 blocks.
09:22:55.782786Z 0 [Note] InnoDB: buffer pool 1 : start to withdraw the last 491520 blocks.
09:22:55.892068Z 0 [Note] InnoDB: buffer pool 1 : withdrew 489350 blocks from free list. Tried to relocate 2166 pages (491517/491520).
09:22:55.900743Z 0 [Note] InnoDB: buffer pool 1 : withdrew 0 blocks from free list. Tried to relocate 2 pages (491519/491520).
09:22:55.908257Z 0 [Note] InnoDB: buffer pool 1 : withdrew 0 blocks from free list. Tried to relocate 0 pages (491519/491520).
09:22:55.915778Z 0 [Note] InnoDB: buffer pool 1 : withdrew 0 blocks from free list. Tried to relocate 1 pages (491520/491520).
09:22:55.923836Z 0 [Note] InnoDB: buffer pool 1 : withdrawn target 491520 blocks.
09:22:56.149172Z 0 [Note] InnoDB: buffer pool 0 : 60 chunks (491511 blocks) were freed.
09:22:56.308997Z 0 [Note] InnoDB: buffer pool 1 : 60 chunks (491520 blocks) were freed.
09:22:56.316258Z 0 [Note] InnoDB: buffer pool 0 : hash tables were resized.
09:22:56.324027Z 0 [Note] InnoDB: buffer pool 1 : hash tables were resized.
09:22:56.393589Z 0 [Note] InnoDB: Resized hash tables at lock_sys, adaptive hash index, dictionary.
09:22:56.393616Z 0 [Note] InnoDB: Completed to resize buffer pool from 17179869184 to 1073741824.
09:22:56.393628Z 0 [Note] InnoDB: Re-enabled adaptive hash index.
再來看下在線修改非主鍵索引名,直接用?ALTER TABLE RENAME INDEX?語法即可。
例如下面的SQL語法:
[yejr@imysql.com]> ALTER TABLE orders RENAME INDEX idx1 TO idxxx1;
Query OK, 0 rows affected (0.11 sec)
Records: 0 Duplicates: 0 Warnings: 0
可以看到,幾乎瞬間完成,盡管我在執(zhí)行這個SQL時正跑著64個并發(fā)tpcc壓測。
更多建議: