索引统计信息维护指南

SQL 变慢了先看你的索引“基数”准不准1. 为什么需要更新统计信息MySQL 优化器在执行 SQL 前会进行“成本计算”。如果统计信息过旧例如表中数据发生了大量增删改优化器可能会产生误判选错索引认为某个区分度低的索引更快。放弃索引由于预估扫描行数过多错误地选择了全表扫描。Index Dive 失败当IN条件超过阈值时优化器会强制依赖统计信息若信息不准性能将雪崩。2. 诊断工具SHOW INDEX在决定是否更新统计信息前你应该先通过SHOW INDEX命令进行“体检”。SHOWINDEXFROMtbl_name;核心指标Cardinality基数这是统计信息中最关键的数值代表索引中唯一值的预估数量。如何判断对比Cardinality与表总行数。如果一个 100 万行的表某个高区分度字段如手机号的基数显示只有几千说明统计信息已经严重失真优化器极大概率会选错索引。结构确认同时可以检查Seq_in_index确认联合索引的字段顺序确保查询符合最左前缀法则。3. 执行命令ANALYZE TABLE当你发现SHOW INDEX中的基数与实际严重不符时应执行ANALYZE TABLE命令ANALYZETABLEtbl_name;功能对表进行采样分析更新索引的基数Cardinality。特点InnoDB 行为它会触发存储引擎对索引树进行随机采样通常是 8 个或 20 个页。在线操作在执行期间表是可读的但会产生轻微的 CPU 和 I/O 负载。持久化分析后的结果会存储在mysql.innodb_table_stats和mysql.innodb_index_stats系统表中。4. 统计信息的存储与触发InnoDB 引擎可以通过参数配置统计信息的更新策略自动更新默认情况下当表中超过10%的数据被修改时InnoDB 会尝试自动重新计算统计信息。持久化配置innodb_stats_persistent设置为ON时统计信息会持久化到磁盘重启后不会丢失。innodb_stats_auto_recalc控制是否在数据大幅变动时自动触发分析。5. 解决“统计信息不准”的进阶手段如果执行ANALYZE TABLE后通过SHOW INDEX观察到的基数依然偏差较大可以调整采样深度增加采样页数通过设置innodb_stats_transient_sample_pages内存或innodb_stats_persistent_sample_pages磁盘来提高采样的覆盖率让预估更精准。6. 常见运维场景大批量导入数据后必须执行一次ANALYZE TABLE否则优化器可能还认为表是空的。执行计划突然变差如果同样的 SQL 以前快现在慢首选使用SHOW INDEX检查统计信息是否失效。配合维护工具除了手动执行也可以使用mysqlcheck --analyze实用程序批量处理多个数据库。