MySQL 5.6.1 中的变化（未发布，里程碑 5）

MySQL 5.6 发行说明 / MySQL 5.6.1 中的变化（未发布，里程碑 5）

MySQL 5.6.1 中的变化（未发布，里程碑 5）

笔记

这是一个里程碑版本，使用风险自负。不支持里程碑版本之间的升级（或从里程碑版本升级到 GA 版本）。重大的开发变更发生在里程碑版本中，您可能会遇到兼容性问题，例如除了运行mysql_upgrade的常规过程之外还需要注意的数据格式更改。例如，您可能会发现有必要在升级前使用mysqldump转储数据并在升级后重新加载。（无论如何，在升级之前进行备份是一种谨慎的预防措施。）

性能模式注释

Performance Schema 添加了以下内容：
- setup_consumers表格内容已更改。以前，该表使用 “扁平”结构，消费者名称和目标表之间是一一对应的。这已被消费者设置的层次结构所取代，这些设置可以逐步更好地控制接收事件的目的地。以前的 xxx_summary_xxx 消费者不再存在。相反，性能模式会自动为启用消费者层次结构中的设置的级别维护适当的摘要。例如，如果仅启用顶级（全局）消费者，则仅维护全局摘要。其他的，例如线程级摘要，则不是。请参阅按消费者预过滤。此外，还添加了优化以减少 Performance Schema 开销。
- 现在可以使用新 setup_objects表按对象过滤事件。目前，该表可用于根据模式名称和/或表名称有选择地检测表。请参阅按对象预过滤。新表 objects_summary_global_by_type汇总了对象的事件。
- 现在可以按线程过滤事件，Performance Schema 会为每个线程收集更多信息。新表 setup_actors可用于根据每个连接会话的用户名和/或主机名有选择地检测用户连接。该 threads表为每个活动的服务器线程包含一行，并用几个新列进行了扩展。添加这些内容后，中可用的信息threads类似于 INFORMATION_SCHEMA.PROCESSLIST 表中可用的信息或中的输出SHOW PROCESSLIST。因此，所有这三个都用于为线程监视目的提供信息。用于 threads在这些方面不同于其他两个线程信息源的使用：
  - 访问threads不需要互斥量并且对服务器性能的影响最小。 INFORMATION_SCHEMA.PROCESSLIST 并且SHOW PROCESSLIST会产生负面的性能后果，因为它们需要互斥锁。
  - threads为每个线程提供附加信息，例如它是前台线程还是后台线程，以及与线程关联的服务器中的位置。
  - threads提供有关后台线程的信息。这意味着 threads可用于监视其他线程信息源无法监视的活动。
  - INSTRUMENTED您可以通过设置列或使用setup_actors表格来控制监视哪些线程。
  出于这些原因，执行服务器监控的 DBA INFORMATION_SCHEMA.PROCESSLIST 或SHOW PROCESSLIST可能希望改为使用监控threads 。
如果从早期版本升级到此 MySQL 版本，则必须运行mysql_upgrade（并重新启动服务器）以将这些更改合并到 performance_schema数据库中。

有关详细信息，请参阅MySQL 性能架构。

添加或更改的功能

