你是否遇到过这样的场景？数据库跑得慢，以为加内存就能解决，结果发现CPU飙升，磁盘却闲得发慌。其实，很多性能问题就出在Linux的“缓存I/O”上。今天咱们聊聊一个绕开缓存的狠角色——直接I/O。

先说说缓存I/O怎么工作的。你写数据到文件，数据先到内核的页缓存，再慢慢刷到磁盘。读数据也是，先看缓存有没有，没有才去磁盘。这设计挺好，能减少磁盘访问，加速读写。但问题来了，如果你的应用程序自己有缓存，比如数据库的Buffer Pool，那内核的页缓存就成了“多余”的中间人。数据在用户态和内核态之间拷贝两次，占用CPU和内存带宽，还可能导致数据丢失（延迟写入）。这时候，直接I/O上场了。

直接I/O就是通过`O_DIRECT`标志，让数据不走内核缓存，直接从用户空间传到磁盘。你写数据，内核只负责拷贝到磁盘，不缓存；读数据，直接从磁盘拉到用户空间。数据流路径变成了：用户空间

那直接I/O到底怎么和Linux I/O栈配合的？VFS识别`O_DIRECT`后，文件系统会走专门的路径，不分配页缓存，直接构造底层的`struct bio`。通用块层依然会合并、排序I/O请求，所以I/O调度器仍然工作，只是缓存层没了。另外，发起直接I/O的进程会进入不可中断睡眠状态（D态），等待磁盘完成。如果磁盘性能差或故障，D态进程会堆积，系统负载飙升。这一点在排查数据库性能问题时特别有用——看到大量D态，基本可以怀疑是存储瓶颈。

性能上，直接I/O不是银弹。数据库爱用它，因为能避免二次拷贝，精确控制自己的缓存策略。高并发随机I/O场景下，数据库的Buffer Pool比内核的LRU算法更懂业务。但大多数应用不该用，比如Web服务器、日志系统。内核会为缓存I/O做顺序预读、合并小I/O，这些优化直接I/O全没了。多个进程访问同一文件时，也无法共享内核缓存，每个进程都得读磁盘，压力巨大。说白了，对普通应用，信任内核的缓存策略更靠谱。

怎么评估直接I/O的性能？用`iostat -dxm 1`看设备级指标，重点看`await`（响应时间）和`svctm`（服务时间）。如果`await`远高于`svctm`，说明I/O队列有堆积。再用`pidstat -d 1`找出哪个进程在狂读写。还有`iotop`，按I/O大小排序，高I/O进程一目了然。`vmstat`里的`b`列（等待I/O的进程数）和`wa`列（等待I/O的CPU占比）也是关键。

有个特殊案例：ZFS文件系统。ZFS有写时复制（COW）和ARC缓存，直接I/O会绕过ARC，但写操作仍然要走COW路径。这意味着直接I/O在ZFS上可能和设计初衷冲突，需要谨慎评估。数据库场景下，可能得权衡ZFS的COW优势与直接I/O的缓存控制优势。

说到底，选择直接I/O，就是在“内核的通用优化”和“应用的自主控制”之间做选择。对于大多数应用，信任内核更省心；对于数据库这样的专业软件，直接I/O是性能优化的关键一环。随着NVMe、Optane等新存储设备普及，直接I/O的延迟优势会越来越明显。你平时用数据库时，会考虑开启直接I/O吗？评论区聊聊你的经验。