如果orderStatus字段的值分布很广，那么索引会更有效。如果大多数行都有相同的状态值，索引效果可能不佳数据倾斜严重：如果status字段的值分布极不均匀，大部分数据集中在少数几个状态上，索引的选择性就会降低，查询效率提升有限首先增加索引肯定会需要额外的空间去储存，另外会影响增删改的性能其次离散性低代表通过索引筛选出的数据量较多，例如status三种状态，1/3的数据和整体数据提升效果较小然后通过二级索引查询数据，是先通过二级索引查询id,然后在通过id去聚簇索引查找数据，多增加一次io消耗

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

选择性（Cardinality）是指列中不同值的数量与总记录数的比例。简单来说，选择性越高（即字段的不同值越多、重复率越低），索引的效果就越好。

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

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

判断方法：可以通过 MySQL 的 SHOW INDEX 命令查看索引的 Cardinality 值，它表示索引的选择性。值越大，索引越有效。sql SHOW INDEX FROM order_info WHERE Key_name = 'idx_order_status'; 如果 Cardinality 很低，说明创建的普通索引对性能提升不大。

4. 查询的数据量的影响

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

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

即将查询的字段都包含在索引中，避免回表。例如，如果你的查询只需要 order_status 和 order_id，那么可以为 order_status 和 order_id 创建联合索引，这样索引中就可以直接返回结果，而不需要回表查询数据。

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

5. 结合不同场景的其他字段

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

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

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

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

6. 分区表

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

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

7. EXPLAIN 查询计划

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

例如：

EXPLAIN SELECT * FROM order_info WHERE order_status = 'FINISHED';

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

快手二面: 千万级别数据的订单表,给订单状态加索引有用嘛

The following article is from 捡田螺的小男孩 Author 捡田螺的小男孩

https://mp.weixin.qq.com/s/HBgtKmMCuC3hgdvHgcqIvA

Last update: 2024-9-19