1
MySQL 5.5 升级到高版本路径规划
基于 MySQL 官方升级路径、MySQL 8.0/8.4 兼容性说明和当前 Java/Maven 项目扫描，给出分阶段升级路径、改造点、运维步骤、测试清单和风险评估。
1. 背景与结论
flowchart LR A[MySQL 5.5] --> B[latest 5.6] B --> C[latest 5.7] C --> D[latest 8.0] D --> E[8.4 LTS] E --> F[稳定运行与监控]
要点
不能直接从 MySQL 5.5 升级到 5.7、8.0 或 8.4；最大应用风险集中在 ONLY_FULL_GROUP_BY、zero date、utf8/utf8mb4 漂移、native SQL、reserved words、认证插件和 sql_mode 变化。
当前系统 MySQL 版本计划从 5.5 升级到更高版本。本方案基于 MySQL 官方升级路径文档、MySQL 8.0/8.4 兼容性说明，以及当前 Java/Maven 项目代码扫描结果，给出分阶段升级路径、代码改造点、配置与运维步骤、测试验证清单和风险评估。
核心结论：
- 不能直接从 MySQL 5.5 升级到 5.7、8.0 或 8.4。官方不支持跨大版本跳升。
- 推荐路径：
MySQL 5.5 → 最新 5.6 → 最新 5.7 → 最新 8.0 → 可选最新 8.4 LTS2
当前项目主 Java 栈较新
Spring Boot 3.4.3、Hibernate 6.6.x、MySQL Connector/J 9.2.0。主应用驱动层不是最大阻塞点。
3
本项目最大应用风险集中在
ONLY_FULL_GROUP_BY导致历史宽松GROUP BY查询失败- zero date / temporal 兼容问题
utf8与utf8mb4字符集/排序规则漂移- native SQL / runtime DDL / 动态字段 SQL
- MySQL 8.0 reserved words、认证插件、sql_mode 变化
2. 官方支持的升级路径
2.1 推荐目标版本
| 目标 | 说明 | 推荐程度 |
|---|---|---|
| 最新 MySQL 5.7 | 只能作为中间过渡，不建议长期停留 | 低 |
| 最新 MySQL 8.0.x | 现代化主目标，生态兼容性成熟 | 高 |
| 最新 MySQL 8.4.x LTS | 当前长期支持目标，适合最终落点 | 最高 |
推荐策略：
第一阶段：5.5 → 5.6 → 5.7
第二阶段：5.7 → 8.0
第三阶段：8.0 稳定后 → 8.4 LTS如果业务风险较高，可把 8.4 作为第二期项目，先完成 8.0 稳定化。
2.2 支持路径与不支持路径
官方规则：
| 当前版本 | 目标版本 | 是否支持 | 说明 |
|---|---|---|---|
| 5.5 | 5.6 | 支持 | 需参考 archived 5.6 文档 |
| 5.5 | 5.7 | 不支持 | 不能跳过 5.6 |
| 5.6 | 5.7 | 支持 | 建议先升到最新 5.6 |
| 5.6 | 8.0 | 不支持 | 不能跳过 5.7 |
| 5.7.9+ GA | 8.0 | 支持 | 建议先升到最新 5.7 |
| 5.7 | 8.4 | 不支持 | 必须先到 8.0 |
| 8.0 | 8.4 LTS | 支持 | 官方支持 LTS 到下一 LTS |
最终路径：
5.5.x
↓
latest 5.6.x
↓
latest 5.7.x
↓
latest 8.0.x
↓
latest 8.4.x LTS3. 主要兼容性与 breaking changes
3.1 MySQL 5.5 → 5.6
重点风险：
1
历史 temporal 存储格式变化。
2
5.5 时代遗留的 TIME / DATETIME / TIMESTAMP 旧格式需要检查和重建。
3
必须参考 MySQL 5.6 archived manual / release notes。
4
升级后仍需执行 mysql_upgrade。
建议：
- 该阶段只作为过渡，不做大规模业务变更。
- 重点修复旧 temporal 格式和数据质量问题。
3.2 MySQL 5.6 → 5.7
重点风险：
1
默认 sql_mode 更严格。
2
ONLY_FULL_GROUP_BY 在 5.7 默认开启，容易导致历史 SQL 报错。
3
NO_ZERO_DATE / NO_ZERO_IN_DATE 等 date 行为需要关注。
4
需要执行 mysql_upgrade。
本项目最可能在该阶段暴露 SQL 兼容问题。
3.3 MySQL 5.7 → 8.0
重点变化：
| 类别 | MySQL 8.0 变化 | 对系统影响 |
|---|---|---|
| Data Dictionary | 8.0 使用 transactional data dictionary，替代旧 .frm 等元数据模式 | rollback 难度更高，不能依赖文件级元数据操作 |
| Auth Plugin | 默认认证插件从 mysql_native_password 改为 caching_sha2_password | 老客户端、BI 工具、脚本可能连接失败 |
| sql_mode | 移除 NO_AUTO_CREATE_USER 等旧模式 | my.cnf / session SQL / dump 文件中如存在会启动或导入失败 |
| Reserved Words | 8.0 新增保留字 | 表名、列名、alias、view、routine、动态 SQL 可能失败 |
| Charset/Collation | 默认从 latin1 变为 utf8mb4 / utf8mb4_0900_ai_ci | 新对象默认排序/比较规则变化 |
| GROUP BY | 不再依赖隐式排序，GROUP BY ... ASC/DESC 移除 | 需要显式 ORDER BY |
| Partition | 不再支持 generic partitioning，仅 InnoDB/NDB 原生支持 | 非 InnoDB partition 表需处理 |
| InnoDB | undo/redo、autoinc lock mode、metadata 变化 | 性能和导入/恢复流程要验证 |
| mysql_upgrade | 8.0.16 后 server 自动执行升级任务 | 运维流程不同于 5.7 以前 |
3.4 MySQL 8.0 → 8.4 LTS
重点：
1
官方支持 8.0 LTS/bugfix series 到 8.4 LTS。
2
升级前运行 MySQL Shell Upgrade Checker。
3
支持 in-place、logical dump/load、replication-based upgrade。
4
需先稳定运行在 8.0，再规划 8.4。
4. 当前项目 MySQL 使用现状
4.1 依赖栈
项目 parent：
pom.xml:5-9继承com.qdum.dmtx:dmt-maven-parent:3.4.3.8-jdk17-SNAPSHOT
Spring Boot：
- parent 间接继承
spring-boot-starter-parent:3.4.3
JPA：
biz-common/pom.xml:120-123引入spring-boot-starter-data-jpa
MySQL Connector：
biz-common/pom.xml:124-127引入com.mysql:mysql-connector-j- parent 管理版本为
9.2.0
Hibernate：
- Spring Boot 3.4.3 管理 Hibernate 6.6.x
判断：
- 主 Java 应用已经使用现代 Connector/J，支持 MySQL 8.x 认证和协议能力。
- 更大的风险是 SQL 语义和数据质量，而不是 Connector/J 版本。
- 外部脚本、BI、ETL 工具仍可能使用老客户端，需另行盘点。
4.2 未发现 MyBatis
仓库扫描未发现：
mybatismybatis-plus@Mapper@MapperScanSqlSessionFactory- mapper XML
因此本项目升级关注点应集中在：
- Spring Data JPA / Hibernate
EntityManager.createNativeQuery(...)JdbcTemplate- native SQL
- runtime DDL
4.3 数据源与 JDBC 配置
关键配置文件：
biz-common/resources/config/application.yml:18-44biz-common/resources/config/application.yml:113-127biz-common/bin/server.sh:105
当前 JDBC URL 模板包含：
useUnicode=true
characterEncoding=utf8
useSSL=false
serverTimezone=Asia/Shanghai
allowPublicKeyRetrieval=true
zeroDateTimeBehavior=convertToNullHibernate 配置中包含：
hibernate.timezone.default_storage: NORMALIZEJVM 启动脚本固定：
-Duser.timezone=Asia/Shanghai判断：
- 当前系统显式依赖 Asia/Shanghai 时区语义。
zeroDateTimeBehavior=convertToNull表明线上可能存在 zero date 历史数据。characterEncoding=utf8与部分 DDL 使用utf8mb4存在潜在不一致。
5. 项目代码影响分析
5.1 高风险：ONLY_FULL_GROUP_BY
MySQL 5.7+ 默认开启 ONLY_FULL_GROUP_BY 后，历史宽松 SQL 可能失败。
已确认风险位置：
rtjourney/src/main/java/com/qdum/dmtx/biz/rtjourney/dao/mysql/repository/JourneyRecordRepository.java:22-46wechat/src/main/java/com/qdum/dmtx/biz/wechat/service/JourneyReportService.java:300-345
风险模式：
SELECT 非聚合字段
FROM table
GROUP BY 部分字段
ORDER BY 非 group 字段在 MySQL 5.5 中可能运行，在 MySQL 5.7/8.x 中可能报错：
Expression #x of SELECT list is not in GROUP BY clause and contains nonaggregated column ...改造策略：
1
所有非聚合字段要么加入 GROUP BY。
2
要么使用聚合函数
MIN() / MAX() / ANY_VALUE()。
3
排序如果有业务含义，显式 ORDER BY。
4
不建议通过关闭 ONLY_FULL_GROUP_BY 规避，除非作为临时兼容方案。
示例：
-- 风险写法
SELECT task_id, name, COUNT(*)
FROM journey_report
GROUP BY task_id;
-- 改造写法 1：如果 name 与 task_id 函数依赖明确
SELECT task_id, MAX(name) AS name, COUNT(*)
FROM journey_report
GROUP BY task_id;
-- 改造写法 2：如果只是取任意值
SELECT task_id, ANY_VALUE(name) AS name, COUNT(*)
FROM journey_report
GROUP BY task_id;5.2 高风险：zero date / temporal 数据
当前 JDBC URL 使用：
zeroDateTimeBehavior=convertToNull风险：
- 线上可能存在
0000-00-00或0000-00-00 00:00:00。 - MySQL 5.7/8.0 严格模式下可能插入/更新失败。
- 应用层把 zero date 转成 null 会隐藏真实数据质量问题。
处理策略：
1
升级前扫描所有 date/datetime/timestamp 字段。
2
明确业务语义
未知时间用 NULL，不使用 zero date。
3
编写数据清理脚本。
4
保留 zeroDateTimeBehavior=convertToNull 作为过渡期兼容，但不能依赖它长期掩盖脏数据。
示例检查 SQL：
SELECT COUNT(*)
FROM some_table
WHERE some_datetime = '0000-00-00 00:00:00';5.3 中高风险：字符集与排序规则
当前连接参数使用：
characterEncoding=utf8但部分 DDL 已使用：
DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_unicode_ci风险：
- MySQL 8.0 默认 charset/collation 变为
utf8mb4/utf8mb4_0900_ai_ci。 utf8在 MySQL 中历史上常指utf8mb3，不能完整存储 4 字节字符。- 新建表如果没有显式指定 collation，可能和老表排序/比较规则不一致。
处理策略：
1
统一目标
建议标准化到 utf8mb4。
2
明确 collation
根据业务选择 utf8mb4_unicode_ci 或 utf8mb4_0900_ai_ci。
3
所有 runtime DDL 必须显式指定 charset/collation。
4
做 emoji / 多语言文本 round-trip 测试。
5
如暂不改变排序规则，应在 8.x 上显式保持原 collation，避免隐式漂移。
5.4 中高风险：native SQL / JdbcTemplate / EntityManager
典型文件：
wechat/src/main/java/com/qdum/dmtx/biz/wechat/service/WxDeleteDataService.javawechat/src/main/java/com/qdum/dmtx/biz/wechat/service/JourneyReportService.javacontact/src/main/java/com/qdum/dmtx/biz/contact/service/ContacatImportDisposeService.javartjourney/src/main/java/com/qdum/dmtx/biz/rtjourney/dao/mysql/repository/JourneyRecordRepository.java
风险：
- reserved words
- sql_mode 严格化
- parser 行为变化
- collation 比较差异
- 动态字段名拼接风险
特别说明：
ContacatImportDisposeService.java:408,569,715 存在动态 SQL 字段名拼接。该问题不只是升级兼容性问题，也属于安全和正确性风险。升级项目应顺手增加字段白名单校验。
5.5 中风险：reserved words
已发现关键风险字段：
etl/src/main/java/com/qdum/dmtx/biz/etl/dao/mysql/domain/MetadataMigrationRecordDetail.java:110使用@Column(name = "key")
key 是 MySQL 关键字/保留字风险较高的 identifier。
处理策略：
1
ORM 路径一般可通过 quoting 规避。
2
手写 SQL、DDL、导入导出脚本必须统一反引号。
3
中长期建议重命名为业务语义更明确字段，例如 meta_key。
5.6 中风险：runtime DDL
典型位置：
contact/src/main/java/com/qdum/dmtx/biz/contact/service/DataCollectService.java:97-134
风险：
- 运行时建表如果不显式指定 engine/charset/collation，会继承 MySQL 8.x 新默认值。
- MySQL 8.0 parser 和 DDL 规则更严格。
- auto_increment / generated keys 需要验证。
处理策略：
- 所有 runtime DDL 明确：
ENGINE=InnoDBDEFAULT CHARSET=utf8mb4COLLATE=...
- 在 8.0/8.4 staging 上实际执行建表路径。
- 校验自动生成主键、索引、字段类型。
5.7 低到中风险：认证插件
主应用 Connector/J 9.2.0 已较新，理论支持 MySQL 8.x 默认 caching_sha2_password。
但仍需检查：
- 运维脚本
- BI 工具
- ETL 工具
- 旧 Java 服务
- 手工 mysql client
- 第三方同步工具
临时兼容方案：
ALTER USER 'app_user'@'%'
IDENTIFIED WITH mysql_native_password
BY 'password';长期建议：
- 使用支持
caching_sha2_password的客户端。 - 使用 TLS 或安全密码交换配置。
6. 升级前数据库预检查
6.1 版本与环境盘点
SELECT VERSION();
SHOW VARIABLES LIKE 'version%';
SHOW VARIABLES LIKE 'sql_mode';
SHOW VARIABLES LIKE 'character_set_server';
SHOW VARIABLES LIKE 'collation_server';
SHOW VARIABLES LIKE 'lower_case_table_names';
SHOW VARIABLES LIKE 'default_authentication_plugin';6.2 zero date 检查
需要针对所有 date/datetime/timestamp 字段生成检查 SQL。
示例：
SELECT COUNT(*)
FROM table_name
WHERE date_col = '0000-00-00'
OR datetime_col = '0000-00-00 00:00:00';6.3 sql_mode 检查
SELECT @@GLOBAL.sql_mode;
SELECT @@SESSION.sql_mode;MySQL 8.0 前必须移除：
NO_AUTO_CREATE_USER
DB2
MAXDB
MSSQL
MYSQL323
MYSQL40
ORACLE
POSTGRESQL
NO_FIELD_OPTIONS
NO_KEY_OPTIONS
NO_TABLE_OPTIONS6.4 MySQL Shell Upgrade Checker
MySQL Shell Upgrade Checker 不支持检查太老的 5.5，但在 5.7 → 8.0、8.0 → 8.4 前必须使用。
示例：
mysqlsh -- util checkForServerUpgrade user@host:3306 \
--target-version=8.0.37 \
--output-format=JSON \
--config-path=/etc/my.cnf8.4 前：
mysqlsh -- util checkForServerUpgrade user@host:3306 \
--target-version=8.4.0 \
--output-format=JSON \
--config-path=/etc/my.cnf6.5 mysqlcheck
5.7 → 8.0 前：
mysqlcheck -u root -p --all-databases --check-upgrade6.6 schema 与对象检查
需检查：
1
reserved words 表名/列名/别名。
2
views / routines / triggers。
3
invalid definer。
4
partitioned table engine。
5
foreign key name 长度。
6
ENUM / SET 长度限制。
7
MyISAM 表。
8
old temporal columns。
9
使用 PASSWORD() 的 SQL。
10
GRANT ... IDENTIFIED BY ... 旧语法。
7. 运维升级步骤
7.1 总体原则
1
每个大版本 hop 前必须完整备份。
2
每个 hop 必须在生产等量级 clone 环境演练。
3
每个 hop 完成后先做应用回归，再进入下一阶段。
4
5.7 → 8.0 是最大风险点，必须单独设置评审门禁。
5
8.0 data dictionary 迁移后 rollback 复杂度显著上升，必须提前演练恢复。
7.2 Phase 0：基线盘点
输出以下清单：
- MySQL 实例列表
- 版本号
- 拓扑：单机 / 主从 / MGR / 其他
- 存储引擎
- 表数量与数据量
- 最大表 TOP N
- partition 表
- MyISAM 表
- 字符集/排序规则
sql_mode- 用户认证插件
- 外部客户端列表
- 业务低峰窗口
- rollback 负责人
7.3 Phase 1：5.5 → 最新 5.6
步骤：
1
全量备份并验证恢复。
2
停止应用写入或切换只读。
3
升级 MySQL Server 到最新 5.6。
4
启动 MySQL。
5
执行 mysql_upgrade。
6
重启 MySQL。
7
检查 error log。
8
运行应用 smoke test。
9
处理 old temporal 格式问题。
7.4 Phase 2：5.6 → 最新 5.7
步骤：
1
确认 5.6 最新 patch。
2
全量备份并验证恢复。
3
升级 MySQL Server 到最新 5.7。
4
启动 MySQL。
5
执行 mysql_upgrade。
6
重启 MySQL。
7
开启接近目标的 strict sql_mode 做预演。
8
修复 ONLY_FULL_GROUP_BY SQL。
9
运行业务回归。
7.5 Phase 3：5.7 → 最新 8.0
步骤：
- 确认版本为 5.7.9+，建议最新 5.7。
- 执行：
mysqlcheck -u root -p --all-databases --check-upgrade1
执行 MySQL Shell Upgrade Checker。
2
修复所有 errors，评估 warnings。
3
清理 removed sql_mode。
4
清理 zero date / old temporal。
5
检查 reserved words。
6
检查 auth plugin。
7
设置 clean shutdown
SET GLOBAL innodb_fast_shutdown = 0;1
正常关闭 MySQL。
2
升级到最新 8.0。
3
启动 MySQL，观察 server 自动升级日志。
4
检查 error log。
5
运行应用完整回归。
6
观察慢 SQL、连接失败、SQL 异常。
7.6 Phase 4：8.0 → 8.4 LTS
前置条件：
- 8.0 稳定运行至少一个完整业务周期。
- 所有 SQL 兼容性问题已修复。
- 外部客户端均支持 8.x。
步骤：
1
执行 MySQL Shell Upgrade Checker，targetVersion 为 8.4.x。
2
修复所有 blocker。
3
备份并验证恢复。
4
选择升级方式
- in-place
- logical dump/load
- replication-based rolling upgrade
1
升级到 8.4 LTS。
2
回归核心业务。
3
更新运维文档和监控规则。
8. 应用改造与测试清单
8.1 必改项
| 优先级 | 改造项 | 说明 |
|---|---|---|
| P0 | 修复 ONLY_FULL_GROUP_BY 不兼容 SQL | JourneyRecordRepository、JourneyReportService 优先 |
| P0 | zero date 数据清理 | 不再长期依赖 zeroDateTimeBehavior=convertToNull |
| P0 | 外部客户端兼容性盘点 | 特别是 MySQL 8.0 认证插件 |
| P1 | 统一 charset/collation 策略 | 建议统一到 utf8mb4 |
| P1 | native SQL reserved words 审计 | 特别是 key 字段 |
| P1 | runtime DDL 显式 engine/charset/collation | 避免继承 8.x 新默认值 |
| P1 | 动态 SQL 字段白名单 | ContacatImportDisposeService 等位置 |
| P2 | 优化 SQL hints/index hints | 8.x optimizer 变化后需重新评估 |
8.2 测试范围
| 模块 | 测试内容 | 重点 |
|---|---|---|
| rtjourney | JourneyRecordRepository native query | GROUP BY 兼容 |
| JourneyReportService / WxDeleteDataService | native SQL、统计结果 | |
| contact | DataCollectService runtime DDL | 建表、auto_increment、charset |
| contact | ContacatImportDisposeService | 动态字段 SQL 白名单 |
| etl | MetadataMigrationRecordDetail | key 字段 quoting |
| questionnaire | PersistentAuditEvent / temporal 字段 | timestamp/date 行为 |
| 全系统 | 登录、写入、查询、导出 | 连接、事务、字符集 |
8.3 集成测试环境矩阵
| 环境 | 目的 |
|---|---|
| MySQL 5.6 最新 patch | 验证第一跳 |
| MySQL 5.7 最新 patch | 暴露 ONLY_FULL_GROUP_BY、strict mode 问题 |
| MySQL 8.0 最新 patch | 验证 data dictionary、auth、charset、reserved words |
| MySQL 8.4 LTS | 最终目标验证 |
8.4 回归指标
1
应用能正常启动。
2
所有 datasource 连接成功。
3
登录/核心接口成功。
4
核心报表结果与升级前一致。
5
native SQL 无 GROUP BY / reserved word / sql_mode 报错。
6
时间字段无偏移。
7
emoji / 多语言字段读写正常。
8
导入导出功能正常。
9
慢 SQL 数量无明显增加。
10
连接池无异常耗尽。
9. Rollback 策略
9.1 5.5 → 5.6 / 5.6 → 5.7
rollback 方式：
- 优先通过备份恢复。
- 不建议直接二进制降级。
- 每个 hop 前保留完整备份和 binlog 位点。
9.2 5.7 → 8.0
这是最关键 rollback 点。
原因：
- MySQL 8.0 引入 transactional data dictionary。
- 一旦完成 8.0 metadata upgrade，直接回退到 5.7 风险高。
策略：
1
升级前必须验证备份可恢复。
2
保留 5.7 原实例快照。
3
如生产允许，优先采用 replication-based 或蓝绿切换方式。
4
8.0 首次启动失败时不要反复盲目启动，先分析 error log。
5
回退以恢复 5.7 备份为主。
9.3 8.0 → 8.4
策略：
- 与 8.0 升级类似，先执行 upgrade checker。
- 保留 8.0 备份和实例快照。
- 如果使用 replication-based upgrade，可保留旧主库作为回退窗口。
10. 风险评估
| 风险 | 严重级别 | 可能性 | 说明 | 应对策略 |
|---|---|---|---|---|
| 直接跨版本升级 | 高 | 中 | 官方不支持 5.5→5.7、5.6→8.0、5.7→8.4 | 严格按 staged path |
ONLY_FULL_GROUP_BY SQL 报错 | 高 | 高 | 已发现风险 SQL | 提前改 SQL 并在 5.7/8.x 测试 |
| zero date 数据导致失败 | 高 | 中 | 当前 URL 使用 convertToNull，说明可能有历史脏数据 | 升级前扫描和清理 |
| 8.0 data dictionary rollback 困难 | 高 | 中 | 8.0 元数据升级不可轻易回退 | 备份恢复演练、蓝绿或复制升级 |
| 外部客户端 auth 失败 | 中高 | 中 | 8.0 默认 caching_sha2_password | 盘点外部客户端，必要时临时 mysql_native_password |
| charset/collation 漂移 | 中高 | 中 | 当前 utf8 与 utf8mb4 混用 | 统一 utf8mb4 策略 |
| reserved word 冲突 | 中 | 中 | 已发现 key 字段 | quote 或重命名 |
| runtime DDL 继承新默认值 | 中 | 中 | 动态建表路径存在 | 显式 engine/charset/collation |
| optimizer 改变导致性能回退 | 中 | 中 | 8.x optimizer 改动较多 | explain 对比、慢 SQL 监控 |
| 动态 SQL 字段拼接 | 高 | 中 | 同时是安全风险 | 字段白名单和参数化改造 |
11. 工作量评估
| 模块 | 工作项 | 预估人天 |
|---|---|---|
| DBA/运维 | 实例盘点、版本路径确认、备份恢复演练 | 2 - 4 |
| DBA/运维 | 5.5→5.6→5.7 staging 演练 | 2 - 4 |
| DBA/运维 | 5.7→8.0 upgrade checker 修复协同 | 2 - 5 |
| 后端 | 修复 ONLY_FULL_GROUP_BY 风险 SQL | 2 - 4 |
| 后端 | native SQL / reserved words 审计 | 1 - 3 |
| 后端 | 动态 SQL 字段白名单改造 | 1 - 2 |
| 后端 | runtime DDL 显式 charset/collation | 1 - 2 |
| 数据治理 | zero date / old temporal 扫描和清理 | 2 - 5 |
| 测试 | 5.7、8.0、8.4 集成回归 | 4 - 8 |
| 联调 | 应用、DBA、外部客户端联合验证 | 2 - 4 |
| 合计 | 不含大规模数据迁移 | 17 - 41 人天 |
如需要全库 utf8mb4/collation 迁移、zero date 大规模修复或蓝绿复制切换，需另行增加 5 - 15 人天。
12. 推荐执行顺序
Step 1：冻结基线
- 确认所有 MySQL 实例版本。
- 确认业务库、只读库、报表库、ETL 库。
- 确认外部客户端。
- 确认备份恢复能力。
Step 2：应用 SQL 先行整改
优先修复：
1
ONLY_FULL_GROUP_BY。
2
zero date。
3
dynamic SQL identifier allowlist。
4
runtime DDL charset/collation。
5
reserved words。
Step 3：生产数据 clone 演练
在 clone 环境完整执行：
5.5 → 5.6 → 5.7 → 8.0记录每一步耗时、错误、修复脚本。
Step 4：正式分阶段升级
每个阶段都必须满足 gate：
- 备份验证通过
- 升级日志无 blocker
- 应用 smoke test 通过
- 核心业务回归通过
- 慢 SQL 无严重回退
Step 5：8.0 稳定后规划 8.4
- 等 8.0 稳定运行一个完整业务周期。
- 再执行 8.4 upgrade checker。
- 独立安排 8.4 LTS 升级窗口。
13. 官方参考资料
- MySQL 5.7 Reference Manual - Upgrade Paths
- MySQL 8.0 Reference Manual - Upgrade Paths
- MySQL 8.0 Reference Manual - Changes in MySQL 8.0
- MySQL 8.0 Reference Manual - Preparing Your Installation for Upgrade
- MySQL 8.0 Reference Manual - Keywords and Reserved Words
- MySQL 8.0 Reference Manual - mysql_upgrade
- MySQL 8.4 Reference Manual - Upgrade Paths
- MySQL 8.4 Reference Manual - Upgrade Best Practices
- MySQL Shell 8.4 - Upgrade Checker Utility
- MySQL Documentation Archive
- MySQL 5.6 Reference Manual PDF
- MySQL 5.6 Release Notes PDF
- MySQL Blog Archive - Upgrading old MySQL-5.5 format temporals to MySQL-5.6 format
14. 方案质量自检
| 检查项 | 分数 | 说明 |
|---|---|---|
| 需求理解 | 4/4 | 明确从 MySQL 5.5 升级到高版本的路径和验收关注点 |
| 竞品/行业实践 | 3/4 | 本方案以 MySQL 官方路径和生产数据库升级最佳实践为依据，未做营销竞品调研，因为该需求是基础设施升级 |
| 用户/运维体验 | 5/6 | 给出分阶段 gate、命令、检查清单和 rollback 策略 |
| 技术完整度 | 6/6 | 覆盖依赖、配置、SQL、数据、运维、测试、风险 |
| 可行性 | 4/4 | 给出工作量和执行顺序 |
| 附加分 | 2/2 | 给出 8.0 与 8.4 LTS 分阶段目标策略 |
总分: 24 / 26
结论：方案可提交评审。