企业官网建设流程全解析

MySQL 8.x 上线已经有段时间了，各大云厂商也都把新实例默认版本切到了 8.0，说它是“事实标准”一点不过分。但我最近连续帮几个业务线做迁移和升级，说实话，真正的麻烦不是安装配置，而是在存量系统迁移过去之后，那些过去能跑的 SQL、能用的参数、看似正常的运维习惯，一个接一个地开始“作妖”。这篇文章我不打算罗列新特性，重点想把我在实际升级和排障过程中踩过、填过的坑说清楚，尤其是那些从 5.7 带过来的惯性思维，在 8.x 里会怎么坑你。

1. 为什么 MySQL 8.x 成了“事实标准”，却人人喊坑

1.1 从 5.7 升到 8.x，到底变了什么

MySQL 8.x 之所以能迅速成为主流，表面原因是官方宣布 5.7 停止维护，实际上更核心的推动力是它确实解决了一大批老问题：底层数据字典从文件系统搬进了 InnoDB，去掉了 frm 文件；原子 DDL 让建表改表不再“改一半”；窗口函数、CTE 让复杂查询终于不需要绕来绕去写临时表；数据字典统一后，information_schema 查询性能也提升明显。这些都是实打实的进步，所以新项目用 8.x 基本没有悬念。

但问题的根源恰恰也在这：8.x 不是 5.7 的“皮肤升级”，而是内核级别的重做。很多在 5.7 里依赖的“潜规则”在 8.x 里被纠正了，或者说被“半纠正”了。我们作为老 DBA，最容易犯的错就是拿着 5.7 的使用习惯去套 8.x，结果要么升级后某些 SQL 突然报错，要么性能表现和预期完全相反。

在几次迁移项目中，我深刻体会到一个事实：升级 8.x 的技术门槛其实不高，真正的门槛是把旧的思维模式切换到新版本的数据字典、优化器、事务模型上。这就像一个老司机开惯了手动挡，突然换到自动挡，你会发现油门刹车还是那两个，但换挡逻辑变了，你原来的条件反射反而会成为安全隐患。

1.2 “升级一时爽，踩坑火葬场”的真实写照

我接手过一个典型的存量订单系统，数据量在 2TB 左右，核心表行数过亿，原来跑在 5.7.36 上。升级计划排了两周，真正执行只花了几个小时，但升级之后的两个月里，我们先后经历了：部分客户端连不上、慢查询数量翻倍、一个统计报表跑出来和历史数据对不上、主从复制延迟抖动、mysqldump 备份出来的文件无法直接导入旧环境等一系列问题。

这些问题单个拿出来都不算大，但凑在一起就非常折磨人。更要命的是，很多问题不像报错那样直接，比如 GROUP BY 结果顺序不对，这种属于“静默错误”，数据不是不能看，而是结果和以前不一样。业务方如果不知道新版本不再保留隐式排序，直接拿新结果去对旧报表，一定会觉得数据错了。

也正是这些经历，让我觉得有必要把 8.x 的“坑”系统性地整理一遍。不是要否认 8.x 的优点，恰恰相反，是想让大家在享受新版本红利的同时，提前知道哪些地方需要绕开旧习惯，避免用生产环境当试验场。

2. 升级后最容易踩的六大“隐形坑”

2.1 认证插件：caching_sha2_password 与旧客户端不兼容

MySQL 8.x 默认的认证插件换成了 caching_sha2_password，不再使用 5.7 的 mysql_native_password。这个改动本身是为了安全性，但对老客户端来说就是一场灾难。我遇到过不止一次，业务方报“连接被拒绝”，结果一查不是密码错，而是客户端的 libmysqlclient 版本太老，根本不认识新的认证握手协议。

最典型的场景是：

• 使用 5.x 版本的 mysql-jdbc 驱动连接 8.x，报错Unable to load authentication plugin 'caching_sha2_password'。
• 使用 PHP 5.x 版本、或者老版本 pdo_mysql，同样失败。
• 使用老版本 mysqldump 从 8.x 导出数据，也会出现认证失败。

解决办法有两个方向：要么升级客户端驱动，要么在服务端把用户认证插件改回 mysql_native_password。我的建议是：如果是正在维护的线上系统，短期内可以先用ALTER USER ... IDENTIFIED WITH mysql_native_password BY '...'过渡，但要把“全部客户端驱动升级到支持 caching_sha2_password”写入正式改造计划。因为新版驱动不仅解决认证问题，还顺带修复了很多连接池和字符集处理方面的历史 bug。

