MySQL升级后必须手动执行ANALYZE TABLE更新统计信息，否则EXPLAIN的rows值失真；需核验索引定义一致性、前缀长度、生成列索引有效性，并利用performance_schema识别僵尸索引，结合EXPLAIN FORMAT=TREE验证优化器行为变化。
升级后立刻检查 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），往往意味着前缀索引被降级，需重新评估字段类型和排序规则
升级后的索引状态不是“看起来还在就行”，而是要验证它是否被优化器真正信任、是否在真实负载下被调用、以及是否还符合当前版本的语义边界。最容易被忽略的是统计信息延迟更新和生成列索引的隐式失效——这两处问题不会报错，但会让慢查询无声无息地回归。
