为什么 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+ 树；真正卡点常在索引维护成本和查询收益的平衡上，而不是“有没有建索引”。
