MySQL 8.0,5.7和MySQL 5.6支持生产使用。

MySQL 8.0在MySQL 8.0.11中实现了一般可用性（GA）状态，该版本于2018年4月19日发布，用于生产。

MySQL 5.7使用MySQL 5.7.9实现了一般可用性（GA）状态，该版本于2015年10月21日发布，用于生产。

MySQL 5.6使用MySQL 5.6.10实现了一般可用性（GA）状态，该版本于2013年2月5日发布，用于生产。

MySQL 5.5使用MySQL 5.5.8实现了通用可用性（GA）状态，该版本于2010年12月3日发布，用于生产.MySQL 5.5系列不再是最新的，但仍在生产中得到支持。

MySQL 5.1通过MySQL 5.1.30实现了一般可用性（GA）状态，该版本于2008年11月14日发布用于生产.Microsoft 5.1的主动开发已经结束。

MySQL 5.0使用MySQL 5.0.15实现了通用可用性（GA）状态，该版本于2005年10月19日发布，用于生产.Microsoft 5.0的主动开发已经结束。

由于我们在这个MySQL版本中引入了许多新的和重要的功能，我们决定开始一个全新的系列。 由于系列号6和7实际上已经被MySQL使用过，所以我们去了8.0。

是。 请参见 第13.2.11节“子查询语法” 。

是。 有关执行多表更新所需的语法，请参见 第13.2.12节“UPDATE语法” ; 对于执行多表删除操作所需的操作，请参见 第13.2.2节“DELETE语法” 。

可以使用触发器来完成多表插入，该 FOR EACH ROW 子句的子句包含 块 INSERT 内的 多个 语句 BEGIN ... END 。 请参见 第24.3节“使用触发器” 。

不过。但是，MySQL有一个 AUTO_INCREMENT 系统，在MySQL 8.0中也可以处理多主复制设置中的插入。 使用 auto_increment_increment 和 auto_increment_offset 系统变量，您可以将每个服务器设置为生成不与其他服务器冲突的自动增量值。 该 auto_increment_increment 值应大于服务器数，并且每个服务器应具有唯一的偏移量。

是，请参见 第11.3.5节“时间值中的小数秒” 。

是。 MySQL是完全多线程的，如果操作系统支持它，它将使用多个CPU。

使用LinuxThreads时，您应该看到至少 运行 三个 mysqld 进程。 这些实际上是线程。 LinuxThreads管理器有一个线程，一个线程用于处理连接，一个线程用于处理警报和信号。

是。 所有当前的MySQL版本都支持事务。 该 InnoDB 存储引擎提供了完整的ACID事务与行级锁，多版本，非锁定重复读取和四个SQL标准的隔离级别。

该 NDB 存储引擎支持的 READ COMMITTED 唯一的事务隔离级别。

请参见 第16章， 备用存储引擎 。 该章包含有关除 InnoDB 存储引擎和 NDB 存储引擎（用于MySQL Cluster） 之外的所有MySQL存储引擎的信息 。 第15章， InnoDB存储引擎将 InnoDB 对此进行介绍 。 是覆盖在 第22章， MySQL的NDB簇8.0 。 NDB

No. InnoDB 是新表的默认存储引擎。 有关 详细信息 ， 请参见 第15.1节“InnoDB简介” 。

PARTITION 提供分区支持 的 存储引擎插件由本机分区处理程序替换。 作为此更改的一部分，无法再使用服务器构建服务器 -DWITH_PARTITION_STORAGE_ENGINE 。 partition 也不再显示在 表格 的输出中 SHOW PLUGINS 或显示在 INFORMATION_SCHEMA.PLUGINS 表格中。

为了支持给定表的分区，用于表的存储引擎现在必须提供其自己的（ “ 本机 ” ）分区处理程序。 InnoDB 是MySQL 8.0中唯一支持包含本机分区处理程序的存储引擎。 尝试使用任何其他存储引擎在MySQL 8.0中创建分区表失败。 （ NDB MySQL Cluster使用 的 存储引擎也提供了自己的分区处理程序，但MySQL 8.0目前不支持。）

是。 的 disabled_storage_engines 配置选项定义了存储引擎不能用于创建表或表空间。 默认情况下， disabled_storage_engines 为空（没有引擎禁用），但可以将其设置为一个或多个引擎的逗号分隔列表。

是。 InnoDB 独占 使用 表可以简化备份和恢复操作。 MySQL Enterprise Backup对 使用 存储引擎 的所有表 进行 热备份 InnoDB 。 对于使用 MyISAM 或其他非 InnoDB 存储引擎的表，它执行 “ 热 ” 备份，数据库继续运行，但这些表在备份时无法修改。 请参见 第30.2节“MySQL企业备份概述” 。

该 ARCHIVE 存储引擎存储大量无索引数据; 它占地面积小，并使用表扫描执行选择。 有关 详细信息 ， 请参见 第16.5节“ARCHIVE存储引擎” 。

服务器SQL模式定义MySQL应支持的SQL语法以及应执行的数据验证检查。 这使得在不同环境中使用MySQL以及将MySQL与其他数据库服务器一起使用变得更加容易。 MySQL服务器将这些模式分别应用于不同的客户端。 有关更多信息，请参见 第5.1.11节“服务器SQL模式” 。

每种模式都可以独立开启和关闭。 有关 可用模式的完整列表， 请参见 第5.1.11节“服务器SQL模式” 。

您可以 使用该 选项 设置默认SQL模式（对于 mysqld 启动） --sql-mode 。 使用该语句 ，您可以在连接中更改设置，无论是本地连接还是全局生效。 您可以通过发出 语句 来检索当前模式 。 SET [GLOBAL|SESSION] sql_mode='modes' SELECT @@sql_mode

模式未链接到特定数据库。 模式可以在本地设置为会话（连接），也可以全局设置为服务器。 您可以使用更改这些设置 。 SET [GLOBAL|SESSION] sql_mode='modes'

当我们提到 严格的模式 ，我们的意思是在模式中至少一者的模式 TRADITIONAL ， STRICT_TRANS_TABLES 或 STRICT_ALL_TABLES 已启用。 可以组合选项，因此您可以为模式添加限制。 有关 更多信息 ， 请参见 第5.1.11节“服务器SQL模式” 。

