TG咨询数据库查询突然变慢，原因可能在SQL、索引、缓存、并发事务，也可能来自云磁盘或宿主机存储。数据库IO性能瓶颈排查的关键，不是看到磁盘忙就立即扩容，而是先确认读写类型、影响范围和发生时间，再用同一口径验证改动是否有效。
一、先确认问题是否真的属于IO
先记录异常开始时间、受影响的接口、数据库实例和操作类型。将应用日志中的请求耗时，与数据库端的执行耗时、锁等待和连接排队时间分开。若数据库执行仅几十毫秒，而接口耗时数秒，重点可能是连接池、网络或应用线程；若执行时间和物理读持续升高，才进入数据库IO性能瓶颈排查主流程。
二、划定读写范围和影响对象
按读、写、日志刷盘、临时文件四类观察。只读查询变慢，常见方向是缓存未命中、扫描行数过多或存储读取延迟；写入变慢，则要关注WAL、检查点、事务提交和磁盘写入队列。不要把所有慢请求混在一起，应区分单个SQL、某类业务、整台实例以及特定时间段。
三、采集数据库和主机指标
在Linux上可用iostat -x观察设备利用率、平均等待时间和队列长度，用vmstat检查内存回收与阻塞情况。PostgreSQL可查看pg_stat_database中的读写统计、临时文件和事务提交情况；使用PostgreSQL 16及以上版本时，还可结合pg_stat_io细分后台进程与客户端的IO活动。采样应覆盖正常时段和异常时段，单次快照很难说明因果。
四、从慢查询中找出主要贡献者
开启并合理使用慢查询记录，按总耗时、调用次数、平均耗时和共享缓冲区命中情况排序。一个单次很慢的SQL，未必比每秒执行数百次的短SQL更值得优先处理。数据库IO性能瓶颈排查应先锁定消耗资源最多的一组语句，并保存其参数、执行计划和发生时间。
五、核对执行计划与访问路径
对目标SQL使用EXPLAIN或EXPLAIN (ANALYZE, BUFFERS)，比较估算行数与实际行数。若估算严重偏小，可能是统计信息过旧；若出现大范围顺序扫描、重复排序、临时文件或回表过多，应检查过滤条件、连接条件和索引覆盖范围。索引并非越多越好：它能减少读取，却会增加写入维护、存储空间和缓存压力。
六、排除锁、并发和后台任务干扰
IO等待有时是表象。使用pg_stat_activity查看活跃会话、等待事件和事务持续时间，再核对是否存在长事务、批量删除、逻辑备份、归档或索引维护。高并发会让多个任务争用相同存储带宽；此时降低并行度、调整任务时间或拆分事务，通常比盲目增加连接数更稳妥。
七、检查存储层和文件系统
确认数据库文件、WAL、临时文件是否位于同一存储设备，并检查剩余空间、文件系统挂载参数和云盘吞吐限制。磁盘延迟突然升高而数据库请求量没有明显变化，可能是同一主机上的其他进程争用资源。对生产盘不要直接运行高负载压测，可先查监控和云平台指标；必要时在隔离环境用接近业务负载的测试验证。
八、用对照实验验证修复结果
一次只改一个主要变量，例如调整一条SQL、补充一个针对性索引，或降低某个任务的并发。记录变更前后的查询耗时、物理读取、缓存命中率、磁盘延迟、锁等待和业务成功率，并在相似流量、相似数据范围下比较。数据库IO性能瓶颈排查的结论必须能够复现，否则不要急于推广到全部实例。
常见问题
磁盘利用率不高，是否可以排除IO问题？
不能。小块随机读、共享存储限流或单个进程等待，都可能在总体利用率不高时造成明显延迟，应同时看请求延迟和等待事件。
增加索引一定能解决查询变慢吗？
不一定。低选择性条件、频繁写入表或统计信息失真时，新增索引收益有限，还可能增加写放大和维护成本。
缓存命中率高，为什么仍然慢？
缓存命中率只反映部分访问路径，锁等待、排序产生的临时文件、日志刷盘和CPU排队仍可能拖慢请求。
什么时候考虑更换存储或扩容？
当SQL和并发已合理，且在稳定业务负载下长期出现高磁盘延迟、队列积压或吞吐达到存储上限，才适合评估升级存储、拆分读写或扩容。
按上述八步保留证据、控制变量并复测，才能把数据库IO性能瓶颈排查从“感觉磁盘很忙”变成可验证、可回滚的技术判断。
