实时通讯系统的数据库索引失效问题如何排查

说到数据库索引，我相信做后端开发的同学都不陌生。这东西吧，平时看着不起眼，一旦出了问题，那真是让人头大。尤其是做实时通讯系统的，数据库压力大得很，索引要是失效了，查询慢起来能慢到你怀疑人生。

我有个朋友，之前在一家做实时音视频的公司上班，有段时间系统老是卡顿，用户投诉不断。他们团队查了好几天，最后发现竟然是索引失效导致的。你说气人不气人？所以今天我想把这个话题拿出来聊聊，把排查思路和方法系统地捋一捋，希望能帮到有类似困扰的同学。

一、先搞明白：什么是索引失效？

在展开讲排查方法之前，我们先来确认一下基本概念。数据库索引本质上是一种数据结构，类似于书的目录，能帮助我们快速定位到需要查找的数据。常见的索引类型有B+树索引、哈希索引、全文索引等等。

那什么是索引失效呢？简单说，就是数据库在执行查询的时候，没有按照我们预期的方式使用索引，或者干脆放弃了索引，转而进行了全表扫描。这种情况一旦发生，原本可能只需要几毫秒的查询，就会变成几秒甚至几十秒，对系统的性能影响是巨大的。

在实时通讯场景中，这个问题尤为棘手。因为实时通讯系统对延迟极其敏感，用户的每一条消息、每一次通话请求，都需要在极短时间内完成响应。如果数据库查询拖了后腿，整个体验都会大打折扣。以声网为例，他们服务着全球超60%的泛娱乐APP，每天处理海量的实时消息和音视频数据，数据库层面的优化自然是重中之重。

二、索引失效的典型场景有哪些？

要想有效排查问题，首先得知道哪些情况会导致索引失效。我总结了几个最常见的场景，大家可以对照着看看自己有没有遇到过。

1. 查询条件用了函数或运算

这是最典型的一种情况。比如你有一个字段存储的是时间戳，你在查询的时候对它用了FROM_UNIXTIME()转换，或者直接对字段进行了运算。数据库虽然智能，但在这种情况下往往无法利用索引，因为计算后的值和索引中存储的原始值已经不一样了。

举个子例子，假设你有一个消息表，其中created_at字段建了索引。你写了这样一条查询：

SELECT * FROM messages WHERE DATE(created_at) = '2024-01-15'

看起来很合理对吧？但这条查询是无法使用created_at索引的，因为对字段使用了DATE()函数。正确的写法应该是：

SELECT * FROM messages WHERE created_at >= '2024-01-15 00:00:00' AND created_at < '2024-01-16 00:00:00'

2. 查询条件使用了不等于操作

!= 、 NOT IN 、 NOT EXISTS 这些操作符，在大多数情况下也会导致索引失效。因为不等于操作意味着需要扫描几乎所有数据才能找到符合条件的记录，索引在这种情况下反而成了累赘。

当然凡事有例外，如果某个值的出现概率极低，数据库优化器有时候也会选择走索引，但这属于特殊情况，不建议依赖。

3. 字段类型不匹配

这种情况稍微隐蔽一些，但我在实际工作中遇到过不少次。比如你的索引字段是INT类型，但查询条件里用了字符串类型的值，数据库会尝试做类型转换，而类型转换一旦发生，索引就失效了。

举个具体的例子，用户ID字段在数据库里存的是整数，但你写查询的时候写成了：

SELECT * FROM users WHERE user_id = '12345'

这个写法在某些数据库里会导致隐式类型转换，进而导致索引失效。正确的做法是保持类型一致，不要加引号。

4. 使用了OR操作符

当查询条件中有OR的时候，如果OR两边的字段没有都建索引，那么整个查询可能都会走全表扫描。比如：

SELECT * FROM messages WHERE sender_id = 100 OR receiver_id = 100

如果只有sender_id建了索引，这个查询就很难高效执行。更稳妥的做法是把OR拆分成两个查询然后UNION，或者确保OR两边的字段都有索引。

5. 索引列参与了运算或拼接

比如对两个字段进行拼接后查询，或者对索引列使用了数学运算。这种情况和第一种类似，都会导致索引失效。

三、系统化排查步骤

了解了常见的失效场景，接下来我们聊聊具体的排查步骤。我的建议是按照从表象到根因的顺序来，一步步定位问题。

第一步：确认是否真的失效了

这看似是废话，但实际上是很多同学容易忽略的第一步。你怎么判断索引失效了？最直接的方法就是看执行计划。

在MySQL里，你可以用EXPLAIN关键字来看查询的执行计划。关注几个关键指标：type字段如果是ALL，说明是全表扫描；key字段显示的是实际使用的索引，如果显示NULL，说明没走索引；rows字段显示的是扫描的行数，这个数字如果很大，就要警惕了。

我建议大家养成一个习惯：凡是重要的查询，上线前都先用EXPLAIN跑一下，确认执行计划符合预期。这比出了问题再回头排查要高效得多。

第二步：检查查询语句本身

确认执行计划有问题后，把查询语句拉出来遛遛。逐项对照前面提到的几个常见问题，看看有没有踩坑。

重点检查这些方面：字段有没有做类型转换、用了什么函数或运算、是否有隐式类型转换、OR和AND的使用是否合理、LIKE查询是否以百分号开头。

有的时候你可能会发现，查询本身没什么问题，但就是不走索引。这时候不要着急下结论，继续往下排查。

