14年血泪史：索引碎片率超30%，搜索直接跪了

发布时间：2026-10-09 23:33:12 所属栏目：搜索优化来源：DaWei

导读：凌晨两点十七分 DBA 小张脚踩人字拖扑到机柜旁的KVM前，手指在回车上连点七次没等页面刷出来就骂娘。前天夜里十点半电商订单模块的两百三十七笔退款请求全卡成了半僵尸状态，业务侧的小姑娘攥着鼠标刷新十八次，后台返回全

凌晨两点十七分 DBA 小张脚踩人字拖扑到机柜旁的KVM前，手指在回车上连点七次没等页面刷出来就骂娘。
前天夜里十点半电商订单模块的两百三十七笔退款请求全卡成了半僵尸状态，业务侧的小姑娘攥着鼠标刷新十八次，后台返回全是504，运营总监拍着桌子在钉钉群@所有人，说半小时内没捋顺全组扣当月绩效。
我上周三晚九点零七分用innotop连进生产库，看着InnoDB行锁等待数跳到一千二百九十一，随手执行show index from ding_dan_biao查碎片率，扫出来结果是百分之三十一点七，根本不是之前运维脚本报的百分之三。
两千零一十六年我在游戏项目里碰过一模一样的场景，当时带五个人的小团队做页游充值后台，碎片率飙到百分之二十七的时候直接停服两个小时跑alter table optimize，全服玩家发三百钻石安抚，现在谁敢随便动核心库的大表，线上一秒钟的停机损失都抵得上当年全服半年的流水。
运营部小李攥着发烫的办公本跑过来，指尖还沾着刚泡的速溶咖啡渍，扯着我袖子说刚才用户投诉已经堆了三百多条，支付回调的mq队列堵了快两万条再拖下去资损要破六位数。
我上周二中午十二点一十四分用percona-toolkit的pt-online-schema-change挂着参数跑碎片整理，开着三十的chunk size限速一百兆每秒，跑了两小时一十七分没锁一秒钟表，最后碎片率落到百分之二点一的时候，之前卡了快二十秒的订单查询接口直接压到十八毫秒返回。
居然有人之前信了网上说的InnoDB不用管碎片的鬼话，上线快三年没做过一次碎片整理，连ding_dan_biao里存了快一千两百万条软删除的无效订单行都没发现，每次查询都要扫三倍的物理页，不卡才见鬼。
上周一下午三点零二分开发组刚上线的统计脚本扫全表count()，没加任何where条件，直接把IOutil干到百分之百，连带着核心交易的读请求全被挤到了队列外，当时监控屏上的磁盘util曲线拉成了一条平直线，我隔着三米远都能听到服务器硬盘转得发出的滋滋响。
简直是拿核心业务当小白鼠瞎折腾，之前写运维巡检脚本的小孩图省事，拿information_schema里的TABLE_ROWS差除以总行数算碎片率，算出来的数偏差能到十倍，报警阈值设成百分之五十都没触发过，等于碎片监控完全是个摆设。
上周四晚八点五十一分我拉着小张蹲在机房走廊啃泡面，翻了近三个月的慢查询日志，发现超过两秒的慢查询里百分之八十七都集中在ding_dan_biao的order_time索引上，碎片把原本有序的索引页撕得七零八落，一次原本只需要三次IO的查询，硬生生要跳十七八次磁道才能读完。
有人说加内存就能盖住碎片问题，纯扯。

文章配图，仅供参考

内存加到两百五十六G也装不下一千两百万条碎片碎成渣的索引页，LRU刷页的频率飙升三倍，本来能全放内存的热索引页，每次查都要从磁盘扒半天才出来，加再多内存都是纯纯浪费。
堪称我从业十四年见过最离谱的索引运维乌龙，全组人盯着假的碎片监控报平安，直到业务直接跪到眼前才反应过来之前的运维报表全是错的。
上周五早七点零九分我把软删除的近九十万条历史订单行分批迁到归档库的history_orders表，开着每批一千行的小事务跑，跑了快四个小时没影响任何在线交易，迁完之后主库的磁盘占用直接少了一百二十七G，连备份的时间都缩短了近二十分钟。
绝对不能等碎片率摸到百分之三十的红线才救火，每个月拿正确的脚本跑一次碎片巡检，阈值设到百分之十五就提前安排低峰期整理，半点儿侥幸的空间都不能留。
小张后来补监控的时候，把碎片率的计算逻辑直接改成拿information_schema.TABLES里的DATA_FREE除以DATA_LENGTH，连告警的回调脚本都绑到了企业微信的机器人上，昨天试测的时候碎片率刚到百分之十六就直接弹了三级告警到所有人的手机上。
没人敢再碰之前那个糊弄人的巡检脚本。

（编辑：站长网）

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

13年模块开发血泪：B+树	内行透底：90%站长错失
速查漏洞+精准修复：索