大多数情况下不需要重建索引；仅从5.6及更早升级到8.0且用Antelope格式含大字段，或升级时发现索引校验失败才需手动重建；真正需关注的是统计信息过期，建议对关键表执行ANALYZE TABLE。
MySQL 升级后 ALTER TABLE ... FORCE 或 OPTIMIZE TABLE 是否必须？
大多数情况下不需要重建索引。MySQL 5.7 → 8.0、8.0.x → 8.0.y（小版本）升级后，索引结构（B+Tree 页面格式、元数据存储方式）保持向后兼容，INFORMATION_SCHEMA.STATISTICS 和 mysql.innodb_index_stats 中的统计信息也不会自动失效。
但有两个例外场景需手动干预：
- 从 MySQL 5.6 或更早版本升级到 8.0 时，若原表使用
Antelope文件格式且含大字段（TEXT/BLOB），升级后ROW_FORMAT=DYNAMIC可能未生效，导致二级索引冗余膨胀 —— 此时执行ALTER TABLE t ENGINE=InnoDB ROW_FORMAT=DYNAMIC;会隐式重建索引 - 升级后首次打开表时触发
dict_table_t元数据重载，若发现索引页校验失败（如磁盘静默错误残留），InnoDB 会报Index corruption detected，此时必须用REPAIR TABLE或重建
哪些索引在升级后实际需要重新分析？
真正该关注的是**统计信息过期**，而非物理索引结构。升级本身不重置 innodb_stats_auto_recalc 计数器，但若升级前长期未更新统计（如关闭了自动采样、或表被大量写入后未 ANALYZE TABLE），优化器可能沿用严重偏差的行数/分布估算，导致执行计划劣化。
建议升级后对高频查询涉及的表批量刷新：
- 确认是否启用自动统计：检查
innodb_stats_auto_recalc = ON（默认 8.0+ 是开启的） - 对关键表显式执行：
ANALYZE TABLE orders, users, payments; - 避免全库
ANALYZE TABLE—— 它会锁表（尤其 MyISAM）且对大表耗时，优先按慢查询日志中EXPLAIN显示rows严重偏离实际的表来处理
OPTIMIZE TABLE 在升级后的真实作用是什么？
它本质是 ALTER TABLE ... ENGINE=InnoDB 的语法糖，在 8.0+ 中等价于重建表（含聚簇索引+所有二级索引），主要解决三类问题：
- 碎片整理：
DATA_FREE高（SHOW TABLE STATUS查看），特别是频繁DELETE+INSERT的表 - 页合并：升级后某些旧版本遗留的
fill_factor设置导致页利用率低（如 50%），OPTIMIZE会按当前版本默认填充率（约 15/16）重新组织 - ROW_FORMAT 切换：如从
COMPACT升级到 8.0 后想启用COMPRESSED，必须通过重建实现
注意：OPTIMIZE TABLE 在 8.0.29+ 支持 ALGORITHM=INPLACE（仅限某些变更），但重建索引本身仍需排他 MDL 锁，线上大表慎用。
升级前后索引设计容易被忽略的兼容性坑
MySQL 8.0 引入的索引行为变化，常被误认为“索引损坏”，实则是语义收紧：
-
CREATE INDEX对函数索引的限制：8.0.13+ 要求表达式必须有确定性（DETERMINISTIC），NOW()、RAND()等直接报错，升级前可用的索引定义可能失效 - 隐藏主键策略变更：5.7 中无主键表会隐式添加
GEN_CLUST_INDEX，8.0.30+ 默认禁用该行为（innodb_force_primary_key=ON），升级后建表若无主键会报错 - 全文索引解析器：8.0 默认使用
ngram解析器，若升级前用mechanical，查询结果分词逻辑不同，需显式指定WITH PARSER ngram保持一致
升级前用 mysqldump --no-create-info 导出 DDL，再用 mysql -e "SELECT VERSION(); SHOW CREATE TABLE t;" 对比新旧版本输出，能提前暴露这类定义级不兼容。