实操中务必要注意，改认证插件后必须刷新权限，而且如果是主从环境，主库和从库的用户都要处理。我见过只改了主库，从库没改，结果从库复制线程频繁报认证错误的情况。

2.2 默认字符集与排序规则：utf8mb4_0900_ai_ci 意外改变行为

5.7 里默认字符集是 utf8mb4，默认排序规则是 utf8mb4_general_ci；到了 8.x，默认字符集仍然是 utf8mb4，但默认排序规则变成了 utf8mb4_0900_ai_ci。这里的 0900 指的是 Unicode 9.0 标准，ai 表示 accent insensitive（不区分重音）。

问题出在哪？我在一次数据迁移后就遇到过一个很诡异的现象：一个用户表的唯一索引在碰到某些特殊字符时，原表能插入新记录，迁移到 8.x 后却报“Duplicate entry”。两边的数据和表结构明明都是从同一份逻辑备份恢复的，为什么结果不一样？

因为 utf8mb4_0900_ai_ci 对某些字符的权重和 utf8mb4_general_ci 不同。尤其是对德语、法语中的重音字符，以及一些特殊符号，0900 的排序规则会认为它们是同一个字符，而 general_ci 会认为它们是不同的字符。所以原本能区分的数据，在新排序规则下被判重了。

更隐蔽的坑是排序行为的变化。utf8mb4_0900_ai_ci 是基于新的 Unicode 排序算法实现的，比 general_ci 更精准，但这也意味着 ORDER BY 的结果顺序会变。如果业务代码里有依赖固定排序顺序的逻辑，比如“按名称倒序取前十条”，升级后很可能取出来的记录和以前不一样。

建议：新库直接用默认规则没问题；旧库迁移时，如果不想改变排序行为，建表语句里要显式指定COLLATE utf8mb4_general_ci。但说实话，既然都到 8.x 了，我更推荐在应用侧把排序依赖清理掉，因为从长远看，0900 排序规则才是后续演进的方向。

2.3 sql_mode 默认值收紧：ONLY_FULL_GROUP_BY 逼疯老代码

8.x 的 sql_mode 默认值比 5.7 更严格，尤其默认启用了 ONLY_FULL_GROUP_BY。在 5.7 里很多团队已经吃过这个亏，但 8.x 把它彻底固化了。

我刚接手的一个后台报表系统，就栽在这个上面。一条 SQL 大概长这样：

SELECT user_id, order_date, SUM(amount) FROM orders GROUP BY user_id;

这条 SQL 在 5.7 下能跑，MySQL 会“聪明地”从每组里挑一个 order_date 返回。但到了 8.x，直接报错：

ERROR 1055 (42000): Expression #2 of SELECT list is not in GROUP BY clause

从数据库理论角度，8.x 是对的：SELECT 里出现了既不在 GROUP BY 里、也没有聚合函数的列，结果本来就是未定义的。从实际业务角度，老代码里这种模糊查询到处都是。

我的处理方式分三步：

1. 先用工具扫描所有业务库的慢查询日志和 general log，提取所有含 GROUP BY 的 SQL，逐一人工判断。
2. 能改 SQL 就改 SQL，把 SELECT 中的非聚合列要么去掉，要么用 ANY_VALUE() 包一层，表示“我确实不在乎取哪个值”。
3. 确实改不完的，在会话级别临时放宽 sql_mode，但严禁直接改全局配置。

这里要特别提一句，ANY_VALUE() 是 MySQL 5.7+ 提供的函数，专门用来兼容“分组后取某个值”的需求。它不是说真的随机取，而是告诉优化器“不需要对这个列做完整性校验”。如果业务上真的需要分组后取某一列的最新值，正确的写法是使用窗口函数或者关联子查询，不要整天想着怎么绕过 ONLY_FULL_GROUP_BY。

2.4 窗口函数和 CTE：能力多了，但滥用更坑

8.x 支持了窗口函数和 CTE，这本来是大利好。我见过太多人一升级就兴奋地把所有子查询改写成 CTE，把所有去重逻辑改成 ROW_NUMBER() OVER (PARTITION BY ...)，结果性能反而暴跌。

举一个真实的例子。某个业务查询要取每个用户最近一单，原来的写法是关联子查询：

SELECT * FROM orders o WHERE o.id = ( SELECT o2.id FROM orders o2 WHERE o2.user_id = o.user_id ORDER BY o2.created_at DESC LIMIT 1 );

