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'使用新 ALTER USER语句设置为。帐户密码过期后，在后续使用该帐户连接到服务器时执行的所有操作都会导致错误，直到用户发出SET PASSWORD建立新帐户密码的语句。有关详细信息，请参阅 第 13.7.1.1 节，“ALTER USER 语句”和 第 6.2.10 节，“服务器处理过期密码”。

MySQL 现在有检查密码安全性的规定：

这两种功能都由 validate_password插件实现。有关详细信息，请参阅第 6.4.3 节 “密码验证插件”。

如果 mysql_upgrade 发现用户帐户的密码使用较早的 4.1 之前的散列方法进行散列，则mysql_upgrade现在会发出警告。应更新此类帐户以使用更安全的密码哈希。请参阅 第 6.1.2.4 节，“MySQL 中的密码散列”

在 Unix 平台上，mysql_install_db 支持一个新选项， --random-passwords它提供更安全的 MySQL 安装。调用mysql_install_db会 --random-passwords 导致它为 MySQL root帐户分配一个随机密码，为这些帐户设置 “密码过期”标志，并删除匿名用户 MySQL 帐户。有关其他详细信息，请参阅 第 4.4.3 节，“mysql_install_db — 初始化 MySQL 数据目录”。

日志记录已被修改，因此密码不会以明文形式出现在写入一般查询日志、慢速查询日志和二进制日志的语句中。请参阅 第 6.1.2.3 节，“密码和日志记录”。

mysql客户端不再记录引用密码的历史文件语句 。请参阅 第 4.5.1.3 节，“mysql 客户端日志记录”。

START SLAVE语法已被修改以允许指定连接参数以连接到源。这提供了将密码存储在 master.info文件中的替代方法。请参阅 第 13.4.2.5 节，“START SLAVE 语句”。

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

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

创建公钥和私钥以及数字签名

执行非对称加密和解密

使用加密哈希进行数字签名以及数据验证和确认

您可以在表上创建FULLTEXT索引 ，并使用 语法InnoDB查询它们。MATCH() ... AGAINST此功能包括一个新的邻近搜索运算符 ( @) 和几个新的配置选项和 INFORMATION_SCHEMA表：有关更多信息，请参阅 第 14.6.2.3 节，“InnoDB 全文索引”。

ALTER TABLE 可以在不复制表、不阻塞对表的插入、更新和删除或两者的情况下执行 多个操作。这些增强功能统称为在线 DDL。有关详细信息，请参阅第 14.13 节，“InnoDB 和在线 DDL”。

InnoDB现在支持语句的 子句，它允许在数据目录之外创建表。此增强功能提供了在更适合您的服务器环境的位置创建表的灵活性。例如，您可以将繁忙的表放在SSD 设备上，或将大表放在大容量 HDD设备上。 DATA DIRECTORY='directory'CREATE TABLE

有关详细信息，请参阅 第 14.6.1.2 节，“在外部创建表”。

InnoDB现在支持 “可传输表空间”的概念，允许 每个表的文件表 空间（.ibd文件）从一个正在运行的 MySQL 实例中导出并导入到另一个正在运行的实例中，而不会因缓冲数据、正在进行的事务和内部数据而导致不一致或不匹配簿记详细信息，例如空间 ID和 LSN。

该命令的FOR EXPORT子句 FLUSH TABLE将任何未保存的更改从 InnoDB内存缓冲区 写入.ibd文件。.ibd将文件和一个单独的元数据文件复制 到另一台服务器后，语句的DISCARD TABLESPACEandIMPORT TABLESPACE子句 ALTER TABLE用于将表数据带入不同的 MySQL 实例。

此增强功能提供了移动驻留在 file-per-table 表空间中的表的灵活性， 以更好地适应您的服务器环境。例如，您可以将繁忙的表移动到SSD设备，或将大表移动到大容量 HDD设备。有关详细信息，请参阅第 14.6.1.3 节，“导入 InnoDB 表”。

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

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

您可以编写 InnoDB通过 NoSQL 风格的 API 访问表的 MySQL 应用程序。此功能使用流行的 memcached守护进程来中继诸如ADD、SET和GET键值对之类的请求。这些存储和检索数据的简单操作避免了 SQL 开销，例如解析和构建 查询执行计划. 您可以通过 NoSQL API 和 SQL 访问相同的数据。例如，您可以使用 NoSQL API 进行快速更新和查找，使用 SQL 进行复杂查询并与现有应用程序兼容。有关详细信息，请参阅第 14.20 节，“InnoDB memcached 插件”。

