MySQL现在提供了一种将身份验证凭据加密存储在选项文件中的方法.mylogin.cnf．要创建该文件，请使用mysql_config_editor实用程序。MySQL客户端程序稍后可以读取该文件，以获得连接到MySQL服务器的身份验证凭据。mysql_config_editor写.mylogin.cnf使用加密的文件，因此凭证不以明文形式存储，并且当客户机程序解密其内容时仅在内存中使用。通过这种方式，密码可以以非明文格式存储在文件中，并在以后使用，而不需要在命令行或环境变量中公开。有关更多信息，请参见章节4.6.6，“mysql_config_editor - MySQL配置实用程序”．

MySQL现在支持对用户帐户密码进行更强的加密，通过一个名为sha256_password实现了SHA-256密码哈希。这个插件是内置的，所以它总是可用的，不需要显式加载。有关更多信息，包括创建使用SHA-256密码的帐户的说明，请参见第6.4.1.4节“SHA-256可插式认证”．

的mysql.user系统表现在有一个password_expired列。默认值为“N”，但可以设置为“Y”与新改变用户声明。帐户的密码过期后，在使用该帐户连接到服务器的后续操作中执行的所有操作都会导致错误，直到用户发出一个设置密码语句以建立新的帐户密码。有关更多信息，请参见第13.7.1.1节，“ALTER USER语句”,第6.2.10节“过期密码的服务器处理”．

MySQL现在提供了检查密码安全性的功能:

控件实现这两个功能validate_password插件。有关更多信息，请参见第6.4.3节“密码验证插件”．

mysql_upgrade现在，如果它发现使用4.1以前的旧散列方法散列的密码的用户帐户，就会产生一个警告。这样的帐户应该更新以使用更安全的密码哈希。看到第6.1.2.4节“MySQL中的密码哈希”

在Unix平台上,mysql_install_db支持一个新的选项，——随机密码，这提供了更安全的MySQL安装。调用mysql_install_db与——随机密码导致它给MySQL分配一个随机密码根账户,设置”密码过期”标记，并删除匿名用户MySQL帐户。有关其他详细信息，请参见mysql_install_db -初始化MySQL数据目录．

日志记录已被修改，以便在写入常规查询日志、慢查询日志和二进制日志的语句中，密码不会以纯文本形式出现。看到第6.1.2.3节“密码和日志记录”．

的mysql客户端不再记录到引用密码的历史文件语句。看到章节4.5.1.3，“mysql客户端日志”．

开始的奴隶语法已被修改，以允许指定连接参数以连接到源。对象中存储密码的替代方法master.info文件。看到第13.4.2.5节，“START SLAVE语句”．

MySQL现在将授予命名管道上的客户机的访问控制设置为Windows上成功通信所需的最小值。较新的MySQL客户端软件可以打开命名管道连接，无需任何额外配置。如果旧的客户端软件不能立即升级，则新的named_pipe_full_access_groupsystem变量可用于为Windows组提供打开命名管道连接的必要权限。完全访问组中的成员应该是受限的和临时的。

使用公钥非对称加密实现附加的数据保护

创建公钥、私钥和数字签名

执行非对称加解密

使用加密散列进行数字签名和数据验证和验证

您可以创建全文上的索引InnoDB表，并使用匹配()……反对语法。此功能包括一个新的接近搜索操作符(@)和几个新的配置选项和INFORMATION_SCHEMA表:见第14.6.2.3节“InnoDB全文索引”为更多的信息。

几个ALTER TABLE可以在不复制表、不阻塞对表的插入、更新和删除或两者都不阻塞的情况下执行操作。这些增强被统称为在线DDL．看到第14.13节“InnoDB和在线DDL”获取详细信息。

InnoDB现在支持数据目录= '目录＇条款的创建表语句，该语句允许在数据目录之外创建表。这种增强提供了在更适合服务器环境的位置创建可创建对象的灵活性。例如，可以将忙表放在固态硬盘设备上，还是大容量的表硬盘驱动器设备。