不兼容的更改： 以下过时的构造已被删除。在显示备选方案的地方，应更新应用程序以使用它们。
- --log服务器选项和系统log变量。相反，使用 general_log系统变量启用通用查询日志，并使用 general_log_file系统变量设置通用查询日志文件名。
- 系统log_slow_queries变量。相反，使用 slow_query_log系统变量来启用慢查询日志和 slow_query_log_file系统变量来设置慢查询日志文件名。
- --one-thread服务器选项。改用 --thread_handling=no-threads 。
- --skip-thread-priority服务器选项。
- 系统engine_condition_pushdown变量。请改用变量的engine_condition_pushdown 标志。optimizer_switch
- 、have_csv、 have_innodb和系统变量have_ndbcluster。 have_partitioning改用 SHOW ENGINES。
- 系统sql_big_tables变量。改用 big_tables。
- 系统sql_low_priority_updates变量。改用 low_priority_updates 。
- 系统sql_max_join_size变量。改用max_join_size。
- 和SLAVE START语句SLAVE STOP。请改用 START SLAVEand STOP SLAVE语句。
- 语句的ONE_SHOT修饰符。SET
重要变更；复制： 复制过滤选项，例如 --replicate-do-db、 --replicate-rewrite-db和 --replicate-do-table在区分大小写方面彼此不一致。现在所有--replicate-*选项都遵循相同的区分大小写规则，适用于 MySQL 服务器中其他地方的数据库和表的名称，包括 lower_case_table_names系统变量的影响。（错误#51639，错误#11759334）
重要变更；Replication：在语句中添加了MASTER_RETRY_COUNT选项 .out 的输出中添加了相应的列。该选项设置此列中显示的值。旨在最终取代旧的（现在已弃用）服务器选项，现在是设置从服务器在失去与主服务器的连接后可能尝试重新连接的最大次数的首选方法。（错误#44209、错误#11752887、错误#44486、错误#11753110）CHANGE MASTER TOMaster_Retry_CountSHOW SLAVE STATUSMASTER_RETRY_COUNT--master-retry-count
InnoDB： 设置 innodb_read_ahead_threshold为 0禁用预读。在 5.6.1 之前，值0将在读取 64 页范围的边界页时触发预读。（错误#11763876，错误#56646）

InnoDB： 现在可以报告回滚段InnoDB的总大小，以页面为单位。使用计数器通过表报告该值。您启用和查询计数器如下： information_schema.innodb_metricstrx_rseg_current_size

mysql> SET GLOBAL innodb_monitor_enable = 'trx_rseg_current_size';

mysql> SELECT name, count, max_count, comment
    ->     FROM innodb_metrics WHERE name = 'trx_rseg_current_size';
+-----------------------+-------+-----------+----------------------------------------+
| name                  | count | max_count | comment                                |
+-----------------------+-------+-----------+----------------------------------------+
| trx_rseg_current_size |   346 |       346 | Current rollback segment size in pages |
+-----------------------+-------+-----------+----------------------------------------+

（漏洞 #57584）

复制： SHOW SLAVE STATUS现在显示 I/O 线程每次连接尝试的实际重试次数。（错误#56416，错误#11763675）
复制： 添加了Slave_last_heartbeat 状态变量，显示复制从站最后一次收到心跳信号的时间。该值使用 TIMESTAMP格式显示。（漏洞 #45441）
复制： 时间戳已添加到输出中 SHOW SLAVE STATUS以显示最近的 I/O 和 SQL 线程错误发生的时间。该 Last_IO_Error列现在以最近的 I/O 错误的时间戳为前缀，并 Last_SQL_Error显示最近的 SQL 线程错误的时间戳。时间戳值使用YYMMDD hh:mm:ss这两列中的格式。有关详细信息，请参阅 SHOW SLAVE STATUS 语句。（错误#43535、错误#11752361、错误#64255、错误#13726435）
现在有一个bind_address 包含选项值的系统变量 --bind-address。这使该地址能够在运行时访问。（错误#44355，错误#11752999）
仅包含表名的“未知表”错误消息现在也包含数据库名。（漏洞 #34750，漏洞 #11747993）
以前，如果字符串变得太大EXPLAIN，大联合的输出会截断UNION RESULT列表末尾的行，如下所示：
```
<union1,2,3,4,...>
```
为了更容易理解联合边界，截断现在发生在字符串的中间：
```
<union1,2,3,...,9>
```
（缺陷 #30597，缺陷 #11747073）
OpenGIS 规范定义了测试两个几何值之间关系的函数。MySQL 最初实现这些函数时，它们使用对象边界矩形并返回与相应的基于 MBR 的函数相同的结果。现在可以使用使用精确对象形状的相应版本。这些版本以 ST_前缀命名。例如， Contains()使用对象边界矩形，而ST_Contains() 使用对象形状。有关详细信息，请参阅测试几何对象之间空间关系的函数。

现在也ST_有已经精确的现有空间函数的别名。例如， ST_IsEmpty()是的别名 IsEmpty()

