升级后立刻检查 INFORMATION_SCHEMA.STATISTICS
是否同步更新
MySQL 升级（尤其是跨大版本，如 5.7 → 8.0）后，
INFORMATION_SCHEMA.STATISTICS中的索引统计信息可能未自动刷新，导致
EXPLAIN显示的
rows严重失真，误判索引有效性。 执行
ANALYZE TABLE table_name;强制更新统计信息，不是可选操作，是必须步骤 对所有高频查询表批量执行：
SELECT CONCAT('ANALYZE TABLE ', table_schema, '.', table_name, ';') FROM information_schema.tables WHERE table_schema NOT IN ('mysql','information_schema','performance_schema','sys');，再复制结果运行
注意：8.0+ 默认启用 innodb_stats_auto_recalc=ON，但首次升级后仍需手动触发一次，否则旧统计值可能残留
用 SHOW INDEX
和 INFORMATION_SCHEMA.KEY_COLUMN_USAGE
核验索引定义一致性
升级过程本身不删除索引，但某些场景下索引会“失效”——比如列字符集变更、前缀长度超限、或使用了被弃用的语法（如
FULLTEXT在非
utf8mb4下行为异常）。
SHOW INDEX FROM table_name;看
Sub_part是否为
NULL或数值异常（如 8.0 中
VARCHAR(255)字段建了
INDEX(col(1000))会静默截断，实际生效前缀可能是 767 或 3072，取决于
innodb_large_prefix和行格式） 对比升级前后
SELECT * FROM INFORMATION_SCHEMA.KEY_COLUMN_USAGE WHERE TABLE_SCHEMA = 'db' AND TABLE_NAME = 't';的
COLUMN_NAME和
ORDINAL_POSITION，确认复合索引字段顺序没被意外重排 特别检查含生成列（generated column）的索引：8.0.23+ 对
STORED列索引支持更严格，若升级后查询变慢，先查该索引是否仍在
SHOW CREATE TABLE输出中
通过 performance_schema.table_io_waits_summary_by_index_usage
找“僵尸索引”
升级后是清理低效索引的黄金窗口——新版本的
performance_schema表提供了更精确的索引使用统计，比旧版
Handler_read_*状态变量更可靠。 查近 7 天未被任何查询使用的索引：
SELECT OBJECT_SCHEMA, OBJECT_NAME, INDEX_NAME FROM performance_schema.table_io_waits_summary_by_index_usage WHERE INDEX_NAME IS NOT NULL AND COUNT_READ = 0 ORDER BY OBJECT_SCHEMA, OBJECT_NAME;注意：该统计仅从实例重启后开始累积，若升级后没重启过 mysqld，数据为空——此时需先执行
TRUNCATE TABLE performance_schema.table_io_waits_summary_by_index_usage;再观察几天 别直接删主键或唯一约束索引，即使
COUNT_READ=0；它们可能被外键检查、唯一性校验等隐式路径使用
执行 EXPLAIN FORMAT=TREE
验证索引选择逻辑变化
MySQL 8.0 引入了新的优化器提示和更激进的索引合并策略，同一 SQL 在升级后可能走完全不同执行计划，尤其影响
OR条件、多范围扫描、或松散索引扫描场景。 对核心业务 SQL 运行
EXPLAIN FORMAT=TREE SELECT ...，重点看输出中是否出现
index_rowid_intersection或
index_merge——这表示优化器主动组合多个索引，但实际性能未必更好 如果发现原本走单索引变成走
index_merge且响应变慢，可用
USE INDEX或
FORCE INDEX锁定旧路径临时止损 检查
key_length值是否异常缩小（如从 767 降到 307），往往意味着前缀索引被降级，需重新评估字段类型和排序规则
升级后的索引状态不是“看起来还在就行”，而是要验证它是否被优化器真正信任、是否在真实负载下被调用、以及是否还符合当前版本的语义边界。最容易被忽略的是统计信息延迟更新和生成列索引的隐式失效——这两处问题不会报错，但会让慢查询无声无息地回归。
