MariaDB非选择性外键索引致查询性能低下问题排查

听起来你遇到的是优化器执行计划选择失当的问题——明明单独用b列的索引效率更高，却偏偏选了两个索引的交集方案，这在涉及非选择性索引（比如你的a列，仅5个不同值）时确实容易出现。下面是几个针对性的解决方案，按推荐优先级排序：

1. 创建(b, a)复合索引（最优长期方案） #

这是最彻底的解决办法，复合索引可以直接定位到同时满足b=y和a=x的行，完全避免索引交集的额外开销。而且你完全不用担心外键的问题——a列的单独索引依然保留，丝毫不会影响数据完整性约束。

创建索引的语句：

CREATE INDEX idx_b_a ON your_table (b, a);

创建完成后，用EXPLAIN查看执行计划，应该会看到优化器选择这个复合索引，type列会显示ref，查询耗时应该能大幅降低。

2. 强制使用b列的索引（快速临时方案） #

如果暂时不想创建新索引，可以用FORCE INDEX提示强制优化器使用b列的索引，之后再在结果集中过滤a=x的条件。因为b列选择性高，通过它过滤后的数据量已经很小，再检查a的值几乎没有额外开销。

示例查询语句：

SELECT * FROM your_table FORCE INDEX (idx_b) WHERE a=x AND b=y;

同样用EXPLAIN验证，执行计划里应该会显示使用idx_b索引，而非索引合并逻辑。

3. 调整优化器参数（不推荐全局修改） #

如果以上两种方法都不适用，可以临时关闭会话级的索引交集优化，强制优化器不考虑这种执行计划：

SET SESSION optimizer_switch='index_merge_intersection=off';

不过这个方法要谨慎，它会影响当前会话的所有查询，可能导致其他原本适合索引交集的查询性能下降，所以只建议作为临时测试或特定场景下的应急手段。

最后，记得每次调整后都用EXPLAIN分析执行计划，确认优化器的选择符合预期，同时可以用ANALYZE TABLE your_table;更新表的统计信息，帮助优化器做出更准确的决策。

内容的提问来源于stack exchange，提问作者Itamar Tayer