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 值或重复值过多的列。

• 默认值 innodb_stats_method = nulls_equal：把所有 NULL 当作同一值，若某列 NULL 占比高，基数会被严重低估
• 若该列允许 NULL 且业务中 NULL 含义明确（如“未填写”），可临时设为 nulls_unequal 再 ANALYZE
• 验证方式：SELECT COUNT(DISTINCT col) FROM t WHERE col IS NOT NULL; 对比 SHOW INDEX 输出的 Cardinality

迁移含大量重复值的字段（如状态码、类型字段）时，ANALYZE TABLE 不够用

对于低选择性列（例如 status TINYINT 只有 0/1/2 三个值），即使 Cardinality 刷新正确，优化器也大概率不走索引——因为走索引回表的成本 > 直接全表扫描。这时单纯 ANALYZE TABLE 无法“修复”索引失效，它只是让优化器做出了更真实的判断。

• 不要强行“让索引生效”，先确认这个查询是否真需要走该索引：用 FORCE INDEX 强制走索引，对比 SELECT ... FROM t FORCE INDEX(idx_status) WHERE status=1 和原 SQL 的 EXPLAIN + 实际执行时间
• 若强制走索引反而更慢，说明优化器没选错；应考虑覆盖索引（如 INDEX(status, create_time, id)）或业务层过滤
• 这类字段单独建索引意义不大，优先合并进复合索引的左侧位置

跨版本迁移后，ANALYZE TABLE 失效？检查 innodb_stats_persistent 和 information_schema 权限

MySQL 5.6+ 默认开启 innodb_stats_persistent，统计信息存入 mysql.innodb_table_stats 表。若迁移时没导出这张系统表（mysqldump --all-databases 默认不包含），新实例就只有空的统计信息，ANALYZE TABLE 也无法写入。

• 检查：SELECT * FROM mysql.innodb_table_stats WHERE database_name='your_db' AND table_name='your_table';
• 若无记录，且 innodb_stats_persistent=ON，需先插入基础元数据，或临时关掉：SET GLOBAL innodb_stats_persistent=OFF;，再执行 ANALYZE TABLE
• 确保执行用户有 PROCESS 权限（ANALYZE 需要访问 information_schema）；云数据库如 RDS 可能限制该权限，需用管理员账号操作

真正容易被忽略的是：迁移后第一反应总想“重建索引”，但 ALTER TABLE ... ENGINE=InnoDB 或 DROP/ADD INDEX 并不会刷新统计信息——它只重建 B+ 树结构。该做的始终是让优化器“看清现状”，而不是反复折腾索引本身。