MariaDB查询未使用索引问题排查与优化咨询

嘿，这种明明加了索引却没生效的情况真的很让人头疼，我给你梳理几个最常见的原因和排查方向，你可以对着自己的场景逐一排查：

• 索引字段被函数/运算包裹：比如你写了WHERE YEAR(created_at) = 2024或者WHERE contact_id + 1 = 100，这种情况下数据库没法直接利用索引，得把运算移到等式另一侧，或者改成直接匹配字段原始值。
• 查询返回数据量占比过高：如果你的查询要返回表中30%以上的数据，优化器会判定全表扫描比走索引更高效——毕竟索引需要回表获取完整数据（除非是覆盖索引）。你可以通过EXPLAIN结果里的rows字段，估算下返回数据的比例。
• 隐式类型转换：要是你的contact_id是字符串类型，但查询里用了数字（比如WHERE contact_id = 123而非WHERE contact_id = '123'），这种类型不匹配的隐式转换会直接导致索引失效。
• 索引选择性过低：如果contact_id字段的重复值特别多（比如大部分行的contact_id都是同一个值），优化器会认为这个索引的区分度太差，直接跳过。你可以用SELECT COUNT(DISTINCT contact_id)/COUNT(*) FROM 你的表名计算选择性，比值越高索引的实用价值越大。
• 多表关联的关联条件有问题：你提到有两张表，要是关联时没用到contact_id，或者关联的两个contact_id字段类型不匹配（比如一张表是INT，另一张是VARCHAR），也会导致索引无法被正常使用。

1. 用EXPLAIN分析查询计划：把你的查询语句前面加上EXPLAIN，重点看这几个列：
   • type：如果是ALL就说明走了全表扫描；
   • key：显示实际用到的索引，要是NULL就代表没用到任何索引；
   • Extra：有没有Using index（用到覆盖索引）或者Using where（有过滤条件）这类关键提示。
     这一步是定位问题的核心，能直接看到优化器的选择逻辑。
2. 确认索引的正确性：检查你创建索引的语句是不是CREATE INDEX idx_contact_id ON 目标表名(contact_id)，有没有不小心建到另一张表上，或者索引字段写错了？
3. 尝试覆盖索引：如果你的查询需要返回很多非索引字段，走索引后还要回表查数据，优化器可能会放弃索引。试试把查询需要的所有字段都加到索引里，比如CREATE INDEX idx_contact_id_cover ON 目标表名(contact_id, col1, col2)，这样查询可以直接从索引中获取所有需要的数据，不用回表。

• 修正查询语句：去掉字段上的函数运算，确保类型匹配。比如把WHERE UPPER(contact_id) = 'ABC'改成WHERE contact_id = 'abc'（如果业务允许忽略大小写的话），或者直接创建函数索引CREATE INDEX idx_upper_contact_id ON 目标表名(UPPER(contact_id))。
• 缩小查询结果集：如果是因为返回数据量太大导致不走索引，考虑添加更多过滤条件（比如时间范围、状态筛选）来缩小结果范围，或者对表进行分区（比如按时间分区，如果你有合适的分区字段）。
• 优化多表关联：确保两张表关联的contact_id字段类型完全一致，并且两张表的contact_id都创建了索引，这样关联查询时才能高效利用索引。

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