EXPLAIN 显示 type=ALL 通常因优化器认为全表扫描比索引更快，主因包括索引列被函数/表达式操作、隐式类型转换、数据分布倾斜或 OR 条件未全命中索引。
为什么 EXPLAIN 显示 type=ALL 却没走索引
这通常不是 SQL 写得不对，而是 MySQL 认为全表扫描比走索引更快。常见原因包括：
• WHERE 条件中对索引列用了函数或表达式，比如 WHERE YEAR(created_at) = 2024，会跳过 created_at 索引
• 索引列参与了隐式类型转换，例如字段是 VARCHAR，但查询写成 WHERE user_id = 123（整数），MySQL 可能放弃索引
• 数据分布极不均匀，比如某值占 95% 行数，优化器直接选全表扫描
• 使用了 OR 连接多个条件，且非所有分支都命中索引，如 WHERE a = 1 OR b = 2，而只有 a 有索引
InnoDB 的聚簇索引如何影响 SELECT * 查询
InnoDB 表必须有聚簇索引（通常是主键），所有数据行都按该索引顺序物理存储。这意味着：
• SELECT * 通过主键查（如 WHERE id = 123）非常快，一次 B+ 树查找 + 直接读取整行数据
• 若用二级索引查 SELECT *（如 WHERE email = 'a@b.com'），MySQL 先查二级索引拿到 id，再回表查聚簇索引——这就是“回表”，开销明显增大
• 如果只查二级索引覆盖的列（SELECT email, created_at WHERE email = 'a@b.com'），且这些列都在该索引里（即“覆盖索引”），则完全避免回表
MyISAM 和 InnoDB 在索引使用上的关键差异
两者底层结构不同，直接影响执行计划：
• MyISAM 使用非聚簇索引：索引文件存的是行指针（物理地址），数据文件独立；因此 SELECT * 总是需要两次 I/O（索引块 + 数据块）
• InnoDB 聚簇索引让主键查询天然高效，但二级索引必然包含主键值，所以联合索引设计时要把高频过滤列放前面，把用于排序/分组的列放后面
• MyISAM 不支持事务和行锁，高并发下容易因表锁拖慢索引查询响应；InnoDB 的 MVCC 和行级锁让索引在并发更新场景更稳定
• COUNT(*) 在 MyISAM 中是 O(1)（元数据缓存），InnoDB 必须扫索引或聚簇索引，除非加了覆盖索引
如何验证一条 SQL 是否真的用了索引
别只看 EXPLAIN 的 key 列是否非 NULL，还要结合其他字段判断实际效果：
• type 值优先级： const ≈ eq_ref > ref > range > index > ALL；index 是全索引扫描，仍可能比 ALL 快，但不是理想状态
• rows 表示预估扫描行数，若远大于结果集行数，说明索引选择率差或范围过大
• Extra 中出现 Using filesort 或 Using temporary，往往意味着排序/分组无法利用索引完成，需调整索引字段顺序或补全字段
• 实际执行加 SQL_NO_CACHE 并观察 profiling 或慢日志中的 Rows_examined，它反映真实扫描量
EXPLAIN SELECT name FROM users WHERE status = 1 AND city = 'Shanghai' ORDER BY created_at DESC;
如果 status 和 city 有联合索引但没包含 created_at，就会触发 Using filesort；改成 (status, city, created_at) 才能消除。
索引不是越多越好，InnoDB 每个二级索引都带主键拷贝，写入更新要同步多棵 B+ 树；真正卡点常在索引维护成本和查询收益的平衡上，而不是“有没有建索引”。
