• 进入"运维那点事"后,希望您第一件事就是阅读“关于”栏目,仔细阅读“关于Ctrl+c问题”,不希望误会!

MySQL 5.7新特性概览-持续更新

MySQL 5.7 彭东稳 8年前 (2016-04-09) 25596次浏览 已收录 0个评论

MySQL 5.7 GA的发布,号称160万只读QPS,大有赶超NoSQL趋势。

MySQL 5.7新特性概览-持续更新

上面这个图是Oracle在只读场景下官方测试的结果,看上去QPS确实提升很大。不过官方的硬件测试环境是很高的,所以这个160万QPS对于大家测试来说,可能还比较遥远,所以实际测试的结果可能会失望。但是,至少我们看到了基于同样测试环境,MySQL 5.7在性能上的改进,对于多核利用的改善。

MySQL 5.7新增特性介绍

一、Security improvements

  • 初始化方式的改变及默认添加用户密码

MySQL默认的部署策略发生了变化,变得更加安全。mysql_install_db弃用了,改用mysqld加–initialize或–initialize-insecure选项来初始化数据目录。使用–initialize时,MySQL数据库初始化完成以后,会产生一个root@localhost用户,从MySQL 5.7开始,root用户的密码不再是空,而是随机产生一个密码,保存于error log,初次登录需使用密码并改变密码。这也导致了用户安装5.7时发现的与5.6版本比较大的一个不同点。

官方文档:http://dev.mysql.com/doc/refman/5.7/en/data-directory-initialization-mysqld.html

  • 删除test库及不再创建匿名账号

MySQL官方已经删除了test数据库,默认安装完后是没有test数据库的,就算用户创建了test库,也可以对test库进行权限控制了,并且不再创建匿名账户。

  • mysql.user表的改变

mysql.user表新增plugin列,且若某账户该字段值为空则账户不能使用。从低版本MySQL升级至MySQL5.7时要注意该问题,且建议DBA将使用mysql_old_password插件的账户替换为使用mysql_native_password插件。另外默认的用户密码字段由Password变成了authentication_string。

  • 增加密码过期策略

数据库管理员可以制定账户密码自动过期策略,密码过期后必须强制进行更改。

官方文档:http://dev.mysql.com/doc/refman/5.7/en/password-expiration-policy.html

  • 增加用户锁定限制

数据库管理员可以锁定/解锁账户来进行更好的登录控制,对应的,mysql.user表中新增account_locked列来表示锁定状态。版本升级过程中要注意该问题。

官方文档:http://dev.mysql.com/doc/refman/5.7/en/account-locking.html

  • 默认开启连接加密

MySQL可以自动创建SSL、RSA证书和Key文件来支持安全连接,但前提是Server用OpenSSL编译,默认情况下客户端是使用安全连接服务器的。

官方文档:http://dev.mysql.com/doc/refman/5.7/en/creating-ssl-rsa-files-using-mysql.html

试验可见:MySQL 5.7客户端使用加密连接

  • 增加密码复杂度检查插件validate_password

如果使用YUM安装MySQL的话,默认会装载这个插件,这个插件就是对用户密码复杂度(字母大小写、数字、特殊字符、密码长度等)的一个检查,如果不满足设定的复杂度要求则不允许创建用户。

试验可见:MySQL 5.7多方式安装

二、SQL mode changes

SQL_Mode变为STRICT_TRANS_TABLES SQL mode

SQL要求更严格,version < 5.6.6 sql_mode 为空,最为宽松,不够严谨。

5.6.6 < version < 5.7.4

NO_ENGINE_SUBSTITUTION

version > 5.7.9

ONLY_FULL_GROUP_BY

STRICT_TRANS_TABLES

NO_ZERO_IN_DATE

NO_ZERO_DATE

ERROR_FOR_DIVISION_BY_ZERO

NO_AUTO_CREATE_USER NO_ENGINE_SUBSTITUTION

以NO_ZERO_DATE为例,如果你原表里有0000-00-00 这种数据,在MySQL 5.7使用默认SQL_Mode时候改表时候就会报错了。

官方文档:http://dev.mysql.com/doc/refman/5.7/en/sql-mode.html#sql-mode-changes

