MySQL多列索引列序优化：交易表查询性能最优方案咨询

嘿，这个问题问到点子上了——多列索引的顺序绝对是影响这类等值查询性能的核心，而且很多人都会和你一样陷入“从低基数列开始”的直觉误区，咱们一步步拆解清楚：

首先纠正直觉误区：不是从最窄（低基数）列开始 #

你的直觉是先放kind（3种取值）、status（6种取值）这类低基数列，但其实对于全等值条件的查询，索引列的核心排序逻辑是：把「能最快缩小结果集范围」的列放在最前面——也就是选择性最高（基数最大）的列。

咱们拿你的数据规模算一笔账：

• parent_ref有50万种取值，平均每个值对应2条记录（100万/50万）
• kind只有3种，平均每个值对应33万条记录
• status有6种，平均每个值对应16万条记录

如果按你的直觉建(kind, status, parent_ref)索引：
MySQL会先扫描所有kind='BATCH_BET'的索引条目（约33万条），再从中筛选status=1的（约5.5万条），最后才能定位到parent_ref='1-0001'的那1-2条。整个过程要扫描几十万条索引条目，IO开销很大。

但如果建(parent_ref, kind, status)索引：
MySQL第一步就通过parent_ref='1-0001'定位到仅2条左右的索引条目，再从中筛选kind和status，几乎没有额外扫描。对比下来，索引扫描的行数差了几个数量级，性能提升非常明显。

列取值分布（基数）的核心影响 #

列的取值分布（也就是基数，即distinct值的数量）直接决定了列的选择性（选择性=distinct值数/总行数，越接近1选择性越高）：

• 选择性越高的列，单次过滤能排除的无效数据越多，结果集缩小得越快
• 对于等值查询，把高选择性列放在索引最前面，能最小化索引扫描的行数，直接降低IO和CPU开销
• 低选择性列在前的话，第一步过滤后会留下大量中间结果，后续需要持续扫描大量索引条目，拖慢查询

还要考虑哪些和取值相关的因素？ #

除了基数，还有几个实际场景的因素需要权衡：

• 查询的复用性：如果你的系统除了这个查询，还有其他高频查询用到kind+status，或者parent_ref+kind这类组合，可能需要调整索引顺序来兼顾多个查询的性能，或者创建复合索引的变体。但如果这个查询是核心高频查询，优先满足它的性能优先级最高。
• 索引维护成本：高基数列在前的索引，在插入、更新、删除数据时，可能会因为索引节点更分散而产生更多页分裂。但对于100万级别的表，这种维护成本远低于查询性能的提升——除非你的写操作（增删改）频率远高于读操作。
• 数据的实际分布偏差：比如有没有某些kind+status的组合占比极高？比如kind='BATCH_BET'且status=1的行占了总数据的30%？不过即便如此，parent_ref的高基数还是能把结果集缩小到2条左右，所以对核心查询的影响不大。
• 覆盖索引的可能性：如果你的查询不需要返回全表所有列（比如只需要id、amount），可以把这些列加入索引，做成覆盖索引（比如(parent_ref, kind, status, id, amount)），这样MySQL直接从索引里取数据，不需要回表查询原数据，性能会再上一个台阶。

最终结论 #

针对你的核心查询，最优的索引顺序是(parent_ref, kind, status)（或者(parent_ref, status, kind)，后两个列的顺序对性能影响极小）。

内容的提问来源于stack exchange，提问作者David Geismar