MySQL 8.0.0 Changes 版本变更事项（2016-

原文链接: https://dev.mysql.com/doc/relnotes/mysql/8.0/en/news-8-0-0.html

Note

这是一个里程碑版本，使用者风险自担。里程碑版本间(或者从一个里程碑版本到一个GA版本)的升级不予支持。里程碑版本间的变更非常大，使用者可能会遇到兼容性问题，例如在运行通常的升级过程 mysql_upgrade 时，需要注意数据格式的变化。举例说明，使用者可能终究会发现在升级版本前，使用 mysqldump 转储数据是非常有必要的。（在任何情况下升级版本前做备份都是一种必要的审慎预防措施。）

账户管理事项

• 不兼容的变更：在mysql系统数据库中的权限表现在的底层引擎是 InnoDB(事务型)。之前，这些表的存储引擎是 MyISAM(非事务型)。这个变更应用于这些表: user, db, tables_priv, columns_priv, procs_priv, proxies_priv。
  权限表存储引擎的变更时改变账户管理语句行为的基础。之前，一个指派给多个用户的账户管理语句可能会产生某些用户成功同时某些用户失败的结果。现在，每个语句都是事务型的，对于指定给多个用户的语句或者都成功，或者一旦有任何错误都进行回滚而不会有任何改变。如果语句执行成功，则写入二进制日志，否则不会写入；在语句执行失败的情况下，会发生回滚并且不会产生行为变更。上述的行为适用于以下类型的语句: ALTER USER, CREATE ROLE, CREATE USER, DROP ROLE, DROP USER, GRANT, RENAME USER, REVOKE。（SET PASSWORD 没有被列入是因为它最多只能用于一名用户，早就是事务型的了。）这个变化的一个副作用是在 MySQL 5.7 主服务器往 MySQL 8.0 从服务器复制时 主服务器上会部分执行成功的账户管理语句在从服务器会完全失败。更多的信息，请查看 原子数据定义语句支持。
  如果你从早起版本升级到该版本，必须运行 mysql_upgrade (并且重启服务器)以将这些变更引入到 mysql 系统数据库中。

  Note

  如果 从一个老版本升级到该版本 MySQL却没有将授权表从 MyISAM 升级到 InnoDB, 服务器将认为这些表只读，执行账户管理语句会返回错误。

  归因于存储引擎从 MyISAM 到 InnoDB 的变更, 在权限表上执行不带 ‘ORDER BY’ 的 SELECT 生成的结果行序可能与之前的版本不同。如果查询结果要求具有特定的行序特性，请使用包含 ORDER BY 子句的语句。

• MySQL 现在支持角色，被命名为特权集合。角色允许为账户分配特权组，并为授予个人特权提供了一种方便的替代方法，既可以用于形式化用户所需的特权分配，并且可以实现：

  • 角色可被创建或删除。
  • 角色能够进行拥有授予和撤销的权限。
  • 角色能够被授予给用户账户和撤销授权。
  • 账户在会话中的有效角色可以在被授权的角色组间进行选择，同时在会话期间，角色类型可能发生变化。

  如需获得更多信息，请查看 用户角色。

  Note

  ROLE 在该版本中已经成为了保留字，因此如果没有引用标识符的话不能被用于标识符。

C API 事项

libmysqlclient 共享库的主版本号从20（MySQL 5.7）增加到21(MySQL 8.0)。 （Bug #77600，Bug #21363863）

字符集支持