表的优化器统计信息InnoDB 以更可预测的时间间隔收集，并且可以在服务器重新启动后保持不变，以提高 计划的稳定性。您还可以控制对InnoDB索引进行的采样量，以使优化器统计信息更加准确并改进查询执行计划。有关详细信息，请参阅 第 14.8.11.1 节，“配置持久优化器统计参数”。

新的优化适用于只读 事务，提高了临时查询和报告生成应用程序的性能和并发性。这些优化会在可行时自动应用，或者您可以指定START TRANSACTION READ ONLY以确保事务是只读的。有关详细信息，请参阅 第 8.5.3 节，“优化 InnoDB 只读事务”。

您可以将InnoDB 撤消日志从 系统表空间移出到一个或多个单独 的表空间中。撤消日志的 I/O 模式使这些新表空间成为迁移到 SSD 存储的良好候选者，同时将系统表空间保留在硬盘存储上。有关详细信息，请参阅第 14.6.3.3 节，“撤消表空间”。

InnoDB您可以通过指定配置选项 来提高校验和功能的效率 innodb_checksum_algorithm=crc32，这会打开更快的校验和算法。此选项替换innodb_checksums选项。使用旧校验和算法（选项值innodb）写入的数据完全向上兼容；使用新校验和算法（选项值 crc32）修改的表空间不能降级到不支持该 innodb_checksum_algorithm选项的早期版本的 MySQL。

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”。

新的配置选项 允许您从熟悉的 0-9 范围内为压缩表 innodb_compression_level选择 压缩 级别。您还可以控制当更新操作导致页面再次被压缩时，缓冲池中的压缩页面是否存储在重做日志中。此行为由 配置选项控制。 InnoDBzlibinnodb_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_cache 文档。

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允许您动态启用和禁用标准 InnoDBMonitor 和 InnoDBLock Monitor 以进行定期输出。通过创建和删除特殊命名的表来启用和禁用定期输出的监视器已被弃用，并且可能会在未来的版本中删除。有关其他信息，请参阅 第 14.17 节，“InnoDB 监视器”。

从 MySQL 5.6.17 开始， 在线 DDL 支持扩展到对常规表和分区InnoDB 表的以下操作：

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

如果您使用InnoDB压缩表，请参阅第 2.11.3 节，“MySQL 5.6 中的更改”以了解相关的升级影响。

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

现在可以使用该 ALTER TABLE ... EXCHANGE PARTITION语句将分区表的分区或子分区表的子分区与具有相同结构的非分区表进行交换。例如，这可用于导入和导出分区。有关更多信息和示例，请参阅 第 19.3.3 节，“使用表交换分区和子分区”。

现在支持对一个或多个分区或子分区的显式选择，以用于查询，以及许多作用于分区表的数据修改语句。例如，假设一个 t包含一些整数列 的表c有 4 个分区，分别命名为 p0、p1、 p2和p3。然后查询仅返回分区中 小于 5 的SELECT * FROM t PARTITION (p0, p1) WHERE c < 5那些行。p0p1c

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

有关语法，请参阅各个语句的说明。有关其他信息和示例，请参阅 第 19.5 节，“分区选择”。

分区锁修剪通过帮助消除不受这些语句影响的分区上的锁，极大地提高了许多作用于具有许多分区的表的 DML 和 DDL 语句的性能。此类语句包括许多 SELECT, SELECT ... PARTITION, UPDATE, REPLACE, INSERT以及许多其他语句。有关更多信息，包括性能因此得到改进的语句的完整列表，请参阅 第 19.6.4 节，“分区和锁定”。

表输入和输出的检测。检测操作包括对持久基表或临时表的行级访问。影响行的操作是获取、插入、更新和删除。

根据模式和/或表名按表过滤事件。

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

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

语句中的语句和阶段的检测。

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

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

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

使用 GTID 时，在启动新副本或故障转移到新源时无需参考日志文件或这些文件中的位置，这大大简化了这些任务。有关使用或不使用二进制日志文件为 GTID 复制配置服务器的更多信息，请参阅 第 17.1.3.3 节，“使用 GTID 进行故障转移和横向扩展”。

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

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

