mysql5.7版本的新特性_《转》MySQL 5.7版本新特性连载

本文是基于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、修改MASTER而无需关闭SLAVE线程等众多特性。

可以在线修改buffer pool对DBA来说实在太方便了，实例运行过程中可以动态调整，避免事先分配不合理的情况，不过 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压测。

MySQL 5.7版本新特性连载(五)

本文是基于MySQL-5.7.7-rc版本，未来可能 还会发生更多变化。

1、支持多源复制(Multi-source replication)，这对采用分库分表的同学绝对是个超级重磅福音。可以把多个MASTER的数据归并到一个实例上， 有助于提高SLAVE服务器的利用率。不过如果是同一个表的话，会存在主键和唯一索引冲突的风险，需要提前做好规划。

【新特性实践】

MySQL 5.7的多源复制采用多通道的模式，例如用以下方法可以创建多个复制通道，将多个MASTER上的数据复制到同一个SLAVE节点中去：

-- 需要先把 MASTER_INFO_REPOSITORY 和 RELAY_LOG_INFO_REPOSITORY 改成 TABLE 模式

[yejr@imysql.com]> SET GLOBAL MASTER_INFO_REPOSITORY = "TABLE";

Query OK, 0 rows affected (0.00 sec)

[yejr@imysql.com]> SET GLOBAL RELAY_LOG_INFO_REPOSITORY = "TABLE";

Query OK, 0 rows affected (0.00 sec)

-- 创建第一个复制通道

[yejr@imysql.com]> CHANGE MASTER TO MASTER_HOST='1.2.3.4', MASTER_USER='user', MASTER_PASSWORD='repl' FOR CHANNEL 'MASTER-01';

Query OK, 0 rows affected, 2 warnings (0.00 sec)

-- 创建第二个复制通道

[yejr@imysql.com]> CHANGE MASTER TO MASTER_HOST='2.3.4.5', MASTER_USER='user', MASTER_PASSWORD='repl' FOR CHANNEL 'MASTER-02';

Query OK, 0 rows affected, 2 warnings (0.00 sec)

-- 查看第二个复制通道的状态

[yejr@imysql.com]> SHOW SLAVE STATUS FOR CHANNEL 'MASTER-02';

*************************** 1. row ***************************

Slave_IO_State:

Master_Host: 2.3.4.5

Master_User: user

Master_Port: 3306

Connect_Retry: 60

Master_Log_File:

Read_Master_Log_Pos: 4

Relay_Log_File: yejr-relay-bin-master@002d02.000001

Relay_Log_Pos: 4

Relay_Master_Log_File:

Slave_IO_Running: No

Slave_SQL_Running: No

Replicate_Do_DB:

Replicate_Ignore_DB:

Replicate_Do_Table:

Replicate_Ignore_Table:

Replicate_Wild_Do_Table:

Replicate_Wild_Ignore_Table:

Last_Errno: 0

Last_Error:

Skip_Counter: 0

Exec_Master_Log_Pos: 0

Relay_Log_Space: 154

Until_Condition: None

Until_Log_File:

Until_Log_Pos: 0

Master_SSL_Allowed: No

Master_SSL_CA_File:

Master_SSL_CA_Path:

Master_SSL_Cert:

Master_SSL_Cipher:

Master_SSL_Key:

Seconds_Behind_Master: NULL

Master_SSL_Verify_Server_Cert: No

Last_IO_Errno: 0

Last_IO_Error:

Last_SQL_Errno: 0

Last_SQL_Error:

Replicate_Ignore_Server_Ids:

Master_Server_Id: 0

Master_UUID:

Master_Info_File: mysql.slave_master_info

SQL_Delay: 0

SQL_Remaining_Delay: NULL

Slave_SQL_Running_State:

Master_Retry_Count: 86400

Master_Bind:

Last_IO_Error_Timestamp:

Last_SQL_Error_Timestamp:

Master_SSL_Crl:

Master_SSL_Crlpath:

Retrieved_Gtid_Set:

Executed_Gtid_Set: f0df162a-1a39-11e5-883a-782bcb65f419:1-11025782

Auto_Position: 0

Replicate_Rewrite_DB:

Channel_Name: master-02

1 row in set (0.00 sec)

其他和复制相关的SQL指令和以往也基本一样，只需在加上FOR CHANNEL ‘CHANNEL-NAME’子句即可。

此外，还支持在线修改replication filter规则，不过不是太建议使用filter规则，因此不重点介绍了。执行下面的SQL命令可以完成filter规则修改：

[yejr@imysql.com]> CHANGE REPLICATION FILTER

REPLICATE_DO_DB = (d1), REPLICATE_IGNORE_DB = (d2);

2、支持多线程复制(Multi-Threaded Slaves, 简称MTS)，在5.6版本中实现了SCHEMA级别的并行复制，不过意义不大，因为我们线上大部分实例的读写压力基本集中在某几个数据表，基本无助于缓解复制延迟问题。倒是MariaDB的多线程并行复制大放异彩，有不少人因为这个特性选择MariaDB(比如我也是其一，呵呵)。

MySQL 5.7 MTS支持两种模式，一种是和5.6一样，另一种则是基于binlog group commit实现的多线程复制，也就是MASTER上同时提交的binlog在SLAVE端也可以同时被apply，实现并行复制。关于MTS的更多详细介绍可以查看姜承尧的分享

值得一提的是，经过对比测试，5.7采用新的并行复制后，仍然会存在一定程度的延迟，只不过相比5.6版本减少了86%，相比MariaDB的并行复制延迟也小不少。

MySQL 5.7版本新特性连载(六)

本文是基于MySQL-5.7.7-rc版本，未来可能 还会发生更多变化。

自动判断底层I/O设备是否可以支持原子IO(AIO)，检测到的话，会自动关闭 double write buffer，进一步提升性能。

支持innodb_page_cleaners选项可设置多个page cleaner线程提高脏页刷新效率。

可通过设置

加强InnoDB read-only模式的性能。

支持一个表上有多个触发器，这样一来，原先已有触发器表也可以支持用

新增log_syslog选项，可将MySQL日志打印到系统日志文件中。

InnoDB和MyISAM引擎的分区表也支持ICP特性。

支持在线(INPLACE)增加 VARCHAR 列的长度。不过 0-255 长度是一个区间，256 以上是另一个区间，不能跨越255这个坎，比如把长度从 100 扩展成 1000(因为 255 长度以内额外用1个字节表示，大于 255 长度则需要额外2个字节表示)。另外还不支持在线缩小 VARCHAR 的长度。