索引漏洞正 silently 拖垮你的搜索体验

　　一个月前那场慢查询爆出来的时候，我正盯着屏幕上的行数跳了快俩小时——风扇在脚底下嗡嗡转，外卖在工位上凉透，开发老王路过问了句“还没好？”，我头都没抬说“快了快了”。结果他凑过来看了一眼，直接笑出声：“你这索引怕不是拿脚写的？”

　　当时的情况是，一个核心表的复合索引字段顺序反了。主键是用户ID+时间戳，结果有人非要把时间戳放第一位，说“按时间查更频繁”。我原以为这种小改动能糊弄过去，结果业务方一上线新功能，查询条件全变了——现在要按用户ID+状态查，原来的索引直接废了一半。慢查询日志里全是“Using filesort”，执行计划显示走了全表扫描，我盯着那行“possible_keys: NULL”看了半天，突然想起上周运维说“最近主库CPU有点高”。

　　这事儿最气的是，它不是突然爆的。业务方两周前就反馈“搜索变慢了”，但那会儿大家都在赶上线，没人当回事。测试环境也没复现——因为测试库的数据量只有生产环境的十分之一，索引漏洞在数据量少的时候根本不显眼。直到生产库涨到千万级，问题才像泡烂的木耳一样浮出来。我后来跟开发吵了一架，他说“索引不是你们DBA管的吗？”，我回“你们改字段顺序的时候问过我吗？”，最后领导拍板“先加临时索引顶着”，结果加完发现事务锁冲突更严重了——因为临时索引没考虑主从同步，从库延迟直接飙到十分钟。

　　那天我加班到十点，窗外天都黑了。回家路上越想越气：索引漏洞这玩意儿，就像藏在地毯下的灰尘，平时看不见，等你踩上去才知道有多脏。它不会让你数据库宕机，不会报错，就是慢慢拖垮你的搜索体验——用户点搜索，三秒没反应，五秒没结果，最后直接关页面走人。业务方只会说“体验差”，不会说“是索引漏了”，但数据不会说谎——DAU掉了五个点，转化率跌了三个点，这些锅最后都得技术背。

　　我后来翻了半天慢查询日志，发现类似的漏洞不少。比如有个表，明明有单列索引，但查询条件里用了函数，导致索引失效；还有个表，复合索引的字段类型不一致，一个INT一个VARCHAR，MySQL居然没报错，只是默默走了全表扫描。最离谱的是有个备份恢复的坑——测试环境恢复数据时，索引文件没同步，导致生产环境的索引结构在测试环境跑偏，测试同学还纳闷“为什么同样的SQL在测试环境快，生产环境慢”。

　　说到这儿突然想起午饭。今天中午点外卖，送来的时候汤洒了一半，我跟骑手吵了十分钟，最后发现是包装袋没封好。这跟索引漏洞多像啊——问题出在细节，但没人愿意花时间检查细节。大家都忙着赶进度，忙着写新功能，忙着应付业务方的需求，等到问题爆了，才想起来“是不是索引有问题？”。

　　我原以为索引优化是技术活，结果发现它更像“排雷”——你得知道哪儿可能有雷，还得知道怎么拆。但现实是，很多雷是“silent”的，它不响，不炸，就静静躺在那儿，等你踩上去。就像那个复合索引字段顺序反了的问题，如果业务方不改查询条件，如果数据量不涨到千万级，如果测试环境能复现，如果运维早点看CPU监控——任何一个“如果”成立，这雷都不会爆。但现实是，所有“如果”都没成立，雷爆了，锅背了，大家继续赶下一个需求。

　　现在我在考虑要不要写个脚本，定期扫索引漏洞。比如检查复合索引的字段顺序是否合理，检查查询条件是否用了函数，检查字段类型是否一致，检查备份恢复时索引文件是否同步。但转念一想，这些事儿本来就该是开发在写SQL时注意的，DBA在审SQL时把关的，测试在测功能时验证的。结果现在全堆到我头上，我成了“索引警察”，每天追着开发改SQL，追着测试补用例，追着运维看监控——这合理吗？

文章配图，仅供参考

（编辑：站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!