输入数据的密集验证，某些设置比未完成验证需要更多时间。 虽然性能影响不是很大，但如果您不需要这样的验证（可能您的应用程序已经处理了所有这些），那么MySQL会为您提供禁用严格模式的选项。 但是，如果确实需要，严格模式可以提供此类验证。

在MySQL 8.0的默认SQL模式包括以下模式： ONLY_FULL_GROUP_BY ， STRICT_TRANS_TABLES ， NO_ZERO_IN_DATE ， NO_ZERO_DATE ， ERROR_FOR_DIVISION_BY_ZERO ，和 NO_ENGINE_SUBSTITUTION 。

有关所有可用模式和默认MySQL行为的信息，请参见 第5.1.11节“服务器SQL模式” 。

是。 MySQL 8.0支持两种类型的存储例程，存储过程和存储函数。

请参见 第24.2节“使用存储的例程” 。

是。 请参阅 https://forums.mysql.com/list.php?98 。

不幸的是，官方规范不是免费提供的（ANSI使它们可以购买）。 但是，有一些书籍，如 SQL-99 Complete，真正 由Peter Gulutzan和Trudy Pelzer提供，它们提供了标准的全面概述，包括存储过程的覆盖范围。

对存储的例程使用明确的命名方案始终是一种好习惯。 您可以管理存储与程序 CREATE [FUNCTION|PROCEDURE] ， ALTER [FUNCTION|PROCEDURE] ， DROP [FUNCTION|PROCEDURE] ，和 SHOW CREATE [FUNCTION|PROCEDURE] 。 您可以使用 数据库中 的 ROUTINES 表 获取有关现有存储过程 的 INFORMATION_SCHEMA 信息（请参见 第25.23节“INFORMATION_SCHEMA ROUTINES表” ）。

是。 对于已命名的数据库 dbname ，请在 INFORMATION_SCHEMA.ROUTINES 表 上使用此查询 ：

选择ROUTINE_TYPE，ROUTINE_NAME
    来自INFORMATION_SCHEMA.ROUTINES
    在哪里ROUTINE_SCHEMA =' dbname';

有关更多信息，请参见 第25.23节“INFORMATION_SCHEMA ROUTINES表” 。

可以使用 SHOW CREATE FUNCTION （对于存储的函数）或 SHOW CREATE PROCEDURE （对于存储过程） 来查看存储的例程的主体 。 有关 更多信息 ， 请参见 第13.7.6.9节“SHOW CREATE PROCEDURE语法” 。

存储过程存储在 mysql.routines 和 mysql.parameters 表中，这些表是数据字典的一部分。 您无法直接访问这些表。 而是查询 INFORMATION_SCHEMA ROUTINES 和 PARAMETERS 表。 请参见 第25.23节“INFORMATION_SCHEMA ROUTINES表” 和 第25.16节“INFORMATION_SCHEMA参数表” 。

您还可以使用 SHOW CREATE FUNCTION 获取有关存储函数的信息，以及 SHOW CREATE PROCEDURE 获取有关存储过程的信息。 请参见 第13.7.6.9节“显示创建过程语法” 。

不。在MySQL 8.0中不支持此功能。

是。

存储过程可以执行 UPDATE 导致触发器激活 的SQL语句，例如 。

是。 存储过程可以根据需要访问一个或多个表。

是。 MySQL 8.0实现了SQL标准 SIGNAL 和 RESIGNAL 语句。 请参见 第13.6.7节“条件处理” 。

MySQL HANDLER 根据SQL标准 实现 定义。 有关详细 信息， 请参见 第13.6.7.2节“DECLARE ... HANDLER语法” 。

存储过程 可以，但存储的功能不能。 如果 SELECT 在存储过程中 执行普通操作 ，则结果集将直接返回给客户端。 您需要使用MySQL 4.1（或更高版本）客户端/服务器协议才能工作。 这意味着，例如，在PHP中，您需要使用 mysqli 扩展而不是旧 mysql 扩展。

不在MySQL 8.0中。

在MySQL 8.0中没有等效的东西。

不在MySQL 8.0中。

在MySQL 8.0中，游标仅在存储过程中可用。

在MySQL 8.0中，游标仅在存储过程中可用。 但是，如果不在a上打开游标 SELECT ，结果将直接发送到客户端。 你也可以 SELECT INTO 变量。 请参见 第13.2.10节“SELECT语法” 。

是的，您可以在 存储过程中 执行此操作 ，但不能在存储的函数中执行此操作。 如果 SELECT 在存储过程中 执行普通操作 ，则结果集将直接返回给客户端。 为此，您需要使用MySQL 4.1（或更高版本）客户端/服务器协议。 这意味着，例如，在PHP中，您需要使用 mysqli 扩展而不是旧 mysql 扩展。

是。 但是，您无法在存储的函数中执行事务操作。

是的，在存储过程和函数中执行的标准操作从主MySQL服务器复制到从服务器。 第24.7节“存储程序二进制日志记录” 中详细描述了一些限制 。

是的，通过主服务器上的普通DDL语句创建的存储过程和函数将复制到从属服务器，因此这些对象将存在于两个服务器上。 ALTER 和 DROP 存储过程和函数语句也被复制。

MySQL记录存储过程中发生的每个DML事件，并将这些单独的操作复制到从属服务器。 不会复制执行存储过程的实际调用。

更改数据的存储函数记录为函数调用，而不是每个函数内部发生的DML事件。

是。 由于从属服务器有权执行从主服务器的二进制日志中读取的任何语句，因此存在使用存储函数进行复制的特殊安全性约束。 如果复制或二进制日志记录（通常用于时间点恢复）处于活动状态，那么MySQL DBA有两个安全选项可供选择：

嵌入在存储过程中的非确定性（随机）或基于时间的操作可能无法正确复制。 就其本质而言，随机产生的结果是不可预测的，并且无法准确再现，因此，复制到从属设备的随机动作不会反映在主设备上执行的操作。 声明存储的函数 DETERMINISTIC 或将 log_bin_trust_function_creators 系统变量 设置 为0将不允许调用随机值操作。

此外，无法在从站上重现基于时间的操作，因为存储过程中此类操作的时间不能通过用于复制的二进制日志重现。 它仅记录DML事件，不考虑时序约束。

