> 本文是基于MySQL-5.7.7-rc版本，未来可能 还会发生更多变化。
## 1、SQL MODE变化
a. 默认启用 STRICT_TRANS_TABLES 模式；
b. 对 ONLY_FULL_GROUP_BY 模式实现了更复杂的特性支持，并且也被默认启用；
c. 其他被默认启用的sql mode还有 NO_ENGINE_SUBSTITUTION；
### iMySQL建议
对广大MySQL使用者而言，以往不是那么严格的模式还是很方便的，在5.7版本下可能会觉得略为不适，慢慢习惯吧。比如向一个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 个字符。
## 2、优化online操作
例如修改buffer pool、修改索引名（非主键）、修改REPLICATION FILTER、修改MATER而无需关闭SLAVE线程 等众多特性。
可以在线修改buffer pool对DBA来说实在太方便了，实例运行过程中可以动态调整，避免事先分配不合理的情况，不过 [innodb_buffer_pool_instances](http://dev.mysql.com/doc/refman/5.7/en/innodb-parameters.html#sysvar_innodb_buffer_pool_instances) 不能修改，而且在 innodb_buffer_pool_instances 大于 1 时，也不能将 buffer pool 调整到 1GB 以内，需要稍加注意。
如果是加大buffer pool，其过程大致是：
~~~
1、以innodb_buffer_pool_chunk_size为单位，分配新的内存pages；
2、扩展buffer pool的AHI(adaptive hash index)链表，将新分配的pages包含进来；
3、将新分配的pages添加到free list中；
~~~
如果是缩减buffer pool，其过程则大致是：
~~~
1、重整buffer pool，准备回收pages；
2、以innodb_buffer_pool_chunk_size为单位，释放删除这些pages（这个过程会有一点点耗时）；
3、调整AHI链表，使用新的内存地址。
~~~
实际测试时，发现在线修改 buffer poo 的代价并不大，SQL命令提交完毕后都是瞬间完成，而后台进程的耗时也并不太久。在一个并发128线程跑tpcc压测的环境中，将 buffer pool 从32G扩展到48G，后台线程耗时 3秒，而从 48G 缩减回 32G 则耗时 18秒，期间压测的事务未发生任何锁等待。
~~~
-- 演示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
~~~
可以看到，几乎瞬间完成，尽管我在执行这个SQL时正跑着64个并发tpcc压测。