此外，现在实现了IsSimple()和 ST_Distance()空间函数，以及集合运算符函数 ST_Difference(), ST_Intersection(), ST_SymDifference(), 和 ST_Union(),（Bug #4249，Bug #11744883）
以下项目已弃用，将在未来的 MySQL 版本中删除。在显示备选方案的地方，应更新应用程序以使用它们。
- 系统thread_concurrency 变量。
- --language服务器选项。请改用lc_messages_dir和 lc_messages系统变量。
- --master-retry-count 服务器选项。请改用MASTER_RETRY_COUNT 选项CHANGE MASTER TO 语句。
改进了对添加基于 Unicode 归类算法 (UCA) 的 Unicode 归类的支持：
- MySQL 现在可以识别用于编写归类描述的 LDML 语法的更大子集。在许多情况下，可以从 Unicode Common Locale Data Repository 下载排序规则定义并将相关部分（即 <rules>和 </rules>标记之间的部分）粘贴到 MySQL Index.xml文件中。
- LDML 规则中的字符表示更加灵活。任何字符都可以按字面意思书写，而不仅仅是基本的拉丁字母。对于基于 UCA 5.2.0 的排序规则，十六进制表示法可用于任何字符，而不仅仅是 BMP 字符。
- 当在解析时发现问题时 Index.xml，会产生更好的诊断。
- 对于需要裁剪规则的排序规则，裁剪信息不再有固定的大小限制。
有关详细信息，请参阅MySQL 中支持的 LDML 语法和 Index.xml 解析期间的诊断。
TO_BASE64()和 FROM_BASE64()函数现在可用于执行与 base-64 字符串之间的编码。
Unicode 实现已扩展为包含一个 utf16le字符集，它对应于 Unicode 字符集的 UTF-16LE 编码。这类似于utf16(UTF-16) 但它是小端而不是大端。

有两种utf16le排序规则可用：
- utf16le_general_ci: 默认排序规则，区分大小写（类似于 utf16_general_ci）。
- utf16le_bin: 区分大小写，按代码点比较，提供与相同的顺序 utf16_bin。
的使用有一些限制 utf16le。除了有关用户定义排序规则的项目外，这些与、和的ucs2限制 utf16相同utf32。
- utf16le不能用作客户端字符集，这意味着它也不适用于 SET NAMESor SET CHARACTER SET。
- 无法用于LOAD DATA加载使用 utf16le.
- FULLTEXT无法在使用utf16le. 但是，您可以IN BOOLEAN MODE在没有索引的列上执行搜索。
- 不推荐使用ENCRYPT()with，因为底层系统调用需要一个以零字节结尾的字符串。utf16le
- 不可能创建用户定义的 UCA 归类， utf16le因为没有 utf16le_unicode_ci归类，它可以作为此类归类的基础。
MySQL 5.6 中对复制的更改使该选项生成的mysqlbinlog输出 --base64-output=ALWAYS 不可用。ALWAYS现在是此选项的无效值。如果给出的选项没有值，则效果现在与相同， --base64-output=AUTO而不是--base64-output=ALWAYS.

参考资料：另请参阅：错误 #28760。
为 Unicode 字符集添加了克罗地亚语归类： utf8_croatian_ci、 ucs2_croatian_ci、 utf8mb4_croatian_ci、 utf16_croatian_ci和 utf32_croatian_ci。这些排序规则针对克罗地亚语字母进行了裁剪：Č, Ć, Dž, Đ, Lj, Nj, Š, Ž。它们基于 Unicode 4.0。
对与优化器相关的系统变量进行了一些更改：
- 系统optimizer_switch变量有 new engine_condition_pushdown 和 index_condition_pushdown flags 来控制是否使用存储引擎条件下推和索引条件下推优化。系统 engine_condition_pushdown变量现在已弃用。有关条件下推的信息，请参阅引擎条件下推优化和索引条件下推优化。
- optimizer_switch系统变量有新的mrr和 mrr_cost_based标志来控制多范围读取优化的使用。系统 optimizer_use_mrr变量已被删除。有关多范围读取的信息，请参阅多范围读取优化。
- 系统join_cache_level变量已重命名为 optimizer_join_cache_level. 这使单个 SHOW VARIABLES LIKE 'optimizer%'语句能够显示更多与优化器相关的设置。
以前仅用于内部连接的块嵌套循环 (BNL) 连接算法已得到扩展，可用于外部连接操作，包括嵌套外部连接。有关详细信息，请参阅阻止嵌套循环和批量密钥访问联接。