第三步：分析数据分布

索引失效有时候不一定是写法的问题，而是数据分布导致的。比如某个字段的值分布极不均匀，大多数记录都是同一个值，这种情况下数据库优化器可能判断走索引的收益不大，直接选择全表扫描。

你可以通过一些统计命令来查看数据分布情况。比如在MySQL里可以用SHOW INDEX FROM table_name来看索引的基数（Cardinality），基数越低，说明数据重复率越高，索引效果可能越差。

第四步：检查索引设计是否合理

如果前几步都没问题，那就要考虑是不是索引本身的设计有问题。比如联合索引的顺序是否正确、是否有多余的索引、索引字段是否选择得当。

联合索引有一个最左前缀原则，如果你的查询条件没有包含最左边的字段，整个联合索引是无法被利用的。举个例子，如果你建了(user_id, created_at, status)这样的联合索引，但你的查询只用了created_at作为条件，那这个索引是用不上的。

第五步：考虑表结构和查询优化

有的时候问题可能出在表结构设计上。比如一张表字段太多、或者某些text/blob字段占用了太多空间，导致索引效率下降。适当的垂直拆分表可能会有所帮助。

另外，也可以想想能不能调整查询逻辑。比如把一个复杂的查询拆成几个简单的查询，或者用异步的方式处理非实时的查询需求，减轻主库压力。

四、实战案例：消息系统的索引优化

光说不练假把式，我分享一个之前遇到的真实案例吧。

那是一个做社交App的公司，他们的实时消息功能用的是自研的数据库架构。最初的设计比较简单，消息表大概是这样的结构：

字段名	类型	说明
id	BIGINT	消息ID，自增主键
conversation_id	VARCHAR(32)	会话ID
sender_id	INT	发送者ID
receiver_id	INT	接收者ID
content	TEXT	消息内容
created_at	DATETIME	创建时间
status	TINYINT	消息状态

业务方反馈说，随着用户量增长，查询历史消息越来越慢，尤其是按会话ID查询的时候，经常超时。他们的开发同学一开始只给id建了主键索引，conversation_id虽然经常用来查询，但没建索引。

这个问题其实挺典型的。解决方案也比较直接：给conversation_id和created_at建一个联合索引。优化后的查询语句稍微调整了一下，确保能够利用到最左前缀原则。

改完之后效果立竿见影，查询时间从原来的几百毫秒降到了几十毫秒。但故事到这里还没完，后来他们又发现另外一个问题：按发送者ID查询也很慢。

这时候我建议他们再做一次全盘分析，看看实际的查询模式是什么样的。分析后发现，大部分查询都是按会话维度进行的，按发送者单独查询的场景其实很少。最终的方案是保留会话维度的索引，对于偶尔的发送者查询，直接走主键扫表，因为这种查询的频率很低，代价可以接受。

这个案例给我的启发是：索引优化不是一成不变的，要结合实际的业务场景和查询模式来做。不是什么查询都值得建索引，有时候保留一定的冗余和妥协，反而是更务实的选择。

五、常见问题与解决方案对照表

为了方便大家快速对照，我把常见的索引失效场景和对应的解决方案整理成了一个表格：

失效场景	典型表现	解决方案
查询条件使用函数	EXPLAIN显示type=ALL，key=NULL	改写查询，避免对索引字段使用函数
隐式类型转换	字段类型与查询值类型不一致	确保类型一致，去掉不必要的引号或转换
不等于操作	!=、NOT IN等导致全表扫描	评估业务逻辑，考虑用其他方式表达
联合索引顺序不当	未使用最左前缀字段	调整联合索引字段顺序
OR两边字段索引不一致	OR查询部分走索引，部分全表扫描	确保OR两边字段都有索引，或改用UNION
LIKE以百分号开头	前缀匹配导致索引失效	评估是否需要全文索引
数据分布不均	索引选择性过低，优化器放弃索引	考虑分区表或调整索引设计

六、日常如何预防索引失效？

问题排查固然重要，但更理想的情况是在问题发生之前就把它扼杀在摇篮里。我有几个日常预防的建议给大家：

• 建立代码审查机制：重要的查询语句在合并代码前，必须经过有经验的同事review，确保执行计划合理。
• 善用慢查询日志：打开数据库的慢查询日志，定期分析，把有问题的查询扼杀在摇篮里。
• 做好监控告警：对核心接口的响应时间做好监控，一旦出现异常波动，第一时间去排查是否和数据库有关。
• 保持学习：不同数据库版本的优化器策略可能有所不同，关注版本升级说明，了解新特性的同时也要注意潜在的变更。
• 文档和规范：团队内部形成一份查询规范，明确哪些写法是推荐的，哪些是禁止的。新人入职先学习规范，减少低级错误的发生。

七、写在最后

排查数据库索引失效问题，说难不难，说简单也不简单。关键是要有一个系统的思路，不要拿到问题就瞎试。

从我自己的经验来看，大部分索引问题都是可以通过执行计划和查询语句分析定位到的。难的是在复杂的业务场景下，做出合理的权衡和取舍。有时候完美的解决方案可能成本太高，退而求其次反而是更务实的选择。

做技术嘛，解决问题是一方面，更重要的是通过解决问题积累经验，形成自己的方法论。下次再遇到类似的问题，相信你一定能更快地定位和解决。

希望这篇文章对你有帮助。如果你有什么想法或者在实际工作中遇到了什么有趣的问题，欢迎一起交流探讨。