最后，在大型DML操作（例如批量插入）期间发生错误的非事务性表可能会遇到复制问题，因为主服务器可能会从DML活动中部分更新，但由于发生了错误，因此不会对从服务器进行更新。 解决方法是使用 IGNORE 关键字 执行函数的DML操作， 以便忽略导致错误的主服务器上的更新，并将不会导致错误的更新复制到从服务器。

影响复制的相同限制确实会影响时间点恢复。

您可以选择基于语句的复制或基于行的复制。 原始复制实现基于基于语句的二进制日志记录。 基于行的二进制日志记录解决了前面提到的限制。

也可以使用 混合 复制（通过启动服务器 --binlog-format=mixed ）。 这种混合形式的复制 “ 知道 ” 是否可以安全地使用语句级复制，或者需要行级复制。

有关其他信息，请参见 第17.2.1节“复制格式” 。

请参见 第24.3节“使用触发器” 。

是。 可在 https://forums.mysql.com/list.php?99 上找到它 。

在MySQL 8.0中，所有触发器都是 FOR EACH ROW ; 也就是说，为插入，更新或删除的每一行激活触发器。 MySQL 8.0不支持使用触发器 FOR EACH STATEMENT 。

没有明确。 MySQL确实对某些 TIMESTAMP 列以及使用定义的列 具有特定的特殊行为 AUTO_INCREMENT 。

在MySQL 8.0中，可以使用 CREATE TRIGGER 语句 创建触发器 ，并使用删除 DROP TRIGGER 。 有关这些语句的更多信息 ， 请参见 第13.1.22节“CREATE TRIGGER语法” 和 第13.1.34节“DROP TRIGGER语法” 。

可以通过查询 INFORMATION_SCHEMA.TRIGGERS 表 获得有关触发器的信息 。 请参见 第25.34节“INFORMATION_SCHEMA TRIGGERS表” 。

是。 您可以 dbname 使用 INFORMATION_SCHEMA.TRIGGERS 表中 的查询 获取在数据库 上 定义的所有触发器的列表， 如下所示：

SELECT TRIGGER_NAME，EVENT_MANIPULATION，EVENT_OBJECT_TABLE，ACTION_STATEMENT
    来自INFORMATION_SCHEMA.TRIGGERS
    在哪里TRIGGER_SCHEMA =' dbname';

有关此表的更多信息，请参见 第25.34节“INFORMATION_SCHEMA TRIGGERS表” 。

您还可以使用 SHOW TRIGGERS 特定于MySQL 的 语句。 请参见 第13.7.6.38节“显示触发器语法” 。

触发器存储在 mysql.triggers 系统表中，系统表是数据字典的一部分。

是。

触发器可以访问其自己的表中的旧数据和新数据。 触发器也可以影响其他表，但不允许通过调用函数或触发器的语句修改已经使用（用于读取或写入）的表。

在MySQL 8.0中，可以为具有相同触发事件和操作时间的给定表定义多个触发器。 例如，您可以 BEFORE UPDATE 为表创建 两个 触发器。 默认情况下，具有相同触发事件和操作时间的触发器按创建顺序激活。 要影响触发器顺序，请在 FOR EACH ROW 指示 之后指定一个子句 ， FOLLOWS 或者 指定 PRECEDES 具有相同触发事件和操作时间的现有触发器的名称。 使用时 FOLLOWS ，新触发器在现有触发器之后激活。 使用时 PRECEDES ，新触发器在现有触发器之前激活。

是。 例如，触发器可以调用 sys_exec() UDF。

是。 可以使用 FEDERATED 存储引擎 更新远程服务器上的表 。 （参见 第16.8节“联合存储引擎” ）。

是。 但是，它们的工作方式取决于您使用的是MySQL的 “ 经典 ” 基于语句还是基于行的复制格式。

使用基于语句的复制时，从属服务器上的触发器由在主服务器上执行的语句执行（并复制到从服务器）。

使用基于行的复制时，由于在主服务器上运行并随后复制到从服务器的语句，因此不会在从服务器上执行触发器。 相反，使用基于行的复制时，在主服务器上执行由主服务器执行触发器引起的更改将应用​​于从服务器。

有关更多信息，请参见 第17.4.1.35节“复制和触发器” 。

同样，这取决于您使用的是基于语句还是基于行的复制。

基于语句的复制。  首先，必须在从属服务器上重新创建主服务器上存在的触发器。 完成此操作后，复制流将像参与复制的任何其他标准DML语句一样工作。 例如，考虑一个 EMP 具有 AFTER 插入触发器 的表 ， 该表 存在于主MySQL服务器上。 从服务器上也存在 相同的 EMP 表和 AFTER 插入触发器。 复制流程将是：

基于行的复制。  使用基于行的复制时，在主服务器上执行触发操作所引起的更改将应用​​于从服务器。 但是，在基于行的复制下，触发器本身实际上并未在从属服务器上执行。 这是因为，如果主设备和从设备都应用了来自主设备的更改，此外，导致这些更改的触发器应用于从设备，这些更改实际上会在从设备上应用两次，从而导致不同的数据主人和奴隶。

在大多数情况下，基于行和基于语句的复制的结果是相同的。 但是，如果在主服务器和从服务器上使用不同的触发器，则无法使用基于行的复制。 （这是因为基于行的格式将在主服务器上执行的触发器所做的更改复制到从服务器，而不是导致触发器执行的语句，并且不执行从服务器上的相应触发器。）相反，任何语句必须使用基于语句的复制来复制导致执行此类触发器的操作。

有关更多信息，请参见 第17.4.1.35节“复制和触发器” 。

请参见 第24.5节“使用视图” 。

是。 请参阅 https://forums.mysql.com/list.php?100

创建视图后，可以删除或更改定义所引用的表或视图。 要检查此类问题的视图定义，请使用该 CHECK TABLE 语句。 （请参见 第13.7.3.2节“检查表语法” 。）

没有。

没有。

如果您的 INSERT 语句有一个列表明确表示只涉及一个表，那么 这是可能的 。

您 无法 在视图上插入单个插入的多个表。

请参见 第25章， INFORMATION_SCHEMA表