有关更多信息，请参见14.6.1.2节“外部创建表”．

InnoDB现在支持的是”移动式表空间”,允许file-per-table表空间(.ibd文件)从一个正在运行的MySQL实例中导出并导入到另一个正在运行的实例中，而不会出现由于缓冲数据、正在进行的事务和内部簿记细节(如空间ID而且LSN．

的用于出口条款的刷新表命令写入任何未保存的更改InnoDB的内存缓冲区.ibd文件。后复制.ibd文件和一个单独的元数据文件到另一个服务器丢弃表空间而且导入表空间条款的ALTER TABLE语句用于将表数据导入另一个MySQL实例。

这种增强提供了移动所驻留的表的灵活性file-per-table以便更好地适应您的服务器环境。例如，您可以将忙表移动到固态硬盘设备，或将大表移动到大容量硬盘驱动器设备。有关更多信息，请参见第14.6.1.3节“导入InnoDB表”．

您现在可以设置InnoDB页面大小将未压缩的表压缩为8KB或4KB，以替代默认的16KB。控件控制此设置innodb_page_size配置选项。您可以在创建MySQL实例时指定大小。所有InnoDB表空间在一个实例中共享相同的页面大小。对于某些工作负载和存储设备的组合，更小的页面大小可以帮助避免冗余或低效的I/O固态硬盘具有小块大小的设备。

算法的改进自适应冲洗使I/O操作在多种情况下更加高效和一致工作负载．新的算法和默认配置值有望提高大多数用户的性能和并发性。高级用户可以通过几个配置选项微调他们的I/O响应能力。看到第14.8.3.4节“配置缓冲池刷新”获取详细信息。

您可以编写MySQL应用程序访问InnoDB表通过nosql风格的API。该特性使用了流行的memcached守护进程来中继请求，例如添加，集,得到键-值对。这些用于存储和检索数据的简单操作避免了SQL开销，如解析和构造查询执行计划．您可以通过NoSQL API和SQL访问相同的数据。例如，您可以使用NoSQL API进行快速更新和查找，使用SQL进行复杂查询并与现有应用程序兼容。看到第14.20节，“InnoDB memcached Plugin”获取详细信息。

优化器统计数据InnoDB表以更可预测的时间间隔收集，并且可以在服务器重新启动时保持，从而得到改进计划稳定．您还可以控制所做的采样量InnoDB索引，以使优化器统计数据更准确，并改进查询执行计划。看到第14.8.11.1节“配置持久优化器统计参数”获取详细信息。

新的优化应用于只读交易，提高特别查询和报告生成应用程序的性能和并发性。这些优化在实际时自动应用，或者您可以指定启动事务只读确保事务是只读的。看到第8.5.3节“优化InnoDB只读事务”获取详细信息。

你可以移动InnoDBundo日志出了系统表空间变成一个或多个单独的表空间．undo日志的I/O模式使这些新的表空间很适合迁移到SSD存储，同时将系统表空间保留在硬盘存储上。有关详细信息,请参见第14.6.3.3节“撤消表空间”．

可以提高效率InnoDB校验和特性，指定配置选项innodb_checksum_algorithm = crc32，它开启了更快的校验和算法。此选项将替换innodb_checksums选择。使用旧校验和算法写入的数据(选项值innodb)完全向上兼容;使用新的校验和算法修改的表空间(选项值crc32)不能降级到不支持的MySQL的早期版本innodb_checksum_algorithm选择。

的InnoDB重做日志文件的最大组合大小从4GB增加到512GB。方法指定较大的值innodb_log_file_size选择。启动行为现在自动处理现有重做日志文件的大小不匹配的情况innodb_log_file_size而且innodb_log_files_in_group．

的——innodb-read-only选项允许您以只读模式运行MySQL服务器。您可以访问InnoDB表在只读媒体上，如DVD或CD，或建立一个数据仓库与多个实例共享相同的数据目录。看到第14.8.2节“为只读操作配置InnoDB”使用的细节。

一个新的配置选项，innodb_compression_level，允许您选择一个压缩水平InnoDB压缩表，从熟悉的0-9范围使用zlib．当更新操作导致页面再次压缩时，您还可以控制缓冲池中的压缩页面是否存储在重做日志中。控件控制此行为innodb_log_compressed_pages配置选项。

的数据块InnoDB压缩表中包含一定量的空白空间(填充)以允许DML操作来修改行数据，而无需重新压缩新值。过多的填充会增加压缩失败的几率，当数据在大量更改后需要重新压缩时，就需要分割页面。填充的数量现在可以动态调整，这样dba就可以降低压缩失败率，而无需使用新参数重新创建整个表，或者使用不同的页面大小重新创建整个实例。相关的新配置选项为innodb_compression_failure_threshold_pct，innodb_compression_pad_pct_max．

几个新InnoDB相关的INFORMATION_SCHEMA的信息InnoDB的关于表、索引和外键的元数据InnoDB数据字典，以及有关性能指标的低级信息，这些信息补充了来自performance Schema表的信息。

为了减轻具有大量表的系统的内存负载，InnoDB现在使用LRU算法释放与已打开表相关的内存，以选择未被访问时间最长的表。为打开的元数据保留更多的内存InnoDB表中，增加的值table_definition_cache配置选项。InnoDB将此值作为”软限制”中打开的表实例的数量InnoDB数据字典缓存。有关更多信息，请参阅table_definition_cache10bet官方网站文档。

InnoDB具有几个内部性能增强，包括通过分隔内核互斥锁减少争用、将冲洗操作从主线程移到单独的线程、启用多个清除线程以及减少大内存系统上缓冲池的争用。

InnoDB使用一种新的，更快的算法来检测死锁．所有的信息InnoDB死锁可以写入MySQL服务器错误日志，以帮助诊断应用程序问题。

为了避免冗长的热身在重新启动服务器之后，特别是对于大型实例InnoDB缓冲池，可以在重新启动后立即将页面重新加载到缓冲池中。MySQL可以在关闭时转储一个紧凑的数据文件，然后参考该数据文件找到页面在下次重新启动时重新加载。您还可以在任何时候手动转储或重新加载缓冲池，例如在基准测试期间或在复杂的报告生成查询之后。看到第14.8.3.5节“保存和恢复缓冲池状态”获取详细信息。

截至MySQL 5.6.16，innochecksum支持大于2GB的文件。在此之前,innochecksum只支持2GB大小的文件。

从MySQL 5.6.16开始，新的全局配置参数，innodb_status_output而且innodb_status_output_locks，允许您动态启用和禁用标准InnoDB监控和InnoDB锁定监视器的周期输出。通过创建和删除特殊命名的表来启用和禁用定期输出的监视器已被弃用，可能会在未来的版本中删除。有关其他信息，请参见第14.17节“InnoDB监控器”．

从MySQL 5.6.17，在线DDL支持扩展到以下常规和分区操作InnoDB表:

从MySQL 5.6.42开始，zlib库与MySQL绑定的版本从1.2.3版本提升到1.2.11版本。MySQL在zlib库的帮助下实现压缩。

如果你使用InnoDB压缩表,请参阅第2.11.3节“MySQL 5.6的变化”相关升级影响。

最大分区数增加到8192。这个数字包括表的所有分区和所有子分区。

方法，可以将分区表的分区或子分区表的子分区与具有相同结构的非分区表交换ALTER TABLE……交换分区声明。例如，这可以用于导入和导出分区。有关更多信息和示例，请参见第19.3.3节“与表交换分区和子分区”．

现在，对于作用于分区表的查询以及许多数据修改语句，都支持显式选择一个或多个分区或子分区。例如，假设有一个表t用某个整数列c有4个分区p0，p1，p2,p3．然后查询SELECT * FROM t PARTITION (p0, p1) WHERE c < 5只从分区中返回那些行p0而且p1的c小于5。

以下语句支持显式分区选择:

有关语法，请参阅各个语句的描述。有关更多信息和示例，请参见第19.5节“分区选择”．

分区锁修剪通过帮助消除不受这些语句影响的分区上的锁，极大地提高了作用于具有多个分区的表的许多DML和DDL语句的性能。这样的陈述包括许多选择，选择……分区，更新，取代，插入，以及许多其他语句。有关更多信息，包括性能因此得到改进的语句的完整列表，请参见第19.6.4节“分区和锁定”．

用于表输入和输出的仪器。仪器化操作包括对持久基表或临时表的行级访问。影响行的操作有:取、插入、更新和删除。

基于模式和/或表名，按表筛选事件。

线程事件过滤。为线程收集更多信息。

用于表和索引I/O以及表锁的汇总表。

语句和语句中的阶段的工具。

在服务器启动时配置仪器和消费者，以前只能在运行时配置。

MySQL现在支持基于事务的复制全局事务标识符(也称为”GTIDs”)．这使得当事务在初始服务器上提交时，以及当它被任何副本应用时，可以识别和跟踪每个事务。

在复制设置中启用gtid主要是使用新的gtid_mode而且enforce_gtid_consistency系统变量。有关支持gtid而引入的其他选项和变量的信息，请参见第17.1.4.5节“全局事务ID选项和变量”．

当使用gtid时，在启动一个新的副本或故障转移到一个新的源时，不需要引用日志文件或这些文件中的位置，这极大地简化了这些任务。有关使用或不使用二进制日志文件为GTID复制提供服务器的详细信息，请参见第17.1.3.3节“使用gtid进行故障转移和扩展”．

基于gtid的复制完全基于事务，这使得检查源和副本的一致性变得简单。如果在给定源上提交的所有事务也在给定副本上提交，则可以保证两个服务器之间的一致性。

有关MySQL Replication中gtid的实现和使用的更完整信息，请参阅第17.1.3节，“使用全局事务标识符的复制”．

MySQL基于行的复制现在支持行映像控制。通过只记录每一行更改(而不是所有列)上唯一标识和执行更改所需的列，可以节省磁盘空间、网络资源和内存使用。属性，可以确定记录的是完整行还是最小行binlog_row_image将服务器系统变量设置为其中一个值最小的(只记录所需列)，完整的(记录所有列)，或者noblob(记录所有列，不需要的除外团或文本列)。看到二进制日志使用的系统变量，以查询更多资料。

MySQL服务器写入和读取的二进制日志现在是崩溃安全的，因为只有完整的事件(或事务)被记录或读取。默认情况下，服务器记录事件的长度以及事件本身，并使用这些信息来验证事件是否被正确写入。方法还可以使服务器使用CRC32校验和为事件写入校验和binlog_checksum系统变量。要使服务器从二进制日志读取校验和，请使用master_verify_checksum系统变量。的——slave-sql-verify-checksumsystem变量导致复制SQL线程从中继日志读取校验和。

MySQL现在支持将源连接信息和复制中继日志信息记录到表和文件中。可以独立控制这些表的使用master_info_repository而且relay_log_info_repository系统变量系统变量。设置master_info_repository来表格导致连接信息记录到slave_master_info表格设置relay_log_info_repository来表格导致中继日志信息记录到slave_relay_log_info表格控件中自动创建两个表mysql系统数据库。

为了使复制对意外停止具有弹性，可以使用slave_master_info而且slave_relay_log_info表必须使用事务性存储引擎，从MySQL 5.6.6开始，这些表是使用InnoDB也是因为这个原因。(Bug #13538891)如果您使用的是之前的MySQL 5.6版本，其中这两个表都使用MyISAM，这意味着在开始复制之前，必须将它们都转换为事务性存储引擎(例如InnoDB)，如果您希望复制对意外中断具有弹性。在这种情况下，您可以通过适当的ALTER TABLE……引擎=…语句。你应该不尝试在复制实际运行时更改这些表所使用的存储引擎。

看到第17.3.2节“处理副本服务器的意外停止”，以查询更多资料。

mysqlbinlog现在可以将二进制日志备份为原始二进制格式。的方法调用时——read-from-remote-server而且——生选项,mysqlbinlog连接到服务器，请求日志文件，并以与原始文件相同的格式写入输出文件。看到4.6.8.3节，“使用mysqlbinlog备份二进制日志文件”．

MySQL现在支持延迟复制，这样复制服务器就会故意落后于源服务器至少指定一段时间。缺省情况下，延迟时间为0秒。使用新的MASTER_DELAY选择改变主设置延迟时间。

延迟复制可以用于防止源上的用户错误(DBA可以将延迟副本回滚到灾难发生之前的时间)，或者在出现延迟时测试系统的行为。看到第17.3.10节，“延迟复制”．

属性可以使具有多个网络接口的副本只使用其中一个网络接口(而不使用其他网络接口)MASTER_BIND选项时发出改变主声明。

的log_bin_basename已添加系统变量。此变量包含二进制日志文件的完整文件名和路径。而log_bin系统变量只显示是否启用二进制日志记录，log_bin_basename方法设置的名称——log-bin服务器选项。

类似地,relay_log_basename系统变量显示中继日志文件的文件名和完整路径。

MySQL Replication现在支持在副本上多线程并行执行事务。在启用并行执行时，复制SQL线程作为多个复制工作线程的协调器，这些线程的值由slave_parallel_workers服务器系统变量。副本上多线程的当前实现假设数据和更新是基于每个数据库进行分区的，并且给定数据库中的更新发生的相对顺序与在源上发生的相同。但是，不需要协调不同数据库之间的事务。事务还可以分布在每个数据库上，这意味着副本上的工作线程可以处理给定数据库上的连续事务，而无需等待对其他数据库的更新完成。

由于不同数据库上的事务在副本上与在源上以不同的顺序发生，因此仅仅检查最近执行的事务并不能保证源上的所有以前的事务都已在副本上执行。这对使用多线程副本时的日志记录和恢复有影响。有关在副本上使用多线程时如何解释二进制日志记录信息的信息，请参见第13.7.5.35节，“SHOW SLAVE STATUS语句”．

优化器现在更有效地处理以下形式的查询(和子查询):

选择……从single_table．.．命令non_index_column(DESC)限制(米，]N；

这种类型的查询在只显示较大结果集中的少数行的web应用程序中很常见。例如:

选择col1,…从t1……按名称订购数量限制10个;选择col1,…从t1……按兰德()限时15;

排序缓冲区的大小为sort_buffer_size．如果排序元素为N行足够小，可以放入排序缓冲区(米+N行,如果米时，服务器可以避免使用归并文件，而完全在内存中执行排序。有关详细信息,请参见第8.2.1.16节“LIMIT查询优化”．

优化器实现了磁盘扫描多范围读取。当基表很大且没有存储在存储引擎的缓存中时，在辅助索引上使用范围扫描读取行可能会导致对基表的多次随机磁盘访问。通过磁盘扫描多范围读取(MRR)优化，MySQL试图减少用于范围扫描的随机磁盘访问的数量，方法是首先只扫描索引并收集相关行的键。然后对键进行排序，最后使用主键的顺序从基表检索行。磁盘扫描MRR的动机是减少随机磁盘访问的数量，取而代之的是对基表数据进行更有序的扫描。有关更多信息，请参见第8.2.1.10节“多范围读优化”．

优化器实现了索引条件下推(ICP)，这是针对MySQL使用索引从表中检索行的情况进行的优化。如果没有ICP，存储引擎将遍历索引以定位基表中的行，并将它们返回给MySQL服务器在哪里行条件。启用ICP后，如果部分在哪里条件可以通过只使用索引中的字段来求值，MySQL服务器推送这部分在哪里降到存储引擎的状态。然后，存储引擎使用索引条目计算推入的索引条件，只有满足这个条件，才读取基行。ICP可以减少存储引擎对基表的访问数量，以及MySQL服务器对存储引擎的访问数量。有关更多信息，请参见第8.2.1.5节“索引条件下推优化”．

的解释语句现在提供的执行计划信息删除，插入，取代,更新语句。在此之前,解释提供的资料只供选择语句。此外,解释语句现在可以生成JSON格式的输出。看到第13.8.2节，“EXPLAIN语句”．

中更有效地处理子查询从子句(即派生表)。中的子查询的物化从子句被延迟到查询执行期间需要它们的内容时，这将提高性能。此外，在查询执行期间，优化器可以向派生表添加索引，以加快从派生表中检索行的速度。有关更多信息，请参见第8.2.2.4节“优化派生表”．

优化器使用半连接和物化策略来优化子查询的执行。看到第8.2.2.1节，“使用半连接转换优化子查询”,第8.2.2.2节，“使用物化优化子查询”．

现在可以使用批处理键访问(BKA)连接算法，它既使用对已连接表的索引访问，也使用连接缓冲区。BKA算法支持内连接、外连接和半连接操作，包括嵌套的外连接和嵌套的半连接。BKA的好处包括由于更高效的表扫描而提高的连接性能。有关更多信息，请参见第8.2.1.11节“块嵌套循环和批处理键访问连接”．

优化器现在具有跟踪功能，主要供开发人员使用。接口是由一组optimizer_trace_xxx系统变量和INFORMATION_SCHEMA。OPTIMIZER_TRACE表格有关详细信息,请参见MySQL内部:跟踪优化器．

块作用域用于确定要选择的处理程序。以前，存储程序被视为具有单一的处理程序选择范围。

条件优先级的解析更加准确。

诊断区域清除已更改。Bug #55843导致在激活处理程序之前从诊断区域清除被处理的条件。这使得条件信息在处理程序中不可用。处理程序现在可以使用条件信息，它可以使用获得诊断声明。如果在处理程序执行期间尚未清除，则在处理程序退出时清除条件信息。

以前，只要情况发生，处理程序就会被激活。现在，直到发生条件的语句完成执行，它们才被激活，这时将选择最合适的处理程序。对于引发多个条件的语句，如果在语句执行过程中稍后引发的条件比前面的条件具有更高的优先级，并且两个条件的处理程序在相同的作用域内，那么这将产生不同的结果。以前，将选择第一个引发的条件的处理程序，即使它的优先级比其他处理程序低。现在将选择优先级最高的条件的处理程序，即使它不是语句引发的第一个条件。

MySQL现在允许小数秒时间，DATETIME,时间戳值，具有高达微秒(6位数字)的精度。看到第11.2.7节“时间值中的小数秒”．

以前，最多一个时间戳每个表的列可以自动初始化或更新为当前日期和时间。这一限制已被取消。任何时间戳列定义可以具有的任意组合默认CURRENT_TIMESTAMP而且在更新CURRENT_TIMESTAMP条款。此外，这些从句现在可以与DATETIME列定义。有关更多信息，请参见第11.2.6节“TIMESTAMP和DATETIME的自动初始化和更新”．

在MySQL中,时间戳数据类型与其他数据类型在默认值、自动初始化和更新属性的赋值方面存在非标准的差异。这些行为仍然是默认的，但现在已弃用，可以通过启用explicit_defaults_for_timestamp服务器启动时的系统变量。看到第11.2.6节“TIMESTAMP和DATETIME的自动初始化和更新”,第5.1.7节，“服务器系统变量”．

新Connection_errors_xxx状态变量提供有关连接错误的信息，但不适用于特定的客户端IP地址。

已向主机缓存中添加了计数器，以跟踪适用于特定IP地址的错误host_cache表公开主机缓存的内容，以便使用选择语句。对主机缓存内容的访问可以回答以下问题:缓存了多少主机、为哪些主机发生了什么类型的连接错误，或者主机错误计数距离达到max_connect_errors系统变量的限制。

属性可以配置主机缓存大小host_cache_size系统变量。