MySQL面试中如何高效回答索引优化相关问题？
- 内容介绍
- 文章标签
- 相关推荐
本文共计909个文字，预计阅读时间需要4分钟。
不是索引本身变慢，而是MySQL在满足查询时被强迫忽略覆盖索引（Covering Index），转而回表查询。只要SELECT的字段没有全部包含在索引中，比如只有id字段在索引中，也可能会触发回表查询。
- 复合索引
(a, b, c)可以高效响应SELECT a, b FROM t WHERE a = 1 AND b > 10（覆盖索引） - 但
SELECT a, b, d FROM t WHERE a = 1就必须回表取d，即使d是主键——因为d不在索引列中 -
SELECT *几乎必然导致回表，尤其当表有大字段（TEXT、BLOB）时，I/O 成倍增加
LIKE '%abc' 为什么用不上索引
前导通配符破坏了 B+ 树的有序查找路径。索引本质是按字典序存储的有序结构，LIKE 'abc%' 可以定位到 abc 开头的范围，但 '%abc' 需要扫描全部叶子节点匹配后缀，等价于全索引扫描。
本文共计909个文字，预计阅读时间需要4分钟。
不是索引本身变慢，而是MySQL在满足查询时被强迫忽略覆盖索引（Covering Index），转而回表查询。只要SELECT的字段没有全部包含在索引中，比如只有id字段在索引中，也可能会触发回表查询。
- 复合索引
(a, b, c)可以高效响应SELECT a, b FROM t WHERE a = 1 AND b > 10（覆盖索引） - 但
SELECT a, b, d FROM t WHERE a = 1就必须回表取d，即使d是主键——因为d不在索引列中 -
SELECT *几乎必然导致回表，尤其当表有大字段（TEXT、BLOB）时，I/O 成倍增加
LIKE '%abc' 为什么用不上索引
前导通配符破坏了 B+ 树的有序查找路径。索引本质是按字典序存储的有序结构，LIKE 'abc%' 可以定位到 abc 开头的范围，但 '%abc' 需要扫描全部叶子节点匹配后缀，等价于全索引扫描。