请参阅 https://forums.mysql.com/list.php?101 。

不幸的是，官方规格不是免费提供的。 （ANSI使它们可以购买。）但是，有一些书籍，例如 SQL-99 Complete，真正 由Peter Gulutzan和Trudy Pelzer提供，它们提供了标准的全面概述，包括 INFORMATION_SCHEMA 。

Oracle和MySQL都在表中提供元数据。 但是，Oracle和MySQL使用不同的表名和列名。 MySQL实现更类似于DB2和SQL Server中的实现，它们也支持 INFORMATION_SCHEMA SQL标准中定义的。

不可以。由于应用程序可能依赖于某种标准结构，因此不应对其进行修改。 因此， 我们无法支持因修改 INFORMATION_SCHEMA 表或数据 而导致的错误或其他问题 。

有关详细的升级信息，请参见 第2.11节“升级MySQL” 。 升级时不要跳过主要版本，而是逐步完成流程，在每个步骤中从一个主要版本升级到下一个版本。 这可能看起来更复杂，但它会节省时间和麻烦。 如果您在升级期间遇到问题，则可以通过MySQL支持，或者如果您拥有MySQL Enterprise订阅，则可以更容易地识别它们的来源。

存储引擎支持已更改如下：

最好的起点是 第6章， 安全性 。

关于特定安全问题，您可能会发现有用的MySQL文档的其他部分包括：

MySQL 8.0中的默认身份验证插件是 caching_sha2_password 。 有关此插件的信息，请参见 第6.4.1.3节“缓存SHA-2可插入身份验证” 。

该 caching_sha2_password 插件提供了比 mysql_native_password 插件（以前的MySQL系列中的默认插件） 更安全的密码加密 。 有关此默认插件更改对服务器操作的影响以及服务器与客户端和连接器的兼容性的信息，请参阅 caching_sha2_password作为首选身份验证插件 。

有关可插入身份验证和其他可用身份验证插件的一般信息，请参见 第6.2.17节“可插入身份验证” 和 第6.4.1节“身份验证插件” 。

大多数8.0二进制文件都支持客户端和服务器之间的SSL连接。 请参见 第6.3节“使用加密连接” 。

如果（例如）客户端应用程序不支持SSL连接，您也可以使用SSH隧道连接。 有关示例，请参见 第6.3.7节“使用SSH从Windows远程连接到MySQL” 。

大多数8.0二进制文件都为启用，验证或两者兼容的客户端/服务器连接启用了SSL。 请参见 第6.3节“使用加密连接” 。

企业版包括 PAM身份验证插件 ，支持针对LDAP目录的身份验证。

不是在这个时候。

MySQL Server 8.0版本不支持NDB Cluster; 它作为单独的产品发布。 NDB Cluster 8.0现在可用作开发人员预览版，用于评估和测试 NDBCLUSTER 存储引擎中 的新功能 ; 有关更多信息，请参见 第22章， MySQL NDB Cluster 8.0 。 强烈建议您将NDB Cluster 7.6用于任何新部署; 如果您使用的是旧版NDB群集，我们建议您尽快升级到此版本。 有关NDB Cluster 7.6中所做改进的概述，请参阅 NDB Cluster 7.6中的新增功能 。

NDB Cluster 7.6基于MySQL Server 5.7和7.6版本的 NDB 存储引擎，是NDB Cluster的最新通用可用性（GA）版本，基于7.6版的 NDB 存储引擎和MySQL Server 5.7。 NDB Cluster 7.6可供生产使用; 用于生产的新部署应使用本系列中最新的GA版本，该版本目前是NDB Cluster 7.6.11。 您可以从 https://dev.mysql.com/downloads/cluster/ 获取最新的NDB Cluster 7.6版本 。 有关本系列中的新功能和其他重要更改的信息，请参阅 NDB Cluster 7.6中的 新增功能 。

有关部署和使用NDB Cluster的详细信息，请参见 第22章， MySQL NDB Cluster 8.0 。

“ NDB ” 代表 “ N etwork D ata b ase ” 。 NDB 并且 NDBCLUSTER 都是存储引擎的名称，它支持MySQL的群集支持。 NDB 是首选，但两个名称都是正确的。

运行可行的群集至少需要三台计算机。 但是， NDB群集中 建议 的最小 计算机数量为四个：一个用于运行管理和SQL节点，另外两个用作数据节点。 两个数据节点的目的是提供冗余; 管理节点必须在单独的机器上运行，以保证在其中一个数据节点发生故障时继续进行仲裁服务。

要提供更高的吞吐量和高可用性，您应该使用多个SQL节点（连接到群集的MySQL服务器）。 运行多个管理服务器也是可能的（尽管不是绝对必要的）。

CJK字符集列表可能因您的MySQL版本而异。 例如， gb18030 MySQL 5.7.4之前不支持字符集。 但是，由于适用语言的名称显示在 表中 DESCRIPTION 每个条目 的 列 INFORMATION_SCHEMA.CHARACTER_SETS 中，因此您可以使用此查询获取所有非Unicode CJK字符集的当前列表：

MySQL的> SELECT CHARACTER_SET_NAME, DESCRIPTION
       FROM INFORMATION_SCHEMA.CHARACTER_SETS
       WHERE DESCRIPTION LIKE '%Chin%'
       OR DESCRIPTION LIKE '%Japanese%'
       OR DESCRIPTION LIKE '%Korean%'
       ORDER BY CHARACTER_SET_NAME;
+ -------------------- + ---------------------------- ----- +
| CHARACTER_SET_NAME | 描述|
+ -------------------- + ---------------------------- ----- +
| big5 | Big5繁体中文|
| cp932 | SJIS for Windows日语|
| eucjpms | UJIS for Windows日语|
| euckr | EUC-KR韩语|
| gb18030 | 中国国家标准GB18030 |
| gb2312 | GB2312简体中文|
| gbk | GBK简体中文|
| sjis | Shift-JIS日语|
| ujis | EUC-JP日语|
+ -------------------- + ---------------------------- ----- +

（有关更多信息，请参见 第25.2节“INFORMATION_SCHEMA CHARACTER_SETS表” 。）

