问： 是否可以直接从 MySQL 5.7 升级到 8.4（或跳过主要版本） ？
答： 不支持跨主版本升级（例如，直接从 MySQL 5.7 升级到 8.4）。 必须从 5.7 升级到 8.0，然后从 8.0 升级到 8.4。 如果将来发布了新的 MySQL 主版本，则不支持跳过主要版本的直接升级。 必须按顺序执行每个主版本升级。
问： 这是否会导致服务器的停机，如果是这样，多久？
答： 如需在升级期间实现最小停机时间，请按照如何使用只读副本实现最小停机时间主版本升级中提到的步骤进行操作。 服务器在升级过程中不可用，因此建议在计划内维护时段执行此作。 估计的停机时间取决于数据库大小、预配的存储大小（已预配的 IOP）和数据库上的表数。 升级时间与服务器上的表数成正比。 若要估计服务器环境的停机时间，建议先对服务器的还原副本执行升级。
问： 我使用的是 HA 服务器。是否可以预期主版本升级的几乎零停机体验，类似于常规维护？
答： 否。 主要版本升级与日常维护有很大不同。 HA 主服务器与备用服务器在跨主版本时的复制不够稳定，因此我们无法在 Azure Database for MySQL 中为此类升级提供接近零停机的体验。
问： 升级后我的备份会发生什么情况？
答： 在主版本升级之前执行的所有备份（自动/按需）将在用于还原时还原到具有以前版本的服务器。 在主版本升级后执行的所有备份（自动/按需）将还原到具有升级版本的服务器。 强烈建议在执行主要版本升级之前先进行一次手动备份，以便在需要时轻松回滚。
已知问题和限制
Microsoft Entra ID 身份验证在副本上被阻止
如果主服务器及其副本都配置了Microsoft Entra身份验证，并且对副本执行主版本升级（从 5.7 升级到 8.0 或从 8.0 到 8.4），则对主副本上的 Entra 身份验证配置所做的任何后续更改都可能导致升级的副本出现问题。 具体而言，副本的身份验证方法从“MySQL 和 Entra 身份验证”重置为“仅 MySQL 身份验证”，从而阻止副本上的Microsoft Entra ID身份验证。
解决方案
若要避免此问题，请不要在主版本和副本在不同的 MySQL 版本上运行时修改Microsoft Entra身份验证配置。 只有在复制层次结构中的每个服务器都升级到同一版本后，才更改Entra ID身份验证设置。
如果已遇到此问题，请使用以下步骤进行恢复：
- 将主服务器升级到版本 8.0（或 8.4），并配置所需的Microsoft Entra管理员用户
- 在版本 8.0 上创建新副本（或 8.4）
- 停用已中断复制的旧副本
- 将工作负载切换到使用新副本
与 5.7 相比，8.0 中的 CPU 使用率缓慢或较高
与 5.7 相比，根据工作负荷的不同，可以在版本 8.0 中观察到速度缓慢或 CPU 使用率较高。 建议升级只读副本或还原并升级到 Azure Database for MySQL 灵活服务器 8.0。 在升级主实例之前，应当使用该副本来测试和调优生产负载和查询。
如果在更新/插入/删除等查询中观察到速度缓慢，则在服务器的门户页面侧窗格中的“设置计算 + 存储”>下启用服务器上的加速日志可能会有所帮助。
从 5.7 升级到 8.0（以及 8.4）后，插入带分数秒和时区偏移量的时间戳字面量时会出现静默数据不一致问题
在 MySQL 8.0 中，同时包含小数秒和时区偏移量的时间戳字面量（例如 '2025-01-01 12:00:00.123+00:00'）在 INSERT 或 UPDATE 操作期间，可能会在未发出提示的情况下被静默转换为错误的值。 错误的值在没有任何报错或警告的情况下被存储，这可能会导致难以在事后发现的数据不一致。 如果应用程序以此格式插入日期时间值，则从 MySQL 5.7 升级到 8.0（和 8.4）的客户可能会遇到此问题。
这是一个已知的 MySQL 社区 bug。 有关详细信息，请参阅 MySQL Bug #118011。
解决方案
在上游修补程序可用之前和之后，在升级前后采取以下预防措施：
- 审核将小数秒与时区偏移量组合在一起的时间戳文本的应用程序代码，并在插入前将其规范化为 UTC（或单个时区），而无需内联偏移量。
- 显式设置会话或服务器
time_zone，并写入不带内联偏移量的日期时间值，以便服务器始终一致地应用已配置的时区。 - 在升级后验证新插入行的代表性示例，以确认存储的值是否与预期值匹配。