MySQL 基于行的复制现在支持行图像控制。通过仅记录为每行更改（而不是所有列）唯一标识和执行更改所需的那些列，可以节省磁盘空间、网络资源和内存使用量。binlog_row_image您可以通过将服务器系统变量设置为值之一 minimal（仅记录必需的列）、 full（记录所有列）或 noblob（记录除不需要BLOB或 列之外的所有列）来确定是记录完整行还是最少行 TEXT。看 与二进制日志记录一起使用的系统变量，了解更多信息。

MySQL 服务器写入和读取的二进制日志现在是崩溃安全的，因为只有完整的事件（或事务）才会被记录或回读。默认情况下，服务器会记录事件的长度以及事件本身，并使用此信息来验证事件是否已正确写入。binlog_checksum您还可以通过设置系统变量使服务器使用 CRC32 校验和为事件写入校验和 。要使服务器从二进制日志中读取校验和，请使用 master_verify_checksum 系统变量。这 --slave-sql-verify-checksum 系统变量导致副本 SQL 线程从中继日志中读取校验和。

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

为了使复制能够对意外停止具有弹性，slave_master_info和 slave_relay_log_info表必须各自使用事务存储引擎，并且从 MySQL 5.6.6 开始，这些表是 InnoDB出于这个原因创建的。（错误 #13538891）如果您使用的是以前的 MySQL 5.6 版本，其中这两个表都使用 MyISAM，这意味着，在开始复制之前，您必须将它们都转换为事务存储引擎（例如 InnoDB) 如果您希望复制对意外停止具有弹性。在这种情况下，您可以通过适当的 ALTER TABLE ... ENGINE=...语句来执行此操作。当复制实际运行时，您不应 尝试更改这些表中的任何一个使用的存储引擎。

有关详细信息，请参阅 第 17.3.2 节，“处理副本服务器的意外停止”。

mysqlbinlog现在能够以其原始二进制格式备份二进制日志。当使用 --read-from-remote-server 和--raw选项调用时， mysqlbinlog连接到服务器，请求日志文件，并以与原始格式相同的格式写入输出文件。请参阅 第 4.6.8.3 节，“使用 mysqlbinlog 备份二进制日志文件”。

MySQL 现在支持延迟复制，这样副本服务器就会故意落后于源服务器至少一段指定的时间。默认延迟为 0 秒。使用新MASTER_DELAY 选项CHANGE MASTER TO设置延迟。

延迟复制可用于防止用户在源上犯错（DBA 可以将延迟的副本回滚到灾难发生之前的时间）或测试系统在出现延迟时的行为方式等目的。请参阅 第 17.3.10 节，“延迟复制”。

MASTER_BIND 现在可以通过在发出CHANGE MASTER TO语句 时 使用该选项，使具有多个网络接口的副本仅使用其中一个（排除其他接口） 。

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

同样， relay_log_basename 系统变量显示中继日志文件的文件名和完整路径。

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

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

优化器现在可以更有效地处理以下形式的查询（和子查询）：

SELECT ... FROM single_table ... ORDER BY non_index_column [DESC] LIMIT [M,]N;

这种类型的查询在仅显示较大结果集中的几行的 Web 应用程序中很常见。例如：

SELECT col1, ... FROM t1 ... ORDER BY name LIMIT 10;
SELECT col1, ... FROM t1 ... ORDER BY RAND() LIMIT 15;

排序缓冲区的大小为 sort_buffer_size. 如果行的排序元素N足够小以适合排序缓冲区（如果指定了M+N 行M），服务器可以避免使用合并文件并完全在内存中执行排序。有关详细信息，请参阅 第 8.2.1.16 节，“LIMIT 查询优化”。

优化器实现磁盘扫描多范围读取。当表很大且未存储在存储引擎的缓存中时，使用二级索引上的范围扫描读取行可能会导致对基表的许多随机磁盘访问。通过磁盘扫描多范围读取 (MRR) 优化，MySQL 尝试通过首先仅扫描索引并收集相关行的键来减少范围扫描的随机磁盘访问次数。然后对键进行排序，最后使用主键的顺序从基表中检索行。Disk-sweep MRR 的动机是减少随机磁盘访问的次数，而是实现对基表数据的更顺序扫描。有关详细信息，请参阅 第 8.2.1.10 节，“多范围读取优化”。