MySQL支持的三个变种 GB （ 国嘉Biaozhun ，或 国家标准 ，或 简体中国 ）字符集这是在中国人民共和国官方： gb2312 ， gbk ，和（从MySQL 5.7.4的） gb18030 。

有时候人们会尝试插入 gbk 字符 gb2312 ，并且大部分时间 gbk 都是 有效的，因为它 是一个超集 gb2312 。 但最终他们试图插入一个罕见的汉字，但它不起作用。 （例如，请参阅Bug＃16072）。

在这里，我们试图准确地澄清哪些字符是合法的， gb2312 或 gbk 参考官方文件。 请在报告 gb2312 或 gbk 错误 之前检查这些参考 ：

也可以将CJK字符存储在Unicode字符集中，尽管可用的排序规则可能不会像您期望的那样对字符进行排序：

用于Unicode字符集的排序规则决定了对集合中的字符进行排序（即区分）的能力：

此外，区分字符与按给定CJK语言的约定排序它们不同。 目前，MySQL只有一个特定于CJK的UCA排序规则 gb18030_unicode_520_ci （需要使用非Unicode gb18030 字符集）。

有关Unicode归类及其区分属性（包括补充字符的归类属性）的信息，请参见 第10.10.1节“Unicode字符集” 。

此问题通常是由于MySQL中的设置与应用程序或操作系统的设置不匹配。 以下是纠正这些类型问题的一些常见步骤：

MySQL支持Big5字符集，这在香港和台湾（中华民国）很常见。 MySQL big5 字符集实际上是Microsoft代码页950，它与原始 big5 字符集 非常相似 。

HKSCS 已提交 添加 扩展的 功能请求 。 需要此扩展程序的用户可能会发现Bug＃13577建议的修补程序很有用。

MySQL的支持 sjis ， ujis ， cp932 ，和 eucjpms 字符集，以及为Unicode。 常见的需求是在字符集之间进行转换。 例如，可能存在Unix服务器（通常带有 sjis 或 ujis ）和Windows客户端（通常带有 cp932 ）。

在下面的转换表中， ucs2 列表示源极，并且 sjis ， cp932 ， ujis ，和 eucjpms 列代表目的地; 也就是说，最后的4列提供了十六进制结果，当我们使用 CONVERT(ucs2) 或我们分配一个 ucs2 包含该值到一个柱 sjis ， cp932 ， ujis ，或 eucjpms 柱。

现在考虑表格的以下部分。

这意味着MySQL将 NOT SIGN （Unicode U+00AC ） 转换 为 sjis 代码点 0x81CA 和 cp932 代码点 3F 。 （ 3F 是问号（ “ ？ ” 。这是在无法执行转换时始终使用的。）

我们的答案是： “ ？ “ 。 有缺点此，许多人宁愿一个 “ 松 ” 的转换，从而使 81CA (NOT SIGN) 在 sjis 变 81CA (FULLWIDTH NOT SIGN) 的 cp932 。

会出现一个问题，因为日文字符集（包括某些版本 sjis 和 euc ）治疗 5C 作为 反向固相线 （ \ 也被称为反斜线），而其他人把它当作日元符号（ ¥ ）。

MySQL仅遵循JIS（日本工业标准）标准描述的一个版本。 在MySQL中， 5C 总是反向的solidus（ \ ） 。

从理论上讲，虽然已有多个版本的 euckr （ 扩展Unix代码韩国 ）字符集，但只注意到一个问题。 我们使用 EUC-KR 的 “ ASCII ” 变体，其中代码点 0x5c 是REVERSE SOLIDUS，即 \ 代替 EUC-KR 的 “ KS-Roman ” 变体，其中代码点 0x5c 是 WON SIGN （ ₩ ）。 这意味着您无法将Unicode转换 U+20A9 为 euckr ：

MySQL的> SELECT
           CONVERT('₩' USING euckr) AS euckr,
           HEX(CONVERT('₩' USING euckr)) AS hexeuckr;
+ ------- + ---------- +
| euckr | hexeuckr |
+ ------- + ---------- +
| ？| 3F |
+ ------- + ---------- +

要查看问题，请创建一个包含一个Unicode（ ucs2 ）列和一个Chinese（ gb2312 ）列的表。

MySQL的> CREATE TABLE ch
       (ucs2 CHAR(3) CHARACTER SET ucs2,
       gb2312 CHAR(3) CHARACTER SET gb2312);

在非严格SQL模式下，尝试将稀有字符 汌 放在两列中。

mysql> SET sql_mode = '';
mysql>INSERT INTO ch VALUES ('A汌B','A汌B');
查询正常，1行受影响，1警告（0.00秒）

将 INSERT 产生一个警告。 使用以下语句查看它是什么：

MySQL的> SHOW WARNINGS\G
*************************** 1。排******************** *******
  等级：警告
   代码：1366
消息：字符串值不正确：第1行第'gb2312'列的'\ xE6 \ xB1 \ x8CB'

所以这只是对该 gb2312 列 的警告 。

mysql> SELECT ucs2，HEX（ucs2），gb2312，HEX（gb2312）FROM ch;
+ ------- + -------------- + -------- + ------------- +
| ucs2 | HEX（ucs2）| gb2312 | 十六进制（gb2312）|
+ ------- + -------------- + -------- + ------------- +
| A汌B | 00416C4C0042 | A？B | 413F42 |
+ ------- + -------------- + -------- + ------------- +

这里需要解释几件事：

使用 mysql 客户端 获取与服务器的直接连接 ，并在那里尝试相同的查询。 如果 mysql 响应正确，则问题可能是您的应用程序接口需要初始化。 使用 mysql 告诉你它与语句一起使用的字符集或设置 SHOW VARIABLES LIKE 'char%'; 。 如果您使用Access，则很可能使用Connector / ODBC进行连接。 在这种情况下，您应该检查 配置连接器/ ODBC 。 例如，如果您使用 big5 ，则输入 SET NAMES 'big5' 。 （在这种情况下，不需要任何 ; 字符。）如果您使用的是ASP，则可能需要添加 SET NAMES 在代码中。 这是一个过去有效的例子：

<％
Session.CodePage = 0
昏暗的strConnection
昏暗的康恩
strConnection =“driver = {MySQL ODBC 3.51 Driver}; server = server; uid = username;” \
               ＆“pwd = password; database = database; stmt = SET NAMES'big5';”