这个写法在 5.7 下虽然不优雅，但只要有 (user_id, created_at) 的索引，表现尚可。同事改成窗口函数后：

SELECT * FROM ( SELECT o.*, ROW_NUMBER() OVER (PARTITION BY user_id ORDER BY created_at DESC) AS rn FROM orders o ) t WHERE t.rn = 1;

按理说窗口函数只需要扫一遍表，应该更快。但实际情况是，它会多一个临时的排序/分组步骤，会占用很大的临时表空间，在数据量大的情况下性能反而更差。

这不是说窗口函数不好，而是要用对场景。窗口函数适合“既需要明细行，又需要聚合值”的查询，比如计算累加、占比、排名。如果最终只需要每组的一条行，大概率还是 GROUP BY + 合适的聚合函数或者关联子查询更高效。

CTE 也有类似问题。非递归 CTE 本质上就是个视图或派生表，很多情况下 MySQL 会物化它，如果外部查询再对这个物化结果做过滤，可能丢失下推优化的机会。我的一般经验是：先用 EXPLAIN 看执行计划，如果发现 CTE 被物化且过滤条件没有下推，就改回原始子查询或临时表。

2.5 自增主键持久化：重启后不再从 max(id)+1 继续

这个坑在 8.x 里其实是一个“修复”，但因为和旧行为差异太大，很多业务都中招了。

5.7 及以前，InnoDB 的自增计数器存在内存里，重启后通过SELECT MAX(auto_increment_col) FROM table重新初始化。这就导致一个经典问题：如果你删除了最大的几行，重启后自增 ID 可能会复用被删除的 ID。业务上如果认为 ID 不会复用，就会出乱子。

8.x 把自增计数器的最大值持久化到了 redo log 里，重启后从持久化值继续。这本来是非常合理的修复，但问题在于，很多业务团队在升级前已经习惯了“删数据 + 手动把自增ID改小”的运维操作。升级到 8.x 后，这条手动干预路径失效了，你即使把表里的数据删光，自增 ID 也不会从 1 开始，而是从上次持久化的最大值继续。

举个例子，某测试表原来的自增 ID 到了 100，你 DELETE 了所有数据，然后执行ALTER TABLE t AUTO_INCREMENT = 1，在 8.x 里这个语句直接不生效，除非你把表 TRUNCATE 了。这一点很关键。如果业务上要求 ID 严格连续，建议改用业务唯一键而不是依赖自增主键的连续性。事实上，自增主键本来就不应该代表任何业务含义，它只保证唯一性和插入性能。

2.6 redo log 和 undo 表空间的重新设计

8.x 对 InnoDB 的 redo log 和 undo 表空间做了较大调整，很多人完全忽略了这些底层变化，直到磁盘空间突然告警才反应出来。

在 5.7 里，redo log 是ib_logfile0和ib_logfile1两个固定文件。8.x 改成了 32 个（默认）#innodb_redo目录下的文件，并且支持动态调整容量。官方目的是为了支持类似innodb_redo_log_capacity这样的动态参数，免去改配置要重启的问题。听起来是好事，但实际运维中，如果你的磁盘空间规划没有考虑 redo log 容量自动调整的空间，很可能会出现实例启动后 redo 文件占用的空间比预期的要大得多。

我遇到过一次比较尴尬的情况：为了优化写入性能，把innodb_redo_log_capacity调到了 16GB。监控显示磁盘剩余空间还有 20GB，看着够用，但随后业务高峰写入压力加大，redo 文件按需增长，加上 binlog、临时表空间一起膨胀，磁盘直接到了 95%。当时排查了很久才意识到，redo log 的动态能力不是简单的“设置多大就占多大”，它会在后台预留和扩展文件，实际占用会超过配置值。

undo 表空间也有变化。8.x 默认会创建两个 undo 表空间，并且支持在线增加 undo 表空间，但是老版本升级上来的库，undo 表空间可能还是旧的独立表空间模式。如果你没有及时清理过长的历史版本，purge 线程跟不上，undo 膨胀问题一样会出现。我的建议是升级后把 undo 表空间状态检查纳入日常巡检，尤其是那些长事务比较多的业务。

3. 迁移与升级实操：少走弯路的落地步骤

3.1 升级前的检查清单与工具选型

很多团队做升级，最关心的是“怎么执行”，反而忽略了“怎么验证”。其实升级方案里最花时间的应该是验证部分。十次升级有九次问题出在兼容性验证不充分。

下面是我在多个项目中沉淀下来的一个升级检查清单，如果你也在准备从 5.7 迁到 8.x，可以照着核一遍：

