MySQL索引未生效：带LIKE条件的查询为何走全表扫描？

• 匹配行数占比过高
  当edge_server = 'AFTEC1'的记录占表总数据量的较大比例（通常20%-30%以上）时，MySQL优化器会判定全表扫描的效率高于走索引。因为走索引需要先定位索引条目，再回表查询聚合所需字段，大量回表的开销反而比直接扫描全表更大。
  解决：若这类查询是高频操作，可建立覆盖索引，将聚合用到的字段也包含进去，避免回表。示例语句：

  CREATE INDEX idx_edge_server_kpi ON cre_kpi(edge_server, attempts, asr, ner, cranckbackCount);
  

• 未使用覆盖索引
  当前索引仅包含edge_server字段，查询需要的attempts、asr等字段不在索引中，执行时需通过索引找到主键后，再去主键索引读取对应行数据（回表操作）。优化器评估后可能选择跳过索引，直接全表扫描。
  解决：创建包含所有查询字段的覆盖索引，让MySQL直接从索引中获取所需数据，无需回表。

• 表统计信息过时
  MySQL优化器依赖表的统计信息估算匹配行数和执行成本，如果统计信息过时（比如表近期有大量数据增删改），优化器会做出错误判断，选择全表扫描。
  解决：执行ANALYZE TABLE cre_kpi;更新表的统计信息，让优化器重新评估执行计划。

• 索引有效性问题
  检查索引是否正常存在且可用：

  SHOW INDEX FROM cre_kpi;
  

  确认edge_server对应的索引状态正常，没有被禁用或创建错误（比如误建部分索引、索引字段类型不匹配等）。

内容的提问来源于stack exchange，提问作者Jibin