设置Conn = Server.CreateObject（“ADODB.Connection”）
Conn.Open strConnection
％>

以同样的方式，如果您使用除 latin1 Connector / NET 之外的任何字符集 ，则必须在连接字符串中指定字符集。 有关 更多信息， 请参阅 使用Connector / NET连接到MySQL 。

如果您使用的是PHP，请尝试以下方法：

<？PHP
  $ link = new mysqli（$ host，$ usr，$ pwd，$ db）;

  if（mysqli_connect_errno（））
  {
    printf（“连接失败：％s \ n”，mysqli_connect_error（））;
    出口（）;
  }

  $ link-> query（“SET NAMES'utf8'”）;
？>

在这种情况下，我们使用的 SET NAMES 改变 character_set_client ， character_set_connection 以及 character_set_results 。

PHP应用程序中经常遇到的另一个问题与浏览器的假设有关。 有时添加或更改 <meta> 标记足以纠正问题：例如，确保用户代理将页面内容解释为 UTF-8 包含 <meta http-equiv="Content-Type" content="text/html; charset=utf-8"> 在 <head> HTML页面 的 部分中。

如果您使用的是Connector / J，请参阅 使用字符集和Unicode 。

在MySQL版本4.0中， 服务器和客户端都有 一个 “ 全局 ” 字符集，并决定服务器管理员使用哪个字符。 这从MySQL版本4.1开始改变。 现在发生的是 “ 握手 ” ，如 第10.4节“连接字符集和排序”中所述 ：

这样做的效果是你无法控制的客户端字符由开始设定 的mysqld 用 --character-set-server=utf8 。 但是，一些亚洲客户更喜欢MySQL 4.0的行为。 为了能够保留这种行为，我们添加了一个 mysqld 开关， --character-set-client-handshake 可以关闭它 --skip-character-set-client-handshake 。 如果启动 mysqld的 使用 --skip-character-set-client-handshake ，那么，当客户端连接时，它发送的字符集的名称，它希望使用的服务器。 但是， 服务器会忽略来自客户端的此请求 。

举例来说，假设您最喜欢的服务器字符集是 latin1 。 进一步假设客户端使用， utf8 因为这是客户端操作系统支持的内容。 使用 latin1 默认字符集 启动服务器 ：

mysqld --character-set-server = latin1

然后使用默认字符集启动客户端 utf8 ：

mysql --default-character-set = utf8

通过查看以下输出可以看到生成的设置 SHOW VARIABLES ：

MySQL的> SHOW VARIABLES LIKE 'char%';
+ -------------------------- + ---------------------- ------------------ +
| Variable_name | 价值|
+ -------------------------- + ---------------------- ------------------ +
| character_set_client | utf8 |
| character_set_connection | utf8 |
| character_set_database | 拉丁1 |
| character_set_filesystem | 二进制|
| character_set_results | utf8 |
| character_set_server | 拉丁1 |
| character_set_system | utf8 |
| character_sets_dir | / usr / local / mysql / share / mysql / charsets / |
+ -------------------------- + ---------------------- ------------------ +

现在停止客户端，并使用 mysqladmin 停止服务器 。 然后再次启动服务器，但这次告诉它跳过这样的握手：

mysqld --character-set-server = utf8 --skip-character-set-client-handshake

utf8 再次 启动客户端 作为默认字符集，然后显示结果设置：

MySQL的> SHOW VARIABLES LIKE 'char%';
+ -------------------------- + ---------------------- ------------------ +
| Variable_name | 价值|
+ -------------------------- + ---------------------- ------------------ +
| character_set_client | 拉丁1 |
| character_set_connection | 拉丁1 |
| character_set_database | 拉丁1 |
| character_set_filesystem | 二进制|
| character_set_results | 拉丁1 |
| character_set_server | 拉丁1 |
| character_set_system | utf8 |
| character_sets_dir | / usr / local / mysql / share / mysql / charsets / |
+ -------------------------- + ---------------------- ------------------ +

通过比较不同的结果可以看出， SHOW VARIABLES 如果使用该 --skip-character-set-client-handshake 选项 ，服务器将忽略客户端的初始设置 。

对于 LIKE 搜索，二进制字符串列类型有一个非常简单的问题，例如 BINARY 和 BLOB ：我们必须知道字符结束的位置。 对于多字节字符集，不同的字符可能具有不同的八位字节长度。 例如，在 utf8 ， A 需要一个字节但 ペ 需要三个字节，如下所示：

+ ------------------------- + ----------------------- ---- +
| OCTET_LENGTH（_utf8'A'）| OCTET_LENGTH（_utf8'ペ​​'）|
+ ------------------------- + ----------------------- ---- +
| 1 | 3 |
+ ------------------------- + ----------------------- ---- +

如果我们不知道字符串中第一个字符的结束位置，我们就不知道第二个字符的开始位置，在这种情况下甚至可以进行非常简单的搜索，例如 LIKE '_A%' 失败。 解决方案是使用定义的非二进制字符串列类型具有正确的CJK字符集。 例如： mycol TEXT CHARACTER SET sjis 。 或者，在比较之前转换为CJK字符集。

这就是为什么MySQL不允许对不存在的字符进行编码的原因之一。 如果对拒绝错误输入不严格，则无法知道字符的结束位置。

对于 FULLTEXT 搜索，我们必须知道单词的开始和结束位置。 对于西方语言，这很少是一个问题，因为大多数（如果不是全部）使用易于识别的单词边界：空间字符。 然而，亚洲写作通常不是这种情况。 我们可以使用任意中途测量，例如假设所有汉字代表单词，或者（对于日语）取决于由于语法结尾而从片假名到平假名的变化。 但是，唯一可靠的解决方案需要一个全面的单词列表，这意味着我们必须在服务器中包含支持的每种亚洲语言的字典。 这根本不可行。

大多数简体中文和基本非半宽带日语假名字符出现在所有CJK字符集中。 以下存储过程接受 UCS-2 Unicode字符，将其转换为其他字符集，并以十六进制显示结果。

DELIMITER //

CREATE PROCEDURE p_convert（ucs2_char CHAR（1）CHARACTER SET ucs2）
开始

