有位读者去快手面试，问了这道题：一个表拥有千万级别数据量，给status字段加索引，是否有效？

这道面试题,还是可以从几个维度结合去回答的,我来跟大家聊聊我的看法~~

加了索引的简单执行流程

极端场景,走索引or全表扫描

status区分度与选择行

查询的数据量的影响

结合不同场景的其他字段

分区表

EXPLAIN 查询计划

我觉得,在回答这个问题,可以跟面试官说说,普通索引加入后的简单执行流程.

假设有一张订单表order_info,然后订单状态字段order_status,有个普通索引idx_order_status,它是B+树索引.

我们现在简单点查询,就是查询已完成FINISHED的历史订单:

select * from order_info where order_status = 'FINISHED'

我们来说一下这个执行流程:

从idx_order_status这棵 B+ 树的根节点开始查找。因为B+ 树是有序的，使用二分查找的方法逐层向下查找,直到找到包含FINISHED的叶子节点。

找到FINISHED的起始位置后，数据库会扫描所有包含FINISHED的叶子节点。因为叶子节点存储了主键ID的值.它会遍历索引的叶子节点，以收集所有匹配FINISHED的记录的主键 ID。

使用从idx_order_status索引中获取的主键 ID，数据库会回到ID主键索引树,找到对应的行记录(这个过程叫做回表)。

我先给大家讲解一个极端情况: 假设订单表里面,全部记录的订单,它的状态都是FINISHED.

那肯定不会呀,我们都知道MySQL有优化器的,它发现这一波操作下来(又B+索引树搜索,又回表,多次IO),还没全表扫描快,那就肯定不走索引啦,而是选择全表扫描啦.

这个极端情况,大家应该能理解吧? 那我们再往下一步,假设一千万数据的表,有那么的几条数据,它的订单状是已下单.其他状态都是已完成(FINISHED),那么你觉得会走索引嘛?

对于这道面试题,粉丝们讨论过,我摘抄来一些讨论点下来,给大家看看:

这些观点,其实都跟区分度和选择性有关.比如,订单表有好多种状态,每种状态的数据量都比较均衡,也就是说订单各种状态区分度很好. 再换种专业说法吧,选择性

如果 status 字段的值非常少且重复率高（例如只有 "下单"、"已支付"、"已取消" 这几种状态），那么普通索引可能不会显著提升查询效率，因为数据库可能会选择进行全表扫描。这种情况下，索引的选择性太低，查询时即便走索引，命中的行数也会很多，反而可能导致查询性能变差。

那我们怎么判断,这个选择性呢? 有个方法

如果查询返回的数据量很大,比如查询状态为 "已完成" 的所有订单,即使有索引，数据库可能也会倾向于全表扫描，因为回表操作（即通过索引找到记录后再根据主键去查找完整行数据）可能比全表扫描还要慢。

这时候,我们可以做一些优化,比如,使用覆盖索引

有些时候,比如你查询已完成的订单,如果返回的数据量特别多,一般要求用分页的,这时候,基于分页,可以针对一些做深分页优化,比如使用标签记录法.

单纯查已完成订单的话,业务场景是比较少的. 一般结合其他场景来一起使用.

如果是结合其他场景,那加联合索引,效果就会比较明显啦.

比如查询某个客户的已完成订单,就是说结合客户号来一起查询,这时候加联合索引 idx_client_no_order_status查询效果就很明显.

又或者查询最近三个月的已完成订单,就是说结合订单创建时间来查询.加联合索引idx_create_time_order_status查询效果也很不错

如果有些时候,你的查询只是根据订单条件来查,不结合其他场景的字段. 那还是可以做一些优化,比如分区表.

如果订单表的数据量很大（如上千万级别），考虑使用分区表，可以基于 order_status 字段或其他高选择性的字段进行分区。分区表可以将数据按指定规则分布到多个物理存储区域中，查询时只需要扫描部分分区，提高查询效率。

我们写完查询SQL的时候,经常建议用EXPLAIN 查看一下查询计划.通过 EXPLAIN 查看查询计划，判断是否使用了索引，以及该索引是否在查询中实际被用到。

例如：

EXPLAINSELECT * FROM order_info WHERE order_status = 'FINISHED';

看看是否返回了 index 或 ref 这样的结果。如果查询结果中没有显示索引使用（如 type 为 ALL，表示全表扫描），说明当前的索引并没有起作用。