• utf8mb4 Unicode 字符集一个新的通用排序归类，被命名为 utf8mb4_0900_ai_ci。 utf8mb4 还有几个新的特定于语言的归类，其特征类似于utf8mb4_0900_ai_ci，但特定于语言的归类优先适用。语言特性的归类才用了类似于 ISO 639-1 语言编码相似的归类名，正如下表所示。有两种情况语言编码名字组成有额外变量( German phone book order, Traditional Spanish)。

  表5 utf8mb4 UCA9.0.0 语言特性类集

  Language	Collation
  Croatian	utf8mb4_hr_0900_ai_ci
  Czech	utf8mb4_cs_0900_ai_ci
  Danish	utf8mb4_da_0900_ai_ci
  Esperanto	utf8mb4_eo_0900_ai_ci
  Estonian	utf8mb4_et_0900_ai_ci
  German phone book order	utf8mb4_de_pb_0900_ai_ci
  Hungarian	utf8mb4_hu_0900_ai_ci
  Icelandic	utf8mb4_is_0900_ai_ci
  Latvian	utf8mb4_lv_0900_ai_ci
  Lithuanian	utf8mb4_lt_0900_ai_ci
  Polish	utf8mb4_pl_0900_ai_ci
  Classical Latin	utf8mb4_la_0900_ai_ci
  Romanian	utf8mb4_ro_0900_ai_ci
  Slovak	utf8mb4_sk_0900_ai_ci
  Slovenian	utf8mb4_sl_0900_ai_ci
  Modern Spanish	utf8mb4_es_0900_ai_ci
  Traditional Spanish	utf8mb4_es_trad_0900_ai_ci
  Swedish	utf8mb4_sv_0900_ai_ci
  Turkish	utf8mb4_tr_0900_ai_ci
  Vietnamese	utf8mb4_vi_0900_ai_ci

  utf8mb4_0900_ai_ci 还可以用作下表语言中的不区分重音、不区分大小写的归类。

  表6 utf8mb4_0900_ai_ci 适用语言

  语言名	语言编码
  German (dictionary order)	de
  English	en
  Canadian French (locale fr_CA)	fr
  Irish Gaelic	ga
  Indonesian	id
  Italian	it
  Luxembourgian	lb
  Malay	ms
  Dutch	nl
  Portuguese	pt
  Swahili	sw
  Zulu	zu

  utf8mb4_da_0900_ai_ci 也可以在下表所列的语言中支持不区分重音、不区分大小写。

  表7 utf8mb4_da_0900_ai_ci 适用的语言

  语言名	语言代码
  Norwegian	no
  Norwegian Bokmål	nb
  Norwegian Nynorsk	nn

  独立于特定语言的utf8mb4_0900_ai_ci和适用于特定语言的 utf8mb4_LANG_0900_ai_ci Unicode 排序归类都有如下特性：

  • 排序归类不区分重音、不区分大小写，基于 Unicode Collation Algorithm(UCA) 9.0.0 和 Common Locale Data Repository(CLDR) v30。这些特性可从排序归类的名字组成中可以看出(_0900, _ai, _ci)。例外：utf8mb4_la_0900_ai_ci 不基于 CLDR 库因为 Classical Latin 没有在 CLDR 中定义。
  • 排序归类集适用于字符范围 [U+0, U+10FFFF]。
  • 如果排序字符集(与归类集一样，翻译者的主观喜好，译者注) 不是基于特定语言的，排序字符集会以默认顺序排序所有字符，包含补充字符。如果排序字符集基于特定语言的，其依据基于特定语言的规则进行排序能够适用的语言，不适用的语言仍按默认顺序。
  • 排序字符集的默认顺序是：排序字符集基于 DUCET 表 (Default Unicode Collation Element Table, 默认统一编码排序集元素表) 根据字符编码在表中的权重进行排序。如果在 DUCET 表中没有对应权重值的字符编码，排序字符集将根据 UCA 算法构建。
  • 对于独立于特定语言的排序字符集，缩写的字符序列被视为单独的字符串。对于基于特定语言的排序字符集，缩写可能改变字符排序顺序。

  更多信息，请查看 统一编码字符集。

编译事项

• Microsoft Windows: 如果要在 Windows 上构建 MySQL, 现有工具链对64位的工具支持度更好（之前是32位）。在64位系统上的构建工具加速了链接过程，同时避免了由于32位链接器产生的地址空间有限的问题。（Bug #80675, Bug #22900585）
• CMake 现在使用 GNU gold 链接器（可用的情况下）进行链接构建。如果不想要使用该链接器，请使用 CMake 选项 -DUSE_LD_GOLD=0。（Bug #23759968, Bug #82163）
• CMake选项 WITH_EXTRA_CHARSET 已经被移除。MySQL 现在默认配置所有的字符集。用户如果想要更少的字符集，请直接编辑 cmake/character_sets.cmake, 然后重新编译服务器。（Bug #80005, Bug #22552125）
• 现在服务器构建依赖的 Boost 库的最小版本是 1.60.0。（Bug #79380, Bug #22253921）
• 已经清理完源码库，包括：清楚不必要的 CMake 检测，移除源文件中无用宏；重新组织头文件减少依赖数，以使其更模块化，移除函数没有定义的函数声明，使用同等功能的工业标准库中的函数替换部分自有函数。
• MySQL 源码现在支持和使用了 C++11 特性。为了能够在所支持平台上获得 C++11 带来的优势，一下编译器应该适用的最小版本为:
  • GCC: >= 4.8
  • Clang: >=3.4 (Xcode 7 on OS X)
  • Solaris Studio: >=12.4 (仅支持 Solaris 客户端构建)
  • Visual Studio: 2015
  • CMake: 在 Windows 平台上，因 Visual Studio 版本的限制导致至少需要 CMake 版本 >= 3.2.3