CREATE TABLE tj
             （ucs2 CHAR（1）字符集ucs2，
              utf8 CHAR（1）字符集utf8，
              big5 CHAR（1）字符集big5，
              cp932 CHAR（1）字符集cp932，
              eucjpms CHAR（1）字符集eucjpms，
              euckr CHAR（1）字符集euckr，
              gb2312 CHAR（1）字符集gb2312，
              gbk CHAR（1）字符集gbk，
              sjis CHAR（1）字符集sjis，
              ujis CHAR（1）字符集ujis）;

INSERT INTO tj（ucs2）VALUES（ucs2_char）;

UPDATE tj SET utf8 = ucs2，
              中文= UCS2，
              CP932 = UCS2，
              eucjpms一起= UCS2，
              EUCKR = UCS2，
              GB2312 = UCS2，
              GBK = UCS2，
              SJIS = UCS2，
              UJIS = UCS2;

/ *如果存在转换问题，UPDATE会产生警告。* /

SELECT hex（ucs2）AS ucs2，
       hex（utf8）AS utf8，
       hex（big5）AS big5，
       hex（cp932）AS cp932，
       hex（eucjpms）AS eucjpms，
       hex（euckr）AS euckr，
       hex（gb2312）AS gb2312，
       hex（gbk）AS gbk，
       hex（sjis）AS sjis，
       hex（ujis）AS ujis
FROM tj;

DROP TABLE tj;

结束//

DELIMITER;

输入可以是任何单个 ucs2 字符，也可以是该字符的代码值（十六进制表示）。 例如，从Unicode的 ucs2 编码和名称 列表 （ http://www.unicode.org/Public/UNIDATA/UnicodeData.txt ），我们知道片假名字符 Pe 出现在所有CJK字符集中，并且其代码值为 X'30DA' 。 如果我们使用此值作为参数 p_convert() ，结果如下所示：

MySQL的> CALL p_convert(X'30DA');
+ ------ + -------- + ------ + ------- + --------- + ------- + -------- + ------ + ------ + ------ +
| ucs2 | utf8 | big5 | cp932 | eucjpms | euckr | gb2312 | gbk | sjis | ujis |
+ ------ + -------- + ------ + ------- + --------- + ------- + -------- + ------ + ------ + ------ +
| 30DA | E3839A | C772 | 8379 | A5DA | ABDA | A5DA | A5DA | 8379 | A5DA |
+ ------ + -------- + ------ + ------- + --------- + ------- + -------- + ------ + ------ + ------ +

由于没有列值 3F （即问号字符 ? ），我们知道每个转换都有效。

通过使用 utf8mb4 字符集和 utf8mb4_ja_0900_as_cs 排序规则， 可以在MySQL 8.0中解决旧MySQL版本中发生的CJK排序问题 。

通过使用 utf8mb4 字符集和 utf8mb4_ja_0900_as_cs 排序规则， 可以在MySQL 8.0中解决旧MySQL版本中发生的CJK排序问题 。

补充字符位于Unicode 基本多语言平面/平面0之外 。 BMP字符在 U+0000 和 之间具有代码点值 U+FFFF 。 补充字符在 U+10000 和 之间具有代码点值 U+10FFFF 。

要存储增补字符，必须使用允许它们的字符集：

不可以 。 “ CJKV ” （ 中文日文朝鲜语越南语 ）是指包含汉（原中文）字符的越南字符集。 MySQL支持带有西方字符的现代越南语脚本，但不支持使用汉字符的旧越南语脚本。

从MySQL 5.6开始，有Unicode字符集的越南语排序规则，如 第10.10.1节“Unicode字符集”中所述 。

是。

可以从 https://dev.mysql.com/doc/ 下载MySQL 5.6手册的日文翻译 。

以下资源可用：

不，不是的。 从站可以停机或保持断开连接数小时甚至数天，然后重新连接并赶上更新。 例如，您可以通过拨号链接建立主/从关系，其中链接仅偶尔以及短时间内启动。 这意味着，在任何给定时间，除非你采取一些特殊措施，否则不保证奴隶与主人同步。

要确保已断开连接的从站可能发生捕获，您不得从主服务器中删除包含尚未复制到从服务器的信息的二进制日志文件。 只有当从服务器能够从上次读取事件的点继续读取二进制日志时，异步复制才能工作。

是的，必须在主站和从站上启用网络。 如果未启用网络，则从站无法连接到主站并传输二进制日志。 检查是否 skip-networking 在任一服务器的配置文件中未启用 该 选项。

检查 Seconds_Behind_Master 输出中 的 列 SHOW SLAVE STATUS 。 请参见 第17.1.7.1节“检查复制状态” 。

当从属SQL线程执行从主服务器读取的事件时，它会将自己的时间修改为事件时间戳。 （这就是 TIMESTAMP 复制的原因。）在 Time 输出 的 列中 SHOW PROCESSLIST ，从属SQL线程显示的秒数是上次复制事件的时间戳与从属机器的实际时间之间的秒数。 您可以使用它来确定上次复制事件的日期。 请注意，如果您的从服务器已与主服务器断开连接一小时，然后重新连接，您可能会立即看到大的 Time 值，例如3600用于从属SQL线程 SHOW PROCESSLIST 。 这是因为slave正在执行一小时的语句。 请参见 第17.2.2节“复制实现细节” 。

使用以下过程：

MySQL复制当前不支持主服务器和从服务器之间的任何锁定协议，以保证分布式（跨服务器）更新的原子性。 换句话说，客户端A可以对共同主设备1进行更新，同时，在它传播到共同主设备2之前，客户端B可以对共同主设备2进行更新，以进行更新。客户端A的工作方式与在共同主服务器1上的工作方式不同。因此，当客户端A的更新使其成为共同主服务器2时，它会生成与您在共同主服务器1上的表不同的表，即使在所有更新之后也是如此来自联合大师2也有传播。

您还应该意识到，就更新而言，双向复制实际上并没有提高性能（如果有的话）。 每个服务器必须执行相同数量的更新，就像您使用单个服务器一样。 唯一的区别是锁争用少一点，因为源自另一台服务器的更新在一个从属线程中被序列化。 即使这种好处也可能被网络延迟所抵消。

