迁移后EXPLAIN显示type=ALL，根本原因是索引统计信息未更新，导致优化器误判成本而弃用索引；执行ANALYZE TABLE可强制刷新统计信息并立即生效。
迁移后 EXPLAIN 显示 type=ALL，不是索引丢了，是优化器“不认识”新数据
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+ 树结构。该做的始终是让优化器“看清现状”，而不是反复折腾索引本身。