在 Solaris 平台上， stlport 库不再使用。因此 SUNPRO_CXX_LIBRARY CMake选项y已无法使用，所以现在的版本中已移除该选项。

组件事项

• MySQL 服务器现在包含基于组件的基础设施已提高服务器可扩展性:
  • 组件可以提供对服务器和其他组件使用的服务。（相对于使用中的服务，服务器本身也是一个组件，等价于其他组件。）组件间只能通过他们提高的服务交互。
  • INSTALL_COMPONENT 和 UNINSTALL_COMPONENT语句为运行时操作组件提供了 SQL 接口。
  • 加载器服务将已安装的组件注册在 mysql.component 系统表中，并为随后的服务器重启时在启动序列中安装已注册组件。

关于组件基础设置及其 SQL 级接口的常用信息，请查看 MySQL 服务器组件。如果想查看组件内部实现信息，请查看 http://dev.mysql.com/doc/dev/mysql-server/latest/。

配置事项

• 不兼容的变更: InnoDB: 之前，激活 innodb_read_only 系统变量只能为 InnoDB 存储引擎防止创建表和删除表。在 MySQL 8.0 版本中，激活 innodb_read_only 会为任何存储引起阻止这些操作。在 mysql 系统数据库中使用表创建和删除操作会修改数据字典表，但是这些表使用了 InnoDB 存储引擎，当激活 innodb_read_only 时不能进行修改。同样的原则适用于其他需要修改数据字典表的操作，包括在使用 innoDB 存储引擎的 mysql 数据库中修改其他表，例如权限表和 func 以及 plugin 表等。（Bug #21611899）
• 内存映射事务协调器的 8KB 的硬编码内存页大小对于诸如 ARM64 和 PowerPC 平台等页面大小大得多的平台来说太小了。服务器现在通过系统调用获得当前平台的页面大小，而非硬编码其值。造成的后果是 --log-tc-size 选项最小值和默认值现在是6倍页面大小。而且，这个值必须是页面大小的整数倍。感谢 Alexey Kopytov 提供了补丁包。（Bug #23014086, Bug #80818, Bug #26931470, Bug #87995）
• MySQL 现在为了在运行时能够改变配置同事在服务器重启后保持配置支持 SET 语句语法的变体 SET_PERSIST。正如 SET_GLOBAL, SET_PERSIST 可被允许用于任何动态(可在运行时设置)�全局系统变量。这个语句不仅可以改变运行时变量值，还可以在数据目录中在名为 mysqld-auto.conf 的选项文件中写入变量设置。服务器启动时，会在处理玩其他选项文件后处理此文件。如需更多信息，请查看 使用选项文件 和 [ SET 变量赋值语法] (https://dev.mysql.com/doc/refman/8.0/en/set-variable.html)。
  为了提供每个变量最近设值的相关信息，Performance Schema 现在有一个 variables_info 表列示了每个系统变量及其被设值的来源。请查看 Performance Schema variables_info 表。
  如果你从一个较早的版本升级到该版本 MySQL， 你必须运行 mysql_upgrade （并重启服务器）以在 Performance Shema中引入这个变更。
• 被废弃的 mysql_install_db 计划已经从 MySQL 版本中移除。现在应该使用带有 --initialize 或 --initialize-insecure 选项的 mysqld 命令进行数据目录初始化。另外，过去用于 mysql_install_db，现在用于 mysqld 里被废弃的 --bootstrap 选项已经被移除，并且 mysql_install_db 中控制安装位置的 INSTALL_SCRIPTDIR CMake 选项也被移除。
  第1个版本测试套件代码之前位于 MySQL 源码的 mysql-test/lib/v1 目录，这部分代码使用了 mysql_install_db，因此现在被移除。MYSQL_INSTALL_DB 环境变量和 MTR_VERSION 值为1的环境变量已不再支持。

数据字典事项

• 不兼容的变更: MySQL Server现在在事务表整合了一个全局数据字典，其中包含数据库对象的信息。在之前的 MySQL 发行版中，字典数据存放在元数据文件和非事务表中。

Important

与没有数据字典的服务器相比，启用数据字典的服务器通常有所差别，详细信息请查看 数据字典用法差异。而且，如果要升级到 MySQL 8.0，升级过程不像以往，会要求你先检查环境条件确认可以升级。更多信息，请查看 升级 MySQL, 尤其是 在 MySQL 5.7 环境中确认升级准备就绪。

InnoDB 在 MySQL 8.0.0 发行版中继续使用自己的数据字典。
以下简要描述这个变更的影响：
- 先前与基表和视图关联的.frm 元数据文件不再存在。以前存储在 .frm 文件重的元数据现在存储在数据字典表中。
与之类似，先前存储在 .TRG 和 .TRN 文件中的触发器元数据现在存储在数据字典表中，这些文件不再存在。
- 由于 .frm 文件的移除，因 .frm 文件结构造成的 64KB 表定义大小的限制被取消。
- 由于 .frm 文件的移除， INFORMATION_SCHEMA.TABLES 的 VERSION 字段现在硬编码为10，该值为 MySQL 5.6 中使用的最后一个 .frm 文件版本。
- 提供给 MySQL 数据字典使用的新字典对象缓存将访问过的数据字典对象存储在内存中，以便最小化磁盘I/O重用对象。基于 LRU 的淘汰策略将最近最少使用的对象从内存移除。缓存由存储不同对象类型的几个分区构成。更多信息，请查看 字典对象缓存。
- 服务器、内部存储引擎和插件能够使用新的内部数据字典 API 在 MySQL 数据字典中访问和存储数据。内部数据字典 API 包含了处理模式、表空间、表空间文件、表、分区表、表分区数据、触发器、存储例程、事件、表对象、视图、字符集和排序字符集的操作。
由于这个变更，CREATE TRIGGER 和 DROP TRIGGER 产生的数据字典更新和二进制日志写入现在已被合并为单一原子事务。
- 数据字典表现在不可见，但是在大部分情况下，可以使用 INFORMATION_SCHEMA 表替代查询。这样一方面随着服务器继续开发底层数据字典表继续变化，另一方面，可以保持一个稳定的 INFORMATION_SCHEMA 接口以供应用程序使用。
一些 INFORMATION_SCHEMA 表以及被完全重写作为数据字典表的视图：

1. CHARACTER_SETS
2. COLLATIONS
3. COLLATION_CHARACTER_SET_APPLICABILITY
4. COLUMNS
5. KEY_COLUMN_USAGE
6. SCHEMATA
7. STATISTICS
8. TABLES
9. TABLE_CONSTRAINTS
10. VIEWS

在上述表中查询现在更高效，因为现在这些表可以从数据字典表中获取信息，而非更慢的其他媒介。尤其特别的是，对于每个作为数据字典表的视图的 `INFORMATION_SCHEMA` 表来说：
    - 对于每个针对 `INFORMATION_SCHEMA` 表的查询来说服务器不再一定要创建临时表。
    - 当底层数据字典表存储以前通过目录扫描获得的值（例如，枚举数据库中的数据库名称或表名称）或文件打开操作（例如，从 `.frm` 文件读取信息）时，现在`INFORMATION_SCHEMA` 使用表查询这些值。 （另外，即使对于非视图 `INFORMATION_SCHEMA` 表，也可以通过在数据字典查找来检索数据库和表名等值，不需要目录或文件扫描。）
    - 底层数据字典的索引允许优化器创建高效的执行计划，而之前处理 `INFORMATION_SCHEMA` 表需要对每个查询都构建一个临时表。