MySQL 5.6 与 8.0 之间的差异是跨越式的中间还隔了一个重要的 5.7 版本,8.0 并非 5.6 的简单增强而是在架构设计、SQL 标准支持、安全模型和性能优化上都进行了重构1.核心差异总览对比维度MySQL 5.6MySQL 8.0SQL 功能基础 SQL不支持窗口函数、CTE支持窗口函数、CTE、角色JSON 功能增强数据字典元数据存储于文件和非事务表中非原子事务性数据字典元数据存储在 InnoDB 中支持原子 DDL默认字符集latin1 or utf8(utf8mb3)utf8mb4查询缓存存在默认禁用已彻底移除索引特性不支持降序索引DESC被忽略支持降序索引、不可见索引复制与高可用基于 GTID 的复制较新特性增强的复制功能支持异步连接故障转移安全性mysql_native_password为默认认证插件caching_sha2_password为默认引入角色和动态权限InnoDB 优化基础 InnoDB 功能大量并发优化如分拆 kernel mutex、flush 操作分离2. SQL 语法与功能增强窗口函数 (Window Functions)5.6 不支持, 8.0 引入了完整的窗口函数如ROW_NUMBER(),RANK(),LEAD(),LAG()使得在查询中直接进行复杂的排名、移动平均和同比/环比分析成为可能无需再依赖自连接或复杂的子查询公用表表达式 (CTE)5.6 不支持,8.0 支持WITH子句包括递归 CTE,这极大地简化了层级数据如组织架构树、分类目录的查询和复杂子查询的编写使 SQL 逻辑更清晰JSON 支持5.6 对 JSON 的支持非常有限,8.0 提供了原生的 JSON 数据类型和丰富的函数如JSON_TABLE可以直接将 JSON 数据当作关系表来查询大大提升了处理半结构化数据的效率3.架构与性能优化数据字典与原子 DDL5.6 的元数据存储在文件和非事务性表中DDL 操作不具备原子性,8.0 引入了事务性数据字典将所有元数据存储在 InnoDB 表中,这直接带来了原子 DDL一个 DDL 操作要么完全成功要么完全失败不会出现中间状态极大提升了数据库在崩溃时的安全性和可靠性查询缓存移除5.6 中查询缓存已默认禁用且在高并发场景下容易成为瓶颈,8.0 得益于更高效的编解码器、自适应哈希索引优化以及查询缓存的移除消除了这一性能瓶颈将优化重心放在了更高效的执行计划和索引上InnoDB 引擎优化8.0 对 InnoDB 进行了大量底层优化例如分拆 kernel mutex、将 flush 操作从主线程分离等旨在提升高并发场景下的可扩展性和吞吐量DDL 算法演进MySQL 5.5 执行 DDL如加字段、加索引时仅支持COPY算法期间表完全只读MySQL 8.0 引入了INSTANT算法对于部分 DDL 操作仅需修改元数据可实现秒级完成显著降低了对业务的影响索引大小限制MySQL 8.0 默认索引大小上限提升至 3072 字节允许组合索引包含更多的列而 5.5 的上限仅为 1000 字节4.安全性与权限管理认证插件5.6 使用mysql_native_password, 8.0 将caching_sha2_password作为默认认证插件提供了更强的密码加密和缓存机制角色 (Roles)5.6 不支持角色概念, 8.0 引入了角色管理可以创建角色并为其授予权限然后将角色授予用户, 这极大简化了批量用户的权限管理是 5.6 所不具备的重要企业级功能5.复制与高可用性故障转移5.6 的复制故障转移需要手动或借助外部工具,8.0 增强了对GTID全局事务标识符的支持并引入了异步连接故障转移机制, 当主库失效时从库可以自动连接到新的主库提升了复制拓扑的自动化恢复能力。6. 索引新特性降序索引在 5.6 中索引定义里的DESC关键字会被忽略索引始终按升序存储, 8.0 开始真正支持降序索引对于需要按降序排序的查询如获取最新记录可以显著提升性能不可见索引8.0 支持将索引标记为“不可见”, 优化器会忽略该索引但索引本身仍会被维护, 这为评估删除索引的影响提供了安全的“后悔药”可以先隐藏索引观察性能确认无影响后再删除自增变量持久化MySQL 8.0 解决了历史遗留问题对AUTO_INCREMENT值进行了持久化数据库重启后不会重置而 5.5 在重启后可能会重置自增主键导致潜在的主键冲突3。生命周期MySQL 5.5 已于 2018 年 12 月正式停止官方支持EOL不再提供安全补丁MySQL 8.0 则是当前企业级应用的主流选择享有长期的官方维护与云原生架构支持7.升级注意事项从 5.6 升级到 8.0不能直接跳级必须遵循5.6 → 5.7 → 8.0的路径,升级前需要重点检查认证插件应用使用的驱动可能不支持 8.0 默认的caching_sha2_password可能需要调整或升级驱动SQL 兼容性5.7 中被废弃的语法或功能如GROUP BY的隐式排序在 8.0 中已被移除需要修改应用 SQL配置参数许多在 5.6/5.7 中被忽略的无效配置项在 8.0 启动时会直接导致错误需要清理配置文件(1).动手前先确认三件检查项说明具体小版本号SELECT VERSION();—— 若低于 5.6.40建议先在 5.6 内升到该系列最新版再走后续流程减少已知 bug操作系统能否跑 8.0官方 8.0 二进制要求 glibc ≥ 2.17即 CentOS/RHEL 6 无法直接运行 8.0需换 OS 或用厂商定制包。这一步常导致“数据迁完了实例起不来”是否开了GTID / 半同步 / MGR 前身架构5.6 的 GTID 有硬限制见下文 B-9会影响升级路径设计(2).兼容性问题清单A 类不改就起不来 / 连不上A-1配置文件残留废弃参数实例拒绝启动5.6 能用而 8.0 彻底移除的典型项query_cache_type / query_cache_size / query_cache_limit # 查询缓存整块移除 innodb_file_format / innodb_file_format_check / innodb_file_format_max innodb_large_prefix # 8.0 恒为 ON innodb_locks_unsafe_for_binlog old_passwords log-slow-queries / slow_query_log 的旧写法 enable-partition # 分区插件不再可禁用 NO_AUTO_CREATE_USER # sql_mode 中此值已不存在做法用 8.0 二进制在测试环境试启动按unknown variable报错逐项清理不要直接复用老 cnfA-2认证插件变更 → 老客户端连不上8.0 默认caching_sha2_password5.6 时代全是mysql_native_password, 老驱动会报Authentication plugin caching_sha2_password cannot be loaded,做法优先级从高到低① 升级驱动JDBC 8.0.x、Python 换 mysqlclient/pymysql 新版、PHP 用 mysqlnd② 账号级改回mysql_native_password③ 全局设default_authentication_pluginmysql_native_password仅过渡,同时注意 8.0 默认 TLS 策略更严老客户端握手失败需检查tls_versionA-3lower_case_table_names初始化后不可改8.0 在--initialize时固化该值改了就拒绝启动,Linux 上 5.6 若是 18.0 也必须 1,做法升级前记录原值新实例初始化时显式指定A-4密码过期导致某天全线 Access denied5.6 无密码过期机制,迁到 8.0 后可能命中default_password_lifetime180(8.0.28 后改为0)做法迁移后立即执行ALTER USER ... PASSWORD EXPIRE NEVERA-5权限不能靠拷mysql库迁移5.6 的mysql.user还有Password字段5.7 改为authentication_string8.0 是事务型数据字典直接拷贝必挂做法用 Percona 工具导出授权语句并在新库重放pt-show-grants -h 5.6-host -u root -p grants.sql # 检查输出里有没有 PASSWORD(...) 形式的旧哈希有则说明存在 4.1 前旧密码需重置A-6物理备份工具版本必须匹配目标版本XtraBackup 2.3 对应 5.62.4 对应 5.78.0 系列对应 8.0,不能用 5.6 的备份直接恢复到 8.0,mysqldump 建议用目标版本的二进制执行A-7mysql_upgrade的生命周期5.6→5.7 每级升完必须手动执行mysql_upgrade --upgrade-system-tables,到 8.0 这一步由服务端首次启动自动完成数据字典升级8.0 里已没有这个命令别在文档里留着它B 类能跑但结果错 / 性能崩B-1sql_mode从宽松变严格最大隐性杀手5.6 默认基本只有NO_ENGINE_SUBSTITUTION8.0 默认ONLY_FULL_GROUP_BY, STRICT_TRANS_TABLES, NO_ZERO_IN_DATE, NO_ZERO_DATE, ERROR_FOR_DIVISION_BY_ZERO, NO_ENGINE_SUBSTITUTION典型报错Expression ... not in GROUP BY clause、Incorrect datetime value: 0000-00-00、Data too long、除零错误、字段无默认值插入失败做法在测试环境开全量严格模式跑回归优先修 SQL工期不够可临时放宽但要记入技术债清单B-2保留字冲突语法报错 10648.0 新增保留字命中老库对象名会直接报错ROWS, SYSTEM, RANK, DENSE_RANK, CUBE, ROLLUP, RECURSIVE, JSON_TABLE, MEMBER, EXCEPT, LATERAL, WINDOW, GENERATED, VIRTUAL, STORED, ENFORCED, CHECK等做法对照官方保留字表全量扫描 schema加反引号或改名B-3CHECK 约束从“注释”变“强制”5.6 解析但不校验 CHECK库里可能已有脏数据8.0 会强制执行且存量脏数据会导致约束添加失败做法升级前先SELECT ... WHERE NOT(条件)扫脏数据清洗后再加约束B-4字符集与排序规则连环坑5.6 默认 latin18.0 默认utf8mb4注意 8.0 中utf8是utf8mb3的别名且会被标记为 deprecated转 utf8mb4 后索引前缀可能超 3072 字节上限 → 唯一索引重建失败排序规则变为utf8mb4_0900_ai_ci同样的数据 ORDER BY 结果顺序会变分页接口会出现重复/漏数据做法在线改字符集大表用 pt-online-schema-change 或 gh-ost业务层补确定性 ORDER BY必要时显式指定 COLLATEB-5GROUP BY 隐式排序被移除5.6 中GROUP BY碰巧有序8.0 不再保证,做法有顺序要求的查询一律显式加ORDER BYB-6explicit_defaults_for_timestamp行为变化5.6 默认 OFF第一个 TIMESTAMP 列自动DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP且 NULL 可存8.0 该参数默认 ON 且不允许再设为 OFF,迁移后 TIMESTAMP 列的默认值和 NULL 处理会变需逐表核对B-7时间类型历史格式问题5.6.4 之前创建的 TIME/DATETIME/TIMESTAMP 列使用旧内部格式需通过REPAIR TABLE/mysql_upgrade/ALTER TABLE ... FORCE重建,5.6 起点虽多为新格式但若库是从更早版本升上来的必须在 5.7 阶段用mysql_upgrade扫一遍B-8空间函数与非标语法不带ST_前缀的空间函数在 8.0 被移除SRID 现在强制执行空间索引要求列与索引 SRID 一致。GIS 业务需逐条核对B-9GTID 相关5.6 特有5.6 的 GTID 不支持非事务引擎表、事务内的CREATE TEMPORARY TABLE、sql_slave_skip_counter,若计划在 8.0 用 GTID/MGR需在 5.7 阶段先把这些隐患清掉5.7 支持在线开启 GTID可在不停机情况下切换B-10复制参数与拓扑限制只能低版本主 → 高版本从且建议只跨一个大版本8.0 从库不能挂 5.6 主库这就是必须经 5.7 的原因5.6 建议先切binlog_formatROW、binlog_row_imageFULL8.0.26 起master/slave术语改为source/replicarpl_semi_sync_master_*→rpl_semi_sync_source_*SHOW SLAVE STATUS→SHOW REPLICA STATUS5.6 的sync_master_info等参数名变动B-11执行计划回退8.0 引入 Hash Join、直方图、降序索引、代价模型调整同一 SQL 计划可能完全不同,做法从 5.6 慢日志抓 Top SQL在 8.0 测试库逐条EXPLAIN FORMATTREE对比B-12监控/运维脚本集体失效5.6 没有sys库8.0 的performance_schema表结构大变setup_*表改名/合并、INFORMATION_SCHEMA.INNODB_*字段变化、mysql_upgrade消失、mysql_install_db→mysqld --initialize、PASSWORD()函数被移除、SHOW PROFILES被移除、ENCODE/DECODE/DES_ENCRYPT 等函数移除,所有巡检、告警、备份脚本要逐条过B-13其他零散项5.6 的.par分区元数据文件在 8.0 取消改用 InnoDB 原生分区 数据字典8.0 内存占用更高同等硬件需复核innodb_buffer_pool_size、文件描述符、swap8.0 默认innodb_undo_tablespaces2undo 独立表空间行为变化X Plugin 默认监听 33060 端口注意防火墙同名索引在 8.0 中每张表内必须唯一5.6 允许重复(3). 迁移步骤Runbook阶段 0评估与定型1~2 周盘点实例数、库表量、数据量、存储过程/触发器/事件/视图、定时任务、中间件与驱动版本、上下游同步链路选路径数据量大 / 停机窗口短→ 逐级主从滚动5.6 主 → 5.7 从 → 切主 → 8.0 从 → 切主数据量小如 200GB/ 能接受较长停机→ 逻辑迁移一步到 8.0跳过 5.7但兼容性问题仍要在测试库验证定回滚方案8.0 主库无法向 5.6 做从库所以回滚只能“切回旧 5.6 主库 补偿增量”必须在方案里写清决策点超过 XX 分钟未成功即回滚OS 与二进制就绪确认 glibc/内核满足 8.0 要求准备好 5.7 与 8.0 两套二进制及匹配版本的 xtrabackup阶段 1测试环境全量演练2~4 周最关键搭与生产同链路的测试环境灌入脱敏真实数据子集含最大表和最复杂业务场景完整走一遍升级记录每步耗时、报错、手工操作SQL 基线抓 Top 50~100 慢 SQL 逐条 EXPLAIN 对比产出“是否回退/处理措施”表全量回归分页列表、聚合报表、金额计算、唯一键冲突路径、零日期/空值路径、批量导入、定时任务压测 故障演练主从延迟、断连重连、认证失败并演练一次完整回滚阶段 2预修复与业务并行SQL 改造GROUP BY/ORDER BY 补全、保留字加反引号、零日期清洗、非标函数替换驱动与中间件升级JDBC、连接池、ORM、分库分表/代理组件确认 8.0 兼容版本权限重构pt-show-grants导出 → 清僵尸账号 → 按需引入 Role字符集整改建议在 5.7 阶段完成降低最终切换风险配置文件瘦身剔除废弃项并加注释阶段 3正式迁移路径一逐级主从滚动推荐1. 5.6 主库切 binlog_formatROW确认现有从库同步正常 2. 部署 5.7 从库用 5.7 mysqldump 或 xtrabackup 2.4 建从追平延迟观察 1~3 天 3. 5.7 从库执行 mysql_upgrade验证业务回归 4. 主从切换5.7 升主老 5.6 降为只读从库保留 可选此时对 5.7 跑 mysqlsh util.checkForServerUpgrade 预判 8.0 问题 5. 部署 8.0 从库追平延迟 6. 最终校验pt-table-checksum 抽检核心表、行数/MAX(id)/金额汇总对账、 存储过程/视图/事件数量比对 7. 【停机窗口】停写 → 等完全追上 → 再校验 → 切流量到 8.0 8. 立刻跑冒烟用例 看核心接口 TP99观察 24~72h 9. 旧库保留只读 3~7 天后下线路径二逻辑迁移一步到 8.0# 用 8.0 的 mysqldump 连接 5.6 导出 mysqldump -h src -u root -p \ --all-databases --single-transaction --triggers --routines --events \ --hex-blob --set-gtid-purgedOFF --max-allowed-packet1G \ --default-character-setutf8mb4 full.sql # 导入 8.0 mysql -h dst -u root -p --max-allowed-packet1G full.sql # 导入后必做 ANALYZE TABLE 核心表; # 统计信息重建否则计划可能很差数据量大时改用mydumper/myloader并行速度快数倍或云厂商 DTS/OMS 类工具支持跨版本异构同步、可反向增量能大幅压缩停机窗口阶段 4收尾ANALYZE TABLE核心表,打开 8.0 新能力原子 DDL、角色、降序索引、不可见索引、clone 插件、资源组更新备份策略xtrabackup 8.0 / 逻辑备份binlog并做一次恢复演练更新监控项替换失效 SQL、更新文档与应急预案复盘遗留技术债如暂时放宽的 sql_mode排期关闭(4). 最容易翻车的 TOP 8#现象根因预防1实例起不来cnf 里有query_cache_*、innodb_large_prefix等废弃参数测试环境先试启动2应用连不上caching_sha2_password 老驱动 / TLS 版本不匹配升级驱动或改认证插件3表“不见了”lower_case_table_names不一致初始化时保持一致4某天突然全线 Access denied密码 180 天过期PASSWORD EXPIRE NEVER5列表页重复/漏数据排序规则变 缺 ORDER BY补确定性 ORDER BY6个别 SQL 从 10ms 变 10s执行计划回退上线前 EXPLAIN 基线对比7TIMESTAMP 默认值/NULL 行为变了explicit_defaults_for_timestamp8.0 强制 ON逐表核对建表语句8GROUP BY/ 除零 / 截断报错严格 sql_mode改 SQL别关模式(5). 三条落地建议别为了省事跳过 5.7 这一档除非走逻辑迁移), 80% 的兼容性问题在 5.7 就会暴露越早修成本越低,而且 5.7 是唯一能跑mysqlsh util.checkForServerUpgrade的前置跳板演练 ≥ 2 次其中一次必须含完整回滚, 第一次演练的目标是发现问题不是成功用云数据库就优先走厂商升级/DTS 服务兼容性问题会被前置拦截比自己搬二进制省事得多8.总结MySQL 8.0 相比 5.6 是一次质变, 它不仅带来了窗口函数、CTE、角色等现代数据库必备功能更通过原子 DDL、事务性数据字典和默认utf8mb4等底层架构的革新为数据一致性和安全性提供了更强的保障, 对于任何仍在使用 5.6 的系统制定向 8.0 的迁移计划都是一个非常值得投入的方向 mysql5.6和mysql8.0的区别
MySQL 5.6 与 8.0 之间的差异是跨越式的中间还隔了一个重要的 5.7 版本,8.0 并非 5.6 的简单增强而是在架构设计、SQL 标准支持、安全模型和性能优化上都进行了重构1.核心差异总览对比维度MySQL 5.6MySQL 8.0SQL 功能基础 SQL不支持窗口函数、CTE支持窗口函数、CTE、角色JSON 功能增强数据字典元数据存储于文件和非事务表中非原子事务性数据字典元数据存储在 InnoDB 中支持原子 DDL默认字符集latin1 or utf8(utf8mb3)utf8mb4查询缓存存在默认禁用已彻底移除索引特性不支持降序索引DESC被忽略支持降序索引、不可见索引复制与高可用基于 GTID 的复制较新特性增强的复制功能支持异步连接故障转移安全性mysql_native_password为默认认证插件caching_sha2_password为默认引入角色和动态权限InnoDB 优化基础 InnoDB 功能大量并发优化如分拆 kernel mutex、flush 操作分离2. SQL 语法与功能增强窗口函数 (Window Functions)5.6 不支持, 8.0 引入了完整的窗口函数如ROW_NUMBER(),RANK(),LEAD(),LAG()使得在查询中直接进行复杂的排名、移动平均和同比/环比分析成为可能无需再依赖自连接或复杂的子查询公用表表达式 (CTE)5.6 不支持,8.0 支持WITH子句包括递归 CTE,这极大地简化了层级数据如组织架构树、分类目录的查询和复杂子查询的编写使 SQL 逻辑更清晰JSON 支持5.6 对 JSON 的支持非常有限,8.0 提供了原生的 JSON 数据类型和丰富的函数如JSON_TABLE可以直接将 JSON 数据当作关系表来查询大大提升了处理半结构化数据的效率3.架构与性能优化数据字典与原子 DDL5.6 的元数据存储在文件和非事务性表中DDL 操作不具备原子性,8.0 引入了事务性数据字典将所有元数据存储在 InnoDB 表中,这直接带来了原子 DDL一个 DDL 操作要么完全成功要么完全失败不会出现中间状态极大提升了数据库在崩溃时的安全性和可靠性查询缓存移除5.6 中查询缓存已默认禁用且在高并发场景下容易成为瓶颈,8.0 得益于更高效的编解码器、自适应哈希索引优化以及查询缓存的移除消除了这一性能瓶颈将优化重心放在了更高效的执行计划和索引上InnoDB 引擎优化8.0 对 InnoDB 进行了大量底层优化例如分拆 kernel mutex、将 flush 操作从主线程分离等旨在提升高并发场景下的可扩展性和吞吐量DDL 算法演进MySQL 5.5 执行 DDL如加字段、加索引时仅支持COPY算法期间表完全只读MySQL 8.0 引入了INSTANT算法对于部分 DDL 操作仅需修改元数据可实现秒级完成显著降低了对业务的影响索引大小限制MySQL 8.0 默认索引大小上限提升至 3072 字节允许组合索引包含更多的列而 5.5 的上限仅为 1000 字节4.安全性与权限管理认证插件5.6 使用mysql_native_password, 8.0 将caching_sha2_password作为默认认证插件提供了更强的密码加密和缓存机制角色 (Roles)5.6 不支持角色概念, 8.0 引入了角色管理可以创建角色并为其授予权限然后将角色授予用户, 这极大简化了批量用户的权限管理是 5.6 所不具备的重要企业级功能5.复制与高可用性故障转移5.6 的复制故障转移需要手动或借助外部工具,8.0 增强了对GTID全局事务标识符的支持并引入了异步连接故障转移机制, 当主库失效时从库可以自动连接到新的主库提升了复制拓扑的自动化恢复能力。6. 索引新特性降序索引在 5.6 中索引定义里的DESC关键字会被忽略索引始终按升序存储, 8.0 开始真正支持降序索引对于需要按降序排序的查询如获取最新记录可以显著提升性能不可见索引8.0 支持将索引标记为“不可见”, 优化器会忽略该索引但索引本身仍会被维护, 这为评估删除索引的影响提供了安全的“后悔药”可以先隐藏索引观察性能确认无影响后再删除自增变量持久化MySQL 8.0 解决了历史遗留问题对AUTO_INCREMENT值进行了持久化数据库重启后不会重置而 5.5 在重启后可能会重置自增主键导致潜在的主键冲突3。生命周期MySQL 5.5 已于 2018 年 12 月正式停止官方支持EOL不再提供安全补丁MySQL 8.0 则是当前企业级应用的主流选择享有长期的官方维护与云原生架构支持7.升级注意事项从 5.6 升级到 8.0不能直接跳级必须遵循5.6 → 5.7 → 8.0的路径,升级前需要重点检查认证插件应用使用的驱动可能不支持 8.0 默认的caching_sha2_password可能需要调整或升级驱动SQL 兼容性5.7 中被废弃的语法或功能如GROUP BY的隐式排序在 8.0 中已被移除需要修改应用 SQL配置参数许多在 5.6/5.7 中被忽略的无效配置项在 8.0 启动时会直接导致错误需要清理配置文件(1).动手前先确认三件检查项说明具体小版本号SELECT VERSION();—— 若低于 5.6.40建议先在 5.6 内升到该系列最新版再走后续流程减少已知 bug操作系统能否跑 8.0官方 8.0 二进制要求 glibc ≥ 2.17即 CentOS/RHEL 6 无法直接运行 8.0需换 OS 或用厂商定制包。这一步常导致“数据迁完了实例起不来”是否开了GTID / 半同步 / MGR 前身架构5.6 的 GTID 有硬限制见下文 B-9会影响升级路径设计(2).兼容性问题清单A 类不改就起不来 / 连不上A-1配置文件残留废弃参数实例拒绝启动5.6 能用而 8.0 彻底移除的典型项query_cache_type / query_cache_size / query_cache_limit # 查询缓存整块移除 innodb_file_format / innodb_file_format_check / innodb_file_format_max innodb_large_prefix # 8.0 恒为 ON innodb_locks_unsafe_for_binlog old_passwords log-slow-queries / slow_query_log 的旧写法 enable-partition # 分区插件不再可禁用 NO_AUTO_CREATE_USER # sql_mode 中此值已不存在做法用 8.0 二进制在测试环境试启动按unknown variable报错逐项清理不要直接复用老 cnfA-2认证插件变更 → 老客户端连不上8.0 默认caching_sha2_password5.6 时代全是mysql_native_password, 老驱动会报Authentication plugin caching_sha2_password cannot be loaded,做法优先级从高到低① 升级驱动JDBC 8.0.x、Python 换 mysqlclient/pymysql 新版、PHP 用 mysqlnd② 账号级改回mysql_native_password③ 全局设default_authentication_pluginmysql_native_password仅过渡,同时注意 8.0 默认 TLS 策略更严老客户端握手失败需检查tls_versionA-3lower_case_table_names初始化后不可改8.0 在--initialize时固化该值改了就拒绝启动,Linux 上 5.6 若是 18.0 也必须 1,做法升级前记录原值新实例初始化时显式指定A-4密码过期导致某天全线 Access denied5.6 无密码过期机制,迁到 8.0 后可能命中default_password_lifetime180(8.0.28 后改为0)做法迁移后立即执行ALTER USER ... PASSWORD EXPIRE NEVERA-5权限不能靠拷mysql库迁移5.6 的mysql.user还有Password字段5.7 改为authentication_string8.0 是事务型数据字典直接拷贝必挂做法用 Percona 工具导出授权语句并在新库重放pt-show-grants -h 5.6-host -u root -p grants.sql # 检查输出里有没有 PASSWORD(...) 形式的旧哈希有则说明存在 4.1 前旧密码需重置A-6物理备份工具版本必须匹配目标版本XtraBackup 2.3 对应 5.62.4 对应 5.78.0 系列对应 8.0,不能用 5.6 的备份直接恢复到 8.0,mysqldump 建议用目标版本的二进制执行A-7mysql_upgrade的生命周期5.6→5.7 每级升完必须手动执行mysql_upgrade --upgrade-system-tables,到 8.0 这一步由服务端首次启动自动完成数据字典升级8.0 里已没有这个命令别在文档里留着它B 类能跑但结果错 / 性能崩B-1sql_mode从宽松变严格最大隐性杀手5.6 默认基本只有NO_ENGINE_SUBSTITUTION8.0 默认ONLY_FULL_GROUP_BY, STRICT_TRANS_TABLES, NO_ZERO_IN_DATE, NO_ZERO_DATE, ERROR_FOR_DIVISION_BY_ZERO, NO_ENGINE_SUBSTITUTION典型报错Expression ... not in GROUP BY clause、Incorrect datetime value: 0000-00-00、Data too long、除零错误、字段无默认值插入失败做法在测试环境开全量严格模式跑回归优先修 SQL工期不够可临时放宽但要记入技术债清单B-2保留字冲突语法报错 10648.0 新增保留字命中老库对象名会直接报错ROWS, SYSTEM, RANK, DENSE_RANK, CUBE, ROLLUP, RECURSIVE, JSON_TABLE, MEMBER, EXCEPT, LATERAL, WINDOW, GENERATED, VIRTUAL, STORED, ENFORCED, CHECK等做法对照官方保留字表全量扫描 schema加反引号或改名B-3CHECK 约束从“注释”变“强制”5.6 解析但不校验 CHECK库里可能已有脏数据8.0 会强制执行且存量脏数据会导致约束添加失败做法升级前先SELECT ... WHERE NOT(条件)扫脏数据清洗后再加约束B-4字符集与排序规则连环坑5.6 默认 latin18.0 默认utf8mb4注意 8.0 中utf8是utf8mb3的别名且会被标记为 deprecated转 utf8mb4 后索引前缀可能超 3072 字节上限 → 唯一索引重建失败排序规则变为utf8mb4_0900_ai_ci同样的数据 ORDER BY 结果顺序会变分页接口会出现重复/漏数据做法在线改字符集大表用 pt-online-schema-change 或 gh-ost业务层补确定性 ORDER BY必要时显式指定 COLLATEB-5GROUP BY 隐式排序被移除5.6 中GROUP BY碰巧有序8.0 不再保证,做法有顺序要求的查询一律显式加ORDER BYB-6explicit_defaults_for_timestamp行为变化5.6 默认 OFF第一个 TIMESTAMP 列自动DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP且 NULL 可存8.0 该参数默认 ON 且不允许再设为 OFF,迁移后 TIMESTAMP 列的默认值和 NULL 处理会变需逐表核对B-7时间类型历史格式问题5.6.4 之前创建的 TIME/DATETIME/TIMESTAMP 列使用旧内部格式需通过REPAIR TABLE/mysql_upgrade/ALTER TABLE ... FORCE重建,5.6 起点虽多为新格式但若库是从更早版本升上来的必须在 5.7 阶段用mysql_upgrade扫一遍B-8空间函数与非标语法不带ST_前缀的空间函数在 8.0 被移除SRID 现在强制执行空间索引要求列与索引 SRID 一致。GIS 业务需逐条核对B-9GTID 相关5.6 特有5.6 的 GTID 不支持非事务引擎表、事务内的CREATE TEMPORARY TABLE、sql_slave_skip_counter,若计划在 8.0 用 GTID/MGR需在 5.7 阶段先把这些隐患清掉5.7 支持在线开启 GTID可在不停机情况下切换B-10复制参数与拓扑限制只能低版本主 → 高版本从且建议只跨一个大版本8.0 从库不能挂 5.6 主库这就是必须经 5.7 的原因5.6 建议先切binlog_formatROW、binlog_row_imageFULL8.0.26 起master/slave术语改为source/replicarpl_semi_sync_master_*→rpl_semi_sync_source_*SHOW SLAVE STATUS→SHOW REPLICA STATUS5.6 的sync_master_info等参数名变动B-11执行计划回退8.0 引入 Hash Join、直方图、降序索引、代价模型调整同一 SQL 计划可能完全不同,做法从 5.6 慢日志抓 Top SQL在 8.0 测试库逐条EXPLAIN FORMATTREE对比B-12监控/运维脚本集体失效5.6 没有sys库8.0 的performance_schema表结构大变setup_*表改名/合并、INFORMATION_SCHEMA.INNODB_*字段变化、mysql_upgrade消失、mysql_install_db→mysqld --initialize、PASSWORD()函数被移除、SHOW PROFILES被移除、ENCODE/DECODE/DES_ENCRYPT 等函数移除,所有巡检、告警、备份脚本要逐条过B-13其他零散项5.6 的.par分区元数据文件在 8.0 取消改用 InnoDB 原生分区 数据字典8.0 内存占用更高同等硬件需复核innodb_buffer_pool_size、文件描述符、swap8.0 默认innodb_undo_tablespaces2undo 独立表空间行为变化X Plugin 默认监听 33060 端口注意防火墙同名索引在 8.0 中每张表内必须唯一5.6 允许重复(3). 迁移步骤Runbook阶段 0评估与定型1~2 周盘点实例数、库表量、数据量、存储过程/触发器/事件/视图、定时任务、中间件与驱动版本、上下游同步链路选路径数据量大 / 停机窗口短→ 逐级主从滚动5.6 主 → 5.7 从 → 切主 → 8.0 从 → 切主数据量小如 200GB/ 能接受较长停机→ 逻辑迁移一步到 8.0跳过 5.7但兼容性问题仍要在测试库验证定回滚方案8.0 主库无法向 5.6 做从库所以回滚只能“切回旧 5.6 主库 补偿增量”必须在方案里写清决策点超过 XX 分钟未成功即回滚OS 与二进制就绪确认 glibc/内核满足 8.0 要求准备好 5.7 与 8.0 两套二进制及匹配版本的 xtrabackup阶段 1测试环境全量演练2~4 周最关键搭与生产同链路的测试环境灌入脱敏真实数据子集含最大表和最复杂业务场景完整走一遍升级记录每步耗时、报错、手工操作SQL 基线抓 Top 50~100 慢 SQL 逐条 EXPLAIN 对比产出“是否回退/处理措施”表全量回归分页列表、聚合报表、金额计算、唯一键冲突路径、零日期/空值路径、批量导入、定时任务压测 故障演练主从延迟、断连重连、认证失败并演练一次完整回滚阶段 2预修复与业务并行SQL 改造GROUP BY/ORDER BY 补全、保留字加反引号、零日期清洗、非标函数替换驱动与中间件升级JDBC、连接池、ORM、分库分表/代理组件确认 8.0 兼容版本权限重构pt-show-grants导出 → 清僵尸账号 → 按需引入 Role字符集整改建议在 5.7 阶段完成降低最终切换风险配置文件瘦身剔除废弃项并加注释阶段 3正式迁移路径一逐级主从滚动推荐1. 5.6 主库切 binlog_formatROW确认现有从库同步正常 2. 部署 5.7 从库用 5.7 mysqldump 或 xtrabackup 2.4 建从追平延迟观察 1~3 天 3. 5.7 从库执行 mysql_upgrade验证业务回归 4. 主从切换5.7 升主老 5.6 降为只读从库保留 可选此时对 5.7 跑 mysqlsh util.checkForServerUpgrade 预判 8.0 问题 5. 部署 8.0 从库追平延迟 6. 最终校验pt-table-checksum 抽检核心表、行数/MAX(id)/金额汇总对账、 存储过程/视图/事件数量比对 7. 【停机窗口】停写 → 等完全追上 → 再校验 → 切流量到 8.0 8. 立刻跑冒烟用例 看核心接口 TP99观察 24~72h 9. 旧库保留只读 3~7 天后下线路径二逻辑迁移一步到 8.0# 用 8.0 的 mysqldump 连接 5.6 导出 mysqldump -h src -u root -p \ --all-databases --single-transaction --triggers --routines --events \ --hex-blob --set-gtid-purgedOFF --max-allowed-packet1G \ --default-character-setutf8mb4 full.sql # 导入 8.0 mysql -h dst -u root -p --max-allowed-packet1G full.sql # 导入后必做 ANALYZE TABLE 核心表; # 统计信息重建否则计划可能很差数据量大时改用mydumper/myloader并行速度快数倍或云厂商 DTS/OMS 类工具支持跨版本异构同步、可反向增量能大幅压缩停机窗口阶段 4收尾ANALYZE TABLE核心表,打开 8.0 新能力原子 DDL、角色、降序索引、不可见索引、clone 插件、资源组更新备份策略xtrabackup 8.0 / 逻辑备份binlog并做一次恢复演练更新监控项替换失效 SQL、更新文档与应急预案复盘遗留技术债如暂时放宽的 sql_mode排期关闭(4). 最容易翻车的 TOP 8#现象根因预防1实例起不来cnf 里有query_cache_*、innodb_large_prefix等废弃参数测试环境先试启动2应用连不上caching_sha2_password 老驱动 / TLS 版本不匹配升级驱动或改认证插件3表“不见了”lower_case_table_names不一致初始化时保持一致4某天突然全线 Access denied密码 180 天过期PASSWORD EXPIRE NEVER5列表页重复/漏数据排序规则变 缺 ORDER BY补确定性 ORDER BY6个别 SQL 从 10ms 变 10s执行计划回退上线前 EXPLAIN 基线对比7TIMESTAMP 默认值/NULL 行为变了explicit_defaults_for_timestamp8.0 强制 ON逐表核对建表语句8GROUP BY/ 除零 / 截断报错严格 sql_mode改 SQL别关模式(5). 三条落地建议别为了省事跳过 5.7 这一档除非走逻辑迁移), 80% 的兼容性问题在 5.7 就会暴露越早修成本越低,而且 5.7 是唯一能跑mysqlsh util.checkForServerUpgrade的前置跳板演练 ≥ 2 次其中一次必须含完整回滚, 第一次演练的目标是发现问题不是成功用云数据库就优先走厂商升级/DTS 服务兼容性问题会被前置拦截比自己搬二进制省事得多8.总结MySQL 8.0 相比 5.6 是一次质变, 它不仅带来了窗口函数、CTE、角色等现代数据库必备功能更通过原子 DDL、事务性数据字典和默认utf8mb4等底层架构的革新为数据一致性和安全性提供了更强的保障, 对于任何仍在使用 5.6 的系统制定向 8.0 的迁移计划都是一个非常值得投入的方向