试验可见:MySQL 5.7默认SQL模式带来的问题总结

三、Online ALTER TABLE

MySQL 5.7支持重命名索引和修改varchar的大小,无需table-copy。这两项操作在之前的版本中,都需要重建索引或表。适用于各引擎。

但存在限制,即只支持0~255字节内的或者255以上字节间的增加,也就是说若从254增到256时不能使用INPLACE算法,必须使用COPY算法,否侧报错。这是因为0~255内的VARCHAR值需要一个额外的字节来编码,而256以上的VARCHAR值需要两个字节来编码。另外使用INPLACE算法缩小VARCHAR的ALTER TABLE也是不支持的,必须用COPY算法。

官方文档:http://dev.mysql.com/doc/refman/5.7/en/alter-table.html

试验可见:MySQL InnoDB Online DDL

四、InnoDB enhancements.

  • 支持动态修改Buffer Pool

从MySQL 5.7.5开始可以在线动态调整InnoDB Buffer Pool,对运维更友好。很多人都经历过Buffer Pool过大或过小调整需要重启实例,运维成本非常高,尤其是主库或其他核心业务。MySQL 5.7为了支持online buffer pool resize,引入chunk的概念,每个chunk默认是128M,当我们在线修改buffer pool的时候,以chunk为单位进行增长或收缩。这个参数的引入,对innodb_buffer_pool_size的配置有了一定的影响。innodb要求buffer pool size是innodb_buffer_pool_chunk_size* innodb_buffer_pool_instances的倍数,如果不是,将会适当调大innodb_buffer_pool_size,以满足要求,因此,可能会出现buffer pool的实际分配比配置文件中指定的size要大的情况。

  • MySQL redo log大小调整

5.5 <= 4G, 5.6 +<= 512G。当然这个也不是越大越好,但是提供了可以 尝试的机会,越大的 redo log 理论会有更稳定的性能。当然带来的风险就是故障恢复时间会更长。下图就是不同 redo 大小的性能对比,主要是看性能抖动情况

MySQL 5.7新特性概览-持续更新

  • Innodb_file_per_table

默认值Off <= 5.6.5 <=On,独立表空间优点很明显。尤其可以使用 InnoDB Transportable tablespaces,可以像MyISAM 一样快速迁移表。

  • Query cache

1<= 5.6.8 <= 0,默认关闭。整体来说关闭query cache是利远大于弊,官方最终也选择了关闭。query cache访问需要获取一个全局锁,高并发时候争用很严重。更主要的是query cache缓存的效果并不好。

  • binlog_rows_query_log_events

默认关闭 ,可选打开,建议打开,还是比较有用的。可以看到row格式下的sql语句,方便排查问题和恢复数据。开启binlog_rows_query_log_events参数后binlog格式如下:

可以看到逻辑SQL执行的语句了,但是这个SQL语句使用#号注释了,如”# update tl set name=’bb’ where id=2″。

  • max_execution_time

MySQL 5.7.4刚引入名字是max_statement_time,后来改成max_execution_time。单位是毫秒,SQL语句的超时中断,自我保护的一种方案。只针对select,也可以在sql里指定。如果percona版本的话,这个参数更暴力,对所有请求生效慎用。

  • Innodb_numa_interleave

建议关掉numa。最早Twitter开源分支里有提供,也可以启动实例时候设置numactl –interleave all,不过实际线上使用系统默认numa策略,并没有遇到过因为numa导致的swap问题。

  • InnoDB临时表的DDL性能提升

InnoDB临时表元数据不再存储于InnoDB系统表而是存储在INNODB_TEMP_TABLE_INFO,包含所有用户和系统创建的临时表信息。该表在第一次在其上运行select时被创建。

InnoDB现在支持MySQL-supported空间数据类型。也即,之前的空间数据是以binary BLOB数据存储的,现在空间数据类型被映射到了一个InnoDB内部数据类型DATA_GEOMETRY.

对于non-compressed InnoDB临时表有独立的表空间,表空间在每次服务器重启时于默认的DATADIR中被重建,可通过innodb_temp_data_file_path选项指定其他路径。

