myisam复合索引失效根因在于统计信息陈旧或隐式类型转换，需用explain验证key/type/key_len字段，强制analyze table并严查字段类型与最左前缀匹配。
MyISAM 引擎下复合索引失效，和 InnoDB 的 B+Tree 索引行为基本一致，但排查时要特别注意 MyISAM 不支持事务、无 MVCC、统计信息更新机制更简单 —— 这些会让 EXPLAIN 结果有时“看起来合理”，实际却没走索引。
用 EXPLAIN 看是否真用了索引
这是唯一可靠起点。不要只看 possible_keys，重点盯 key 和 type 字段：
-
key为空或显示NULL→ 没用上索引（哪怕possible_keys列出了你的复合索引） -
type是ALL→ 全表扫描，索引彻底失效 -
type是range或ref，但key_len明显小于预期 → 只用了复合索引前几列，后续列被跳过 - MyISAM 下
rows值往往比 InnoDB 更“乐观”，别轻信；结合实际执行时间判断
检查复合索引是否被最左前缀截断
MyISAM 的复合索引严格遵循最左前缀原则，且不支持索引下推（ICP），所以一旦跳过首列，整条索引就废了：
- 索引是
INDEX(a, b, c)，但查询写成WHERE b = 1 AND c = 2→a缺失，索引完全不用 - 查询是
WHERE a = 1 AND c = 2→b被跳过，c列无法命中，索引只用到a - 范围查询（
>、、<code>BETWEEN）后，右侧所有列自动失效：例如WHERE a = 1 AND b > 5 AND c = 10→c不会走索引
确认有没有隐式类型转换或函数干扰
MyISAM 对类型转换更敏感，且不会像 InnoDB 那样尝试智能回退：
- 字段是
VARCHAR，条件写成WHERE phone = 13800138000→ MySQL 把每行字符串转数字比较，索引失效 - 用了
DATE(create_time)、UPPER(name)等函数 → 索引列值被改写，MyISAM 无法匹配原始索引项 - 字符集不一致（比如表用
utf8mb4，而连接用latin1）→ 比较前强制转换，同样绕过索引
验证 MyISAM 统计信息是否过期
MyISAM 不自动更新统计信息，EXPLAIN 依赖的行数估算可能严重失真，导致优化器误判“全表扫描更快”：
- 执行
ANALYZE TABLE table_name;强制刷新统计信息（这是 MyISAM 必做动作，InnoDB 通常不需要） - 如果表长期只写不读，或批量导入后没
ANALYZE，rows值可能还是建表时的旧数据 - 极端情况：即使索引存在且条件合规，优化器仍选
ALL，这时ANALYZE往往立竿见影
MyISAM 下索引失效的根因往往藏在统计信息陈旧或类型转换细节里，而不是语法本身 —— 即使 EXPLAIN 看起来没问题，也要动手跑 ANALYZE 和检查字段类型是否严丝合缝。
