MySQL8-中文参考-六-

布客飞龙
119 阅读1小时+

MySQL8 中文参考（六）

原文：docs.oracle.com/javase/tutorial/reallybigindex.html

2.8.8 处理编译 MySQL 时出现的问题

原文：dev.mysql.com/doc/refman/8.0/en/compilation-problems.html

许多问题的解决方案涉及重新配置。如果您重新配置，请注意以下事项：

  • 如果 CMake 在之前已经运行过后再次运行，它可能会使用在先前调用期间收集的信息。这些信息存储在 CMakeCache.txt 中。当 CMake 启动时，它会查找该文件，并在假定信息仍然正确的情况下读取其内容。当您重新配置时，这种假设是无效的。

  • 每次运行 CMake，您必须再次运行 make 进行重新编译。但是，您可能希望在重新编译之前删除先前构建的旧目标文件，因为它们是使用不同的配置选项编译的。

为了防止使用旧的目标文件或配置信息，请在重新运行 CMake 之前运行以下命令：

在 Unix 系统上：

$> make clean
$> rm CMakeCache.txt

在 Windows 系统上：

$> devenv MySQL.sln /clean
$> del CMakeCache.txt

如果在源代码树之外构建，请在重新运行 CMake 之前删除并重新创建您的构建目录。有关在源代码树之外构建的说明，请参阅 如何使用 CMake 构建 MySQL 服务器。

在某些系统上，由于系统包含文件的差异，可能会出现警告。以下列表描述了���编译 MySQL 时最常出现的其他问题：

  • 要定义要使用的 C 和 C++ 编译器，您可以定义 CC 和 CXX 环境变量。例如：

    $> CC=gcc
$> CXX=g++
$> export CC CXX

    虽然可以在命令行上执行此操作，就像刚才展示的那样，但您可能更喜欢在构建脚本中定义这些值，这种情况下不需要 export 命令。

    要指定自己的 C 和 C++ 编译器标志，请使用 CMAKE_C_FLAGS 和 CMAKE_CXX_FLAGS CMake 选项。参见 编译器标志。

    要查看可能需要指定的标志，请使用 mysql_config 呼叫 --cflags 和 --cxxflags 选项。

  • 在使用 CMake 配置 MySQL 后，要查看编译阶段执行的命令，请运行 make VERBOSE=1 而不是仅运行 make。

  • 如果编译失败，请检查是否启用了 MYSQL_MAINTAINER_MODE 选项。此模式会导致编译器警告变为错误，因此禁用它可能会使编译继续进行。

  • 如果您的编译失败并出现以下任何错误，请升级您的 make 版本为 GNU make：

    make: Fatal error in reader: Makefile, line 18:
Badly formed macro assignment

    或者：

    make: file `Makefile' line 18: Must be a separator (:

    或者：

    pthread.h: No such file or directory

    Solaris 和 FreeBSD 已知具有问题的 make 程序。

    GNU make 3.75 已知可用。

  • sql_yacc.cc 文件是从 sql_yacc.yy 生成的。通常，构建过程不需要创建 sql_yacc.cc，因为 MySQL 自带一个预生成的副本。但是，如果你确实需要重新创建它，可能会遇到这个错误：

    "sql_yacc.yy", line *xxx* fatal: default action causes potential...

    这表明你的 yacc 版本不足。你可能需要安装一个较新版本的 bison（yacc 的 GNU 版本）并使用它代替。

    bison 版本旧于 1.75 可能会报告此错误：

    sql_yacc.yy:#####: fatal error: maximum table size (32767) exceeded

    实际上并未超出最大表大小；错误是由旧版本的 bison 中的错误引起的。

有关获取或更新工具的信息，请参阅第 2.8 节，“从源代码安装 MySQL”中的系统要求。

2.8.9 MySQL 配置和第三方工具

原文：dev.mysql.com/doc/refman/8.0/en/source-configuration-third-party.html

需要从 MySQL 源代码中确定 MySQL 版本的第三方工具可以读取顶级源目录中的 MYSQL_VERSION 文件。该文件单独列出了版本的各个部分。例如，如果版本是 MySQL 8.0.36，则文件如下所示：

MYSQL_VERSION_MAJOR=8
MYSQL_VERSION_MINOR=0
MYSQL_VERSION_PATCH=36
MYSQL_VERSION_EXTRA=
MYSQL_VERSION_STABILITY="LTS"

注意

在 MySQL 5.7 及更早版本中，此文件名为 VERSION。

要从版本组件构建一个五位数，使用以下公式：

MYSQL_VERSION_MAJOR*10000 + MYSQL_VERSION_MINOR*100 + MYSQL_VERSION_PATCH

2.8.10 生成 MySQL Doxygen 文档内容

原文：dev.mysql.com/doc/refman/8.0/en/source-installation-doxygen.html

MySQL 源代码包含使用 Doxygen 编写的内部文档。生成的 Doxygen 内容可在 dev.mysql.com/doc/index-other.html 找到。还可以使用以下过程从 MySQL 源分发本地生成此内容：

  1. 安装 doxygen 1.9.2 或更高版本。可在 www.doxygen.nl/ 找到发行版。

    安装 doxygen 后，请验证版本号：

    $> doxygen --version
1.9.2

  2. 安装 PlantUML。

    在 Windows 上安装 PlantUML（在 Windows 10 上测试过）时，必须至少以管理员身份运行一次，以便创建注册表键。打开管理员控制台并运行以下命令：

    $> java -jar *path-to-plantuml.jar*

    该命令应该打开一个 GUI 窗口，并在控制台上不返回任何错误。

  3. 将 PLANTUML_JAR_PATH 环境设置为安装 PlantUML 的位置。例如：

    $> export PLANTUML_JAR_PATH=*path-to-plantuml.jar*

  4. 安装 Graphviz 的 dot 命令。

    安装 Graphviz 后，请验证 dot 的可用性。例如：

    $> which dot
/usr/bin/dot

$> dot -V
dot - graphviz version 2.40.1 (20161225.0304)

  5. 将位置更改到 MySQL 源分发的顶层目录，并执行以下操作：

    首先，执行 cmake：

    $> cd *mysql-source-directory*
$> mkdir build
$> cd build
$> cmake ..

    接下来，生成 doxygen 文档：

    $> make doxygen

    检查错误日志，该日志位于顶层目录中的 doxyerror.log 文件中。假设构建成功执行，请使用浏览器查看生成的输出。例如：

    $> firefox doxygen/html/index.html

2.9 安装后设置和测试

原文：dev.mysql.com/doc/refman/8.0/en/postinstallation.html

2.9.1 初始化数据目录

2.9.2 启动服务器

2.9.3 测试服务器

2.9.4 初始 MySQL 账户的安全性

2.9.5 自动启动和停止 MySQL

本节讨论安装 MySQL 后应执行的任务：

  • 如有必要，初始化数据目录并创建 MySQL 授权表。对于某些 MySQL 安装方法，数据目录初始化可能会自动完成：

    • MySQL Installer 执行的 Windows 安装操作。

    • 使用 Oracle 的服务器 RPM 或 Debian 分发在 Linux 上安装。

    • 在许多平台上使用本机打包系统进行安装，包括 Debian Linux、Ubuntu Linux、Gentoo Linux 等。

    • 使用 DMG 分发在 macOS 上安装。

    对于其他平台和安装类型，您必须手动初始化数据目录。这些包括在 Unix 和类 Unix 系统上从通用二进制和源分发安装，以及在 Windows 上从 ZIP 存档包安装。有关说明，请参见第 2.9.1 节，“初始化数据目录”。

  • 启动服务器并确保可以访问。有关说明，请参见第 2.9.2 节，“启动服务器”和第 2.9.3 节，“测试服务器”。

  • 为初始root账户在授权表中分配密码，如果在数据目录初始化期间尚未完成。密码可防止未经授权访问 MySQL 服务器。有关说明，请参见第 2.9.4 节，“保护初始 MySQL 账户”。

  • 可选地，安排服务器在系统启动和停止时自动启动和停止。有关说明，请参见第 2.9.5 节，“自动启动和停止 MySQL”。

  • 可选地，填充时区表以启用命名时区的识别。有关说明，请参见第 7.1.15 节，“MySQL 服务器时区支持”。

当您准备创建额外用户账户时，您可以在第 8.2 节，“访问控制和账户管理”中找到有关 MySQL 访问控制系统和账户管理的信息。

2.9.1 初始化数据目录

原文：dev.mysql.com/doc/refman/8.0/en/data-directory-initialization.html

安装 MySQL 后，必须初始化数据目录，包括mysql系统模式中的表：

  • 对于某些 MySQL 安装方法，数据目录初始化是自动的，如第 2.9 节，“安装后设置和测试”中所述。

  • 对于其他安装方法，您必须手动初始化数据目录。这些方法包括在 Unix 和类 Unix 系统上从通用二进制和源分发安装，以及在 Windows 上从 ZIP 存档包安装。

本节描述了如何手动为 MySQL 安装方法初始化数据目录，其中数据目录初始化不是自动的。有一些建议的命令可用于测试服务器是否可访问和正常工作，请参见第 2.9.3 节，“测试服务器”。

注意

在 MySQL 8.0 中，默认身份验证插件已从mysql_native_password更改为caching_sha2_password，并且'root'@'localhost'管理帐户默认使用caching_sha2_password。如果您希望root帐户使用先前的默认身份验证插件（mysql_native_password），请参见 caching_sha2_password 和 root 管理帐户。

  • 数据目录初始化概述

  • 数据目录初始化过程

  • 数据目录初始化期间的服务器操作

  • 初始化后的 root 密码分配

数据目录初始化概述

在这里显示的示例中，服务器旨在在mysql登录帐户的用户 ID 下运行。如果该帐户不存在，请创建该帐户（参见创建 mysql 用户和组），或者替换您计划用于运行服务器的不同现有登录帐户的名称。

  1. 将位置更改为 MySQL 安装的顶级目录，通常为/usr/local/mysql（根据需要调整系统的路径名）：

    cd /usr/local/mysql

    在此目录中，您可以找到几个文件和子目录，包括包含服务器以及客户端和实用程序程序的bin子目录。

  2. secure_file_priv系统变量限制导入和导出操作到特定目录。创建一个目录，其位置可以指定为该变量的值：

    mkdir mysql-files

    将目录的用户和组所有权授予mysql用户和mysql组，并适当设置目录权限：

    chown mysql:mysql mysql-files
chmod 750 mysql-files

  3. 使用服务器初始化数据目录，包括包含初始 MySQL 授权表的mysql模式，这些表确定用户如何连接到服务器。例如：

    bin/mysqld --initialize --user=mysql

    对于命令的重要信息，特别是关于您可能使用的命令选项，请参阅数据目录初始化过程。有关服务器执行初始化的详细信息，请参阅数据目录初始化期间的服务器操作。

    通常，只有在首次安装 MySQL 后才需要进行数据目录初始化。（对于现有安装的升级，请执行升级过程；请参阅第三章，升级 MySQL。）但是，初始化数据目录的命令不会覆盖任何现有的mysql模式表，因此在任何情况下运行都是安全的。

  4. 如果您希望部署具有自动支持安全连接的服务器，请使用mysql_ssl_rsa_setup实用程序创建默认的 SSL 和 RSA 文件：

    bin/mysql_ssl_rsa_setup

    欲了解更多信息，请参阅 6.4.3 节，“mysql_ssl_rsa_setup — 创建 SSL/RSA 文件”。

    注意

    mysql_ssl_rsa_setup实用程序已在 MySQL 8.0.34 中弃用。

  5. 在没有任何选项文件的情况下，服务器将使用默认设置启动。（请参阅 7.1.2 节，“服务器配置默认值”。）要明确指定 MySQL 服务器在启动时应使用的选项，请将它们放在选项文件中，例如/etc/my.cnf或/etc/mysql/my.cnf。（请参阅 6.2.2.2 节，“使用选项文件”。）例如，您可以使用选项文件设置secure_file_priv系统变量。

  6. 要安排 MySQL 在系统启动时无需手动干预即可启动，请参阅第 2.9.5 节“自动启动和停止 MySQL”。

  7. 数据目录初始化在mysql模式中创建时区表，但不填充它们。要执行此操作，请使用第 7.1.15 节“MySQL 服务器时区支持”中的说明。

数据目录初始化过程

切换到 MySQL 安装的顶级目录，通常为/usr/local/mysql（根据需要调整系统的路径名）：

cd /usr/local/mysql

要初始化数据目录，请使用--initialize或--initialize-insecure选项调用mysqld，具体取决于您是否希望服务器为'root'@'localhost'帐户生成一个随机初始密码，或者创建该帐户而不设置密码：

  • 使用--initialize进行“默认安全”安装（包括生成随机初始root密码）。在这种情况下，密码被标记为过期，您必须选择一个新密码。

  • 使用--initialize-insecure，不会生成root密码。这是不安全的；假定您打算在将服务器��入生产使用之前及时为该帐户分配密码。

要了解如何分配新的'root'@'localhost'密码，请参阅数据目录初始化后的 root 密码分配。

注意

服务器将任何消息（包括任何初始密码）写入其标准错误输出。如果您在屏幕上看不到消息，请查看错误日志。有关错误日志的信息，包括其位置，请参阅第 7.4.2 节“错误日志”。

在 Windows 上，使用--console选项将消息重定向到控制台。

在 Unix 和类 Unix 系统上，数据库目录和文件的所有权归mysql登录帐户所有，以便在以后运行时服务器可以读取和写入这些文件。为了确保这一点，从系统root帐户启动mysqld，并包括如下所示的--user选项：

bin/mysqld --initialize --user=mysql
bin/mysqld --initialize-insecure --user=mysql

或者，以mysql身份登录时执行mysqld，在这种情况下，您可以从命令中省略--user选项。

在 Windows 上，使用以下命令之一：

bin\mysqld --initialize --console
bin\mysqld --initialize-insecure --console

注意

如果缺少必需的系统库，数据目录初始化可能会失败。例如，您可能会看到类似于以下错误：

bin/mysqld: error while loading shared libraries:
libnuma.so.1: cannot open shared object file:
No such file or directory

如果发生这种情况，您必须手动安装缺失的库或使用系统的软件包管理器。然后重试数据目录初始化命令。

如果mysqld无法识别安装目录或数据目录的正确位置，则可能需要指定其他选项，例如--basedir或--datadir。例如（将命令输入在一行上）：

bin/mysqld --initialize --user=mysql
  --basedir=/opt/mysql/mysql
  --datadir=/opt/mysql/mysql/data

或者，将相关的选项设置放入一个选项文件中，并将该文件的名称传递给mysqld。对于 Unix 和类 Unix 系统，假设选项文件名为/opt/mysql/mysql/etc/my.cnf。将以下内容放入文件中：

[mysqld]
basedir=/opt/mysql/mysql
datadir=/opt/mysql/mysql/data

然后按照以下方式调用mysqld（将命令输入在一行上，首先使用--defaults-file选项）：

bin/mysqld --defaults-file=/opt/mysql/mysql/etc/my.cnf
  --initialize --user=mysql

在 Windows 上，假设C:\my.ini包含以下内容：

[mysqld]
basedir=C:\\Program Files\\MySQL\\MySQL Server 8.0
datadir=D:\\MySQLdata

然后按照以下方式调用mysqld（同样，您应该将命令输入在一行上，首先使用--defaults-file选项）：

bin\mysqld --defaults-file=C:\my.ini
   --initialize --console

重要

在初始化数据目录时，您不应指定除用于设置目录位置的选项（如--basedir或--datadir）以及如果需要的话--user选项之外的任何选项。在初始化后重新启动 MySQL 服务器时可以设置 MySQL 服务器在正常使用期间要使用的选项。有关更多信息，请参阅--initialize选项的描述。

数据目录初始化期间服务器执行的操作

注意

服务器执行的数据目录初始化序列不会替代mysql_secure_installation和mysql_ssl_rsa_setup执行的操作。请参阅 Section 6.4.2, “mysql_secure_installation — Improve MySQL Installation Security”，以及 Section 6.4.3, “mysql_ssl_rsa_setup — Create SSL/RSA Files”。

当使用--initialize或--initialize-insecure选项调用mysqld时，在数据目录初始化序列期间执行以下操作：

  1. 服务器检查数据目录的存在如下：

    • 如果不存在数据目录，则服务器将创建它。

    • 如果数据目录存在但不为空（即包含文件或子目录），服务器在生成错误消息后退出：

      [ERROR] --initialize specified but the data directory exists. Aborting.

      在这种情况下，删除或重命名数据目录，然后重试。

      如果现有数据目录允许非空，但每个条目的名称都以句点（.）开头。

  2. 在数据目录中，服务器创建mysql系统模式及其表，包括数据字典表、授权表、时区表和服务器端帮助表。请参阅 Section 7.3, “The mysql System Schema”。

  3. 服务器初始化系统表空间和管理InnoDB表所需的相关数据结构。

    注意

    在mysqld设置InnoDB系统表空间后，对表空间特性的某些更改需要设置一个全新的实例。符合更改的包括系统表空间中第一个文件的文件名和撤销日志的数量。如果不想使用默认值，请确保在运行mysqld之前在 MySQL 配置文件中设置innodb_data_file_path和innodb_log_file_size配置参数。还要确保根据需要指定其他影响InnoDB文件创建和位置的参数，如innodb_data_home_dir和innodb_log_group_home_dir。

    如果这些选项在您的配置文件中，但该文件不在 MySQL 默认读取的位置，请在运行mysqld时使用--defaults-extra-file选项指定文件位置。

  4. 服务器创建一个'root'@'localhost'超级用户账户和其他保留账户（参见第 8.2.9 节，“保留账户”）。一些保留账户被锁定，不能被客户端使用，但'root'@'localhost'用于管理目的，您应该为其分配一个密码。

    关于'root'@'localhost'账户的密码，服务器的操作取决于您如何调用它：

    • 使用--initialize但不使用--initialize-insecure，服务器生成一个随机密码，标记为过期，并显示密码的消息：

      [Warning] A temporary password is generated for root@localhost:
iTag*AfrH5ej

    • 使用--initialize-insecure（无论是否使用--initialize，因为--initialize-insecure隐含了--initialize），服务器不生成密码或标记为过期，并写入警告消息：

      [Warning] root@localhost is created with an empty password ! Please
consider switching off the --initialize-insecure option.

    有关分配新的'root'@'localhost'密码的说明，请参见初始化后的 root 密码分配。

  5. 服务器填充用于HELP语句的服务器端帮助表（参见第 15.8.3 节，“HELP 语句”）。服务器不填充时区表。要手动执行此操作，请参见第 7.1.15 节，“MySQL 服务器时区支持”。

  6. 如果init_file系统变量指定了一个包含 SQL 语句的文件，服务器将执行文件中的语句。此选项使您能够执行自定义引导序列。

    当服务器以引导模式运行时，某些功能不可用，限制了文件中允许的语句。这些包括与账户管理相关的语句（如CREATE USER或GRANT)、复制和全局事务标识符。

  7. 服务器退出。

初始化后的 root 密码分配

在使用--initialize或--initialize-insecure启动服务器初始化数据目录后，正常启动服务器（即，不使用这两个选项之一）并为'root'@'localhost'账户分配一个新密码：

  1. 启动服务器。有关说明，请参见第 2.9.2 节，“启动服务器”。

  2. 连接到服务器：

    • 如果您使用了--initialize但没有使用--initialize-insecure来初始化数据目录，请以root身份连接到服务器：

      mysql -u root -p

      然后，在密码提示符处，输入服务器在初始化序列期间生成的随机密码：

      Enter password: *(enter the random root password here)*

      如果您不知道此密码，请查看服务器错误日志。

    • 如果您使用了--initialize-insecure来初始化数据目录，请以无密码的root身份连接到服务器：

      mysql -u root --skip-password

  3. 连接后，使用ALTER USER语句分配一个新的root密码：

    ALTER USER 'root'@'localhost' IDENTIFIED BY '*root-password'*;

请参阅 第 2.9.4 节，“保护初始 MySQL 帐户”。

注意

尝试连接到主机127.0.0.1通常会解析为localhost帐户。但是，如果服务器启用了skip_name_resolve，则会失败。如果您打算这样做，请确保存在一个可以接受连接的帐户。例如，要能够使用--host=127.0.0.1或--host=::1连接为root，请创建这些帐户：

CREATE USER 'root'@'127.0.0.1' IDENTIFIED BY '*root-password*';
CREATE USER 'root'@'::1' IDENTIFIED BY '*root-password*';

可以将这些语句放在一个文件中，通过init_file系统变量执行，如数据目录初始化期间的服务器操作中所讨论的那样。

2.9.2 启动服务器

原文：dev.mysql.com/doc/refman/8.0/en/starting-server.html

2.9.2.1 启动 MySQL 服务器时出现问题的故障排除

本节描述了如何在 Unix 和类 Unix 系统上启动服务器。（对于 Windows，请参阅 Section 2.3.4.5, “首次启动服务器”。）有关一些建议的命令，您可以使用这些命令来测试服务器是否可访问并正常工作，请参阅 Section 2.9.3, “测试服务器”。

如果您的安装包含mysqld_safe，请像这样启动 MySQL 服务器：

$> bin/mysqld_safe --user=mysql &

注意

对于安装了 MySQL 的 Linux 系统，使用 RPM 包，服务器的启动和关闭是通过 systemd 管理的，而不是通过mysqld_safe，并且mysqld_safe未安装。请参阅 Section 2.5.9, “使用 systemd 管理 MySQL 服务器”。

如果您的安装包含 systemd 支持，请像这样启动服务器：

$> systemctl start mysqld

如果服务名称与 mysqld 不同，请替换为适当的服务名称（例如，在 SLES 系统上为 mysql）。

MySQL 服务器必须使用非特权（非root）登录帐户运行非常重要。为了确保这一点，请以 root 身份运行mysqld_safe，并包含如下所示的 --user 选项。否则，您应该以 mysql 登录后执行该程序，这种情况下，您可以在命令中省略 --user 选项。

有关以非特权用户身份运行 MySQL 的进一步说明，请参阅 Section 8.1.5, “如何以普通用户身份运行 MySQL”。

如果命令立即失败并打印 mysqld ended，请查看错误日志中的信息（默认情况下是数据��录中的 *host_name*.err 文件）。

如果服务器无法访问数据目录，启动或读取 mysql 模式中的授权表，它会在错误日志中写入一条消息。如果您在继续此步骤之前忽略了通过初始化数据目录创建授权表，或者如果您在运行初始化数据目录的命令时没有使用 --user 选项，可能会出现此类问题。删除 data 目录并使用 --user 选项运行该命令。

如果您在启动服务器时遇到其他问题，请参见第 2.9.2.1 节，“启动 MySQL 服务器时出现问题的故障排除”。有关mysqld_safe的更多信息，请参见第 6.3.2 节，“mysqld_safe — MySQL 服务器启动脚本”。有关 systemd 支持的更多信息，请参见第 2.5.9 节，“使用 systemd 管理 MySQL 服务器”。

原文：dev.mysql.com/doc/refman/8.0/en/starting-server-troubleshooting.html

2.9.2.1 启动 MySQL 服务器时出现问题的故障排除

本节提供了有关启动服务器时出现问题的故障排除建议。有关 Windows 系统的其他建议，请参阅第 2.3.5 节，“解决 Microsoft Windows MySQL 服务器安装问题”。

如果您在启动服务器时遇到问题，请尝试以下方法：

  • 检查错误日志以查看服务器为何无法启动。日志文件位于数据目录中（在 Windows 上通常为C:\Program Files\MySQL\MySQL Server 8.0\data，对于 Unix/Linux 二进制分发为/usr/local/mysql/data，对于 Unix/Linux 源码分发为/usr/local/var）。在数据目录中查找名称形式为*host_name*.err和*host_name*.log的文件，其中*host_name*是您服务器主机的名称。然后检查这些文件的最后几行。使用tail命令显示它们：

    $> tail *host_name*.err
$> tail *host_name*.log

  • 指定存储引擎所需的任何特殊选项。您可以创建一个my.cnf文件，并为您计划使用的引擎指定启动选项。如果您要使用支持事务表的存储引擎（InnoDB，NDB），请确保在启动服务器之前将它们配置为您想要的方式。如果您使用InnoDB表，请参阅第 17.8 节，“InnoDB 配置”以获取指南，以及第 17.14 节，“InnoDB 启动选项和系统变量”以获取选项语法。

    尽管存储引擎对您省略的选项使用默认值，但 Oracle 建议您查看可用选项，并为任何默认值不适合您安装的选项指定显式值。

  • 确保服务器知道在哪里找到数据目录。mysqld服务器将此目录用作其当前目录。这是它期望找到数据库并写入日志文件的地方。服务器还会在数据目录中写入 pid（进程 ID）文件。

    默认数据目录位置在服务器编译时被硬编码。要确定默认路径设置是什么，使用带有--verbose和--help选项调用mysqld。如果数据目录位于系统的其他位置，请使用--datadir选项指定该位置给mysqld或mysqld_safe，在命令行或选项文件中。否则，服务器将无法正常工作。作为--datadir选项的替代方案，您可以使用--basedir指定 MySQL 安装的基本目录的位置给mysqld，然后mysqld在那里查找data目录。

    要检查指定路径选项的效果，请使用这些选项调用mysqld，然后跟随--verbose和--help选项。例如，如果将位置更改为安装mysqld��目录，然后运行以下命令，它会显示使用基本目录/usr/local启动服务器的效果：

    $> ./mysqld --basedir=/usr/local --verbose --help

    你可以指定其他选项，比如--datadir，但--verbose和--help必须是最后的选项。

    一旦确定了所需的路径设置，启动服务器时不要带--verbose和--help。

    如果mysqld当前正在运行，可以通过执行以下命令查找它正在使用的路径设置：

    $> mysqladmin variables

    或者：

    $> mysqladmin -h *host_name* variables

    *host_name*是 MySQL 服务器主机的名称。

  • 确保服务器可以访问 data directory。数据目录及其内容的所有权和权限必须允许服务器读取和修改它们。

    如果在启动mysqld时遇到Errcode 13（表示Permission denied），这意味着数据目录或其内容的权限不允许服务器访问。在这种情况下，您需要更改相关文件和目录的权限，以便服务器有权使用它们。您也可以以root用户身份启动服务器，但这会带来安全问题，应该避免。

    切换到数据目录并检查数据目录及其内容的所有权，以确保服务器有访问权限。例如，如果数据目录是/usr/local/mysql/var，使用以下命令：

    $> ls -la /usr/local/mysql/var

    如果数据目录或其文件或子目录的所有权不属于您用于运行服务器的登录帐��，请将它们的所有权更改为该帐户。如果帐户名为mysql，请使用以下命令：

    $> chown -R mysql /usr/local/mysql/var
$> chgrp -R mysql /usr/local/mysql/var

    即使拥有正确的所有权，如果系统上运行了其他安全软件来管理应用程序对文件系统各部分的访问，MySQL 可能无法启动。在这种情况下，重新配置该软件以允许mysqld访问其在正常操作期间使用的目录。

  • 验证服务器要使用的网络接口是否可用。

    如果出现以下任一错误，则表示可能有其他程序（也许是另一个mysqld服务器）正在使用mysqld尝试使用的 TCP/IP 端口或 Unix 套接字文件：

    Can't start server: Bind on TCP/IP port: Address already in use
Can't start server: Bind on unix socket...

    使用ps来确定是否有另一个mysqld服务器正在运行。如果是，请在再次启动mysqld之前关闭服务器。（如果有其他服务器在运行，并且您确实想要运行多个服务器，您可以在第 7.8 节，“在一台机器上运行多个 MySQL 实例”中找到如何操作的信息。）

    如果没有其他服务器在运行，请执行命令telnet *your_host_name* *tcp_ip_port_number*。（默认的 MySQL 端口号是 3306。）然后按下几次回车键。如果你没有收到类似telnet: Unable to connect to remote host: Connection refused的错误消息，那么可能是其他程序正在使用mysqld尝试使用的 TCP/IP 端口。找出是哪个程序在使用，并禁用它，或者告诉mysqld使用不同的端口监听，使用--port选项。在这种情况下，当使用 TCP/IP 连接到服务器时，客户端程序指定相同的非默认端口号。

    另一个端口无法访问的原因可能是您的防火墙阻止对其的连接。如果是这样，请修改防火墙设置以允许访问该端口。

    如果服务器启动但无法连接，请确保您在/etc/hosts中有类似以下内容的条目：

    127.0.0.1       localhost

  • 如果无法启动mysqld，尝试使用--debug选项创建一个跟踪文件以查找问题。参见第 7.9.4 节，“DBUG 包”。

2.9.3 测试服务器

原文：dev.mysql.com/doc/refman/8.0/en/testing-server.html

在数据目录初始化并启动服务器后，执行一些简单的测试以确保其正常工作。本节假定您当前的位置是 MySQL 安装目录，并且其中包含一个包含此处使用的 MySQL 程序的 bin 子目录。如果不是这样，请相应调整命令路径名称。

或者，将 bin 目录添加到您的 PATH 环境变量设置中。这样可以使您的 shell（命令解释器）正确找到 MySQL 程序，从而可以通过仅输入程序名称而不是路径名称来运行程序。参见 6.2.9 节“设置环境变量”。

使用 mysqladmin 来验证服务器是否正在运行。以下命令提供了简单的测试，以检查服务器是否正在运行并响应连接：

$> bin/mysqladmin version
$> bin/mysqladmin variables

如果无法连接到服务器，请指定 -u root 选项以连接为 root。如果您已经为 root 账户分配了密码，还需要在命令行中指定 -p 并在提示时输入密码。例如：

$> bin/mysqladmin -u root -p version
Enter password: *(enter root password here)*

mysqladmin version 的输出会根据您的平台和 MySQL 版本略有不同，但应该类似于这里显示的内容：

$> bin/mysqladmin version
mysqladmin  Ver 14.12 Distrib 8.0.36, for pc-linux-gnu on i686
...

Server version          8.0.36
Protocol version        10
Connection              Localhost via UNIX socket
UNIX socket             /var/lib/mysql/mysql.sock
Uptime:                 14 days 5 hours 5 min 21 sec

Threads: 1  Questions: 366  Slow queries: 0
Opens: 0  Flush tables: 1  Open tables: 19
Queries per second avg: 0.000

要查看您可以使用 mysqladmin 进行的其他���作，请使用 --help 选项调用它。

验证您可以关闭服务器（如果 root 账户已经有密码，请包括 -p 选项）：

$> bin/mysqladmin -u root shutdown

验证您可以再次启动服务器。可以通过使用 mysqld_safe 或直接调用 mysqld 来执行此操作。例如：

$> bin/mysqld_safe --user=mysql &

如果 mysqld_safe 失败，请参阅 2.9.2.1 节“启动 MySQL 服务器时出现问题的故障排除”。

运行一些简单的测试，以验证您可以从服务器检索信息。输出应类似于此处显示的内容。

使用 mysqlshow 查看存在哪些数据库：

$> bin/mysqlshow
+--------------------+
|     Databases      |
+--------------------+
| information_schema |
| mysql              |
| performance_schema |
| sys                |
+--------------------+

安装的数据库列表可能有所不同，但始终包括至少 mysql 和 information_schema。

如果您指定了数据库名称，mysqlshow 将显示数据库中的表列表：

$> bin/mysqlshow mysql
Database: mysql
+---------------------------+
|          Tables           |
+---------------------------+
| columns_priv              |
| component                 |
| db                        |
| default_roles             |
| engine_cost               |
| func                      |
| general_log               |
| global_grants             |
| gtid_executed             |
| help_category             |
| help_keyword              |
| help_relation             |
| help_topic                |
| innodb_index_stats        |
| innodb_table_stats        |
| ndb_binlog_index          |
| password_history          |
| plugin                    |
| procs_priv                |
| proxies_priv              |
| role_edges                |
| server_cost               |
| servers                   |
| slave_master_info         |
| slave_relay_log_info      |
| slave_worker_info         |
| slow_log                  |
| tables_priv               |
| time_zone                 |
| time_zone_leap_second     |
| time_zone_name            |
| time_zone_transition      |
| time_zone_transition_type |
| user                      |
+---------------------------+

使用mysql程序从mysql模式中的表中选择信息：

$> bin/mysql -e "SELECT User, Host, plugin FROM mysql.user" mysql
+------+-----------+-----------------------+
| User | Host      | plugin                |
+------+-----------+-----------------------+
| root | localhost | caching_sha2_password |
+------+-----------+-----------------------+

此时，您的服务器正在运行，您可以访问它。如果您尚未为初始帐户分配密码，请按照 Section 2.9.4, “Securing the Initial MySQL Account”中的说明加强安全性。

关于mysql，mysqladmin和mysqlshow的更多信息，请参见 Section 6.5.1, “mysql — The MySQL Command-Line Client”，Section 6.5.2, “mysqladmin — A MySQL Server Administration Program”和 Section 6.5.7, “mysqlshow — Display Database, Table, and Column Information”。

2.9.4 保护初始 MySQL 帐户

原文：dev.mysql.com/doc/refman/8.0/en/default-privileges.html

MySQL 安装过程涉及初始化数据目录，包括在mysql系统模式中定义 MySQL 帐户的授权表。有关详细信息，请参见第 2.9.1 节，“初始化数据目录”。

本节描述如何为在 MySQL 安装过程中创建的初始root帐户分配密码，如果您尚未这样做。

注意

执行本节描述的过程的替代方法：

  • 在 Windows 上，您可以在安装过程中使用 MySQL Installer 执行该过程（参见第 2.3.3 节，“Windows 上的 MySQL Installer”）。

  • 在所有平台上，MySQL 发行版包括mysql_secure_installation，一个命令行实用程序，自动化了大部分保护 MySQL 安装过程的过程。

  • 在所有平台上，MySQL Workbench 可用，并提供管理用户帐户的功能（参见第三十三章，MySQL Workbench）。

在以下情况下，初始帐户可能已经分配了密码：

  • 在 Windows 上，使用 MySQL Installer 执行的安装会让您选择分配密码。

  • 使用 macOS 安装程序进行安装会生成一个初始的随机密码，并在对话框中向用户显示。

  • 使用 RPM 软件包进行安装会生成一个初始的随机密码，并写入服务器错误日志。

  • 使用 Debian 软件包进行安装会让您选择分配密码。

  • 对于手动执行数据目录初始化的情况，使用mysqld --initialize，mysqld会生成一个初始的随机密码，标记为过期，并写入服务器错误日志。参见第 2.9.1 节，“初始化数据目录”。

mysql.user授权表定义了初始的 MySQL 用户帐户及其访问权限。MySQL 的安装仅创建一个具有所有权限并可以执行任何操作的'root'@'localhost'超级用户帐户。如果root帐户没有密码，您的 MySQL 安装是不受保护的：任何人都可以连接到 MySQL 服务器作为root，无需密码并被授予所有权限。

'root'@'localhost'账户还在mysql.proxies_priv表中有一行，允许为''@''（即所有用户和所有主机）授予PROXY权限。这使root能够设置代理用户，以及委派其他账户设置代理用户的权限。参见 Section 8.2.19, “Proxy Users”。

要为初始的 MySQL root账户分配密码，请使用以下程序。在示例中用你想要使用的密码替换*root-password*。

如果服务器未运行，请启动服务器。有关说明，请参见 Section 2.9.2, “Starting the Server”。

初始的root账户可能有密码，也可能没有。选择以下适用的任一程序：

  • 如果root账户存在并且初始的随机密码已过期，请使用该密码连接到服务器作为root，然后选择一个新密码。如果数据目录是使用mysqld --initialize初始化的，无论是手动还是使用安装程序，在安装操作期间没有指定密码选项。因为密码存在，你必须使用它连接到服务器。但因为密码已过期，你不能将该账户用于除选择新密码之外的任何目的，直到你选择一个新密码。

    1. 如果你不知道初始的随机密码，查看服务器错误日志。

    2. 使用密码连接到服务器作为root：

      $> mysql -u root -p
Enter password: *(enter the random root password here)*

    3. 选择一个新密码以替换随机密码：

      mysql> ALTER USER 'root'@'localhost' IDENTIFIED BY '*root-password*';

  • 如果root账户存在但没有密码，请使用无密码连接到服务器作为root，然后分配一个密码。如果你使用mysqld --initialize-insecure初始化数据目录，则是这种情况。

    1. 使用无密码连接到服务器作为root：

      $> mysql -u root --skip-password

    2. 分配密码：

      mysql> ALTER USER 'root'@'localhost' IDENTIFIED BY '*root-password*';

为root账户分配密码后，每次使用该账户连接到服务器时，都必须提供该密码。例如，要使用mysql客户端连接到服务器，请使用此命令：

$> mysql -u root -p
Enter password: *(enter root password here)*

要使用mysqladmin关闭服务器，请使用此命令：

$> mysqladmin -u root -p shutdown
Enter password: *(enter root password here)*

注意

有关设置密码的更多信息，请参见 Section 8.2.14, “Assigning Account Passwords”。如果设置后忘记了root密码，请参见 Section B.3.3.2, “How to Reset the Root Password”。

要设置额外的账户，请参见 Section 8.2.8, “Adding Accounts, Assigning Privileges, and Dropping Accounts”。

2.9.5 自动启动和停止 MySQL

原文：dev.mysql.com/doc/refman/8.0/en/automatic-start.html

本节讨论了启动和停止 MySQL 服务器的方法。

通常，您可以通过以下方式之一启动mysqld服务器：

  • 直接调用mysqld。这在任何平台上都适用。

  • 在 Windows 上，您可以设置一个 MySQL 服务，该服务在 Windows 启动时自动运行。请参阅 Section 2.3.4.8, “Starting MySQL as a Windows Service”。

  • 在 Unix 和类 Unix 系统上，您可以调用mysqld_safe，它会尝试确定mysqld的正确选项，然后使用这些选项运行它。请参阅 Section 6.3.2, “mysqld_safe — MySQL Server Startup Script”。

  • 在支持 systemd 的 Linux 系统上，您可以使用它来控制服务器。请参阅 Section 2.5.9, “Managing MySQL Server with systemd”。

  • 在使用 System V 风格运行目录（即 /etc/init.d 和特定运行级别目录）的系统上，调用mysql.server。该脚本主要用于系统启动和关闭。它通常以 mysql 的名称安装。mysql.server脚本通过调用mysqld_safe来启动服务器。请参阅 Section 6.3.3, “mysql.server — MySQL Server Startup Script”。

  • 在 macOS 上，安装一个 launchd 守护程序以在系统启动时启用自动 MySQL 启动。该守护程序通过调用mysqld_safe来启动服务器。详情请参阅 Section 2.4.3, “Installing and Using the MySQL Launch Daemon”。MySQL 首选项面板还提供了通过系统偏好设置启动和停止 MySQL 的控制。请参阅 Section 2.4.4, “Installing and Using the MySQL Preference Pane”。

  • 在 Solaris 上，使用服务管理框架（SMF）系统来启动和控制 MySQL 启动。

systemd，mysqld_safe 和 mysql.server 脚本，Solaris SMF，以及 macOS 启动项（或 MySQL 首选项面板）可用于手动启动服务器，或在系统启动时自动启动。systemd，mysql.server 和启动项也可用于停止服务器。

以下表显示服务器和启动脚本从选项文件中读取的选项组。

表 2.15 MySQL 启动脚本和支持的服务器选项组

脚本选项组
mysqld[mysqld], [server], [mysqld-*major_version*]
mysqld_safe[mysqld], [server], [mysqld_safe]
mysql.server[mysqld], [mysql.server], [server]

[mysqld-*major_version*] 意味着像 [mysqld-5.7] 和 [mysqld-8.0] 这样的名称组将被版本为 5.7.x、8.0.x 等的服务器读取。此功能可用于指定仅可由给定发布系列内的服务器读取的选项。

为了向后兼容，mysql.server 还会读取 [mysql_server] 组，而 mysqld_safe 也会读取 [safe_mysqld] 组。为了保持最新，您应该更新您的选项文件以使用 [mysql.server] 和 [mysqld_safe] 组。

有关 MySQL 配置文件及其结构和内容的更多信息，请参见 Section 6.2.2.2, “使用选项文件”。

2.10 Perl 安装注意事项

原文：dev.mysql.com/doc/refman/8.0/en/perl-support.html

2.10.1 在 Unix 上安装 Perl

2.10.2 在 Windows 上安装 ActiveState Perl

2.10.3 使用 Perl DBI/DBD 接口时出现的问题

Perl DBI 模块提供了一个通用的数据库访问接口。您可以编写一个适用于许多不同数据库引擎的 DBI 脚本，而无需更改。要使用 DBI，您必须安装 DBI 模块，以及每种类型的数据库服务器的 DataBase Driver (DBD) 模块。对于 MySQL，这个驱动程序是 DBD::mysql 模块。

注意

MySQL 发行版不包含 Perl 支持。您可以从search.cpan.org获取必要的模块，Unix 系统可以使用 ActiveState ppm程序在 Windows 上获取。以下部分描述了如何执行此操作。

DBI/DBD 接口需要 Perl 5.6.0，最好使用 5.6.1 或更高版本。如果您使用较旧版本的 Perl，DBI 无法工作。您应该使用DBD::mysql 4.009 或更高版本。尽管早期版本可用，但它们不支持 MySQL 8.0 的全部功能。

2.10.1 在 Unix 上安装 Perl

原文：dev.mysql.com/doc/refman/8.0/en/perl-installation.html

MySQL Perl 支持要求您已安装了 MySQL 客户端编程支持（库和头文件）。大多数安装方法都会安装必要的文件。如果您在 Linux 上从 RPM 文件安装 MySQL，请确保也安装了开发者 RPM。客户端程序在客户端 RPM 中，但客户端编程支持在开发者 RPM 中。

您需要用于 Perl 支持的文件可以从 CPAN（Comprehensive Perl Archive Network）获取，网址为search.cpan.org。

在 Unix 上安装 Perl 模块的最简单方法是使用CPAN模块。例如：

$> perl -MCPAN -e shell
cpan> install DBI
cpan> install DBD::mysql

DBD::mysql安装运行了一系列测试。这些测试尝试使用默认用户名和密码连接到本地 MySQL 服务器。（默认用户名是 Unix 上的登录名，Windows 上是ODBC。默认密码是“no password”。）如果您无法使用这些值连接到服务器（例如，如果您的帐户有密码），测试将失败。您可以使用force install DBD::mysql来忽略失败的测试。

DBI需要Data::Dumper模块。如果没有安装，您应该在安装DBI之前安装它。

也可以以压缩的tar存档形式下载模块分发，并手动构建模块。例如，要解压和构建一个 DBI 分发，可以使用以下过程：

  1. 解压分发到当前目录：

    $> gunzip < DBI-*VERSION*.tar.gz | tar xvf -

    这个命令会创建一个名为DBI-*VERSION*的目录。

  2. 将位置更改为解压分发的顶级目录：

    $> cd DBI-*VERSION*

  3. 构建分发并编译所有内容：

    $> perl Makefile.PL
$> make
$> make test
$> make install

make test命令很重要，因为它验证模块是否正常工作。请注意，在DBD::mysql安装期间运行该命令以执行接口代码时，MySQL 服务器必须正在运行，否则测试将失败。

重新构建和重新安装DBD::mysql分发是一个好主意，每当你安装新版本的 MySQL 时。这确保了最新版本的 MySQL 客户端库被正确安装。

如果您没有权限在系统目录中安装 Perl 模块，或者想要安装本地 Perl 模块，下面的参考可能会有用：learn.perl.org/faq/perlfaq8.html#How-do-I-keep-my-own-module-library-directory-

2.10.2 在 Windows 上安装 ActiveState Perl

原文：dev.mysql.com/doc/refman/8.0/en/activestate-perl.html

在 Windows 上，您应该按照以下步骤使用 ActiveState Perl 安装 MySQL DBD模块：

  1. 从www.activestate.com/Products/ActivePerl/获取 ActiveState Perl 并安装。

  2. 打开控制台窗口。

  3. 如果需要，设置HTTP_proxy变量。例如，您可以尝试这样的设置：

    C:\> set HTTP_proxy=my.proxy.com:3128

  4. 启动 PPM 程序：

    C:\> C:\perl\bin\ppm.pl

  5. 如果之前没有安装过，安装DBI：

    ppm> install DBI

  6. 如果成功，运行以下命令：

    ppm> install DBD-mysql

这个步骤适用于 ActiveState Perl 5.6 或更高版本。

如果无法使该步骤生效，应安装 ODBC 驱动程序，然后通过 ODBC 连接到 MySQL 服务器：

use DBI;
$dbh= DBI->connect("DBI:ODBC:$dsn",$user,$password) ||
  die "Got error $DBI::errstr when connecting to $dsn\n";

2.10.3 使用 Perl DBI/DBD 接口时的问题

原文：dev.mysql.com/doc/refman/8.0/en/perl-support-problems.html

如果 Perl 报告找不到../mysql/mysql.so模块，则问题可能是 Perl 找不到libmysqlclient.so共享库的位置。您可以通过以下方法之一解决此问题：

  • 将libmysqlclient.so复制到其他共享库所在的目录（可能是/usr/lib或/lib）。

  • 修改用于编译DBD::mysql的-L选项，以反映libmysqlclient.so的实际位置。

  • 在 Linux 上，您可以将包含libmysqlclient.so的目录路径添加到/etc/ld.so.conf文件中。

  • 将包含libmysqlclient.so的目录路径添加到LD_RUN_PATH环境变量中。一些系统使用LD_LIBRARY_PATH代替。

请注意，如果链接器无法找到其他库，则可能还需要修改-L选项。例如，如果链接器无法找到libc，因为它在/lib中，而链接命令指定为-L/usr/lib，请将-L选项更改为-L/lib或将-L/lib添加到现有链接命令中。

如果从DBD::mysql获得以下错误，则您可能正在使用gcc（或使用用gcc编译的旧二进制文件）：

/usr/bin/perl: can't resolve symbol '__moddi3'
/usr/bin/perl: can't resolve symbol '__divdi3'

在构建mysql.so库时（编译 Perl 客户端时，请检查make的输出以查看mysql.so），在链接命令中添加-L/usr/lib/gcc-lib/... -lgcc。-L选项应指定系统上包含libgcc.a的目录路径。

此问题的另一个原因可能是 Perl 和 MySQL 都未使用gcc编译。在这种情况下，您可以通过使用gcc编译两者来解决不匹配问题。

第三章 升级 MySQL

原文：dev.mysql.com/doc/refman/8.0/en/upgrading.html

目录

3.1 开始之前

3.2 升级路径

3.3 升级最佳实践

3.4 MySQL 升级过程升级了什么

3.5 MySQL 8.0 中的更改

3.6 准备升级安装

3.7 在 Unix/Linux 上升级 MySQL 二进制或基于包的安装

3.8 使用 MySQL Yum 存储库升级 MySQL

3.9 使用 MySQL APT 存储库升级 MySQL

3.10 使用 MySQL SLES 存储库升级 MySQL

3.11 在 Windows 上升级 MySQL

3.12 升级 MySQL 的 Docker 安装

3.13 升级故障排除

3.14 重建或修复表或索引

3.15 将 MySQL 数据库复制到另一台机器

本章描述了升级 MySQL 安装的步骤。

升级是一个常见的过程，因为您可以在相同的 MySQL 发行系列中获取错误修复或在主要 MySQL 发行版之间获取重要功能。您首先在一些测试系统上执行此过程，以确保一切顺利运行，然后在生产系统上执行。

注意

在以下讨论中，必须使用具有管理权限的 MySQL 帐户运行的 MySQL 命令包括在命令行中使用 -u root`` 指定 MySQL root 用户。需要 root 密码的命令还包括 -p 选项。因为 -p 后面没有选项值，这些命令会提示输入密码。在提示时输入密码并按 Enter 键。

SQL 语句可以使用mysql命令行客户端执行（以 root 身份连接以确保具有必要的权限）。

3.1 开始之前

原文：dev.mysql.com/doc/refman/8.0/en/upgrade-before-you-begin.html

在升级之前，请查看本节中的信息。执行任何建议的操作。

  • 了解升级过程中可能发生的情况。请参见第 3.4 节，“MySQL 升级过程升级了什么”。

  • 通过创建备份来保护您的数据。备份应包括包含 MySQL 数据字典表和系统表的mysql系统数据库。参见第 9.2 节，“数据库备份方法”。

    重要

    从 MySQL 8.0 降级到 MySQL 5.7，或从一个 MySQL 8.0 版本降级到以前的 MySQL 8.0 版本，不受支持。唯一支持的替代方法是恢复在升级之前进行的备份。因此，在开始升级过程之前，备份数据至关重要。

  • 查看第 3.2 节，“升级路径”以确保您打算的升级路径得到支持。

  • 查看第 3.5 节，“MySQL 8.0 中的更改”以了解升级前应注意的更改。某些更改可能需要采取行动。

  • 查看第 1.3 节，“MySQL 8.0 中的新功能”以了解已弃用和移除的功能。如果您使用其中任何功能，则升级可能需要对这些功能进行更改。

  • 查看第 1.4 节，“MySQL 8.0 中添加、弃用或移除的服务器和状态变量和选项”。如果您使用已弃用或移除的变量，则升级可能需要配置更改。

  • 查看发布说明以获取有关修复、更改和新功能的信息。

  • 如果您使用复制，请查看第 19.5.3 节，“升级复制拓扑”。

  • 查看第 3.3 节，“升级最佳实践”并相应地进行计划。

  • 升级过程因平台和初始安装方式而异。使用适用于当前 MySQL 安装的过程：

    • 对于非 Windows 平台上的二进制和基于软件包的安装，请参考第 3.7 节，“在 Unix/Linux 上升级 MySQL 二进制或基于软件包的安装”。

      注意

      对于支持的 Linux 发行版，升级基于软件包的安装的首选方法是使用 MySQL 软件仓库（MySQL Yum 仓库，MySQL APT 仓库和 MySQL SLES 仓库）。

    • 对于在企业 Linux 平台或 Fedora 上使用 MySQL Yum 仓库进行安装，请参考 第 3.8 节，“使用 MySQL Yum 仓库升级 MySQL”。

    • 对于在 Ubuntu 上使用 MySQL APT 仓库进行安装，请参考 第 3.9 节，“使用 MySQL APT 仓库升级 MySQL”。

    • 对于在 SLES 上使用 MySQL SLES 仓库进行安装，请参考 第 3.10 节，“使用 MySQL SLES 仓库升级 MySQL”。

    • 对于使用 Docker 进行的安装，请参考 第 3.12 节，“升级 Docker 安装的 MySQL”。

    • 对于在 Windows 上安装，请参考 第 3.11 节，“在 Windows 上升级 MySQL”。

  • 如果您的 MySQL 安装包含大量数据，在原地升级后可能需要很长时间才能转换，那么创建一个用于评估所需转换和执行工作量的测试实例可能会很有用。要创建一个测试实例，请复制包含 mysql 数据库和其他数据库但不包含数据的 MySQL 实例。在测试实例上运行升级过程，以评估执行实际数据转换所需的工作量。

  • 重新构建和重新安装 MySQL 语言接口是在安装或升级到新版本的 MySQL 时建议的。这适用于 MySQL 接口，如 PHP mysql 扩展和 Perl DBD::mysql 模块。

3.2 升级路径

原文：dev.mysql.com/doc/refman/8.0/en/upgrade-paths.html

  • 从 MySQL 5.7 升级到 8.0 是支持的。然而，升级仅在正式发布（GA）版本之间支持。对于 MySQL 8.0，要求您从 MySQL 5.7 GA 版本（5.7.9 或更高版本）升级。不支持从 MySQL 5.7 的非 GA 版本升级。

  • 在升级到下一个版本之前，建议先升级到最新版本。例如，在升级到 MySQL 8.0 之前，先升级到最新的 MySQL 5.7 版本。

  • 不支持跳过版本的升级。例如，直接从 MySQL 5.6 升级到 8.0 是不支持的。

  • 一旦一个发布系列达到正式发布（GA）状态，就支持在发布系列内升级（从一个 GA 版本到另一个 GA 版本）。例如，从 MySQL 8.0.x 升级到 8.0.y 是支持的。（不支持涉及开发状态非 GA 版本的升级。）跳过一个版本也是支持的。例如，从 MySQL 8.0.x 升级到 8.0.z 是支持的。MySQL 8.0.11 是 MySQL 8.0 发布系列中的第一个 GA 状态发布。

3.3 升级最佳实践

原文：dev.mysql.com/doc/refman/8.0/en/upgrade-best-practices.html

MySQL 支持在小版本之间升级（在 LTS 系列内）和到下一个主要版本（跨 LTS 系列）。升级提供最新功能、性能和安全修复。

为了准备并确保您对最新 MySQL 版本的升级成功，我们建议遵循以下最佳实践：

  • 决定升级为主要版本还是次要版本

  • 决定升级类型

  • 审查支持的平台

  • 了解 MySQL 服务器变更

  • 运行升级检查器并修复不兼容性

  • 在测试环境中运行应用程序

  • 基准应用程序和工作负载性能

  • 并行运行两个 MySQL 版本

  • 运行最终测试升级

  • 检查 MySQL 备份

  • 升级生产服务器

  • 企业支持

决定升级为主要版本还是次要版本

MySQL 发布模型区分了 LTS（长期支持）和创新版本。 LTS 版本提供 8 年以上的支持，适用于生产环境。创新版本为用户提供最新功能和能力。了解更多关于MySQL 发布模型。

执行小版本升级很简单，而大版本升级需要在升级前进行战略规划和额外测试。这个指南对于大版本升级尤为有用。

决定升级类型

有三种主要的升级 MySQL 的方式，请阅读相关文档以确定哪种升级方式最适合您的情况。

  • 原地升级：替换 MySQL 服务器软件包。

  • 逻辑升级：从旧的 MySQL 实例导出 SQL 到新的实例。

  • 复制拓扑升级：考虑每个服务器的拓扑角色。

查看支持的平台

如果您当前的操作系统不受新版本 MySQL 支持，则计划升级操作系统，否则不支持就地升级。

有关当前支持的平台列表，请参见：www.mysql.com/support/supportedplatforms/database.html

了解 MySQL 服务器的更改

每个主要版本都带来新功能、行为变化、弃用和移除。了解每个对现有应用程序的影响非常重要。

请参见：第 3.5 节，“MySQL 8.0 中的更改”。

运行升级检查器并修复不兼容性

MySQL Shell 的升级检查器实用程序检测数据库版本之间必须在升级之前解决的不兼容性。util.checkForServerUpgrade() 函数验证 MySQL 服务器实例是否准备好升级。连接到现有的 MySQL 服务器，并选择您计划升级到的 MySQL 服务器版本，以便实用程序报告在升级之前需要解决的问题。这些问题包括数据类型、存储引擎等不兼容性。

当升级检查工具不再报告任何问题时，您就可以准备升级了。

在测试环境中运行应用程���

完成升级检查器的要求后，接下来在新的目标 MySQL 服务器上测试您的应用程序。检查 MySQL 错误日志和应用程序日志中的错误和警告。

基准测试应用程序和工作负载性能

我们建议通过比较您的应用程序和工作负载在使用先前版本和新版本的 MySQL 时的性能来进行基准测试。通常，新版本的 MySQL 添加功能并提高性能，但也有可能升级后某些查询运行速度较慢。可能导致性能回退的问题：

  • 先前的服务器配置对于新版本不是最佳的

  • 数据类型的更改

  • 多字节字符集支持需要额外的存储空间

  • 存储引擎更改

  • 删除或更改的索引

  • 更强的加密

  • 更强的身份验证

  • SQL 优化器的更改

  • 新版本的 MySQL 需要额外的内存

  • 物理或虚拟硬件较慢 - 计算或存储

有关相关信息和潜在的缓解技术，请参见有效性能回归。

并行运行两个 MySQL 版本

为了最小化风险，在运行升级系统的同时最好保持当前系统运行。

运行最终测试升级

在升级生产服务器之前进行练习和试运行。在升级生产系统之前彻底测试升级程序。

检查 MySQL 备份

在执行升级之前，请检查完整备份是否存在并可行。

升级生产服务器

您已准备好完成升级。

企业支持

如果您是 MySQL 企业版客户，您也可以联系 MySQL 支持团队的专家以解决任何问题。

3.4 MySQL 升级过程升级的内容

原文：dev.mysql.com/doc/refman/8.0/en/upgrading-what-is-upgraded.html

安装新版本的 MySQL 可能需要升级现有安装的这些部分：

  • 包含 MySQL 服务器运行所需信息的表的 mysql 系统模式（请参阅 第 7.3 节，“mysql 系统模式”）。 mysql 模式表分为两大类：

    • 存储数据库对象元数据的数据字典表。

    • 系统表（即剩余的非数据字典表），用于其他操作目的。

  • 其他模式，其中一些是内置的，可能被服务器“拥有”，而另一些则不是：

    • performance_schema, INFORMATION_SCHEMA, ndbinfo, 和 sys 模式。

    • 用户模式。

与可能需要升级的安装部分相关联的两个不同版本号：

  • 数据字典版本。 这适用于数据字典表。

  • 服务器版本，也称为 MySQL 版本。 这适用于系统表和其他模式中的对象。

在这两种情况下，现有 MySQL 安装适用的实际版本存储在数据字典中，当前期望的版本编译到新版本的 MySQL 中。 当实际版本低于当前期望版本时，必须将与该版本相关联的安装部分升级到当前版本。 如果两个版本都指示需要升级，则必须首先进行数据字典升级。

作为刚提到的两个不同版本的反映，升级分为两个步骤：

  • 步骤 1：数据字典升级。

    此步骤升级：

    • mysql 模式中的数据字典表。 如果实际数据字典版本低于当前期望版本，则服务器会创建具有更新定义的数据字典表，将持久化的元数据复制到新表中，原子性地用新表替换旧表，并重新初始化数据字典。

    • 性能模式，INFORMATION_SCHEMA 和 ndbinfo。

  • 步骤 2：服务器升级。

    此步骤包括所有其他升级任务。 如果现有 MySQL 安装的服务器版本低于新安装的 MySQL 版本，则必须升级其他所有内容：

    • mysql 模式中的系统表（剩余的非数据字典表）。

    • sys 模式。

    • 用户模式。

数据字典升级（步骤 1）是服务器的责任，服务器会在启动时根据需要执行此任务，除非使用阻止其执行的选项。MySQL 8.0.16 中的选项是 --upgrade=NONE，MySQL 8.0.16 之前是 --no-dd-upgrade。

如果数据字典过时但服务器被阻止升级它，服务器将不运行，并���错退出。例如：

[ERROR] [MY-013381] [Server] Server shutting down because upgrade is
required, yet prohibited by the command line option '--upgrade=NONE'.
[ERROR] [MY-010334] [Server] Failed to initialize DD Storage Engine
[ERROR] [MY-010020] [Server] Data Dictionary initialization failed.

MySQL 8.0.16 对步骤 2 的责任发生了一些变化：

  • 在 MySQL 8.0.16 之前，mysql_upgrade 升级性能模式、INFORMATION_SCHEMA 和步骤 2 中描述的对象。预期 DBA 在启动服务器后手动调用 mysql_upgrade。

  • 从 MySQL 8.0.16 开始，服务器执行以前由 mysql_upgrade 处理的所有任务。尽管升级仍然是一个两步操作，但服务器会执行这两步，从而简化了流程。

根据您要升级到的 MySQL 版本，在 原地升级 和 逻辑升级 中的说明指示服务器是否执行所有升级任务，或者您必须在服务器启动后手动调用 mysql_upgrade。

注意

因为服务器在 MySQL 8.0.16 中升级了性能模式、INFORMATION_SCHEMA 和步骤 2 中描述的对象，所以 mysql_upgrade 不再需要，并且在该版本中已被弃用；预计在未来的 MySQL 版本中将其移除。

在 MySQL 8.0.16 之前和之后，步骤 2 中发生的大部分情况是相同的，尽管可能需要不同的命令选项来实现特定效果。

从 MySQL 8.0.16 开始，--upgrade 服务器选项控制服务器在启动时是否以及如何执行自动升级：

  • 没有选项或使用 --upgrade=AUTO，服务器会升级任何被确定为过时的内容（步骤 1 和 2）。

  • 使用 --upgrade=NONE，服务器不执行任何升级（跳过步骤 1 和 2），但如果数据字典必须升级，服务器也会报错退出。服务器不允许使用过时的数据字典运行；服务器要么升级它，要么退出。

  • 使用 --upgrade=MINIMAL，如果需要（步骤 1），服务器将升级数据字典、性能模式和 INFORMATION_SCHEMA。请注意，使用此选项进行升级后，无法启动组复制，因为复制内部依赖的系统表未更新，并且在其他领域也可能出现功能减少的情况。

  • 使用 --upgrade=FORCE，如果需要（步骤 1），服务器将升级数据字典、性能模式和 INFORMATION_SCHEMA，并强制升级其他所有内容（步骤 2）。请注意，使用此选项可能会导致服务器启动时间较长，因为服务器会检查所有模式中的所有对象。

FORCE 用于强制执行第 2 步操作，如果服务器认为这些操作是必要的。 FORCE 与 AUTO 的一个区别是，使用 FORCE 时，如果系统表（如帮助表或时区表）丢失，服务器会重新创建这些表。

以下列表显示了 MySQL 8.0.16 之前的升级命令以及 MySQL 8.0.16 及更高版本的等效命令：

  • 执行正常升级（根据需要执行步骤 1 和 2）：

    • MySQL 8.0.16 之前：mysqld 后跟 mysql_upgrade

    • 截至 MySQL 8.0.16：mysqld

  • 根据需要仅执行步骤 1：

    • MySQL 8.0.16 之前：不可能执行步骤 1 中描述的所有升级任务，同时排除步骤 2 中描述的任务。但是，您可以使用 mysqld 后跟 mysql_upgrade 以 --upgrade-system-tables 和 --skip-sys-schema 选项来避免升级用户模式和 sys 模式。

    • 截至 MySQL 8.0.16：mysqld --upgrade=MINIMAL

  • 根据需要执行第 1 步，并强制执行第 2 步：

    • MySQL 8.0.16 之前：mysqld 后跟 mysql_upgrade --force

    • 截至 MySQL 8.0.16：mysqld --upgrade=FORCE

MySQL 8.0.16 之前，某些 mysql_upgrade 选项会影响其执行的操作。以下表格显示了截至 MySQL 8.0.16，要实现类似效果应使用哪些服务器 --upgrade 选项值。（这些不一定是确切的等效值，因为给定的 --upgrade 选项值可能具有额外效果。）

mysql_upgrade 选项服务器选项
--skip-sys-schema--upgrade=NONE 或 --upgrade=MINIMAL
--upgrade-system-tables--upgrade=NONE 或 --upgrade=MINIMAL
--force--upgrade=FORCE

升级步骤 2 的附加说明：

  • 步骤 2 会安装sys模式（如果尚未安装），否则将其升级到当前版本。如果存在sys模式但没有version视图，则会出现错误，因为缺少version视图表明这是用户创建的模式：

    A sys schema exists with no sys.version view. If
you have a user created sys schema, this must be renamed for the
upgrade to succeed.

    在这种情况下进行升级，首先删除或重命名现有的sys模式。然后再次执行升级过程。（可能需要强制执行步骤 2。）

    为了防止sys模式检查：

    • 截至 MySQL 8.0.16：使用--upgrade=NONE或--upgrade=MINIMAL选项启动服务器。

    • 在 MySQL 8.0.16 之前：使用--skip-sys-schema选项调用mysql_upgrade。

  • 步骤 2 会升级系统表以确保其具有当前结构。无论是服务器还是mysql_upgrade执行该步骤都是如此。关于帮助表和时区表的内容，mysql_upgrade不会加载任何类型的表，而服务器会加载帮助表，但不会加载时区表。（即，在 MySQL 8.0.16 之前，服务器仅在数据目录初始化时加载帮助表。从 MySQL 8.0.16 开始，它在初始化和升级时加载帮助表。）加载时区表的过程取决于平台，并且需要由 DBA 做出决策，因此无法自动完成。

  • 从 MySQL 8.0.30 开始，当第 2 步升级mysql模式中的系统表时，mysql.db、mysql.tables_priv、mysql.columns_priv和mysql.procs_priv表的主键中的列顺序被更改为将主机名和用户名列放在一起。将主机名和用户名放在一起意味着可以使用索引查找，这提高了CREATE USER、DROP USER和RENAME USER语句的性能，以及对具有多个权限的多个用户进行 ACL 检查。如果系统具有大量用户和权限，则需要删除并重新创建索引，这可能需要一些时间。

  • 第 2 步根据需要处理所有用户模式中的所有表。表检查可能需要很长时间才能完成。在处理表时，每个表都会被锁定，因此在处理过程中对其他会话不可用。检查和修复操作可能需要很长时间，特别是对于大表。表检查使用CHECK TABLE语句的FOR UPGRADE选项。有关此选项的详细信息，请参见第 15.7.3.2 节，“CHECK TABLE Statement”。

    要防止表检查：

    • 截至 MySQL 8.0.16 版本：使用--upgrade=NONE或--upgrade=MINIMAL选项启动服务器。

    • 在 MySQL 8.0.16 版本之前：使用--upgrade-system-tables选项调用mysql_upgrade。

    要强制进行表检查：

    • 截至 MySQL 8.0.16 版本：使用--upgrade=FORCE选项启动服务器。

    • 在 MySQL 8.0.16 版本之前：使用--force选项调用mysql_upgrade。

  • 第 2 步将 MySQL 版本号保存在名为mysql_upgrade_info的文件中，该文件位于数据目录中。

    要忽略mysql_upgrade_info文件并执行检查，请执行以下操作：

    • 截至 MySQL 8.0.16 版本：使用--upgrade=FORCE选项启动服务器。

    • 在 MySQL 8.0.16 版本之前：使用--force选项调用mysql_upgrade。

    注意

    mysql_upgrade_info文件已被弃用；预计将在 MySQL 的未来版本中删除。

  • 第 2 步使用当前 MySQL 版本号标记所有已检查和修复的表。这确保了下次使用相同版本的服务器进行升级检查时，可以确定是否需要再次检查或修复给定的表。

3.5 MySQL 8.0 的变化

原文：dev.mysql.com/doc/refman/8.0/en/upgrading-from-previous-series.html

在升级到 MySQL 8.0 之前，请查看本节中描述的更改，以确定哪些适用于您当前的 MySQL 安装和应用程序。执行任何建议的操作。

标记为不兼容更改的更改与早期版本的 MySQL 不兼容，并且可能需要您在升级之前注意。我们的目标是避免这些更改，但偶尔它们是必要的，以纠正比版本之间的不兼容性更糟糕的问题。如果适用于您的安装的升级问题涉及不兼容性，请按照描述中给出的说明操作。

  • 数据字典变化

  • 将 caching_sha2_password 作为首选身份验证插件

  • 配置更改

  • 服务器更改

  • InnoDB 变化

  • SQL 更改

  • 更改的服务器默认值

  • 有效性能回归

数据字典变化

MySQL Server 8.0 包含一个全局数据字典，其中包含事务表中数据库对象的信息。在以前的 MySQL 系列中，字典数据存储在元数据文件和非事务系统表中。因此，升级过程要求您通过检查特定先决条件来验证安装的升级准备情况。有关更多信息，请参见第 3.6 节，“准备升级安装”。启用数据字典的服务器存在一些一般操作上的差异；请参见第 16.7 节，“数据字典使用差异”。

将 caching_sha2_password 作为首选身份验证插件

caching_sha2_password 和 sha256_password 认证插件提供比 mysql_native_password 插件更安全的密码加密，而 caching_sha2_password 提供比 sha256_password 更好的性能。由于 caching_sha2_password 具有卓越的安全性和性能特性，因此从 MySQL 8.0 开始，它是首选的认证插件，并且也是默认的认证插件，而不是 mysql_native_password。这一变化影响了服务器和 libmysqlclient 客户端库：

  • 对于服务器，default_authentication_plugin 系统变量的默认值从 mysql_native_password 更改为 caching_sha2_password。

    这一变化仅适用于安装或升级到 MySQL 8.0 或更高版本后创建的新帐户。对于已存在于升级安装中的帐户，它们的认证插件保持不变。希望切换到 caching_sha2_password 的现有用户可以使用 ALTER USER 语句进行切换：

    ALTER USER *user*
  IDENTIFIED WITH caching_sha2_password
  BY '*password*';

  • libmysqlclient 库将 caching_sha2_password 视为默认的认证插件，而不是 mysql_native_password。

以下部分讨论了 caching_sha2_password 更显著角色的影响：

  • caching_sha2_password 兼容性问题和解决方案

  • caching_sha2_password 兼容的客户端和连接器

  • caching_sha2_password 和 root 管理员帐户

  • caching_sha2_password 和复制

caching_sha2_password 兼容性问题和解决方案

重要

如果您的 MySQL 安装必须为 8.0 之前的客户端提供服务，并且在升级到 MySQL 8.0 或更高版本后遇到兼容性问题，解决这些问题并恢复到 8.0 之前的兼容性的最简单方法是重新配置服务器以恢复到先前的默认认证插件 (mysql_native_password)。例如，在服务器选项文件中使用以下行：

[mysqld]
default_authentication_plugin=mysql_native_password

该设置使得 8.0 之前的客户端可以连接到 8.0 服务器，直到您的安装中使用的客户端和连接器升级以了解caching_sha2_password为止。然而，该设置应被视为临时解决方案，而不是长期或永久解决方案，因为在该设置生效时创建的新帐户将放弃caching_sha2_password提供的改进的身份验证安全性。

使用caching_sha2_password比mysql_native_password提供更安全的密码哈希（以及随之改进的客户端连接身份验证）。然而，它也具有兼容性影响，可能会影响现有的 MySQL 安装：

  • 客户端和连接器如果没有更新以了解caching_sha2_password，可能会在连接到配置了caching_sha2_password作为默认身份验证插件的 MySQL 8.0 服务器时遇到问题，即使是使用不使用caching_sha2_password进行身份验证的帐户也是如此。这个问题的原因是服务器向客户端指定了其默认身份验证插件的名称。如果客户端或连接器基于一个不能优雅处理未识别的默认身份验证插件的客户端/服务器协议实现，可能会出现以下错误之一：

    Authentication plugin 'caching_sha2_password' is not supported

    Authentication plugin 'caching_sha2_password' cannot be loaded:
dlopen(/usr/local/mysql/lib/plugin/caching_sha2_password.so, 2):
image not found

    Warning: mysqli_connect(): The server requested authentication
method unknown to the client [caching_sha2_password]

    有关编写连接器以优雅处理服务器对未知默认身份验证插件的请求的信息，请参见身份验证插件连接器编写注意事项。

  • 使用一个使用caching_sha2_password进行身份验证的帐户的客户端必须使用安全连接（使用 TLS/SSL 凭据通过 TCP 进行连接，一个 Unix 套接字文件，或共享内存），或者支持使用 RSA 密钥对进行密码交换的未加密连接。这个安全要求不适用于mysql_native_passsword，因此切换到caching_sha2_password可能需要额外的配置（参见 8.4.1.2 节，“Caching SHA-2 Pluggable Authentication”）。然而，在 MySQL 8.0 中，默认情况下客户端连接更倾向于使用 TLS/SSL，因此已经符合该偏好的客户端可能不需要额外的配置。

  • 未更新以了解caching_sha2_password的客户端和连接器无法连接到使用caching_sha2_password进行身份验证的账户，因为它们不认可此插件为有效。（这是客户端/服务器认证插件兼容性要求的一个特殊实例，如认证插件客户端/服务器兼容性中所讨论的。）要解决此问题，请重新链接客户端到 MySQL 8.0 或更高版本的libmysqlclient，或获取一个识别caching_sha2_password的更新连接器。

  • 因为caching_sha2_password现在也是libmysqlclient客户端库中的默认认证插件，所以从 MySQL 8.0 客户端连接到使用mysql_native_password（之前的默认认证插件）的账户时，认证需要在客户端/服务器协议中进行额外的往返，除非客户端程序使用--default-auth=mysql_native_password选项调用。

用于 8.0 之前 MySQL 版本的libmysqlclient客户端库能够连接到 MySQL 8.0 服务器（除了使用caching_sha2_password进行身份验证的账户）。这意味着基于libmysqlclient的 8.0 之前的客户端也应该能够连接。例如：

  • 标准的 MySQL 客户端，如mysql和mysqladmin都是基于libmysqlclient。

  • Perl DBI 的 DBD::mysql 驱动程序是基于libmysqlclient的。

  • MySQL Connector/Python 具有基于libmysqlclient的 C 扩展模块。要使用它，请在连接时包含use_pure=False选项。

当现有的 MySQL 8.0 安装升级到 MySQL 8.0.4 或更高版本时，一些较旧的基于libmysqlclient的客户端可能会“自动”升级，因为它们是动态链接的，因此它们使用升级安装的新客户端库。例如，如果 Perl DBI 的 DBD::mysql 驱动程序使用动态链接，它可以在升级到 MySQL 8.0.4 或更高版本后直接使用libmysqlclient，结果如下：

  • 在升级之前，使用 DBD::mysql 的 DBI 脚本可以连接到 MySQL 8.0 服务器，除了使用caching_sha2_password进行身份验证的账户。

  • 升级后，相同的脚本也能够使用caching_sha2_password账户。

然而，前述结果发生是因为 MySQL 8.0 安装中 8.0.4 之前的libmysqlclient实例是二进制兼容的：它们都使用共享库主版本号 21。对于链接到来自 MySQL 5.7 或更早版本的libmysqlclient的客户端，它们链接到具有不兼容的不同版本号的共享库。在这种情况下，客户端必须重新编译以便与 MySQL 8.0 服务器和caching_sha2_password帐户完全兼容。

MySQL Connector/J 5.1 至 8.0.8 能够连接到 MySQL 8.0 服务器，除了使用caching_sha2_password进行身份验证的帐户。（连接器/J 8.0.9 或更高版本需要连接到caching_sha2_password帐户。）

使用除libmysqlclient之外的客户端/服务器协议实现的客户端可能需要升级到了解新身份验证插件的较新版本。例如，在 PHP 中，MySQL 连接通常基于mysqlnd，目前不了解caching_sha2_password。在更新的mysqlnd版本可用之前，使 PHP 客户端连接到 MySQL 8.0 的方法是重新配置服务器，将mysql_native_password恢复为默认身份验证插件，如前所述。

如果客户端或连接器支持显式指定默认身份验证插件的选项，请使用它来命名除caching_sha2_password之外的插件。示例：

  • 一些 MySQL 客户端支持--default-auth选项。（标准 MySQL 客户端，如mysql和mysqladmin支持此选项，但可以成功连接到 8.0 服务器而无需它。但是，其他客户端可能支持类似的选项。如果是这样，值得尝试。）

  • 使用libmysqlclient C API 的程序可以使用MYSQL_DEFAULT_AUTH选项调用mysql_options()函数。

  • 使用客户端/服务器协议的本机 Python 实现的 MySQL Connector/Python 脚本可以指定auth_plugin连接选项。（或者，使用 Connector/Python C 扩展，可以连接到 MySQL 8.0 服务器而无需auth_plugin。）

兼容caching_sha2_password的客户端和连接器

如果有已更新以了解caching_sha2_password的客户端或连接器可用，则使用它是连接到配置为默认身份验证插件为caching_sha2_password的 MySQL 8.0 服务器时确保兼容性的最佳方法。

这些客户端和连接器已升级以支持caching_sha2_password：

  • MySQL 8.0（8.0.4 或更高版本）中的 libmysqlclient 客户端库。标准 MySQL 客户端，如 mysql 和 mysqladmin 基于 libmysqlclient，因此它们也是���容的。

  • MySQL 5.7（5.7.23 或更高版本）中的 libmysqlclient 客户端库。标准 MySQL 客户端，如 mysql 和 mysqladmin 基于 libmysqlclient，因此它们也是兼容的。

  • MySQL Connector/C++ 1.1.11 或更高版本或 8.0.7 或更高版本。

  • MySQL Connector/J 8.0.9 或更高版本。

  • MySQL Connector/NET 8.0.10 或更高版本（通过经典 MySQL 协议）。

  • MySQL Connector/Node.js 8.0.9 或更高版本。

  • PHP：X DevAPI PHP 扩展（mysql_xdevapi）支持 caching_sha2_password。

    PHP：PDO_MySQL 和 ext/mysqli 扩展不支持 caching_sha2_password。此外，当与 PHP 版本 7.1.16 之前的版本和 PHP 7.2 之前的版本一起使用时，即使未使用 caching_sha2_password，它们也无法连接到 default_authentication_plugin=caching_sha2_password。

caching_sha2_password 和 root 管理员帐户

对于升级到 MySQL 8.0，现有帐户的身份验证插件保持不变，包括 'root'@'localhost' 管理员帐户的插件。

对于新的 MySQL 8.0 安装，在初始化数据目录时（使用 第 2.9.1 节，“初始化数据目录” 中的说明），会创建 'root'@'localhost' 帐户，并且该帐户默认使用 caching_sha2_password。因此，在数据目录初始化后连接到服务器时，您必须使用支持 caching_sha2_password 的客户端或连接器。如果您可以这样做，但希望安装后 root 帐户使用 mysql_native_password，请按照通常的方式安装 MySQL 并初始化数据目录。然后连接到服务器作为 root，并使用 ALTER USER 如下更改帐户身份验证插件和密码：

ALTER USER 'root'@'localhost'
  IDENTIFIED WITH mysql_native_password
  BY '*password*';

如果您使用的客户端或连接器尚不支持 caching_sha2_password，则可以使用修改后的数据目录初始化过程，一旦创建帐户，就将 root 帐户与 mysql_native_password 关联起来。为此，可以使用以下任一技术：

  • 在 --initialize 或 --initialize-insecure 选项中提供一个 --default-authentication-plugin=mysql_native_password 选项。

  • 在选项文件中将default_authentication_plugin设置为mysql_native_password，并使用--defaults-file选项命名该选项文件，以及--initialize或--initialize-insecure。 （在这种情况下，如果您继续使用该选项文件进行后续服务器启动，则新帐户将使用mysql_native_password而不是caching_sha2_password创建，除非从选项文件中删除default_authentication_plugin设置。）

caching_sha2_password和复制

对于所有服务器都已升级到 MySQL 8.0.4 或更高版本的复制场景，副本连接到源服务器可以使用使用caching_sha2_password进行身份验证的账户。对于这样的连接，与使用caching_sha2_password进行身份验证的其他客户端相同的要求适用：使用安全连接或基于 RSA 的密码交换。

要连接到用于源/副本复制的caching_sha2_password账户：

  • 使用以下任何一个CHANGE MASTER TO选项：

    MASTER_SSL = 1
GET_MASTER_PUBLIC_KEY = 1
MASTER_PUBLIC_KEY_PATH='*path to RSA public key file*'

  • 或者，如果在服务器启动时提供所需的密钥，则可以使用 RSA 公钥相关选项。

要连接到使用caching_sha2_password账户的组复制：

  • 对于使用 OpenSSL 构建的 MySQL，设置以下任何一个系统变量：

    SET GLOBAL group_replication_recovery_use_ssl = ON;
SET GLOBAL group_replication_recovery_get_public_key = 1;
SET GLOBAL group_replication_recovery_public_key_path = '*path to RSA public key file*';

  • 或者，如果在服务器启动时提供所需的密钥，则可以使用 RSA 公钥相关选项。

配置更改

  • 不兼容更改：MySQL 存储引擎现在负责提供自己的分区处理程序，MySQL 服务器不再提供通用分区支持。InnoDB和NDB是唯一提供本机分区处理程序并在 MySQL 8.0 中受支持的存储引擎。使用任何其他存储引擎的分区表必须在升级服务器之前进行更改，要么将其转换为InnoDB或NDB，要么删除其分区，否则之后无法使用。

    有关将MyISAM表转换为InnoDB的信息，请参见第 17.6.1.5 节，“从 MyISAM 转换表到 InnoDB”。

    在 MySQL 8.0 中，使用不支持的存储引擎创建分区表的表创建语句将失败并显示错误（ER_CHECK_NOT_IMPLEMENTED）。如果您从在 MySQL 5.7（或更早版本）中创建的转储文件中导入数据库到 MySQL 8.0 服务器，请确保任何创建分区表的语句不会同时指定不支持的存储引擎，可以通过删除任何与分区相关的引用，或者将存储引擎指定为InnoDB或允许其默认设置为InnoDB来实现。

    注意

    在第 3.6 节，“准备升级安装”中描述了如何在升级到 MySQL 8.0 之前识别必须更改的分区表的过程。

    有关更多信息，请参阅第 26.6.2 节，“与存储引擎相关的分区限制”。

  • 不兼容更改：几个服务器错误代码未被使用并已被移除（详细列表请参见 MySQL 8.0 中删除的功能）。特别测试任何这些错误代码的应用程序应该进行更新。

  • 重要更改：默认字符集已从latin1更改为utf8mb4。这些系统变量受到影响：

    • character_set_server和character_set_database系统变量的默认值已从latin1更改为utf8mb4。

    • collation_server和collation_database系统变量的默认值已从latin1_swedish_ci更改为utf8mb4_0900_ai_ci。

    因此，除非显式指定字符集和校对规则，否则新对象的默认字符集和校对规则与以前不同。这包括数据库及其中的对象，如表、视图和存储过程。假设以前使用的是默认值，保留它们的一种方法是在my.cnf文件中使用以下行启动服务器：

    [mysqld]
character_set_server=latin1
collation_server=latin1_swedish_ci

    在复制设置中，从 MySQL 5.7 升级到 8.0 时，建议在升级之前将默认字符集更改回 MySQL 5.7 中使用的字符集。升级完成后，可以将默认字符集更改为utf8mb4。

    另外，您应该知道 MySQL 8.0 强制执行对给定字符集中允许字符的检查，而 MySQL 5.7 不执行；这是一个已知问题。这意味着，在尝试升级之前，您应确保没有注释包含未在使用的字符集中定义的字符。您可以通过以下两种方式修复此问题：

    • 将字符集更改为包含相关字符的字符集。

    • 删除有问题的字符或字符。

    上述适用于表、文件和索引注释。

  • 不兼容更改：从 MySQL 8.0.11 开始，禁止使用与服务器初始化时使用的lower_case_table_names设置不同的设置启动服务器。这个限制是必要的，因为各种数据字典表字段使用的校对是基于服务器初始化时定义的lower_case_table_names设置，重新启动服务器使用不同设置会导致标识符的排序和比较出现不一致。

服务器更改

  • 在 MySQL 8.0.11 中，已删除了与帐户管理相关的几个弃用功能，例如使用GRANT语句修改用户帐户的非权限特性，NO_AUTO_CREATE_USER SQL 模式，PASSWORD()函数和old_passwords系统变量。

    从 MySQL 5.7 复制到 8.0 的涉及这些已移除功能的语句可能导致复制失败。使用任何已移除功能的应用程序应进行修订以避免使用它们，并在可能的情况下使用替代方案，如 MySQL 8.0 中已移除的功能中所述。

    为避免在 MySQL 8.0 上启动失败，请从 MySQL 选项文件的sql_mode系统变量设置中删除任何NO_AUTO_CREATE_USER实例。

    将包含NO_AUTO_CREATE_USER SQL 模式的转储文件加载到 MySQL 8.0 服务器中会导致失败。从 MySQL 5.7.24 和 MySQL 8.0.13 开始，mysqldump会从存储程序定义中删除NO_AUTO_CREATE_USER。使用早期版本的mysqldump创建的转储文件必须手动修改以删除NO_AUTO_CREATE_USER的实例。

  • 在 MySQL 8.0.11 中，这些已弃用的兼容性 SQL 模式被移除：DB2、MAXDB、MSSQL、MYSQL323、MYSQL40、ORACLE、POSTGRESQL、NO_FIELD_OPTIONS、NO_KEY_OPTIONS、NO_TABLE_OPTIONS。它们不能再分配给sql_mode系统变量，也不能作为mysqldump --compatible选项的允许值。

    移除MAXDB意味着CREATE TABLE或ALTER TABLE中的TIMESTAMP数据类型不再被视为DATETIME。

    从 MySQL 5.7 到 8.0 的复制中，涉及已移除 SQL 模式的语句可能导致复制失败。这包括在当前sql_mode值包含任何已移除模式的情况下执行的存储程序（存储过程和函数、触发器和事件）的CREATE语句的复制。使用任何已移除模式的应用程序应进行修改以避免使用它们。

  • 许多 MySQL 8.0 错误消息的文本已经修订和改进，提供的信息比 MySQL 5.7 更多更好。如果您的应用程序依赖于特定内容或格式的错误消息，您应该测试这些内容，并准备在升级之前更新应用程序。

  • 截至 MySQL 8.0.3，空间数据类型允许一个SRID属性，明确指示存储在列中的值的空间参考系统（SRS）。参见第 13.4.1 节，“空间数据类型”。

    具有显式SRID属性的空间列是 SRID 受限制的：该列仅接受具有该 ID 的值，并且该列上的SPATIAL索引成为优化器使用的对象。优化器会忽略没有SRID属性的空间列上的SPATIAL索引。参见第 10.3.3 节，“空间索引优化”。如果您希望优化器考虑对没有 SRID 限制的空间列上的SPATIAL索引，应修改每个这样的列：

    • 验证列中的所有值是否具有相同的 SRID。要确定几何列*col_name*中包含的 SRIDs，使用以下查询：

      SELECT DISTINCT ST_SRID(*col_name*) FROM *tbl_name*;

      如果查询返回多行，则该列包含混合的 SRIDs。在这种情况下，修改其内容使所有值具有相同的 SRID。

    • 重新定义列以具有显式SRID属性。

    • 重新创建SPATIAL索引。

  • 由于空间函数命名空间更改实施了执行精确操作的函数的ST_前缀，或者基于最小边界矩形执行操作的函数的MBR前缀，因此在 MySQL 8.0.0 中删除了几个空间函数。在生成列定义中使用已删除的空间函数可能会导致升级失败。在升级之前，运行mysqlcheck --check-upgrade以查找已删除的空间函数，并用它们的ST_或MBR命名的替代函数替换任何找到的函数。有关已删除的空间函数列表，请参考 MySQL 8.0 中删除的功能。

  • 当进行就地升级到 MySQL 8.0.3 或更高版本时，具有RELOAD权限的用户会自动被授予BACKUP_ADMIN权限。

  • 从 MySQL 8.0.13 开始，由于基于行或混合复制模式与基于语句的复制模式在处理临时表的方式上的差异，切换二进制日志格式在运行时有了新的限制。

    • 如果会话有任何打开的临时表，则不能使用SET @@SESSION.binlog_format。

    • 如果任何复制通道有任何打开的临时表，则不能使用SET @@global.binlog_format和SET @@persist.binlog_format。如果复制通道有打开的临时表，则允许使用SET @@persist_only.binlog_format，因为与PERSIST不同，PERSIST_ONLY不会修改运行时全局系统变量值。

    • 如果任何复制通道应用程序正在运行，则不能使用SET @@global.binlog_format和SET @@persist.binlog_format。这是因为更改仅在复制通道的应用程序重新启动时生效，此时复制通道可能有打开的临时表。这种行为比以前更为严格。如果任何复制通道应用程序正在运行，则允许使用SET @@persist_only.binlog_format。

    • 从 MySQL 8.0.27 开始，为internal_tmp_mem_storage_engine配置会话设置需要SESSION_VARIABLES_ADMIN或SYSTEM_VARIABLES_ADMIN权限。

    • 截至 MySQL 8.0.27 版本，克隆插件允许在捐赠者 MySQL 服务器实例上进行并发 DDL 操作，同时克隆操作正在进行中。以前，在克隆操作期间会持有备份锁，阻止捐赠者上的并发 DDL。要恢复到在克隆操作期间阻止捐赠者上的并发 DDL 的先前行为，请启用 clone_block_ddl 变量。参见 第 7.6.7.4 节，“克隆和并发 DDL”。

  • 从 MySQL 8.0.30 版本开始，在启动时列出的 log_error_services 值中的错误日志组件将在 MySQL 服务器启动序列的早期隐式加载。如果您以前使用 INSTALL COMPONENT 安装了可加载的错误日志组件，并且您在启动时列出了这些组件（例如，从选项文件中读取的 log_error_services 设置），则应更新配置以避免启动警告。有关更多信息，请参见 错误日志配置方法。

InnoDB 更改

  • 基于 InnoDB 系统表的 INFORMATION_SCHEMA 视图已被内部数据字典表上的内部系统视图所取代。受影响的 InnoDB INFORMATION_SCHEMA 视图已更名为：

    表 3.1 重命名的 InnoDB 信息模式视图

    旧名称新名称
    INNODB_SYS_COLUMNSINNODB_COLUMNS
    INNODB_SYS_DATAFILESINNODB_DATAFILES
    INNODB_SYS_FIELDSINNODB_FIELDS
    INNODB_SYS_FOREIGNINNODB_FOREIGN
    INNODB_SYS_FOREIGN_COLSINNODB_FOREIGN_COLS
    INNODB_SYS_INDEXESINNODB_INDEXES
    INNODB_SYS_TABLESINNODB_TABLES
    INNODB_SYS_TABLESPACESINNODB_TABLESPACES
    INNODB_SYS_TABLESTATSINNODB_TABLESTATS
    INNODB_SYS_VIRTUALINNODB_VIRTUAL
    旧名称新名称

    升级到 MySQL 8.0.3 或更高版本后，请更新任何引用先前 InnoDB INFORMATION_SCHEMA 视图名称的脚本。

  • MySQL 捆绑的 zlib 库版本从 1.2.3 版升级到 1.2.11 版。

    zlib 1.2.11 中的 zlib compressBound()函数返回的压缩给定长度字节所需的缓冲区大小的估计比 zlib 版本 1.2.3 中的估计略高。compressBound()函数由确定在创建压缩的InnoDB表或在压缩的InnoDB表中插入和更新行时允许的最大行大小的InnoDB函数调用。因此，与早期版本中成功的最大行大小非常接近的CREATE TABLE ... ROW_FORMAT=COMPRESSED，INSERT和UPDATE操作现在可能会失败。为避免此问题，在升级之前，在 MySQL 8.0 测试实例上测试具有大行的压缩InnoDB表的CREATE TABLE语句。

  • 随着--innodb-directories功能的引入，使用绝对路径创建的文件表和通用表空间文件或位于数据目录之外的位置应添加到innodb_directories参数值中。否则，在恢复过程中，InnoDB将无法定位这些文件。要查看表空间文件位置，请查询 Information Schema FILES表：

    SELECT TABLESPACE_NAME, FILE_NAME FROM INFORMATION_SCHEMA.FILES \G

  • 撤销日志不再可以驻留在系统表空间中。在 MySQL 8.0 中，默认情况下，撤销日志驻留在两个 undo 表空间中。有关更多信息，请参见第 17.6.3.4 节，“Undo Tablespaces”。

    当从 MySQL 5.7 升级到 MySQL 8.0 时，MySQL 5.7 实例中存在的任何 undo 表空间都将被删除，并由两个新的默认 undo 表空间替换。默认的 undo 表空间是在innodb_undo_directory变量定义的位置创建的。如果innodb_undo_directory变量未定义，则 undo 表空间将在数据目录中创建。从 MySQL 5.7 升级到 MySQL 8.0 需要进行缓慢关闭，以确保 MySQL 5.7 实例中的 undo 表空间为空，从而可以安全地删除它们。

    从较早的 MySQL 8.0 版本升级到 MySQL 8.0.14 或更高版本时，作为 innodb_undo_tablespaces 设置大于 2 的结果存在于升级前实例中的撤销表空间被视为用户定义的撤销表空间，可以在升级后使用 ALTER UNDO TABLESPACE 和 DROP UNDO TABLESPACE 语法分别停用和删除。在 MySQL 8.0 版本系列内进行升级可能不总是需要慢速关闭，这意味着现有的撤销表空间可能包含撤销日志。因此，升级过程不会删除现有的撤销表空间。

  • 不兼容更改：从 MySQL 8.0.17 开始，CREATE TABLESPACE ... ADD DATAFILE 子句不允许循环目录引用。例如，以下语句中的循环目录引用 (/../) 是不允许的：

    CREATE TABLESPACE ts1 ADD DATAFILE ts1.ibd '*any_directory*/../ts1.ibd';

    在 Linux 上存在对限制的例外情况，如果前面的目录是符号链接，则允许循环目录引用。例如，如果上面示例中的数据文件路径是 any_directory 是符号链接，则允许。 (数据文件路径仍然可以以 '../' 开头。)

    为避免升级问题，在升级到 MySQL 8.0.17 或更高版本之前，请从表空间数据文件路径中删除任何循环目录引用。要检查表空间路径，请查询信息模式 INNODB_DATAFILES 表。

  • 由于 MySQL 8.0.14 引入的一个回归，从 MySQL 5.7 或 MySQL 8.0.14 之前的 MySQL 8.0 版本在区分大小写文件系统上进行原地升级到 MySQL 8.0.16 时，对于具有分区表和 lower_case_table_names=1 的实例会失败。失败是由于与分区表文件名相关的大小写不匹配问题引起的。导致回归的修复已被撤销，这允许从 MySQL 5.7 或 MySQL 8.0.14 之前的 MySQL 8.0 版本升级到 MySQL 8.0.17 以正常运行。然而，回归仍然存在于 MySQL 8.0.14、8.0.15 和 8.0.16 版本中。

    在从 MySQL 8.0.14、8.0.15 或 8.0.16 升级到 MySQL 8.0.17 的区分大小写文件系统上进行原地升级时，如果存在分区表且 lower_case_table_names=1，在升级二进制文件或软件包到 MySQL 8.0.17 后启动服务器时会出现以下错误：

    Upgrading from server version *version_number* with
partitioned tables and lower_case_table_names == 1 on a case sensitive file
system may cause issues, and is therefore prohibited. To upgrade anyway, restart
the new server version with the command line option 'upgrade=FORCE'. When
upgrade is completed, please execute 'RENAME TABLE *part_table_name*
TO *new_table_name*; RENAME TABLE *new_table_name*
TO *part_table_name*;' for each of the partitioned tables.
Please see the documentation for further information.

    如果在升级到 MySQL 8.0.17 时遇到此错误，请执行以下解决方法：

    1. 使用 --upgrade=force 重新启动服务器以强制进行升级操作。

    2. 识别具有小写分区名称分隔符 (#p# 或 #sp#）的分区表文件名：

      mysql> SELECT FILE_NAME FROM INFORMATION_SCHEMA.FILES WHERE FILE_NAME LIKE '%#p#%' OR FILE_NAME LIKE '%#sp#%';

    3. 对于每个识别的文件，将相关表重命名为临时名称，然后将表重新命名为原始名称。

      mysql> RENAME TABLE *table_name* TO *temporary_table_name*;
mysql> RENAME TABLE *temporary_table_name* TO *table_name*;

    4. 确保没有具有小写分区名称分隔符的分区表文件名（应返回空结果集）。

      mysql> SELECT FILE_NAME FROM INFORMATION_SCHEMA.FILES WHERE FILE_NAME LIKE '%#p#%' OR FILE_NAME LIKE '%#sp#%';
Empty set (0.00 sec)

    5. 在每个重命名的表上运行 ANALYZE TABLE 以更新 mysql.innodb_index_stats 和 mysql.innodb_table_stats 表中的优化器统计信息。

    由于 MySQL 8.0.14、8.0.15 和 8.0.16 版本中仍存在的回归，从 MySQL 8.0.14、8.0.15 或 8.0.16 导入分区表到 MySQL 8.0.17 在 lower_case_table_names=1 的区分大小写文件系统上不受支持。尝试这样做会导致“表空间缺失于表”错误。

  • MySQL 在构建表分区的表空间名称和文件名时使用分隔符字符串。一个“ #p# ”分隔符字符串位于分区名称之前，一个“ #sp# ”分隔符字符串位于子分区名称之前，如下所示：

     *schema_name*.*table_name*#p#*partition_name*#sp#*subpartition_name*
      *table_name*#p#*partition_name*#sp#*subpartition_name*.ibd

    历史上，在诸如 Linux 等区分大小写的文件系统上，分隔符字符串为大写（#P# 和 #SP#），而在诸如 Windows 等不区分大小写的文件系统上为小写（#p# 和 #sp#）。从 MySQL 8.0.19 开始，分隔符字符串在所有文件系统上都为小写。此更改可防止在区分大小写和不区分大小写的文件系统之间迁移数据目录时出现问题。不再使用大写分隔符字符串。

    另外，基于用户指定的分区或子分区名称生成的分区表空间名称和文件名，无论 lower_case_table_names 设置如何，现在都会生成（并在内部存储）为小写，以确保不区分大小写。例如，如果创建了一个名为 PART_1 的表分区，则表空间名称和文件名将以小写形式生成：

     *schema_name*.*table_name*#p#*part_1*
      *table_name*#p#*part_1*.ibd

    在升级期间，MySQL 检查并根据需要修改：

    • 在磁盘上和数据字典中识别分区表文件名，以确保小写分隔符和分区名称。

    • 数据字典中的分区元数据，以解决之前 bug 修复引入的相关问题。

    • InnoDB 统计数据用于之前 bug 修复引入的相关问题。

    在表空间导入操作期间，会检查并根据需要修改磁盘上的分区表空间文件名，以确保小写分隔符和分区名称。

  • 从 MySQL 8.0.21 开始，在启动时或从 MySQL 5.7 升级时，如果发现表空间数据文件位于未知目录中，将向错误日志写入警告。已知目录是由datadir、innodb_data_home_dir和innodb_directories变量定义的目录。要使目录成为已知目录，请将其添加到innodb_directories设置中。使目录成为已知目录可确保在恢复期间可以找到数据文件。有关更多信息，请参见崩溃恢复期间的表空间发现。

  • 重要变更：从 MySQL 8.0.30 开始，innodb_redo_log_capacity变量控制重做日志文件占用的磁盘空间量。随着这一变更，默认的重做日志文件数量和位置也发生了变化。从 MySQL 8.0.30 开始，InnoDB在数据目录中的#innodb_redo目录中维护 32 个重做日志文件。以前，InnoDB默认在数据目录中创建两个重做日志文件，并且重做日志文件的数量和大小由innodb_log_files_in_group和innodb_log_file_size变量控制。这两个变量现已弃用。

    当定义了innodb_redo_log_capacity设置时，将忽略innodb_log_files_in_group和innodb_log_file_size设置；否则，将使用这些设置来计算innodb_redo_log_capacity设置（innodb_log_files_in_group * innodb_log_file_size = innodb_redo_log_capacity）。如果这些变量都没有设置，则重做日志容量将设置为innodb_redo_log_capacity的默认值，即 104857600 字节（100MB）。

    与任何升级一样，此更改在升级之前需要干净的关闭。

    有关此功能的更多信息，请参见第 17.6.5 节，“重做日志”。

  • 在 MySQL 5.7.35 之前，具有冗余或紧凑行格式的表中的索引没有大小限制。从 MySQL 5.7.35 开始，限制为 767 字节。从 MySQL 5.7.35 之前的 MySQL 版本升级到 MySQL 8.0 可能会导致无法访问的表。如果具有冗余或紧凑行格式的表的索引大于 767 字节，请在升级到 MySQL 8.0 之前删除索引并重新创建。错误消息为：

    mysql> ERROR 1709 (HY000): Index column size too large. The maximum column size is 767 bytes.

SQL 变更

  • 不兼容更改：从 MySQL 8.0.13 开始，已删除了对 GROUP BY 子句的已弃用 ASC 或 DESC 修饰符。先前依赖于 GROUP BY 排序的查询可能会产生与先前 MySQL 版本不同的结果。为了产生给定的排序顺序，请提供一个 ORDER BY 子句。

    从 MySQL 8.0.12 或更低版本中使用 ASC 或 DESC 修饰符进行 GROUP BY 子句的查询和存储程序定义应进行修改。否则，升级到 MySQL 8.0.13 或更高版本可能会失败，复制到 MySQL 8.0.13 或更高版本的复制服务器也可能失败。

  • 在 MySQL 8.0 中可能会保留一些在 MySQL 5.7 中未保留的关键字。请参阅第 11.3 节，“关键字和保留字”。这可能导致先前用作标识符的单词变得非法。要修复受影响的语句，请使用标识符引用。请参阅第 11.2 节，“模式对象名称”。

  • 升级后，建议测试应用程序代码中指定的优化器提示，以确保这些提示仍然需要实现所需的优化策略。优化器增强有时可能使某些优化器提示变得不必要。在某些情况下，不必要的优化器提示甚至可能适得其反。

  • 不兼容更改：在 MySQL 5.7 中，为 InnoDB 表指定 FOREIGN KEY 定义而不带 CONSTRAINT *symbol* 子句，或者指定 CONSTRAINT 关键字而不带 symbol，会导致 InnoDB 使用生成的约束名。在 MySQL 8.0 中，InnoDB 的行为发生了变化，使用 FOREIGN KEY *index_name* 值而不是生成的名称。由于约束名必须在模式（数据库）中唯一，这种更改导致由于外键索引名称在模式中不唯一而导致错误。为避免此类错误，新的约束命名行为已在 MySQL 8.0.16 中恢复，InnoDB 再次使用生成的约束名。

    为了与 InnoDB 保持一致，基于 MySQL 8.0.16 或更高版本的 NDB 发行版如果未指定 CONSTRAINT *symbol* 子句，或者指定 CONSTRAINT 关键字而不带 symbol，则使用生成的约束名。基于 MySQL 5.7 和早期 MySQL 8.0 发行版的 NDB 发行版使用 FOREIGN KEY *index_name* 值。

    上述描述的更改可能会对依赖于先前外键约束命名行为的应用程序造成不兼容性。

  • MySQL 8.0 中的系统变量值处理方式已更改，例如 IFNULL() 和 CASE() 等 MySQL 流控制函数；现在系统变量值被视为相同字符和排序规则的列值，而不是常量。一些使用这些函数与系统变量的查询可能会被拒绝，出现 Illegal mix of collations。在这种情况下，将系统变量转换为正确的字符集和排序规则。

  • 不兼容的更改：MySQL 8.0.28 修复了先前 MySQL 8.0 版本中的问题，即 CONVERT() 函数有时允许将 BINARY 值无效地转换为非二进制字符集。可能依赖于此行为的应用程序应在升级之前进行检查，并在必要时进行修改。

    特别是，在索引生成列的表达式中使用 CONVERT()，函数行为的更改可能导致在升级到 MySQL 8.0.28 之后索引损坏。您可以通过以下步骤防止这种情况发生：

    1. 在执行升级之前，纠正任何无效的输入数据。

    2. 删除然后重新创建索引。

      您还可以使用 ALTER TABLE *table* FORCE 强制重建表。

    3. 升级 MySQL 软件。

    如果您无法事先验证输入数据，则在升级到 MySQL 8.0.28 之后，不应重新创建索引或重建表。

更改的服务器默认值

MySQL 8.0 提供了改进的默认值，旨在为大多数用户提供最佳的开箱即用体验。这些变化是由于技术的进步（机器拥有更多 CPU，使用 SSD 等），存储的数据更多，MySQL 正在发展（InnoDB，Group Replication，AdminAPI）等。以下表格总结了已更改的默认值，以为大多数用户提供最佳的 MySQL 体验。

选项/参数旧默认值新默认值
服务器更改
character_set_serverlatin1utf8mb4
collation_serverlatin1_swedish_ciutf8mb4_0900_ai_ci
explicit_defaults_for_timestampOFFON
optimizer_trace_max_mem_size16KB1MB
validate_password_check_user_nameOFFON
back_log-1 (autosize) changed from : back_log = 50 + (max_connections / 5)-1 (autosize) changed to : back_log = max_connections
max_allowed_packet4194304 (4MB)67108864 (64MB)
max_error_count641024
event_schedulerOFFON
table_open_cache20004000
log_error_verbosity3 (Notes)2 (Warning)
local_infileON (5.7)OFF
InnoDB 更改
innodb_undo_tablespaces02
innodb_undo_log_truncateOFFON
innodb_flush_methodNULLfsync (Unix), unbuffered (Windows)
innodb_autoinc_lock_mode1 (consecutive)2 (interleaved)
innodb_flush_neighbors1 (enable)0 (disable)
innodb_max_dirty_pages_pct_lwm0 (%)10 (%)
innodb_max_dirty_pages_pct75 (%)90 (%)
性能模式更改
performance-schema-instrument='wait/lock/metadata/sql/%=ON'OFFON
performance-schema-instrument='memory/%=COUNTED'OFFCOUNTED
performance-schema-consumer-events-transactions-current=ONOFFON
performance-schema-consumer-events-transactions-history=ONOFFON
performance-schema-instrument='transaction%=ON'OFFON
复制更改
log_binOFFON
server_id01
log-slave-updatesOFFON
expire_logs_days030
master-info-repositoryFILETABLE
relay-log-info-repositoryFILETABLE
transaction-write-set-extractionOFFXXHASH64
slave_rows_search_algorithmsINDEX_SCAN, TABLE_SCANINDEX_SCAN, HASH_SCAN
slave_pending_jobs_size_max16M128M
gtid_executed_compression_period10000
组复制更改
group_replication_autorejoin_tries03
group_replication_exit_state_actionABORT_SERVERREAD_ONLY
group_replication_member_expel_timeout05
选项/参数旧默认值新默认值

有关已添加的选项或变量的更多信息，请参阅 MySQL 8.0 的选项和变量更改，在MySQL 服务器版本参考中。

以下部分解释了默认值的更改以及它们可能对您的部署产生的影响。

服务器默认值

  • character_set_server系统变量和命令行选项--character-set-server的默认值从latin1更改为utf8mb4。这是服务器的默认字符集。目前，UTF8MB4 是网络的主要字符编码，这一变化使得绝大多数 MySQL 用户的生活更加便利。从 5.7 升级到 8.0 不会更改任何现有数据库对象的字符集，但是，除非您明确设置character_set_server（要么回到以前的值，要么设置为新值），否则新模式默认使用utf8mb4。我们建议尽可能迁移到utf8mb4。

  • collation_server系统变量和命令行参数--collation-server的默认值从latin1_swedish_ci更改为utf8mb4_0900_ai_ci。这是服务器的默认排序规则，即字符集中字符的排序。排序规则和字符集之间存在链接，因为每个字符集都有可能的排序规则列表。从 5.7 升级到 8.0 不会更改任何现有数据库对象的排序规则，但会影响新对象。

  • explicit_defaults_for_timestamp系统变量的默认值从OFF（MySQL 传统行为）更改为ON（SQL 标准行为）。此选项最初在 5.6 中引入，在 5.6 和 5.7 中为OFF。

  • optimizer_trace_max_mem_size系统变量的默认值从16KB更改为1MB。旧默认值会导致对于任何非平凡查询，优化器跟踪被截断。这一变化确保了大多数查询的优化器跟踪是有用的。

  • validate_password_check_user_name系统变量的默认值从OFF更改为ON。这意味着当启用validate_password插件时，默认情况下现在拒绝与当前会话用户名匹配的密码。

  • back_log系统变量的自动调整算法已更改。自动调整值（-1）现在设置为max_connections的值，这比由50 + (max_connections / 5)计算的值大。back_log在服务器无法跟上传入请求的情况下排队传入的 IP 连接请求。在最坏的情况下，例如在网络故障后，有max_connections数量的客户端尝试重新连接时，它们都可以被缓冲，并且避免了拒绝重试循环。

  • max_allowed_packet系统变量的默认值从4194304（4M）更改为67108864（64M）。这个更大的默认值的主要优点是减少接收关于插入或查询大于max_allowed_packet的错误的机会。它应该与您想要使用的最大第 13.3.4 节，“BLOB 和 TEXT 类型”一样大。要恢复到以前的行为，请设置max_allowed_packet=4194304。

  • max_error_count系统变量的默认值从64更改为1024。这确保了 MySQL 处理更多警告，例如触及数千行并且其中许多行给出转换警告的 UPDATE 语句。许多工具通常会批量更新，以帮助减少复制延迟。外部工具如 pt-online-schema-change 默认为 1000，gh-ost 默认为 100。MySQL 8.0 覆盖了这两种用例的完整错误历史。没有静态分配，因此此更改仅影响生成大量警告的语句的内存消耗。

  • event_scheduler系统变量的默认值从OFF更改为ON。换句话说，默认情况下启用事件调度程序。这是 SYS 中新功能的启用程序，例如“终止空闲事务”。

  • table_open_cache系统变量的默认值从2000更改为4000。这是一个增加表访问会话并发性的微小更改。

  • log_error_verbosity系统变量的默认值从3（Notes）更改为2（Warning）。目的是使 MySQL 8.0 错误日志默认情况下更少冗长。

InnoDB 默认值

  • 不兼容的更改 innodb_undo_tablespaces系统变量的默认值从0更改为2。这配置了 InnoDB 使用的撤销表空间的数量。在 MySQL 8.0 中，innodb_undo_tablespaces的最小值为 2，回滚段不再可以在系统表空间中创建。因此，这是一个您无法恢复到 5.7 行为的情况。这个更改的目的是能够自动截断 Undo 日志（见下一项），回收像mysqldump这样的（偶尔的）长事务使用的磁盘空间。

  • innodb_undo_log_truncate系统变量的默认值从OFF更改为ON。启用后，超过innodb_max_undo_log_size定义的阈值的撤销表空间将被标记为截断。只有撤销表空间可以被截断。不支持截断位于系统表空间中的撤销日志。从 5.7 升级到 8.0 会自动将系统转换为使用撤销表空间，8.0 中不再支持使用系统表空间。

  • innodb_flush_method系统变量的默认值在 Unix-like 系统上从NULL更改为fsync，在 Windows 系统上从NULL更改为unbuffered。这更多是术语和选项的清理，没有任何实质性影响。对于 Unix 来说，这只是一个文档更改，因为默认值在 5.7 中也是fsync（默认的NULL意味着fsync）。同样，在 Windows 上，innodb_flush_method默认的NULL在 5.7 中意味着async_unbuffered，在 8.0 中被默认的unbuffered替换，这与现有的默认innodb_use_native_aio=ON具有相同的效果。

  • 不兼容的更改 innodb_autoinc_lock_mode系统变量的默认值从1（连续）更改为2（交错）。将交错锁定模式作为默认设置的更改反映了从基于语句到基于行的复制作为默认复制类型的更改，该更改发生在 MySQL 5.7 中。基于语句的复制需要连续的自增锁定模式，以确保自增值按照可预测和可重复的顺序分配给给定序列的 SQL 语句，而基于行的复制不受 SQL 语句执行顺序的影响。因此，这一更改已知与基于语句的复制不兼容，并可能破坏一些依赖于顺序自增的应用程序或用户生成的测试套件。可以通过设置innodb_autoinc_lock_mode=1;来恢复先前的默认值。

  • innodb_flush_neighbors系统变量的默认值从1（启用）更改为0（禁用）。这是因为快速 IO（SSD）现在是部署的默认设置。我们预计对于大多数用户，这将带来轻微的性能提升。使用较慢硬盘的用户可能会看到性能下降，并鼓励他们通过设置innodb_flush_neighbors=1来恢复到先前的默认值。

  • innodb_max_dirty_pages_pct_lwm系统变量的默认值从0 (%)更改为10 (%)。当innodb_max_dirty_pages_pct_lwm=10时，InnoDB 在缓冲池中包含修改（'脏'）页面超过 10%时增加其刷新活动。这一变化的目的是略微降低峰值吞吐量，以换取更一致的性能。

  • innodb_max_dirty_pages_pct系统变量的默认值从75 (%)更改为90 (%)。这一变化与innodb_max_dirty_pages_pct_lwm的更改结合在一起，确保 InnoDB 的刷新行为平稳，避免刷新突发。要恢复到先前的行为，设置innodb_max_dirty_pages_pct=75和innodb_max_dirty_pages_pct_lwm=0。

性能模式默认值

  • 默认情况下，性能模式元数据锁定（MDL）仪表化默认打开。performance-schema-instrument='wait/lock/metadata/sql/%=ON'的编译默认值从OFF更改为ON。这是为了在 SYS 中添加基于 MDL 的视图的启用器。

  • 性能模式内存仪表化默认开启。performance-schema-instrument='memory/%=COUNTED'的编译默认值从OFF更改为COUNTED。这很重要，因为如果在服务器启动后启用了仪表化，会导致计算不正确，可能会因为错过分配而得到负余额，但捕捉到释放。

  • 性能模式事务仪表化默认开启。performance-schema-consumer-events-transactions-current=ON，performance-schema-consumer-events-transactions-history=ON，和performance-schema-instrument='transaction%=ON'的编译默认值从OFF更改为ON。

复制默认值

  • log_bin系统变量的默认值从OFF更改为ON。换句话说，默认情况下启用了二进制日志记录。几乎所有的生产安装都启用了二进制日志，因为它用于复制和时间点恢复。因此，默认情况下启用二进制日志可以省去一个配置步骤，稍后启用需要重新启动mysqld。默认情况下启用它还提供更好的测试覆盖率，并且更容易发现性能退化。记得也设置server_id（见下面的更改）。8.0 的默认行为就好像你发出了./mysqld --log-bin --server-id=1。如果你在 8.0 上想要 5.7 的行为，可以发出./mysqld --skip-log-bin --server-id=0。

  • server_id系统变量的默认值从0更改为1（与log_bin=ON的更改相结合）。服务器可以使用这个默认 ID 启动，但实际上你必须根据部署的复制基础架构设置server-id，以避免出现重复的服务器 ID。

  • log-slave-updates系统变量的默认值从OFF更改为ON。这会导致副本将复制的事件记录到自己的二进制日志中。这个选项对于组复制是必需的，并且在各种复制链设置中确保正确的行为，这在今天已经成为常态。

  • expire_logs_days系统变量的默认值从0更改为30。新的默认值30会导致mysqld定期清理未使用的超过 30 天的二进制日志。这个改变有助于防止过多的磁盘空间被浪费在不再需要用于复制或恢复目的的二进制日志上。旧值0禁用了任何自动二进制日志清理。

  • master_info_repository和relay_log_info_repository系统变量的默认值从FILE更改为TABLE。因此，在 8.0 中，默认情况下将复制元数据存储在 InnoDB 中。这增加了默认情况下尝试实现崩溃安全复制的可靠性。

  • transaction-write-set-extraction系统变量的默认值从OFF更改为XXHASH64。这个改变默认启用了事务写入集。通过使用事务写入集，源必须稍微增加一些工作来生成写入集，但结果对于冲突检测是有帮助的。这是 Group Replication 的要求，新的默认值使得在源上启用二进制日志写入集并行化变得更容易，以加快复制速度。

  • slave_rows_search_algorithms系统变量的默认值从INDEX_SCAN,TABLE_SCAN更改为INDEX_SCAN,HASH_SCAN。这个改变通过减少复制应用程序必须执行的表扫描次数来加快基于行的复制速度，以应用对没有主键的表的更改。

  • slave_pending_jobs_size_max系统变量的默认值从16M更改为128M。这个改变增加了可用于多线程复制的内存量。

  • gtid_executed_compression_period系统变量的默认值从1000更改为0。这个改变确保mysql.gtid_executed表的压缩只在需要时隐含发生。

Group Replication Defaults

  • group_replication_autorejoin_tries的默认值从 0 更改为 3，这意味着默认情况下启用了自动重新加入。这个系统变量指定成员在被驱逐或在达到group_replication_unreachable_majority_timeout设置之前无法联系到大多数组时，尝试自动重新加入组的次数。

  • group_replication_exit_state_action的默认值从ABORT_SERVER更改为READ_ONLY。这意味着当一个成员退出组时，例如在网络故障后，实例将变为只读，而不是被关闭。

  • group_replication_member_expel_timeout 的默认值从 0 更改为 5，这意味着在 5 秒检测期之后，被怀疑与组失去联系的成员将在 5 秒后被驱逐。

这些默认值大多对开发和生产环境都是合理的。但有一个例外，我们决定保持名为 innodb_dedicated_server 的新选项设置为 OFF，尽管我们建议在生产环境中将其设置为 ON。默认设置为 OFF 的原因是它会导致共享环境（如开发人员笔记本电脑）无法使用，因为它会占用 所有 可用内存。

对于生产环境，我们建议将 innodb_dedicated_server 设置为 ON。当设置为 ON 时，以下 InnoDB 变量（如果没有明确指定）将根据可用内存进行自动缩放 innodb_buffer_pool_size、innodb_log_file_size 和 innodb_flush_method。请参阅 第 17.8.12 节，“为专用 MySQL 服务器启用自动配置”。

尽管新的默认值是大多数用例的最佳配置选择，但也存在特殊情况，以及出于遗留原因使用现有的 5.7 配置选择。例如，有些人希望尽可能少地更改他们的应用程序或运行环境来升级到 8.0。我们建议评估所有新的默认值，并尽可能多地使用它们。大多数新的默认值可以在 5.7 中进行测试，因此您可以在升级到 8.0 之前在 5.7 生产环境中验证新的默认值。对于您需要保留旧的 5.7 值的少数默认值，请在您的运行环境中设置相应的配置变量或启动选项。

MySQL 8.0 拥有性能模式 variables_info 表，显示了每个系统变量最近设置的来源，以及其值范围。这提供了关于配置变量及其值的所有信息的 SQL 访问。

有效的性能退化

在 MySQL 版本 5.7 和 8.0 之间预期会出现性能退化。MySQL 8.0 拥有更多功能，改变了默认值，更加稳健，并增加了安全功能和额外的诊断信息。以下列出了这些版本之间出现性能退化的有效原因，包括潜在的调解选项。这并非详尽列表。

MySQL 版本 5.7 和 8.0 之间默认值更改相关的变化：

  • 在 5.7 中，默认情况下禁用二进制日志记录，而在 8.0 中默认启用。

    调解：通过在启动时指定--skip-log-bin或--disable-log-bin选项来禁用二进制日志记录。

  • 默认字符集从latin1更改为utf8mb4在 8.0 中。虽然utf8mb4在 8.0 中表现比 5.7 好得多，但latin1比utf8mb4更快。

    调解：如果不需要utf8mb4，在 8.0 中使用latin1。

事务数据字典（原子 DDL）在 8.0 中引入。

  • 这增加了鲁棒性/可靠性，但以 DDL 性能（CREATE / DROP 密集负载）为代价，但不应影响 DML 负载（SELECT / INSERT / UPDATE / DELETE）。

    调解：无

从 5.7.28 开始使用的更现代的 TLS 密码/算法在启用 TLS（SSL）时产生影响（默认情况下）：

  • 在 MySQL 5.7.28 之前，MySQL 社区版使用 yaSSL 库，企业版使用 OpenSSL。

    从 MySQL 5.7.28 开始，MySQL 仅使用 OpenSSL 及其更强的 TLS 密码，这在性能方面更昂贵。

    从 MySQL 5.7.28 或更早版本升级到 MySQL 8.0 可能会导致 TLS 性能退化。

    调解：无（如果出于安全原因需要 TLS）

性能模式（PFS）在 8.0 中比 5.7 更广泛：

  • 在 MySQL 8.0 中无法将 PFS 编译取消，但可以关闭。即使关闭了一些性能模式仍将存在，但开销会更小。

    调解：在 8.0 中设置 performance_schema = OFF，或者在需要部分但不是全部 PFS 功能时以更细粒度关闭性能模式仪表。

在 8.0 中默认启用截断撤消表空间，这可能会显著影响性能：

  • 从历史上看，InnoDB 将撤消日志存储在系统表空间中，但无法回收撤消日志使用的空间。系统表空间只会增长而不会缩小，这激发了相关功能请求以解决此问题。

    MySQL 8.0 将撤消日志移至单独的表空间，从而允许手动和自动撤消日志截断。

    然而，自动截断会带来永久性能开销，并且可能导致停顿。

    调解：在 8.0 中设置 innodb_undo_log_truncate = OFF，并根据需要手动截断撤消日志。有关相关信息，请参阅截断撤消表空间。

字符类[[:alpha:]]或[[:digit:]]在 MySQL 8.0 中的正则表达式函数（如REGEXP()和RLIKE()）中的性能不如在 MySQL 5.7 中表现得好。这是因为 MySQL 8.0 中用 ICU 库替换了 Spencer 正则表达式库，ICU 库在内部使用 UTF-16。

中介：在[[:alpha:]]的位置使用[a-zA-Z]；在[[:digit:]]的位置使用[0-9]。

avatar
文章
阅读
粉丝