innochecksum (离线的InnoDB文件校验工具),新增新的选择项或扩展的功能,如,可指定特定的校验算法、可以只重写校验值而不进行验证、可指定允许的校验和不匹配量、显示各类页的个数、导出页类型信息、输出至日志、从标准输入读取数据等。目前可支持超过2G的文件。(http://dev.mysql.com/doc/refman/5.7/en/innochecksum.html)

针对临时表及相关对象引入新的“non-redo” undo log,存放于临时表空间。该类型的undo log非 redolog 因为临时表不需崩溃恢复、也就无需redo logs,但却需要 undo log用于回滚、MVCC等。默认的临时表空间文件为ibtmp1,位于数据目录在每次服务器启动时被重新创建,可通过innodb_temp_data_file_path指定临时表空间。(http://dev.mysql.com/doc/refman/5.7/en/innodb-temporary-table-undo-logs.html)

可通过innodb_buffer_pool_dump_pct调整buffer pool中最近使用的页读取并dump的百分比。当有其他InnoDB后台任务所引起的I/O活动时,可通过 innodb_io_capacity 限制各I/O活动包括 buffer pool load 操作的频次。

InnoDB支持full-text parser 插件(http://dev.mysql.com/doc/refman/5.7/en/full-text-plugins.html)

支持多page cleaner线程从buffer pool中刷脏页,通过 innodb_page_cleaners配置线程数,默认值为1.

支持使用INPLACE算法的online DDL语句重建普通表和分区表:OPTIMIZE TABLE、ALTER TABLE … FORCE、ALTER TABLE … ENGINE=INNODB。

Linux系统中Fusion-io Non-Volatile Memory (NVM)文件系统提供了原子写能力,使InnoDB双写变得冗余。因此,MySQL5.7.4以后,对于支持原子写的Fusion-io设备上的系统表空间InnoDB doublewrite buffer会自动关闭。

对于分区表和独立的InnoDB表分区从MySQL5.7.4开始支持“可传输”表空间,使得分区表的备份步骤更加容易也使得在不同MySQl实例间拷贝分区表和独立的表分许成为可能。(http://dev.mysql.com/doc/refman/5.7/en/tablespace-copying.html)

可通过 innodb_buffer_pool_size 参数动态调整buffer pool大小,resize以chunk为单位,chunk大小通过 innodb_buffer_pool_chunk_size配置,另可通过Innodb_buffer_pool_resize_status 状态变量观察调整过程。(http://dev.mysql.com/doc/refman/5.7/en/innodb-buffer-pool-online-resize.html)

MySQL5.7.5开始Multi-threaded page clean也在shutdown和recover阶段被支持。

MySQL5.7.5后支持空间数据类型上建索引。且可通过 ALTER TABLE … ADD SPATIAL INDEX ALGORITHM=INPLACE进行在线操作。

创建和重建索引时支持bulk load,该方法被称为“sorted index build”,提升了索引创建效率,支持全文索引但不支持空间索引。可通过innodb_fill_factor定义每个页的填充因子,剩余的空间用于将来的索引增长。(http://dev.mysql.com/doc/refman/5.7/en/sorted-index-builds.html)

使用新的日志记录类型(MLOG_FILE_NAME)来识别上一个检查点以来发生变化的表空间。这简化了崩溃恢复时的表空间发现,消除了redo log应用之前的文件系统扫描。 (http://dev.mysql.com/doc/refman/5.7/en/innodb-recovery-tablespace-discovery.html).需要注意的是这一行为导致了redo log格式的变化,所以升级至MySQL5.7.5或者从改版本降级时需完全关闭MySQL。

可通过配置 innodb_undo_log_truncate来truncate undo表空间中的undo logs。系统表空间内的undo logs不会被truncate。(默认情况下undo log存储于系统表空间,可通过innodb_undo_directory、 innodb_undo_logs、 innodb_undo_tablespaces进行调整。http://dev.mysql.com/doc/refman/5.7/en/truncate-undo-tablespace.html )

支持本地化分区(native partitioning),之前需依赖ha_partition handler为每个分区创建handler对象,现在只需一个partition-aware handler对象,节约了内存。(可通过mysql_upgrade或者ALTER TABLE … UPGRADE PARTITIONING将老方法建的分区表升级为新的)。

支持使用CREATE TABLESPACE语句创建通用表空间。并可以通过 CREATE TABLE tbl_name … TABLESPACE [=] tablespace_name 或者 ALTER TABLE tbl_name TABLESPACE [=] tablespace_name将表添加到创建的通用表空间。(http://dev.mysql.com/doc/refman/5.7/en/general-tablespaces.html)

可通过innodb_default_row_format指定InnoDB表的默认行格式,新版本的默认值有COMPACT替换为了DYNAMIC 。

五、Json Support

随着非结构化数据存储需求的持续增长,各种非结构化数据存储的数据库应运而生(如MongoDB)。从最新的数据库使用 排行榜 来看,MongoDB已经超过了PostgreSQL,其火热程度可见一斑。各大关系型数据库也不甘示弱,纷纷提供对JSON的支持,以应对非结构化数据库的挑战。MySQL数据库从5.7.8版本开始,也提供了对JSON的支持。不再以字符串形式存储而是以二进制格式存储,允许快速读取文档元素。JSON列在插入或更新时会自动进行验证,文档格式不正确会报错。除了可用常用比较操作符进行比较外还引入一系列函数用于处理JSON类型。(http://dev.mysql.com/doc/refman/5.7/en/json.html

其使用方式如下:

MySQL对支持JSON的做法是,在server层提供了一堆便于操作JSON的函数,至于存储,就是简单地将JSON编码成BLOB,然后交由存储引擎层进行处理,也就是说,MySQL 5.7的JSON支持与存储引擎没有关系,MyISAM存储引擎也支持JSON格式。

MySQL支持JSON以后,总是避免不了拿来与MongoDB进行一些比较。但是,MySQL对JSON的支持,至少有两点能够完胜MongoDB:

1.可以混合存储结构化数据和非结构化数据,同时拥有关系型数据库和非关系型数据库的优点。

2.能够提供完整的事务支持。

试验可见:MySQL 5.7新特性JSON格式支持

六、Generate Column

generated column是MySQL 5.7引入的新特性,所谓generated column,就是数据库中这一列由其他列计算而得。例如,知道直角三角形的两条直角边,要求直角三角形的面积。很明显,面积可以通过两条直角边计算而得,那么,这时候就可以在数据库中只存放直角边,面积使用generated column,如下所示:

在MySQL 5.7中,支持两种generated column,即virtual generated column和stored generated column,前者只将generated column保存在数据字典中(表的元数据),并不会将这一列数据持久化到磁盘上;后者会将generated column持久化到磁盘上,而不是每次读取的时候计算所得。很明显,后者存放了可以通过已有数据计算而得的数据,需要更多的磁盘空间,与virtual column相比并没有优势。因此,在不指定generated column的类型时,默认是virtual column,如下所示:

如果读者觉得generate column提供的功能,也可以在用户代码里面实现,并没有什么了不起的地方,那么,或许还有一个功能能够吸引挑剔的你,那就是为generate column创建索引。在这个例子中,如果我们需要根据面积创建索引以加快查询,就无法在用户代码里面实现,使用generate column就变得非常简单:

试验可见:MySQL 5.7支持为表增加计算列

七、Performance improvements

性能一直都是用户最关心的问题,在MySQL每次新版本中,都会有不少性能提升。在MySQL 5.7中,性能相关的改进非常多,这里仅介绍部分改进,包括临时表相关的性能改进、只读事务的性能优化、连接建立速度的优化和复制性能的改进。

  • 临时表的性能改进

MySQL 5.7 为了提高临时表相关的性能,对临时表相关的部分进行了大幅修改,包括引入新的临时表空间;对于临时表的DDL,不持久化相关表定义;对于临时表的DML,不写redo,关闭change buffer等。所有临时表的改动,都基于以下两个事实 :

1. 临时表只在当前会话中可见。

2. 临时表的生命周期是当前连接(MySQL宕机或重启,则当前连接结束)。

也就是说,对于临时表的操作,不需要其他数据一样严格地进行一致性保证。通过不持久化元信息,避免写redo等方式,减少临时表操作的IO,以提高临时表操作的性能。

  • 只读事务性能改进

众所周知,在传统的OLTP应用中,读操作远多于写操作,并且,读操作不会对数据库进行修改,如果是非锁定读,读操作也不需要进行加锁。因此,对只读事务进行优化,是一个不错的选择。

在MySQL 5.6中,已经对只读事务进行了许多优化。例如,将MySQL内部实现中的事务链表分为只读事务链表和普通事务链表,这样在创建ReadView的时候,需要遍历事务链表长度就会小很多。

在MySQL 5.7中,首先假设一个事务是一个只读事务,只有在该事务发起了修改操作时,才会将其转换为一个普通事务。MySQL 5.7通过 避免为只读事务分配事务ID ,不为只读事务分配回滚段,减少锁竞争等多种方式,优化了只读事务的开销,提高了数据库的整体性能。

  • 加速连接处理

在MySQL 5.7之前,变量的初始化操作(THD、VIO)都是在连接接收线程里面完成的,现在将这些工作下发给工作线程,以减少连接接收线程的工作量,提高连接的处理速度。这个优化对那些频繁建立短连接的应用,将会非常有用。

八、Sys Schema

sys schema是MySQL 5.7.7中引入的一个系统库,包含了一系列视图、函数和存储过程, 该项目专注于MySQL的易用性。例如,我们可以通过sys schema快速的知道,哪些语句使用了临时表,哪个用户请求了最多的io,哪个线程占用了最多的内存,哪些索引是无用索引等。

sys schema中包含了大量的视图,那么,这些视图的信息来自哪里呢?视图中的信息均来自performance schema统计信息。这里有一个很好的比喻:

For Linux users I like to compare performance_schema to /proc, and SYS to vmstat.

也就是说,performance schema提供了信息源,但是,没有很好的将这些信息组织成有用的信息,从而没有很好的发挥它们的作用。而sys schema使用performance schema信息,通过视图的方式给出解决实际问题的答案。

例如,下面这些问题,在MySQL 5.7之前,需要借助外部工具才能知道,在MySQL 5.7中,直接查询sys库下相应的表就能得到答案:

• 如何查看数据库中的冗余索引select * from sys.schema_redundant_indexes;

• 如何获取未使用的索引select * from schema_unused_indexes;

• 如何查看使用全表扫描的SQL语句select * from statements_with_full_table_scans

包含sys库,存储从performance_schema收集用来辅助DBA和开发者的信息的相关对象,如,表和触发器、视图、存储过程、存储函数等,可用以调优和问题诊断。(http://dev.mysql.com/doc/refman/5.7/en/sys-schema.html)

九、Replication

  • replication info in tables

crash-safe slave方案,最早Google做的方案是存储在事务日志里。单独存储更灵活,可以解决很多从库宕机后duplicate key 问题。

MySQL 5.7新特性概览-持续更新

  • 动态修改复制过滤

支持在线设置复制的过滤规则,不再需要重启MySQL,只需要停止SQL thread,修改完成以后,启动SQL thread。

试验可见:MySQL主从复制过滤参数介绍

  • 支持多源复制

开始支持多源复制也即从多个master向某一个salve复制。用于将多个server备份到单个server、合并表shard、从多个server合并数据到单个server等(目前不提供冲突检测和解决方案,交由应用层处理。http://dev.mysql.com/doc/refman/5.7/en/replication-multi-source.html)。

随多源复制而引入的另外一项技术为复制信道(replication channels),Replication channels使slave可以打开多个连接,每个信道连接至不同的master进行复制。(http://dev.mysql.com/doc/refman/5.7/en/replication-channels.html)

试验可见:MySQL 5.7多源复制实践

  • Group Replication Performance Schema tables

performance_schema中新增一批表提供复制组相关信息(http://dev.mysql.com/doc/refman/5.7/en/performance-schema-replication-tables.html)

  • Group Replication SQL

引入如下两条组复制控制语句:(http://dev.mysql.com/doc/refman/5.7/en/replication-group-sql.html)

START GROUP_REPLICATION

STOP GROUP_REPLICATION

  • 支持在线开启GTID

在线开启GTID ,在之前的版本中,由于不支持在线开启GTID,用户如果希望将低版本的数据库升级到支持GTID的数据库版本,需要先关闭数据库,再以GTID模式启动,所以导致升级起来特别麻烦。MySQL 5.7以后,这个问题不复存在。当然也不是简单的SET @@GLOBAL.GTID_MODE = ON,步骤也是很复杂,不过至少不用停机,也是进步。

但是经过本人测试发现,至少目前还不是多么完美,并发大的情况下会导致数据丢失。

试验可见:MySQL 5.7在线把基于日志复制变更为GTID的复制

  • 从库无须开启log_slave_updates

MySQL 5.7新增gtid_executed,避免GTID复制必须开启log_slave_updates。MySQL 5.6版本开启GTID模式,必须打开参数log_slave_updates,简单来说就是必须在从机上再记录一份二进制日志。这样的无论对性能还是存储的开销,无疑会相应的增大。而MySQL 5.7版本开始无需在GTID模式下启用参数log_slave_updates,其中最重要的原因在于5.7在mysql库下引入了新的表gtid_executed。通过引入gtid_executed表实现,对性能优一定帮助,大大简化切换流程。增强半同步复制,确保从库先收到,设置半同步从库个数。使用mysqlbinlog作为伪slave是个不错方案。

试验可见:MySQL 5.7新增gtid_executed,避免GTID复制必须开启log_slave_updates

  • 基于表的并行复制技术

并行复制优化 ,MySQL 5.6默认并行复制。logical-clock 5.7引入,一个组提交内事务都可以并行,可以达到接近主库并发效果。

十、System and status variables.

http://dev.mysql.com/doc/refman/5.7/en/server-system-variables.html

优先从performance_schema下的表中获取系统变量和状态变量信息(老版本从information_schema下的表中获取,这些表将来会被移除),这对show variables和show status语句也有影响,也即信息源来自于performance_schema。若想使用原来的表获取信息可开启show_compatibility_56 参数(不推荐,只作为升级过程中的辅助工具,将来会被移除)。(http://dev.mysql.com/doc/refman/5.7/en/performance-schema-variable-table-migration.html)

十一、其他方面的改进

  • Optimizer

explain可以用来获取其他SESSION/CONNECTION中正在运行的语句的执行计划(前提条件是正在运行语句且语句类型支持EXPLAIN),语法为:EXPLAIN [options] FOR CONNECTION connection_id;其中connection_id即连接id,可由information_schema.processlist或者CONNECTION_ID()获取。
支持在语句中(以往是在optimizer_switch系统变量里)提供优化器提示信息以便于对语句的执行计划进行更还的控制。同样,在使用explain/desc查看执行计划时也可以在语句中使用优化提示,以便于查看优化提示是如何影响执行计划的。(http://dev.mysql.com/doc/refman/5.7/en/optimizer-hints.html

  • Triggers

之前的版本每个表上对于某一触发事件(insert\update\delete)和触发时机(before\after)的组合只能有一个触发器,新版本取消了这一限制。比如:值之前的版本,创建了如下触发器后CREATE TRIGGER ins_sum BEFORE INSERT ON account FOR EACH ROW SET @sum = @sum + NEW.amount;不能在创建另外的基于 BEFORE INSERT ON account的触发器了,新版本可以,只要触发器不同名即可。

  • Logging

之前版本,Unix或类Unix系统上的MySQL支持将错误日志发送到syslog,具体是通过mysqld_safe捕获错误输出然后传递到syslog来实现的。新的版本原生支持将错误日志输出到syslog,且适用于windows系统,只需要通过简单的参数(log_syslog等)配置即可。(http://dev.mysql.com/doc/refman/5.7/en/error-log.html

mysql支持–syslog选项,可将交互式的语句输出到系统的syslog中(Unix或类Unix系统下一般是/var/log/message)。对于匹配“ignore”过滤规则(可通过 –histignore选项或者 MYSQL_HISTIGNORE环境变量进行设置)的语句不会被记入。关于mysql客户端的日志使用参见:http://dev.mysql.com/doc/refman/5.7/en/mysql-logging.html

  • MySQL client

在Linux下,我们经常使用ctrl+c来终止一个命令的运行,在MySQL 5.7之前,如果用户输入了错误的SQL语句,按下ctrl+c ,虽然能够”结束”SQL语句的运行,但是,也会退出当前会话,MySQL 5.7对这一违反直觉的地方进行了改进,不再退出会话,用起来非常顺手。

  • Database name rewriting with mysqlbinlog

mysqlbinlog工具添加新的选项–rewrite-db,支持从行复制格式的二进制日志中读取事件时将数据库名重写 –rewrite-db=’dboldname->dbnewname’.可以通过指定多次该参数来指定多个重写规则。

  • HANDLER with partitioned tables

可以在分区表上使用HANDLER(http://dev.mysql.com/doc/refman/5.6/en/handler.html)

  • Index condition pushdown support for partitioned tables

使用InnoDB或者MyISAM的分区表上的查询支持使用ICP(http://dev.mysql.com/doc/refman/5.7/en/index-condition-pushdown-optimization.html

  • WITHOUT VALIDATION support for ALTER TABLE … EXCHANGE PARTITION

ALTER TABLE … EXCHANGE PARTITION语句包含{WITH|WITHOUT} VALIDATION 从句,默认为WITH VALIDATION ,会逐行验证交换过来的值是否满足分区边界定义。若指定了WITHOUT VALIDATION则不进行验证。(http://dev.mysql.com/doc/refman/5.7/en/partitioning-management-exchange.html)

  • Master dump thread improvements

master dump thread进行了重构来减少锁争用提升master吞吐量。之前的版本中只要读取一个时间dump thread就要获取锁;MySQL5.7.2和后续版本中,只有从最近一次成功写入的事件末位位置读取时才会获取锁。这意味值多个dump threads可并发读取二进制日志,且可以在客户端向二进制日志写入时读取。

  • Globalization improvements

开始包含gb18030字符集,支持 China National Standard GB18030 字符集。

  • XA

对分布式事务做了Bug修复和性能改进。

  • Changing the replication master without STOP SLAVE

新版本MySQL主从复制时在执行CHANGE MASTER TO语句前可不必执行 STOP SLAVE。此时,CHANGE MASTER语句的行为依赖于slave的SQL线程和IO线程;两个线程的启/停决定了某一时刻CHANGE MASTER TO语句中可以/不可以使用的选项。具体规则如下:

  • 若SQL线程停止,则可在CHANGE MASTER TO语句中使用 RELAY_LOG_FILE,
    RELAY_LOG_POS和MASTER_DELAY
    选项的组合,即时是IO线程正在运行中也无妨。若此时IO线程还在运行则不能运行除上述选项之外的选项。
  • 若IO线程停止,则可以在CHANGE MASTER TO语句中使用除了RELAY_LOG_FILE,
    RELAY_LOG_POS和MASTER_DELAY 选项之外的任何选项的组合,即时是SQL线程正在运行也无妨。
  • 在运行CHANGE MASTER TO…MASTER_AUTO_POSITION=1之前SQL线程和IO线程必须停止。

可通过 SHOW SLAVE STATUS命令检查SQL线程和IO线程运行状态。
之前的版本中若使用基于语句的复制且有临时表那么在执行STOP SLVAVE后执行CHANGE MASTER TO可能在远slave上留下临时表。新版本中会给出警告,如果在执行CHANGE MASTER TO使Slave_open_temp_tables 仍为0.

废弃特性

如下特性在MySQL5.7中不推荐使用,可能在将来的版本中被移除:
ERROR_FOR_DIVISION_BY_ZERO, NO_ZERO_DATE和NO_ZERO_IN_DATE几个sql mode不赞成使用了(但目前默认开启),长远的计划是将这个mode包含进 strict mode而明确移除这几个单独的mode。
关于账户管理语句有一下不赞成再使用的特性:

不推荐使用GRANT语句创建用户,而推荐使用CREATE USER语句创建。这样一来NO_AUTO_CREATE_USER这一sql mode对于GRANT语句也就没什么意义了,所以也将降级。

不推荐使用GRANT语句修改账户属性,而仅用于账户赋权。账户属性通过CREATE USER或者ALTER USER在创建或修改时赋予或者改动;

不推荐使用IDENTIFIED BY PASSWORD ‘hash_string’ 语法,推荐使用IDENTIFIED WITH auth_plugin AS ‘hash_string’ ;

不推荐使用SET PASSWORD语句和PASSWORD()函数,而推荐使用ALTER USER来修改账户密码;

不推荐使用old_password系统变量。

不推荐使用GROUP BY隐式排序,推荐明确使用ORDER BY从句。(GROUP BY排序只是MySQL的扩展语法,可能在将来版本移除)

不推荐使在EXPLAIN语句中使用EXTENDED和PARTITIONS关键字(仍可被识别但在新版本中已不必要。)
–skip-innodb以及–innodb=OFF, –disable-innodb等不赞成使用,因为新版本中InnoDB不能能被禁止了。

不推荐使用log_warnings系统变量和–log_warnings选项,推荐使用 log_error_verbosity 。

binlog_max_flush_queue_time 在新版本中已失效。

innodb_support_xa 在新版本中无效,因为XA事务的两阶段提交在MySQL5.7中默认支持。

metadata_locks_cache_size和metadata_locks_hash_instances、sync_frm、 character_set_database、collation_database系统变量不再起作用。

ENCRYPT(), ENCODE(), DECODE(), DES_ENCRYPT()和DES_DECRYPT() 不推荐使用,建议使用 AES_ENCRYPT() 和 AES_DECRYPT()。

请使用MBREquals()替代MBREqual()。

请使用Performance Schema替代INFORMATION_SCHEMA.PROFILING。

请使用原生的syslog替代mysqld_safe支持的syslog输出。

mysqlcheck工具的–fix-db-names和–fix-table-names选项不推荐使用,以及ALTER DATABASE语句的UPGRADE DATA DIRECTORY NAME从句不推荐使用。

移除特性

对pre-4.1版本的密码hash格式的支持被移除,相关联的,old_passwords系统变量、 OLD_PASSWORD()函数被移除,mysql_old_password认证插件被移除,–secure-auth选项无效且将在后续版本移除、 secure_auth 变量值允许为1,–skip-secure-auth被移除。

YEAR(2)不再被支持,请使用YEAR(4).

innodb_mirrored_log_groups被移除。

使用default_storage_engine代替storage_engine。

thread_concurrency、timed_mutexes 系统变量。

ALTER TABLE的IGNORE从句。

INSERT DELAYED 、 REPLACE DELAYED 中的DELAYED会被忽略,相关联的mysqldump中的–delayed-insert 选项被移除,performance_schema.table_lock_waits_summary_by_table中相关列被移除,mysqlbinlog不再为INSERT DELAYED注解。

Windows系统中使用.sys文件的Database symlinking被移除而使用支持native symlink 的mylink。(http://dev.mysql.com/doc/refman/5.7/en/windows-symbolic-links.html)

mysql_upgrade中的–basedir, –datadir 和–tmpdir 选项。
选项前缀不再被支持,只支持使用选项全名,比如要用–key-buffer-size而不能用–key-buffer,还有–skip-grant-tables与–skip-grant等。

SHOW ENGINE INNODB MUTEX输出被移除,可通过Performance Schema表上创建视图获取相关信息。

InnoDB表空间监控和InnoDB表监控被移除。表监控信息可通过INFORMATION_SCHEMA表获取。

用于启用和禁用InnoDB Monitor以及InnoDB Lock Monitor的特殊命名的表被移除,由 innodb_status_output和innodb_status_output_locks两个动态的系统变量取代.(http://dev.mysql.com/doc/refman/5.7/en/innodb-monitors.html

innodb_use_sys_malloc 和 innodb_additional_mem_pool_size 系统变量移除。

msql2mysql, mysql_convert_table_format, mysql_find_rows, mysql_fix_extensions, mysql_setpermission, mysql_waitpid, mysql_zap, mysqlaccess和mysqlbug 移除。

mysqlhotcopy被移除,可以使用mysqldump和 MySQL Enterprise Backup或者一些开源工具。

binary-configure.sh脚本被移除。

INNODB_PAGE_ATOMIC_REF_COUNT CMake选项被移除

innodb_create_intrinsic选项、 innodb_optimize_point_storage 、innodb_log_checksum_algorithm 选项被移除。


如果您觉得本站对你有帮助,那么可以支付宝扫码捐助以帮助本站更好地发展,在此谢过。
喜欢 (5)
[资助本站您就扫码 谢谢]
分享 (0)

您必须 登录 才能发表评论!