说起来，

前言

不管你是面试还是日常调优。只要聊到数据库运行速度，“索引”几乎一定是绕不开的话题。

很多小伙伴知道索引能加速查询，但问到“怎么建索引才能让查询最快”时往往只能答出“给 where 后面的列加索引”。话说回来，

如果你曾经因为错误的索引设计导致查询变慢、写入卡顿。或者在面试中被问到“如何调整索引”，那一定深知这不是一件简单的事。

更多项目实战请访问我的技术网站：

从技巧一来看。选择高选择性的列作为索引

问题现象

有些小伙伴习惯性地给所有出现在 WHERE 子句中的列都加上索引，结果发现加了索引反而更慢。

比如给“性别”列加索引，查询男性使用者时依然扫描了大量数据。

什么是选择性？

选择性 = COUNT / COUNT比值越接近 0 或 1，选择性越高。选择性高的列能快速过滤掉大量数据。

-- 查看选择性
SELECT
COUNT / COUNT AS gender_selectivity,COUNT / COUNT AS user_selectivity
FROM users;

• 低选择性性别，索引几乎没用。
• 高选择性使用者 ID、订单号，索引价值很高。

底层原理

InnoDB 的 B+Tree 索引结构，每个叶子节点存储一个键值 + 行指针。当选择性很低时虽然树高度低，但每个键值对应海量行。仍需回表读取大量数据，代价甚至超过全表扫描。此时调整器会选全表扫描，

正确做法

只在高选择性列上建索引。若业务必须过滤低选择性字段。可将其放在联合索引的末尾,作为二次筛选项。

-- 不推荐
ALTER TABLE orders ADD INDEX idx_status;按理说，-- 推荐：status 作为联合索引的后续列
ALTER TABLE orders ADD INDEX idx_user_status;话说回来，

适用场景与优缺点

• 优点: 高选择性索引能迅速定位少量数据。 极大减少 IO，
• 缺点: 低选择性索引浪费空间，而且写入时需要维护。
• 适用场景: 使用者 ID、订单号、手机号等唯一或接近唯一的列。

再看技巧二。联合索引遵循最左前缀法则

Create了 ,写成,结果不走索，引发极慢查询。你可能也遇到过类似情况——看似合理，却让调整器完全忽略了你的联合索引用意图。

最左前缀原则

A B+Tree 上的联合索引用 a 排序；当 a 相同再按 b 排序；b 相同再按 c 排序，只有包含最左边列的条件才能使用整个联合键。否则后面列即使等值，也无法起作用。

正确与错误示例

-- 正确：用到所有列
SELECT * FROM t WHERE a =?AND b =，AND c =?，-- 正确：只用到了 a 和 b，c 无法完全匹配。但已过滤大量数据
SELECT * FROM t WHERE a =?AND b =，;-- 正确：只用 a，也能使用部分键
SELECT * FROM t WHERE a =?，-- 错误：跳过 a 完全无法使用键
SELECT * FROM t WHERE b =?AND c =，;-- 错误：范围查询后的列无法使用键
SELECT * FROM t WHERE a =?
AND b>，老实说，AND c =?
，-- c 不会走键，因为 b 是范围

调整建议

• EQL 列放最左边： 例如 id、status 等等.
• SCOPE 列放右边： 如 range 查询>。<, BETWEEN.
• 尽量保证查询条件覆盖最左前缀，避免跳过前列导致失效。

适用场景

{ul}

多条件组合查询频繁的表。例如日志分析、报表生成等.

}

需要排序、分组、过滤的大型业务表.

{/ul}

---

技巧三这方面，尽量使用覆盖索引，避免回表

什么是回表？

---