服务器磁盘IO高，本质是读写请求量超过了磁盘（或云盘）能扛住的处理能力，最常见的原因集中在业务写入突增、内存不足触发swap、慢查询与日志刷盘、以及云盘或RAID本身的性能上限这几处。先把这句话记住，后面的排查就不会乱。
服务器磁盘IO高是什么原因导致的？先分清这几种情况
磁盘IO不是孤立指标,它像一条传送带，应用把包裹放上去，文件系统打包，块设备搬运，最后落到物理盘或云盘，任何一段堵住，监控上看到的都是IO飙升，业内专家指出，排查时不要一上来就盯着磁盘硬件，先按“业务系统存储”三层往下拆。
业务层：写入量突然放大
这是最常见的场景,定时备份、批量导入、日志集中落盘、图片视频转码、爬虫回写，都会在某个时间点把写入量推高，特征是IO曲线和业务时间窗高度吻合，过了那个点就回落，你可以在服务器上执行：
sar -d 1 5
看哪块盘的tps和kB_wrtn/s在特定时段冲高，再对照crontab和业务日志，基本能锁定是谁在写。
系统层：内存不足与swap
内存不够时,Linux会把不常用的页换到swap分区，swap在磁盘上，换入换出就是实打实的随机IO，表现为free -m里swap使用量上涨，vmstat 1的si、so两列不为零，这类IO往往伴随系统卡顿，但业务日志里看不出明显异常，容易被忽略。
存储层：云盘性能上限与RAID配置
云服务器上,磁盘IO高有时不是“用得多”，而是“盘就到顶了”，普通云盘、SSD云盘、ESSD不同层级有各自的IOPS和吞吐上限，突发型实例还有积分机制，积分耗尽后IO性能会明显下滑，物理机上则要看RAID卡缓存策略和电池状态，写缓存失效时，写入性能会掉一个台阶。
应用层：慢查询与日志刷盘
数据库服务器上,一条没走索引的查询可能扫几百万行，产生大量随机读，日志框架如果配置成每条同步刷盘，高频写入也会把磁盘压满，行业共识认为，数据库类负载的IO问题，相当一部分源头在SQL和参数配置，而不是磁盘本身。
服务器磁盘IO占用100%怎么排查（可直接照做的命令）
别急着换盘,按下面四步走，多数问题能在半小时内定位。
第一步：用iostat和iotop定位是谁在读写
iostat -x 1 iotop -oPa
iostat -x重点看%util、await、aqu-sz三列。%util接近100%只说明磁盘忙，不代表一定有问题；await明显升高才说明请求在排队。iotop -oPa直接列出哪个进程在读写，按o只显示有IO的进程，按a看累计量。
第二步：区分读多还是写多
pidstat -d 1
输出里kB_rd/s和kB_wr/s分开列，读多，优先查缓存命中率和慢查询；写多，优先查日志、备份和批量任务，两者排查方向完全不同，别混着来。
| 现象 | 优先怀疑 | 常用命令 |
|---|---|---|
| 读IO高、await高 | 缓存不足、慢查询、随机读 | pidstat -d 1、数据库慢日志 |
| 写IO高、%util满 | 日志刷盘、备份、批量写入 | iotop -oPa、sar -d |
| 读写都高且swap上涨 | 内存不足 | vmstat 1、free -m |
| 周期性尖峰 | 定时任务 | crontab -l、业务日志 |
第三步：看队列深度和响应时间
aqu-sz是平均队列长度，如果它持续大于1，说明请求在排队，磁盘已经是瓶颈。await超过十几毫秒且持续，就要考虑是盘本身慢，还是上层压得太狠，云服务器可以对照云厂商文档里的云盘性能指标，看是否已经贴着上限跑。
第四步：对照业务时间窗做排除
把IO曲线和业务发布、备份、报表任务的时间轴叠在一起看，很多“莫名其妙”的IO高峰，其实是某个没写限速的备份脚本，或者一次全量数据同步，找到时间对应关系，比盲猜硬件故障有效得多。
云服务器磁盘IO性能瓶颈怎么判断
云上排查和物理机不太一样,盘是虚拟的，性能有明确档位。
云盘类型与IOPS上限
不同云盘类型对应不同的IOPS和吞吐基线,小容量盘往往IOPS也低，系统盘和数据盘混用更容易撞上限，判断方法很直接：看监控里的IOPS是否长期贴着该盘型的标称值，同时await同步升高，基本就是性能瓶颈，而不是故障。
突发性能与积分机制
部分实例规格采用突发性能模式,平时攒积分，忙时消耗，积分耗尽后IO能力会被限制，特征是前一段时间很快，后面突然变慢，监控上IO延迟抬升但吞吐反而下降，登录云控制台看积分余额，能快速确认。
共享存储的邻居干扰
少数共享型存储存在邻居干扰,表现为同一时段IO延迟波动，但自己业务量没变，这类问题不好自证，通常需要结合云厂商的监控和工单排查，日常能做的，是把关键业务放到独享型或更高档位的云盘上。
数据库服务器磁盘IO负载高如何优化
数据库是磁盘IO的重灾区,优化要按“查询日志数据布局”的顺序来。
索引与慢查询
先开慢查询日志,找出扫描行数大、执行频繁的语句，缺索引的补索引，索引失效的改写SQL，大范围排序和临时表尽量下推到应用层，多数情况下，几条核心慢查询处理完，磁盘读IO会明显下降。
日志与刷盘参数
事务日志、binlog、慢日志、错误日志都在写盘，刷盘策略在“安全”和“性能”之间取舍，调整前要确认业务对数据丢失的容忍度，日志文件也不要无限增长，按大小滚动并定期清理，避免单文件过大带来的额外IO。
分离冷热数据与读写
把历史数据归档到单独的表空间或低成本存储,热表保持小而精，读写分离能把报表类查询导到从库，减少主库磁盘压力，条件允许时，把redo日志、数据文件、临时目录放到不同的物理盘或云盘上，避免互相争抢。
服务器磁盘IO读写慢和内存不足有关系吗
有关系,而且比很多人想的更直接。
swap是IO放大的元凶
内存不足时,系统频繁换页，一次内存访问变成一次磁盘读写。vmstat 1里si、so持续非零，同时磁盘读IO升高，基本可以确认，解决办法不是换更快的盘，而是加内存或减少内存占用。
页缓存命中率
Linux会用空闲内存做文件缓存,缓存足够时，读请求大多在内存里完成；缓存被挤占后，读操作落到磁盘，IO自然上升。free -m里buff/cache长期偏低，而业务读量没变，就要考虑内存是否被其他进程吃掉了。
日常预防：把磁盘IO问题挡在发生之前
- 给备份、同步、批量任务加限速，别让它们和业务高峰抢盘。
- 监控里同时看
%util、await、aqu-sz，单看一个指标容易误判。 - 云服务器按业务量选云盘档位,别用小容量盘硬扛高IOPS需求。
- 数据库定期做慢查询治理,日志按大小滚动。
- 内存留出余量,swap使用量纳入告警。
- 新业务上线前用
fio做一次磁盘压测，心里有底。
fio --name=test --rw=randwrite --bs=4k --size=1G --numjobs=4 --runtime=60 --group_reporting
这条命令能大致看出随机写能力,和云盘标称值对照，偏差过大就要查原因。
磁盘IO问题说到底是一道“谁在读写、读写多少、盘能不能扛”的选择题，把这三问答清楚，大多数高IO都能落到具体原因上，而不是停留在“磁盘好像很忙”的模糊判断。
关于服务器磁盘IO的常见问题解答
服务器磁盘IO高一定是磁盘坏了吗？
不一定,磁盘故障通常会伴随dmesg里的I/O错误、smartctl -a里的重映射扇区增长、以及读写超时，没有这些迹象、只是%util高，优先查业务量、内存和配置，真正硬件故障在磁盘IO问题里占比较小。
云服务器磁盘IO跑满，升级配置就能解决吗？
要看瓶颈在哪,如果是云盘IOPS上限，升级云盘档位或扩容容量通常有效；如果是内存不足导致swap，升CPU和内存更对路；如果是慢查询，升级硬件只是把问题往后拖，先定位再花钱，顺序别反。
磁盘IO长期偏高会有什么后果？
最直接的是请求延迟上升,业务响应变慢；数据库场景下可能引发连接堆积和超时，长期高负载还会加速磁盘磨损，云盘则可能持续消耗突发积分，把IO当作容量指标定期看，比等业务报警再处理更划算。