优化器实现索引条件下推 (ICP)，这是针对 MySQL 使用索引从表中检索行的情况的优化。如果没有 ICP，存储引擎会遍历索引以定位基表中的行，并将它们返回给 MySQL 服务器，MySQL 服务器会评估这些WHERE行的条件。在启用 ICP 的情况下，如果 WHERE仅使用索引中的字段可以评估部分条件，则 MySQL 服务器会推送这部分条件WHERE 条件下降到存储引擎。然后，存储引擎使用索引条目评估推送的索引条件，只有在满足条件时才会读取基行。ICP 可以减少存储引擎必须对基表执行的访问次数以及 MySQL 服务器必须对存储引擎执行的访问次数。有关详细信息，请参阅 第 8.2.1.5 节，“索引条件下推优化”。

该EXPLAIN语句现在提供 DELETE、 INSERT、 REPLACE和 UPDATE语句的执行计划信息。以前，仅为报表EXPLAIN 提供信息 。SELECT此外，该EXPLAIN 语句现在可以生成 JSON 格式的输出。请参阅 第 13.8.2 节，“EXPLAIN 语句”。

优化器更有效地处理 FROM子句中的子查询（即派生表）。子句中子查询的具体化 FROM被推迟到查询执行期间需要它们的内容时，这提高了性能。此外，在查询执行期间，优化器可能会向派生表添加索引以加快从中检索行的速度。有关详细信息，请参阅 第 8.2.2.4 节，“优化派生表”。

优化器使用半连接和物化策略来优化子查询执行。请参阅 第 8.2.2.1 节，“使用半连接转换优化子查询”和 第 8.2.2.2 节，“使用物化优化子查询”。

Batched Key Access (BKA) 连接算法现在可用，它使用对连接表的索引访问和连接缓冲区。BKA算法支持内连接、外连接和半连接操作，包括嵌套外连接和嵌套半连接。BKA 的好处包括由于更有效的表扫描而提高了连接性能。有关详细信息，请参阅 第 8.2.1.11 节，“阻止嵌套循环和成批密钥访问连接”。

优化器现在具有跟踪功能，主要供开发人员使用。该接口由一组 系统变量和 表提供。有关详细信息，请参阅 MySQL 内部结构：跟踪优化器。 optimizer_trace_xxxINFORMATION_SCHEMA.OPTIMIZER_TRACE

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

更准确地解决了条件优先级。

诊断区域清理已更改。错误 #55843 导致在激活处理程序之前从诊断区域清除已处理的条件。这使得条件信息在处理程序中不可用。现在条件信息对处理程序可用，可以用GET DIAGNOSTICS语句检查它。如果在处理程序执行期间尚未清除条件信息，则在处理程序退出时清除条件信息。

以前，一旦条件发生，处理程序就会被激活。现在它们不会被激活，直到条件发生的语句完成执行，此时选择最合适的处理程序。这对于引发多个条件的语句可能会有所不同，如果在语句执行期间稍后引发的条件比较早的条件具有更高的优先级并且两个条件在相同范围内有处理程序。以前，将选择引发第一个条件的处理程序，即使它的优先级低于其他处理程序。

MySQL 现在允许 、 和值的小数秒TIME，精度可达微秒（6 位）。请参阅 第 11.2.7 节，“时间值中的小数秒”。 DATETIMETIMESTAMP

以前， TIMESTAMP每个表最多一列可以自动初始化或更新为当前日期和时间。此限制已取消。任何TIMESTAMP 列定义都可以具有 DEFAULT CURRENT_TIMESTAMP和 ON UPDATE CURRENT_TIMESTAMP子句的任意组合。此外，这些子句现在可以与 DATETIME列定义一起使用。有关详细信息，请参阅 第 11.2.6 节，“TIMESTAMP 和 DATETIME 的自动初始化和更新”。

在 MySQL 中，TIMESTAMP 数据类型在默认值以及自动初始化和更新属性的分配方面与其他数据类型存在非标准差异。explicit_defaults_for_timestamp 这些行为仍然是默认行为，但现在已弃用，并且可以通过在服务器启动时启用系统变量来关闭 。请参阅 第 11.2.6 节，“TIMESTAMP 和 DATETIME 的自动初始化和更新”和 第 5.1.7 节，“服务器系统变量”。

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

计数器已添加到主机缓存以跟踪适用于特定 IP 地址的错误，并且新的 host_cache性能模式表公开了主机缓存的内容，以便可以使用 SELECT语句对其进行检查。访问主机缓存内容可以回答诸如缓存了多少主机、哪些主机发生了何种连接错误或主机错误计数接近 max_connect_errors 系统变量限制等问题。

现在可以使用 host_cache_size系统变量配置主机缓存大小。