1. 版本和系统环境确认：目标版本是否在你的 OS 发行版官方支持列表里，glibc 版本是否满足，比如某些老 CentOS 7 上的 glibc 版本可能跑不了官方二进制包。
2. 字符集和排序规则：统计所有库表的默认字符集，尤其关注含特殊字符的字段。
3. sql_mode：导出当前全局 sql_mode，逐项确认哪些会在升级后消失或变更。
4. 认证插件：检查所有用户使用的 plugin，并统计客户端连接版本。
5. 存储过程、函数、触发器：用mysqlcheck或者官方升级工具做语法检查。
6. 分区表：8.x 对分区表有一些限制调整，比如不支持在分区表上使用外键，需要提前检查。
7. 自增列：确认是否对自增 ID 有“必须连续”的依赖。
8. 定时任务和脚本：所有调用 mysql 命令行的地方，都要检查客户端兼容性。

工具选型方面，官方提供的 MySQL Shell 升级检查器（util.checkForServerUpgrade）是首选。它能扫描库里的对象并给出兼容性问题列表，虽然不会覆盖所有业务逻辑问题，但至少能把语法层面的坑先扫掉。实际操作中，我会配合自己写的 SQL 扫描脚本，主要是查 information_schema 中所有表结构，对比 5.7 和 8.x 的保留字列表。升级后很多报错其实是因为表名或者字段名撞上了新保留字，比如groups、rank、cume_dist这些在 8.x 成为保留字后，不加反引号就会失败。

3.2 兼容性评估与回归测试要点

兼容性评估不能只看数据库层面。我曾经吃过一个大亏：升级前所有 SQL 检查都通过了，但上线后部分功能异常，最后定位到是业务代码里的 ORM 框架生成的 SQL 使用了INSERT IGNORE和ON DUPLICATE KEY UPDATE。这两个语法本身在 8.x 是支持的，但配合某些特殊字符集或分区表时行为有细微差异，会导致主键冲突未被正确处理。

所以，回归测试绝对不能只做功能层面的“点一下按钮看看通不通”，必须把核心链路的 SQL 单独拎出来做数据对比。我的做法是：

• 搭建一个与生产配置一致的 8.x 测试实例。
• 把生产环境最近一周的通用日志（general log）收集起来，过滤出 SELECT、UPDATE、DELETE、INSERT 等语句。
• 在一个只读的测试库上按顺序回放这些语句，重点观察报错和慢查询。

这样做能最大限度还原线上 SQL 的真实执行情况。通用日志量非常大，一周可能有几十 GB，所以建议只采样高峰期 1-2 小时，基本就能覆盖大部分问题。

回归测试的数据一致性对比也很关键。我通常会在新老两套库上跑同一批统计 SQL，把结果做差集对比。比如分组统计每天的订单量、金额合计数、去重用户数，任何不一致都要找到原因。多数不一致来自排序规则变化或隐式类型转换，但也有小概率来自优化器行为变化导致的“语义相同、结果不同”的执行计划。

3.3 参数对比与配置迁移示例

5.7 里很多参数到了 8.x 要么被移除，要么改名，如果直接沿用旧配置文件，实例可能都启动不了。

举几个常见例子：

• query_cache_size/query_cache_type在 8.x 中已被移除。5.7 里即使不启用查询缓存，你也会在配置文件里设一个很小的值，升级后必须删除。
• innodb_large_prefix参数名已不存在，8.x 默认就是大前缀，旧配置写上去会被忽略或报错。
• innodb_file_format和innodb_file_per_table的某些旧设置已无效。
• log_warnings改名为log_error_verbosity。
• tx_isolation改名为transaction_isolation。
• max_allowed_packet的参数含义没变，但 8.x 的默认值改成了 64MB，某些老配置设的 16MB 仍然能生效，问题是可能不够用。

我一般会在升级前用官方文档里的参数对照表整理一份自定义配置 diff，然后逐项确认。这里分享一个比较稳妥的做法：先在测试机上用官方二进制初始化一个全新实例，生成默认配置文件，再把老实例的所有自定义参数逐项往里填，填完一项就启动一次确认。不要一次性把整个 my.cnf 搬过去，不然报错了你都不知道是哪个参数引起的。

举一个实际迁移后的配置片段示例：

