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;"对比新旧版本输出，能提前暴露这类定义级不兼容。
