后端实习手记：漏洞修复加速索引，提升搜索排名

　　上周在实习中接手了一个搜索功能的性能优化任务。用户反馈商品搜索响应慢，尤其在关键词模糊匹配时，页面常卡顿3秒以上。日志显示数据库查询耗时占比高达85%，而核心表的搜索字段未建索引——这是典型的“漏掉基础优化”的案例。

　　我先用EXPLAIN分析了高频搜索SQL：SELECT FROM products WHERE name LIKE '%蓝牙%' OR description LIKE '%蓝牙%'。执行计划明确指出type为ALL，即全表扫描，且rows超过12万。表中已有主键和分类ID索引，但text类型字段name和description完全无索引支持。MySQL对LIKE前缀通配符（如'%蓝牙'）无法使用B+树索引，但后缀匹配（'蓝牙%'）可以——而业务中90%的搜索实际是用户输入开头即触发联想，比如“蓝”“耳机”，并非纯中间匹配。

　　于是将搜索逻辑拆解：前端输入≥2字符时，后端优先走前缀匹配；仅当用户明确点击“全词搜索”或输入含空格/特殊符号时，才启用全文检索兜底。同时为name和description字段分别添加前缀索引：ALTER TABLE products ADD INDEX idx_name_prefix (name(50)), ADD INDEX idx_desc_prefix (description(50))。50是经验值——覆盖98%的商品名称长度，又避免索引过大拖慢写入。

　　上线后QPS从42提升至186，平均响应时间降至320ms。更关键的是，搜索结果相关性明显改善：过去“蓝牙音箱”可能排在“蓝莓果酱”之后，现在因索引加速了精确前缀筛选，结合原有TF-IDF排序权重，高相关商品自然浮出。运营同事惊喜地发现，“无线耳机”关键词下TOP3点击率上升47%。

　　这次修复让我意识到：索引不是越全越好，而是要贴合真实查询模式。一个50字符的前缀索引，比给整列加FULLTEXT更轻量、更稳定，也规避了中文分词不准的风险。DBA师兄提醒我：“索引是数据的路标，不是装饰画——它必须指向人真正走的那条路。”

AI辅助设计图，仅供参考

　　后来复盘发现，问题根源不在技术本身，而在需求文档里写着“支持模糊搜索”，却没定义“模糊”的具体场景。我们默认做了最重的方案，反而忽略了80%用户的实际行为路径。现在每次评审PR前，我都会问一句：“这个查询，在用户手指离开键盘的第300毫秒内，到底发生了什么？”

　　实习第三周，我提交了第一份正式的索引治理清单：标记冗余索引、归档低频查询、为新增字段预设索引策略。带教老师说：“你修的不只是SQL，是数据与人的连接效率。”——原来后端工程师的键盘，敲下的不只是代码，还有用户等待时心里滴答作响的时间。

（编辑：站长网）

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