[mysqld] # 基础设置 port = 3306 socket = /tmp/mysql.sock datadir = /data/mysql # InnoDB 相关 innodb_buffer_pool_size = 32G innodb_buffer_pool_instances = 8 innodb_flush_log_at_trx_commit = 1 innodb_redo_log_capacity = 16G # 日志设置 server-id = 1001 log_bin = /data/mysql/binlog binlog_format = ROW binlog_expire_logs_seconds = 604800 # 其他性能参数 performance_schema = ON max_connections = 500

这里想特别提醒innodb_redo_log_capacity。这个参数是 8.0.30 之后才引入的，用来替代innodb_log_file_size。如果你还在用老参数，MySQL 启动时会给一个警告，告诉你这个参数已经废弃。过去调 redo log 大小需要改配置重启，现在可以动态调，但别忘记监控磁盘空间。

4. 性能问题：为什么同样的SQL在8.x里反而慢

4.1 优化器变化：直方图、索引跳跃扫描与代价模型

8.x 的优化器引入了直方图（Histogram）、索引跳跃扫描（Index Skip Scan），并且代价模型有所调整。这是好事，但也带来一个意想不到的副作用：同样的 SQL，在 5.7 里走 A 索引，在 8.x 里可能走 B 索引，甚至走全表扫描，最终性能差异巨大。

我碰到过一个慢查询案例，是一个多表 JOIN 的报表 SQL。5.7 下执行耗时 0.3 秒，8.x 下变成了 12 秒。EXPLAIN 一对比，发现 8.x 优化器选择了完全不同的 JOIN 顺序，驱动表从小表变成了大表。

原因在于 8.x 对索引基数估计、条件过滤性估算的算法更精确，但“更精确”不代表“对你的数据更友好”。特别是当表上的数据分布和数据量没有及时 ANALYZE 更新统计信息时，优化器会基于过期的统计信息做决策，自然容易判断错。

我的建议是：升级后不要直接拿生产流量去验证性能，先做一轮全库的ANALYZE TABLE。然后针对已知的核心 SQL，用EXPLAIN ANALYZE看实际执行步骤和耗时，不要只看预估行数。如果发现某个 SQL 的执行计划在新版本下明显变差，可以通过FORCE INDEX或者优化器提示（hint）先稳住，再考虑从 SQL 改写层面根治。

8.x 的直方图功能也可能造成性能回退。如果你的表数据分布很不均匀，并且建了直方图，优化器反而可能会因此选择一个“理论上更准”但“实际上更慢”的执行路径。遇到这种场景，最简单的处理是 DROP HISTOGRAM 或重新采集，但根子上还是要结合业务查询模式来设计索引。

4.2 隐藏行为：GROUP BY 不再隐式排序

这是最容易被当成“数据错误”的性能坑。在 5.7 里，SELECT ... GROUP BY col的结果默认会按 col 排序，很多老业务就依赖这一点，比如分页查询里的“分组后取第一页”，实际是靠隐式排序实现的。8.x 移除了 GROUP BY 的隐式排序，如果你不主动加 ORDER BY，结果顺序是不保证的。

我遇到一个实际案例是，某报表系统的一个接口用了SELECT user_id, SUM(amount) FROM orders GROUP BY user_id LIMIT 10，业务方默认取的是金额最大的前 10 个用户。5.7 下因为隐式排序，取到的恰好是金额最大的。8.x 下这个行为消失了，返回的 10 个用户基本是随机的前 10 条，报表直接就“错了”。

这类问题特别隐蔽，因为它不报错、不超时，就是结果不对。排查时如果没有前后数据对比，很难发现。我的工具方法很简单：升级后跑一批典型统计 SQL，分别在 5.7 和 8.x 上执行，然后把结果做 md5 比对，不一致的 SQL 逐条检查。不要完全相信业务团队的“接口数据没问题”判断，很多时候“没问题”只是没人对过具体数值。

4.3 监控与诊断：sys.schema 视图、performance_schema 新特性

8.x 的 performance_schema 和 sys schema 也比 5.7 丰富得多。很多团队还在用 5.7 的老办法，通过SHOW PROCESSLIST和SHOW STATUS去诊断问题，这在新版本下效率太低了。

升级到 8.x 后，我墙裂建议把以下这些视图加入日常巡检：

• sys.statement_analysis：按总延迟排序的 SQL 统计，快速定位 TOP N 慢查询。
• sys.session：取代老套路的SHOW PROCESSLIST，能看到会话的当前 SQL、事务状态、锁等待。
• sys.schema_unused_indexes：找出从来没被用过的索引，帮助清理冗余索引。
• sys.innodb_lock_waits：死锁和锁等待排查比手工查 information_schema 好用太多。
• sys.memory_by_user_by_current_bytes：定位内存消耗大户。

