加入收藏 | 设为首页 | 会员中心 | 我要投稿 草根网 (https://www.0515zz.com/)- 数据工坊、大数据、建站、存储容灾、数据快递!
当前位置: 首页 > 教程 > 正文

SQL Server查询卡顿?5个索引优化技巧提速3倍

发布时间:2026-11-12 11:25:05 所属栏目:教程 来源:DaWei
导读:  “这查询慢得像在等审批流走完三级会签。”我刚说完,小陈就低头去抠键盘右下角那个翘起来的ESC键,抠了三下——他昨天说要修,结果今天还在抠。  去年7月份的事。当时需求评审那一刻,产品把“订单列表支持按任意字段

  “这查询慢得像在等审批流走完三级会签。”我刚说完,小陈就低头去抠键盘右下角那个翘起来的ESC键,抠了三下——他昨天说要修,结果今天还在抠。


  去年7月份的事。当时需求评审那一刻,产品把“订单列表支持按任意字段组合筛选”写进PRD第17页第三段,加粗,还画了个小星星。没人问SQL怎么跑。老张直接说“加索引呗”,语气跟说“加个盐”似的。白板笔没水了,我拿蓝色那只划重点,划到一半只剩白印子。投影仪对焦不准,左下角“索引建议”四个字始终糊成一团灰块,大家也就那么看着。


  我原以为只是where条件写得糙,结果一抓执行计划——扫全表,扫了1200万行,中间还嵌着两个nested loop join。但你猜怎么着?那张订单主表,建表语句里连一个非聚集索引都没有。只有聚集索引,还是用的自增ID。真·优胜劣汰:没被查的字段活下来了,被查的字段全在裸奔。


  空调在滴水,嗒、嗒、嗒,每声都卡在我说“覆盖索引”这个词的尾音上。小陈手机一直在震,震动模式,声音不大,但节奏太准,像在给我的语速打拍子。我讲第一条技巧:“把SELECT字段塞进INCLUDE里”,老张突然抬头,“等等,INCLUDE能塞text类型不?”我没接,因为我也记不清是哪个版本了。SQL Server 2016之后?大概那个数。他笔记本上写着“text不支持”,但底下又划了条横线,没写为什么。


文章配图,仅供参考

  第二条,最坑的是ORDER BY字段必须出现在索引键里,不能只靠INCLUDE。我们有个报表接口,排序字段是update_time,但索引建的是(create_time, status),用户偏要点update_time倒序。结果就是:索引用了,但SQL Server硬生生给你加个Sort操作符,占掉78%成本。我那天导出执行计划截图发群里,李薇回了个“????”,再没下文。桌上那摞打印的需求单没人收,边角都卷起来了,最上面那张印着“2023Q3数据看板V2.1优化清单”,墨有点洇。


  第三条,筛选字段顺序很重要。不是谁在WHERE里写前面谁就优先。而是按选择性从高到低排——身份证号 > 用户等级 > 创建时间。可我们有张日志表,索引是(oper_type, user_id, create_time),oper_type只有5个值,selectivity烂得像隔夜泡面。我改完顺序那天晚上测,同样SQL,从9.3秒压到2.1秒。但我跟开发提这事时,老张正在吃外卖,汤洒了一点在桌上,他拿纸巾按住,没抬头:“哦,那下次建索引前先跑个DISTINCT count?”——这话他根本没打算执行,就是堵我嘴。


  第四条,千万别信“覆盖索引万能”。我们有个导出功能,SELECT FROM order_detail WHERE order_id = @id,于是有人把所有字段全INCLUDE进去。结果索引大小干到了47GB,比表本身还大。查一条记录要读138个页。后来砍掉三个LOB字段,索引缩到8GB,快了五倍不止。但没人记得是谁当初拍板要“全覆盖”的。反正PRD里没写索引设计,那就等于没责任。


  第五条……算了,第五条其实是个心态问题。别总想着一个索引解决所有WHERE变体。你列十个筛选条件组合,最多撑死建仨索引。剩下七个?要么前端加限制,要么告诉用户“不支持同时按门店+商品类目+售后状态+发票类型四维筛选”。取舍不是妥协,是让系统里的每个索引都活下来——而不是养一堆废索引,在统计信息更新时拖慢整个实例。这点老板不懂,他只懂“用户要什么我们就给什么”,上周还让我加个“按快递员微信昵称模糊搜订单”,我直接说“这个得先让快递员把昵称填进CRM”。他摆手说“先放灰度”,然后去看自己手机上新装的股票APP。


  李薇昨天问我:“有没有可能,慢不是索引的事,是磁盘IO?”我说有可能。但她没追问。我就没再说下去。其实那天看了I/O等待,PAGEIOLATCH_SH平均43ms,高于阈值,但临时文件组放在C盘——而C盘是系统盘,还装着防病毒软件。这事跟索引优化无关,但跟“谁动的部署脚本”有关。我记得是小陈写的自动化部署包,但他肯定不认。他现在改在抠空格键了。


  会议室椅子少一把,王工一直站着听,中间扶了三次桌沿。他最后说了一句:“其实上周用户反馈说搜索框点了没反应,我以为是前端JS卡了。”没人接话。那功能上线后没人用——是指“搜索订单详情”那个弹窗,点了就转圈,二十秒后自动关掉。我们埋点显示曝光率100%,点击率2.3%,但后续行为路径全断在loading层。产品说“可能是网络问题”,开发说“没报错啊”,运维说“数据库CPU不到30%”。其实就差一个索引。就一个。


  我本来想今晚把订单表的索引重建逻辑写成脚本丢GitLab,但想了想,先找老张要一下他们组下周排期表。他要是真把“索引治理”排进迭代,我就把手头那份没人看的文档重命名,改成《2024H1历史索引存档(作废)》。要是没排,我就继续抠白板笔,直到它出水为止。

(编辑:草根网)

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