结合这项工作，一个新的系统变量 optimizer_join_cache_level控制连接缓冲的完成方式。
--bind-address许多 MySQL 客户端程序都添加了一个选项： mysql、mysqldump、 mysqladmin、mysqlbinlog、 mysqlcheck、mysqlimport和mysqlshow。这是用于具有多个网络接口的计算机，使您能够选择使用哪个接口连接到 MySQL 服务器。

对 C API 函数进行了相应的更改 mysql_options()，它现在有一个MYSQL_OPT_BIND用于指定接口的选项。参数是主机名或 IP 地址（指定为字符串）。

修正错误

不相容的变化；复制：使用基于语句的复制时语句的行为INSERT DELAYED 已更改如下：

以前在使用的时候binlog_format=STATEMENT，在客户端执行的时候会发出警告 INSERT DELAYED；现在，在这种情况下不会发出警告。

以前，在使用时 binlog_format=STATEMENT， INSERT DELAYED被记录为 INSERT DELAYED；现在，它被记录为INSERT，没有 DELAYED选项。

但是，当 binlog_format=STATEMENT, INSERT DELAYED继续执行为INSERT（没有 DELAYED选项）。使用时的行为 INSERT DELAYED保持不变binlog_format=ROW： INSERT DELAYED不生成警告，作为执行INSERT DELAYED，并使用基于行的格式进行记录。

此更改也会影响 binlog_format=MIXED, 因为 INSERT DELAYED不再被视为不安全。现在，当日志记录格式为时 MIXED，不会切换到基于行的日志记录。这意味着该语句使用基于语句的日志记录格式作为简单记录 INSERT（即没有 DELAYED选项）。（错误#54579，错误#11762035）

参考资料：另请参阅：Bug #56678、Bug #11763907、Bug #57666。此问题是 Bug #39934、Bug #11749859 的回归。
不相容的变化；复制： 在确定是否复制 CREATE DATABASE、 DROP DATABASE或 ALTER DATABASE语句时，数据库级选项现在优先于任何 --replicate-wild-do-table 选项。换句话说，当尝试复制这些语句之一时， --replicate-wild-do-table当且仅当没有适用于该语句的数据库级选项时，现在才会检查选项。（错误#46110，错误#11754498）
不兼容的更改：FLUSH TABLES WITH READ LOCK当两个或多个连接中不断加载并发 DML 语句时，就会发生语句饥饿当通过语句打开某个表的HANDLER连接试图通过 DML 语句更新数据而另一个连接试图FLUSH TABLES WITH READ LOCK并发执行时，就会发生死锁。

这些问题是由全局读锁实现引起的，重新实现后会产生以下后果：
- 为了解决此补丁暴露的事件处理代码中的死锁问题，LOCK_event_metadata互斥体被替换为事件元数据锁。因此，现在禁止对事件进行 DDL 操作 LOCK TABLES。这是一个不兼容的更改。
- 全局读锁 ( FLUSH TABLES WITH READ LOCK) 不再阻塞临时表上的 DML 和 DDL。在此补丁之前，服务器行为在这方面并不一致：在某些情况下，临时表上的 DML/DDL 语句被阻止；在其他情况下，他们不是。由于主要用例 FLUSH TABLES WITH READ LOCK 是各种形式的备份，并且在备份期间不保留临时表，因此服务器现在始终允许在全局读取锁定下对临时表进行 DML/DDL。
- 线程状态集已更改：
  - Waiting for global metadata lock替换为Waiting for global read lock.
  - 以前，Waiting for release of readlock用于指示 DML/DDL 语句正在等待释放读锁， Waiting to get readlock并用于指示FLUSH TABLES WITH READ LOCK正在等待获取全局读锁。现在Waiting for global read lock用于这两种情况。
  - 以前，Waiting for release of readlock用于导致显式或隐式提交的所有语句，以指示它们正在等待释放读锁 Waiting for all running commits to finish并由FLUSH TABLES WITH READ LOCK. 现在Waiting for commit lock用于这两种情况。
  - 还有另外两个新状态，Waiting for trigger metadata lock和Waiting for event metadata lock。
（错误#57006、错误#11764195、错误#54673、错误#11762116）
不兼容的更改： CREATE TABLE声明（包括 CREATE TABLE ... LIKE）现在在 LOCK TABLES声明生效时被禁止。