8.x 还支持了EXPLAIN ANALYZE，它不只是看执行计划，而是真正执行 SQL 并返回每一步的实际行数、实际耗时和循环次数。我遇到优化器判断错误时，第一件事就是跑EXPLAIN ANALYZE，再结合优化器提示做调整。这个功能是我认为 8.x 最值得推荐的排障工具，没有之一。

另外，8.x 的 performance_schema 对事务、锁、复制、内存等维度的监控更细。比如可以通过performance_schema.data_lock_waits精确看到是哪个事务堵住了哪个事务，而不只是“Lock wait timeout exceeded”这种模糊报错。对生产系统排障效率提升非常明显。

5. 常见问题速查与排查心得

5.1 高频报错对照表

这里我把迁移和运维过程中最常碰到的报错、原因和解决方案整理成了一张速查表，适合直接打印出来或者放进团队 wiki。

5.2 排查思路实录

分享一个比较典型的排查过程，也许能帮大家少走弯路。

某天线上监控突然告警，一个订单查询接口的 P99 延迟从 30ms 涨到了 800ms。当时升级完 8.x 已经过去三周，中间也发过几次版本，所以一开始大家都没把数据库升级当主线怀疑对象。

我先看了sys.statement_analysis，发现出现了一条新的慢查询，用的是ORDER BY created_at DESC LIMIT 20，看起来很简单，也建了索引。但 EXPLAIN 显示走的是全表扫描加 filesort。

继续深挖发现，这条 SQL 里 JOIN 了一张只有几百行的配置表，配置表的关联字段是字符串类型。表结构里配置表的关联字段是varchar(32)，订单表的关联字段也是varchar(32)，两边都有索引。但 8.x 优化器突然选择了把配置表作为驱动表，然后对订单表做全表扫描。

我尝试手动加上STRAIGHT_JOIN强制订单表为驱动表，性能立刻恢复到 30ms。接着用EXPLAIN ANALYZE对比两组计划，发现优化器认为配置表驱动时只需要回表几百次，但忽略了订单表上的过滤条件下推失效的问题。

最终修复不是靠 hint 了事，而是通过改写 SQL，把配置表子查询的结果提前聚合，减少 JOIN 行数，才让优化器回归正常。所以如果你也遇到“升级后慢查询突然很多”的情况，建议先按这个顺序排查：统计信息是否更新、执行计划是否改变、排序规则是否影响索引匹配、SQL 是否依赖隐式转换。

5.3 踩坑后的经验沉淀

项目经历了几轮折腾后，我总结出几条比较个人的经验，不一定适合所有团队，但至少能帮各位规避重复踩坑。

第一条：升级 8.x 不是 DBA 一个部门的事。应用研发、测试、运维必须一起参与。尤其是应用研发要理解“GROUP BY 不再隐式排序”“默认字符集排序规则变化”这些行为变更，否则出了问题只会甩锅给数据库。

第二条：8.x 的默认配置不等于最优配置。很多人升级后纯粹靠官方默认参数跑，结果性能不如 5.7。核心还是要把 buffer pool、redo log、binlog 相关参数按实际业务数据量去调。升级文档里给的是“安全配置”，不是“性能配置”。

第三条：重新审视索引设计。8.x 支持不可见索引（invisible index）、函数索引、索引跳跃扫描，很多 5.7 时代的索引设计已经过时了。我在升级后做过一次索引清理，删掉了 30% 的冗余索引，不仅写入性能提升，磁盘占用也降了不少。

第四条：一定要把ANALYZE TABLE和EXPLAIN ANALYZE变成日常习惯。8.x 的优化器能力很强，但它需要合格的统计信息输入。如果你发现某个查询性能不稳定，先跑一遍ANALYZE TABLE再对比执行计划，很多“玄学”问题其实是统计信息过期。

MySQL 8.x 无疑值得投入，但把老系统迁上去是一件需要耐心和细节的工程。希望这些踩坑记录能让大家少走一些弯路。最后再分享一个小技巧：升级完成后，别急着删除旧版本数据目录，至少保留一个完整快照，最好是能直接启动的物理备份。我在真实生产环境里见过不止一次，升级后发现数据问题，想回滚却因为旧数据目录被清理而只能靠备份恢复，白白损失好几个小时的写入数据。8.x 的升级机制虽然成熟，但从工程稳妥性来看，给自己留一条明确的后路永远是最划算的决策。