MySQL迁移后如何通过analyze_table刷新索引统计有效解决索引失效问题？
- 内容介绍
- 文章标签
- 相关推荐
本文共计1071个文字，预计阅读时间需要5分钟。
MySQL迁移（无论是跨版本、跨实例，使用mysqldump或物理备份）后，常见现象是索引仍在（SHOW INDEX能查到），但查询突然变慢，EXPLAIN显示type为ALL或key为NULL。这不是索引被删除，而是统计信息过时，优化器误判索引过高，主动放弃使用。
InnoDB 的索引选择严重依赖表的行数、索引基数（Cardinality）、数据分布等统计信息，这些信息默认由后台线程异步采样更新，迁移后不会自动重算——它还记着旧库那几万行的数据特征，而新库可能已千万级。
-
ANALYZE TABLE是最直接有效的刷新手段，强制重新采样并更新统计信息 - 执行后立刻生效，无需重启，也不锁表（仅对表加短暂的 MDL 读锁）
- 注意：在大表上执行会触发 I/O，建议避开业务高峰；若启用了
innodb_stats_persistent=ON，统计信息会持久化到磁盘，迁移后更需手动ANALYZE
ANALYZE TABLE 执行后 Cardinality 仍为 0 或明显不准？检查 innodb_stats_method
有时 ANALYZE TABLE 看似执行成功，但 SHOW INDEX FROM t 中关键列的 Cardinality 仍是 0 或远低于实际唯一值数量。这通常是因为 innodb_stats_method 配置不当，导致采样跳过了 NULL 值或重复值过多的列。
本文共计1071个文字，预计阅读时间需要5分钟。
MySQL迁移（无论是跨版本、跨实例，使用mysqldump或物理备份）后，常见现象是索引仍在（SHOW INDEX能查到），但查询突然变慢，EXPLAIN显示type为ALL或key为NULL。这不是索引被删除，而是统计信息过时，优化器误判索引过高，主动放弃使用。
InnoDB 的索引选择严重依赖表的行数、索引基数（Cardinality）、数据分布等统计信息，这些信息默认由后台线程异步采样更新，迁移后不会自动重算——它还记着旧库那几万行的数据特征，而新库可能已千万级。
-
ANALYZE TABLE是最直接有效的刷新手段，强制重新采样并更新统计信息 - 执行后立刻生效，无需重启，也不锁表（仅对表加短暂的 MDL 读锁）
- 注意：在大表上执行会触发 I/O，建议避开业务高峰；若启用了
innodb_stats_persistent=ON，统计信息会持久化到磁盘，迁移后更需手动ANALYZE
ANALYZE TABLE 执行后 Cardinality 仍为 0 或明显不准？检查 innodb_stats_method
有时 ANALYZE TABLE 看似执行成功，但 SHOW INDEX FROM t 中关键列的 Cardinality 仍是 0 或远低于实际唯一值数量。这通常是因为 innodb_stats_method 配置不当，导致采样跳过了 NULL 值或重复值过多的列。