索引漏洞正悄然拖垮你的搜索性能

　　索引漏洞正悄然拖垮你的搜索性能

　　去年春晚，我盯着大屏实时监控看——00:18:23，北京主IDC的MySQL集群QPS从8600骤跌至1170，慢查询日志里93%的语句卡在`SELECT FROM user_profile WHERE city = ? AND reg_time > ? ORDER BY last_login DESC LIMIT 20`，而这张表在2023年10月才加了`(city, reg_time)`联合索引，却漏掉了`last_login`——排序字段没进索引！运维小张凌晨三点喊我时，用户投诉量已冲上App Store差评榜首第2位。

　　我翻出2022年那套旧索引设计规范——用的是B+树深度优先遍历逻辑，当时还标红强调“覆盖排序字段”。可2023年上线的“智能索引推荐引擎”自动扫描SQL后，竟把`ORDER BY last_login`判定为“低选择性冗余列”，直接砍掉。它没读过我们业务里“最后登录时间”的分布：73.4%用户last_login集中在最近72小时，实际选择性高达0.89——比city字段高整整2.1倍。这哪是AI？这是用统计学幻觉当手术刀，在索引心脏上划了道歪口子。

　　上周三下午，我在金融客户那边复现故障：他们给交易流水表建了`(status, create_time)`索引应付“查待处理单”，结果运营部门临时加了个报表需求——要按`create_time`倒序拉“近1小时所有失败订单”，执行计划显示走了全表扫描，5.2亿行数据，耗时41秒。他们DBA信誓旦旦说“索引已覆盖where条件”，可没人检查`create_time`单独作为排序字段时的回表代价。我手动补了`(create_time, status)`索引后，响应压到0.38秒——不是优化，是补漏。

　　更荒唐的是分库分表场景。某电商把订单拆成128个库、每个库32张表，他们在`order_id`字段建了全局唯一索引，却忘了`user_id + create_date`这个高频组合从未被覆盖——上周五晚八点促销峰值期，37个分片同时触发“排序合并超时”，因为中间件要从128个物理节点拉数据再本地排序。他们的索引报告里写着“覆盖率达98.7%”，可这数字把`ORDER BY user_id, create_date`这种跨分片无法下推的场景完全抹掉了。技术部还在庆贺新平台上线——其实数据库早就在后台咳血。

文章配图，仅供参考

　　新技术真香。但香在哪？香在它能一秒生成27个候选索引方案——问题是它不会告诉你，方案#15那个`(region, level, ts)`索引，在ts字段值倾斜度达92.3%（华东区占全量68%）时，会让范围扫描退化成线性扫描。这缺陷我在2023年8月的压测里亲眼见过：同样SQL，在华北区跑0.11秒，切到华东区就飙到12.6秒。我手改索引时加了`INCLUDE (level)`才压住波动——可工具报告里连INCLUDE语法都不支持输出。

　　我试过把“智能索引引擎”训练集换成我们真实的慢查询归档包，它反而更糟：因为归档里有大量测试SQL带着`LIMIT 1`或`FORCE INDEX`，模型学偏了，生成的索引把`LIMIT`当成高优信号，拼命压缩索引宽度，结果线上真实分页查询全崩。现在我只敢让它当实习生——写初稿，我来画红线、填坑、打补丁。

　　对了，你服务器上那个叫`idx_user_2024_q1`的索引——去`SHOW INDEX FROM user_table`看看，Key_len是不是比预估少了4字节？那是`is_vip TINYINT`字段被悄悄忽略了。这事我上周刚修好，但不确定下周会不会重演。

　　我已经在GitLab新建了repo：db-index-autopsy，把春晚那次的原始慢日志、执行计划、修复后的索引定义都扔进去了。代码还没写完，目前只有37行bash脚本和一段骂娘录音。

（编辑：站长网）

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