服务器磁盘IO狂飙排查实录

一、问题突袭：客服告警+用户反馈，双重暴击

今天下午正琢磨着eBPF相关的小功能呢，腾讯云客服的电话突然打过来，语气还挺急：“你服务器CPU占用率飙得老高，是不是出问题了？” 我心里咯噔一下，赶紧登进常用的监控工具 Beszel ——结果一看CPU才20%出头，稳得很啊！正纳闷这“乌龙告警”呢，往下一滑监控面板，瞬间傻眼：磁盘IO的读速居然冲到了 36MB/s。

还没等我理清头绪，用户那边又发来截图吐槽：“你们系统某个功能点一直转圈，加载不出来！” 我放大截图仔细一看，角落里明晃晃显示着 “Deadlock” ——得，线索一下子串起来了：CPU告警是烟雾弹，磁盘IO高才是真凶，而且十有八九和MySQL脱不了干系！

二、顺藤摸瓜：揪出MySQL这个“资源小偷”

锁定元凶

iotop -oPa

既然怀疑是MySQL在搞事，我直接在服务器敲了iotop -oPa命令（懂行的都知道，这是排查进程IO占用的神器）。命令执行完，结果一目了然：MySQL进程直接霸占榜首，读速高达148MB/s，写速更是飙到324MB/s，短时间内累计读写量居然接近34.58GB——合着服务器的磁盘IO全被它占了，能不卡吗？

深挖病因

SHOW ENGINE INNODB STATUS

光知道是MySQL搞事还不够，得弄明白它为啥这么“费盘”。想起用户反馈的死锁问题，我立马登录MySQL，执行了show engine innodb status命令（排查InnoDB引擎问题的必备操作）。结果输出一堆密密麻麻的日志，看得我头大，直接复制粘贴丢给了豆包。不愧是我的技术小搭子，秒速分析出结果：原来是几个事务调度器“打架”，导致部分表的查询没命中索引，只能硬着头皮全表扫描，既引发了死锁，又把磁盘IO给拉爆了！

三、加个复合索引，瞬间“退烧”

搞清楚问题根源是索引缺失，解决起来就简单了！根据豆包指出的未命中索引的表，再结合用户截图里涉及的死锁相关表，我针对性地加了两个复合索引。

敲完命令刷新 Beszel 监控，效果立竿见影：磁盘IO直接从几十MB/s掉到了几MB/s，服务器瞬间恢复丝滑，用户那边也马上反馈“功能正常能用了”——没想到这么棘手的问题，加个索引就秒解决，简直不要太爽！