此更改的一个结果是进行与不只是复制文件CREATE TABLE ... LIKE相同的检查。这意味着如果当前 SQL 模式与创建原始表时有效的模式不同，则表定义可能被认为对新模式无效并且语句将失败。（错误#42546，错误#11751609）CREATE TABLE.frm
创新数据库；复制： 如果 master 有 innodb_file_per_table=OFF， innodb_file_format=Antelope （和innodb_strict_mode=OFF），或两者都有，则忽略CREATE TABLE 选项，例如KEY_BLOCK_SIZE这可以让主人避免引发 ER_TOO_BIG_ROWSIZE错误。

但是，忽略的CREATE TABLE 选项仍然写入二进制日志，因此，如果从服务器有 innodb_file_per_table=ON和 innodb_file_format=Barracuda，它可能会在执行日志中的记录时遇到 ER_TOO_BIG_ROWSIZE错误，导致从服务器 SQL 线程中止并且复制失败。

在 master 运行 MySQL 5.1 而 slave 是 MySQL 5.5（或更高版本）的情况下，当 master 和 slave 都以和的默认值运行时会发生 innodb_file_per_table故障 innodb_file_format。这可能会导致升级过程中出现问题。

innodb_file_per_table为解决此问题，和的默认值 innodb_file_format分别恢复为 MySQL 5.1 默认值，即 OFF和Antelope。（错误#56318，错误#11763590）
InnoDB： 如果 MySQL 服务器在创建表后立即崩溃在随后的重启期间InnoDB退出 signal 11如果服务器在 InnoDB为表创建主索引之后但在索引定义被记录在 MySQL 元数据中之前停止，则可能会出现此问题。（漏洞 #57616）

参考资料：这个问题是 Bug #54582 的回归。
InnoDB： 启用二进制日志记录后，InnoDB可能会在崩溃恢复期间停止，并显示一条消息引用事务 ID 0。（错误＃54901，错误＃11762323）
复制： 由于 MySQL 5.5.3 中所做的更改，在 binlog_cache_size和 max_binlog_cache_size服务器系统变量中所做的设置会影响二进制日志语句缓存（也在该版本中引入）和二进制日志事务缓存（以前简称为二进制日志缓存） . 这意味着由于设置其中一个或两个变量而使用的资源是预期数量的两倍。为了纠正这个问题，这些变量现在只影响事务缓存。此问题的修复还引入了两个新的系统变量 binlog_stmt_cache_size和 max_binlog_stmt_cache_size，它们仅影响二进制日志语句缓存。

此外， Binlog_cache_use每当使用任一缓存时状态变量都会递增，并且每当使用任一缓存中 Binlog_cache_disk_use的磁盘空间时都会递增，这会导致语句和事务缓存的性能调整出现问题，因为无法确定其中的哪一个在尝试解决过多的磁盘寻道和相关问题时被超过了。这个问题通过改变这两个状态变量的行为来解决，使它们仅在响应二进制日志事务缓存的使用时增加，以及通过引入两个新的状态变量 Binlog_stmt_cache_use和 Binlog_stmt_cache_disk_use，它们仅通过使用二进制日志语句缓存来增加。

系统变量关于活动会话的行为 max_binlog_cache_size也已更改以匹配 binlog_cache_size系统变量的行为：以前，更改 max_binlog_cache_size在现有会话中生效；现在，与中的更改一样 binlog_cache_size，中的更改 max_binlog_cache_size仅在值更改后开始的会话中生效。

有关详细信息，请参阅与二进制日志记录一起使用的系统变量和服务器状态变量。（错误#57275，错误#11764443）
复制：Binlog_cache_use和而Binlog_cache_disk_use status 递增两次。（错误#56343，错误#11763611）

参考：这个问题是 Bug #50038 的回归。
复制：发出时STOP SLAVE，如果事务仅更新使用事务存储引擎的表，则从 SQL 线程回滚当前事务并立即停止。以前，即使事务包含 CREATE TEMPORARY TABLE语句、 DROP TEMPORARY TABLE语句或两者，也会发生这种情况，尽管这些语句无法回滚。因为临时表在用户会话（在本例中为复制用户）的生命周期内持续存在，所以它们会一直存在，直到从站停止或重置。当交易在后续交易重新开始时 START SLAVE语句，SQL 线程中止并显示要创建（或删除）的临时表已经存在（或不存在，在后一种情况下）的错误。