将一台服务器设置为主服务器并指示所有写入服务器。 然后配置与预算和机架空间一样多的从站，并在主站和从站之间分配读取。 您还可以使用 --skip-innodb 和 --low-priority-updates 选项 启动从站 ，并将 delay_key_write 系统变量 设置为 ALL 在从站端获得速度提升。 在这种情况下，slave使用非事务 MyISAM 表而不是 InnoDB 表来通过消除事务开销来获得更快的速度。

请参见使用复制作为横向扩展解决方案的指南， 第17.3.5节“使用复制进行 横向扩展 ” 。

MySQL复制对于处理频繁读取和不频繁写入的系统最有利。 理论上，通过使用单主/多从设置，您可以通过添加更多从设备来扩展系统，直到用完网络带宽，或者更新负载增长到主设备无法处理的程度。

要确定在增加的好处开始趋于平稳之前可以使用多少个从站，以及可以提高站点性能的程度，您必须知道查询模式，并通过对读取和写入的吞吐量之间的关系进行基准测试来确定。典型的主人和典型的奴隶。 此处的示例显示了对假设系统的复制可以获得的相当简化的计算。 让我们 reads 和 writes 代表人数分别为读取和每秒写入。

假设系统负载由10％写入和90％读取组成，我们通过基准测试确定 reads 1200 - 2 * writes 。 换句话说，系统可以在没有写入的情况下每秒执行1,200次读取，平均写入速度是平均读取速度的两倍，并且关系是线性的。 假设主设备和每个从设备具有相同的容量，并且我们有一个主设备和 N 从设备。 然后我们为每个服务器（主服务器或从服务器）：

reads = 1200 - 2 * writes

reads = 9 * writes /（ N + 1）（读取被拆分，但写入复制到所有从站）

9 * writes /（ N + 1）+ 2 * writes = 1200

writes = 1200 /（2 + 9 /（ N + 1））

最后一个等式表示 N 从站 的最大写入次数 ，给定最大可能的读取速率为每秒1,200次，每次写入的读取次数为9次。

该分析得出以下结论：

这些计算假设无限的网络带宽，而忽略了可能对您的系统产生重大影响的其他几个因素。 在许多情况下，如果添加 N 复制从属 ，则可能无法执行与刚刚显示的计算类似的计算，以准确预测系统上将发生的情况 。 但是，回答以下问题可帮助您确定是否以及通过多少复制来提高系统性能：

如何实现冗余完全取决于您的应用程序和环境。 高可用性解决方案（具有自动故障转移）需要主动监控以及自定义脚本或第三方工具，以提供从原始MySQL服务器到从属服务器的故障转移支持。

要手动处理该过程，您应该能够通过更改应用程序与新服务器通信或从故障服务器调整MySQL服务器的DNS到新服务器，从故障主服务器切换到预配置服务器。

有关更多信息和一些示例解决方案，请参见 第17.3.8节“在故障转移期间切换主站” 。

检查 binlog_format 系统变量 的值 ：

MySQL的> SHOW VARIABLES LIKE 'binlog_format';

示出的值将是一 STATEMENT ， ROW 或 MIXED 。 对于 MIXED 模式，默认情况下使用基于语句的日志记录，但复制会在某些条件下自动切换到基于行的日志记录，例如不安全的语句。 有关何时可能发生这种情况的信息，请参见 第5.4.4.3节“混合二进制日志格式” 。

Slaves自动知道要使用哪种格式。

使用 --replicate-wild-ignore-table=mysql.% 选项忽略 mysql 数据库 中表的复制来 启动服务器 。

是。

是。

MySQL线程池是一个MySQL服务器插件，它扩展了MySQL服务器的默认连接处理功能，以限制并发执行的语句/查询和事务的数量，以确保每个都有足够的CPU和内存资源来完成其任务。 对于MySQL 8.0，线程池插件包含在商业产品MySQL企业版中。

MySQL Server中的默认线程处理模型使用每个客户端连接一个线程执行语句。 随着越来越多的客户端连接到服务器并执行语句，整体性能会下降。 线程池插件提供了另一种线程处理模型，旨在减少开销并提高性能。 线程池插件通过有效管理大量客户端连接的语句执行线程来提高服务器性能，尤其是在现代多CPU /核心系统上。

有关更多信息，请参见 第5.6.3节“MySQL Enterprise线程池” 。

线程池使用 “ 分而治之 ”的 方法来限制和平衡并发。 与MySQL服务器的默认连接处理不同，线程池将连接和线程分开，因此连接与执行从这些连接接收的语句的线程之间没有固定的关系。 然后，线程池管理可配置线程组内的客户端连接，根据提交的工作性质对它们进行优先级排序。

有关更多信息，请参见 第5.6.3.3节“线程池操作” 。

MySQL连接池在客户端运行，以确保MySQL客户端不会经常连接到MySQL服务器和从MySQL服务器断开连接。 它旨在缓存MySQL客户端中的空闲连接，以供其他用户在需要时使用。 当查询提交到MySQL服务器时，这最小化了建立和拆除连接的开销和费用。 MySQL连接池无法查看查询处理功能或后端MySQL服务器的负载。 相比之下，线程池在MySQL服务器端运行，旨在管理从访问后端MySQL数据库的客户端连接接收到的入站并发连接和查询的执行。

第28章， 连接器和API中 介绍了通过MySQL连接器进行的MySQL连接池 。

对于最佳线程池用例，需要考虑一些经验法则：

MySQL Threads_running 变量跟踪当前在MySQL服务器中执行的并发语句的数量。 如果此变量始终超出服务器无法以最佳状态运行的区域（对于InnoDB工作负载通常超过40），则线程池将是有益的，尤其是在极端并行过载情况下。

如果您使用 innodb_thread_concurrency 限制并发执行语句的数量，您会发现线程池通过为线程组分配连接，然后根据事务内容，用户定义的名称等排队执行，只能更好地解决相同的问题。 。

最后，如果您的工作负载主要包含短查询，则线程池将是有益的。

要了解更多信息，请参见 第5.6.3.4节“线程池调整” 。

线程池有许多用户案例驱动的配置参数，这些参数会影响其性能。 要了解这些以及有关调优的提示，请参见 第5.6.3.4节“线程池调整” 。