2018年，MySQL 官方发布了全新的社区版本 MySQL 8.0，相较于社区版本 MySQL 5.7，其在性能、功能、安全性和可维护性等方面均有显著提升。尽管社区版本 MySQL 5.7 拥有广泛的用户群体，属于备受信赖的服务版本，但 MySQL 官方已于2023年10月起，停止了对社区版本 MySQL 5.7 进行问题修复和功能更新。因此，MySQL 官方鼓励和建议用户将 MySQL 5.7升级至 MySQL 8.0以获得更出色的数据库服务。但 MySQL 5.7升级到 MySQL 8.0并非易事，升级前需要做大量的准备工作，升级过程中也会出现升级失败又难以解析失败原因的情况，使得用户对于升级数据库版本变得警惕而慎重。鉴于以上背景，腾讯云 MySQL 为用户提供了轻松便捷的解决方案，帮助用户稳定实现 MySQL 5.7升级至 MySQL 8.0。本文为您介绍 MySQL 官方数据库版本的生命周期支持情况、社区版本 MySQL 5.7升级至 MySQL 8.0的问题以及腾讯云 MySQL 提供的解决方案。
MySQL 官方数据库版本生命周期支持情况
MySQL 5.7版本由 Oracle 公司于2015年10月正式发布，作为对 MySQL 5.6的重大升级，其在性能优化、功能扩展及安全增强等方面均有显著突破，迅速成为企业级数据库部署的主流选择。2018年，MySQL 8.0的推出进一步提升了数据库技术的边界。2023年10月25日，MySQL 社区发布了5.7系列的最终版本5.7.44，标志着该版本正式进入生命周期终止阶段，此后将不再提供问题修复和功能更新。基于技术演进与安全维护的长期考量，官方强烈建议用户迁移至持续维护的 MySQL 8.0版本，以获得更完善的技术支持与更先进的数据库特性。
社区版本 MySQL 8.0核心特性
特性 | 说明 |
解决了 MySQL 5.7版本中 DDL 中断导致文件残留的问题，确保了文件操作的原子性，同时解决了 Server 层和引擎层数据不一致的问题。 | |
大大缩短 DDL 执行的时长，快速完成表结构的变更，同时消除了 Binlog 复制延迟。 说明： | |
相比传统的复制方式更加高效，直接在源实例上进行授权和克隆，极大地提高了 MySQL 的可扩展性。 | |
可以将索引设置对优化器不可见，从而避免潜在的重复删除和重建索引的操作。 | |
新增了多个与 JSON 相关的函数，并对 JSON 的内存使用进行了优化。 |
腾讯云 MySQL 8.0核心特性
说明：
特性 | 说明 |
腾讯云 TXSQL 内核团队针对并行复制功能进行了优化，支持按 table 并行，相当于将其粒度拆分至表，提升了并行度，从而减少主从延迟。 | |
对线程池动态切换进行优化，在不重启数据库服务的情况下，可动态开启或关闭线程池。 | |
支持创建 range 或 list 类型的二级分区，提高数据的管理和查询效率。 | |
支持将用户 drop table、truncate table 操作的表放入到回收站中，以便在需要时可以恢复这些数据。 | |
在 InnoDB 引擎上设计和实现了闪回查询功能，仅需通过简单的 SQL 语句即可查询误操作前的历史数据。 | |
Kill 超过一定时长的空闲事务，及时释放资源。 |
社区版本 MySQL 5.7升级至 MySQL 8.0的问题
问题1：升级前需要做大量的准备工作
MySQL 8.0版本在数据字典架构重构、存储引擎优化及 SQL 语法扩展等方面有较多重大变化，与 MySQL 5.7版本存在显著的版本差异和功能演进。为确保升级过程的平稳性，建议在版本迁移前进行全面兼容性评估，并制定完备的预检方案与应急预案，以规避潜在的技术风险。MySQL 8.0和 MySQL 5.7的主要差异如下图所示，详细差异请参见 MySQL 官方文档。
MySQL 5.7升级到 MySQL 8.0是通过 inplace upgrade 的方式进行的，即直接使用 MySQL 8.0的二进制文件来启动 MySQL 5.7的实例，升级程序将自动进行相关的检查和升级。
升级前的准备工作是为了消除升级程序中无法自动处理的“不兼容的”变化。主要工作如下。
MySQL 8.0引入了全新的数据字典用于保存数据库中的元信息，Server 层和 InnoDB 层共享一份元数据。MySQL 8.0的 information_schema 中的视图全部源自于数据字典表，与 InnoDB 相关的视图被重命名（INNODB_SYS_XXX 重命名为 INNODB_XXX）。若用户的应用依赖于这些视图，需要确保应用已做出相应的修改。在升级前需要确认业务是否依赖于 MySQL 8.0中删除的系统表（如 mysql.proc、mysql.event 等），若依赖则需使用新的访问方式去获取所需的数据。此外，对于和 MySQL 8.0系统表同名的用户表（如 catalogs、routines 等），需要手动执行
RENAME/DROP TABLE 操作。腾讯云 MySQL 8.0不再支持部分旧版本数据类型。如果表中字段含有 MySQL 8.0不支持的数据类型，需要在升级前通过
REPAIR TABLE 或逻辑导出加导入的方式修复。更多信息请参见 准备升级。MySQL 8.0中，分区表的处理已由 Server 层下沉至引擎层，MySQL Server 不再支持通用分区。Non-native 的分区表在 MySQL 8.0中被废弃，因此需要将这类分区表改为 Native 类型（如 InnoDB 引擎）或是删除该分区表。
较早版本的 MySQL 5.7（5.0.17之前的版本）的触发器（Triggers）不支持 DEFINER 属性，因此在 MySQL 5.7实例中可能会存在缺失 DEFINER 属性的触发器，这些触发器会导致升级 MySQL 8.0失败。在升级前您需要重新创建这些缺失 DEFINER 属性的触发器。
MySQL 8.0中，外键约束的长度存在限制，如果外键约束过长，在升级过程中可能会导致错误和失败。因此，在进行升级之前，需要将外键约束的长度修改为小于64个字符。
MySQL 8.0之前版本，视图的列名长度上限为255个字符，而在 MySQL 8.0版本中，视图的列名长度上限缩短至64个字符。因此，在进行升级之前，需要将视图中过长的列名修改为长度小于64个字符的列名。
MySQL 8.0中，单个 ENUM 和 SET 列元素的长度不得超过255个字符或1020个字节，因此在升级之前需要修改超出限制的 ENUM 和 SET。
如果 .frm 文件和 InnoDB 数据字典表元数据信息不一致，那么会导致升级错误。因此，在进行升级之前，需要对数据进行逻辑导出和导入。若存在游离的 .frm 文件（即不含 .ibd 文件仅有 .frm 文件），则需要进行相应清理。
MySQL 8.0废弃了部分空间函数。如果生成列中包含了已删除的函数（新引入的空间函数以“ST”和“MBR”开头），则需要在升级前对相应的列进行修改。
在进行升级前，必须确保 MySQL 5.7的实例已经进行了正确的关闭，即需要确保在升级前不存在待应用的 REDO 日志和等待回滚的事务。
MySQL 8.0中引入了一些新的保留字，其中大多数禁止用作表名、列名等，因此需要对 MySQL 5.7中包含的 MySQL 8.0引入的新保留字做处理。
在升级前，需要将废弃的 sql_mode 变量内容（例如 NO_AUTO_CREATE_USER 等）修改为 MySQL 8.0支持的模式，以避免导致实例无法启动。
较新版本的 MySQL 8.0实例（8.0.13及之后的版本），共享表空间（系统表空间和通用表空间）中不允许存在 InnoDB 类型的分区表，因此在进行升级前需要将共享表空间移动至独立表空间。
MySQL 8.0实例中，GROUP BY 子句不支持 ASC 或 DESC 排序规则，因此，在进行升级前，需要修改或删除包含相应句法的存储过程。
在 MySQL 5.7中，lower_case_table_names 是一个可修改的值，但在 MySQL 8.0中，lower_case_table_names 是一个初始化参数，一旦实例初始化完成，就无法在后续进行修改。在进行升级时，若需要将该参数值修改为1，请确保升级前库表名称为小写，以避免出现升级错误。
MySQL 5.7和 MySQL 8.0的字符集和排序规则的配置可能存在差异，这可能导致索引失效、查询报错等问题，例如：
MySQL 8.0默认字符集为 utf8mb4，使用1 - 4字节存储一个字符，MySQL 5.7默认字符集为 utf8mb3，使用1 - 3字节存储一个字符，因此字段和索引长度会受到影响。在 REDUNDANT 或者 COMPACT 行格式下，InnoDB 引擎所允许的最大索引长度为767字节，对应在 MySQL 5.7中索引允许的最大字符数是255，而在8.0中则无法创建超过191字符的索引。
当在 MySQL 5.7中使用了 utf8mb3 字符集创建表，如果升级 MySQL 8.0后默认使用的字符集为 utf8mb4，新建表在没有指定 character set 时默认使用 utf8mb4。当新表（utf8mb4）和迁移表（utf8mb3）相关字段发生 JOIN 时，会因为 JOIN 两端字符集类型不一致导致索引失效。
当在 MySQL 5.7中使用了 utf8mb4_general_ci 排序规则创建表，如果升级到 MySQL 8.0后，默认使用的排序规则为 utf8mb4_0900_ai_ci，新建表在没有指定 collation 时默认使用 utf8mb4_0900_ai_ci。由于 utf8mb4_general_ci和utf8mb4_0900_ai_ci 优先级相同（无法选择排序规则），当新表和迁移表相关字段发生 JOIN 时，会因为 JOIN 两端排序规则不兼容导致报错。
为避免出现字符集引发的问题，在升级前需要检查 MySQL 中的字符集和排序规则使用情况，您也可以通过下述 SQL 来修改库、表、字段的字符集和排序规则。
# 修改库的字符集和排序规则ALTER DATABASE database_name CHARACTER SET = charset COLLATE = collation;# 修改表的字符集和排序规则ALTER TABLE table_name CONVERT TO CHARACTER SET charset COLLATE collation;# 修改字段的字符集和排序规则ALTER TABLE table_name CHANGE column_name column_name type CHARACTER SET charset COLLATE collation;
除了上述的准备工作外，版本间存在的驱动、错误码、参数、优化器差异等也需要业务上做适配。对于自建用户，在进行 MySQL 5.7到 MySQL 8.0的大版本升级前，可以利用 MySQL Shell、mysqlcheck 工具和社区的升级检查文档检查准备工作。MySQL 5.7升级到 MySQL 8.0的变化和检查细节请参见 MySQL 官方文档。
问题2：升级失败且难以分析失败原因
尽管社区提供了完善的升级检查工具和详尽的帮助文档以辅助用户完成版本升级前的兼容性评估和问题排查，但在实际升级操作过程中仍频繁出现升级失败的情况，并且很难从日志信息中逐一分析升级失败的原因。升级失败分析困难的原因包括但不限于以下几点：
报错不明确。不同原因导致的错误，在日志中可能会记录为相同或相似的错误。用户需要投入大量时间和精力来排查错误的根本原因，这增加了升级的难度。
报错不完整。在问题出现后，针对性地解决后发现重复的问题再次导致失败。这是因为升级程序在首次检测到某一类错误时就提前退出，导致相同问题无法一次性全部被检测到。用户需要进行多次尝试和排查，这增加了升级的复杂性和时间成本。
部分错误只提供了错误提示，却没有相应的解决方案。用户需要自行查找解决方案或向社区寻求帮助，这增加了升级过程中的困惑和不确定性。
部分 MySQL 5.7或更早版本存在的问题已经得到修复，但对存量实例的处理仍然存在不足。
使用腾讯云 MySQL 轻松实现 MySQL 5.7升级至 MySQL 8.0
腾讯云 MySQL 数据库团队积累了丰富的经验，建立了完善的升级前检查逻辑，对升级中产生的问题进行了分析和修复，保障升级平稳进行。腾讯云 MySQL 也将延长对不同版本的 MySQL 的支持期限，为用户提供更充裕的缓冲时间。社区 MySQL 和腾讯云 MySQL 生命周期如下：
版本 | 腾讯云支持开始日期 | 腾讯云支持结束日期 | 社区停用日期 |
MySQL 5.7 | 2017年6月 | 2028年9月 | 2023年10月 |
MySQL 8.0 | 2020年8月 | - | 2026年4月 |
与自建 MySQL 自行升级的用户相比，用户进行腾讯云 MySQL 的大版本升级时，无需进行繁琐的检查，也无需反复核查错误日志并逐一解决问题，仅需点击控制台上的升级按钮，所有升级动作将在后台自动完成。
升级方法
总结
在进行数据库大版本升级时，必须进行详细的升级前检查，逐步解决升级过程中出现的问题，并且完成升级后的验证和测试工作。或许腾讯云 MySQL 并未完全解决 MySQL 5.7升级到 MySQL 8.0过程中的所有问题，但腾讯云 MySQL 团队一直在进行相关问题的修复和建设，并为用户提供了简便和高效的数据库大版本升级机制。随着 MySQL 8.0版本的稳定推进，数据库大版本升级的问题会逐步得到解决。
相关文档
自建 MySQL 或第三方云数据库 MySQL 迁移至腾讯云 MySQL 的方法请参见 使用 DTS 服务迁移。
了解数据库版本以及 MySQL 8.0和 MySQL 5.7版本功能差异，请参见 数据库版本。