在此修复之后，如果正在进行的事务包含 CREATE TEMPORARY TABLE语句、 DROP TEMPORARY TABLE语句或两者，则 SQL 线程现在会等待事务结束，然后停止。（错误#56118，错误#11763416）
复制： 当为新的二进制日志文件生成名称时发生错误，错误会被记录下来但不会显示给用户。（漏洞 #46166）

参考资料：另请参阅：Bug #37148、Bug #11748696、Bug #40611、Bug #11750196、Bug #43929、Bug #51019。
Replication： 当lower_case_table_names在slave上设置为1，但在master上没有设置时，复制语句中的数据库名称不会被转换，导致复制在使用区分大小写的文件系统的slave上失败。这发生在基于语句和基于行的复制中。

此外，当 lower_case_table_names仅在从站上使用设置为 1 的基于行的复制时，表的名称也不会转换，也会导致使用区分大小写的文件系统的从站复制失败。（漏洞 #37656）
设置 collation_connection为ucs2或 utf16字符集的排序规则之一后，此后无法更改排序规则。（缺陷 #65000，缺陷 #13970475）
-DBUILD_CONFIG=mysql_releaseLinux 上的cmakelibaio以前需要链接进来。现在可以指定 -DIGNORE_AIO_CHECK不使用libaio. （缺陷 #58955，缺陷 #11765940）
fn_format从调用时发生 Valgrind 故障archive_discover。（缺陷 #58205，缺陷 #11765259）
将未以空值终止的字符串传递给 UpdateXML()或 ExtractValue()导致服务器因断言而失败。（错误#57279，错误#11764447）
在引导程序模式下，服务器无法执行超过 10,000 个字符的语句。（错误#55817，错误#11763139）
NULL对于某些包含GROUP BY. （错误#45267，错误#11753766）
如果HAVING索引可用，子句可能会丢失 ORDER BY，从而错误地允许返回其他行。（缺陷 #45227，缺陷 #11753730）
优化器可能会低估连接处理期间列描述符所需的内存，并导致内存损坏或服务器崩溃。（错误#42744，错误#11751763）
服务器针对表的WHERE ... OR ... GROUP BY查询返回了不正确的结果。InnoDB（缺陷 #37977，缺陷 #11749031）
错误检查的XOR子查询优化导致断言失败。（错误#37899，错误#11748998）
一个查询可以使用一个索引来生成所需的排序，而另一个索引用于通过索引条件下推进行范围访问可能会导致服务器崩溃。（漏洞 #37851，漏洞 #11748981）
启用索引条件下推后， InnoDB可能会由于记录中预期的下推代码与实际存在的代码不匹配而崩溃。（错误#36981，错误#11748647）
范围优化器忽略了半连接子查询中内表的条件IN，导致优化器错过了良好的查询执行计划。（错误#35674，错误#11748263）
依赖子查询和连接可能会导致服务器崩溃或内存溢出。（错误#34799，错误#11748009）
FROM从子句和子句中引用同一个表的视图中进行选择会 IN 导致服务器崩溃。（漏洞 #33245）
深度嵌套的子查询可能会导致堆栈溢出或服务器崩溃。（漏洞 #32680，漏洞 #11747503）
DECIMAL服务器在优化将索引列与字符串值进行比较的查询时崩溃。（缺陷 #32262，缺陷 #11747426）
服务器因使用range checked for each record访问方法的优化而崩溃。（缺陷 #32229，缺陷 #11747417）
Contains()多面体几何失败。（缺陷 #32032，缺陷 #11747370）
如果优化器使用多范围读取访问方法进行索引查找，则包含任何BLOB或 TEXT数据类型的行可能会出现不正确的结果。（缺陷 #30622，缺陷 #11747076）
与 MySQL 5.1 相比，优化器无法对某些查询使用连接缓冲，导致这些查询的性能降低。（缺陷 #30363，缺陷 #11747028）
对于用于解决 LIMIT查询的多范围读取扫描，无法关闭扫描会导致表的文件描述符泄漏MyISAM 。（缺陷 #30221，缺陷 #11746994）
SHOW CREATE DATABASE没有考虑 lower_case_table_names系统变量的值。（缺陷 #21317，缺陷 #11745926）