我的问题是关于通过偏移量从专用文件访问数据，而不需要任何数据库或序列化框架。虽然教科书上说建议按块访问数据，例如一次检索/刷新 4KiB，但我有时会怀疑性能方面的必要性。
我看到许多数据库项目使用块感知设计来管理数据，例如批量从磁盘读取/写入数据，而不是实际请求的字节。
如今内存/磁盘和系统缓冲区由操作系统/硬件控制，尽管
FileDescriptor.sync()因此，即使程序按块访问数据，这增加了复杂性，但操作系统机制可能会消除这种工作量。相反，如果程序仅使用其偏移量访问数据，而不考虑块，则底层操作系统可能会像往常一样帮助安排块检索。更不用说某些编程语言采用复杂的内存模型，可能会影响磁盘访问，例如 Java。
我知道这对于 ACID 的块/缓冲区管理很有帮助，但我想知道这种设计是否也是为了提高效率？
我搜索了该网站，但没有找到任何线索。请注意一些关键词，我很抱歉我的无知。
值得在现代操作系统/硬件上按块访问数据吗？
也许吧。正如您所观察到的，通常在硬件级别、操作系统内核以及用户空间中的应用程序下方存在缓冲，所有这些都是为了提高 I/O 性能。特定应用程序是否可以从以块感知方式执行应用程序级 I/O 操作中受益取决于应用程序的数据访问模式。
应用程序级块感知的目的通常是减少必须在较低级别（尤其是硬件级别）执行的（面向块的）I/O 操作的数量。例如，如果我不小心设计数据库，我最终可能会得到主要结构，这些结构经常跨越比它们需要的更多的硬件块。尽管有所有缓冲，但检索较少的块比检索更多的块更快。以整个磁盘块为单位写入应用层数据也可以更快，因为这样系统可以忽略目标块的初始内容。否则，它必须首先读取其中一些块的内容，更新必须覆盖的部分，然后才写入块。
不知道这样的设计是否也是为了效率？
你是对的，设计和实现硬件块大小的应用程序级调节需要更多工作，也更复杂。除了 I/O 效率原因之外，不会进行此类设计。它们在这方面是否成功是一个不同的问题，但对于旨在提供高 I/O 吞吐量的应用程序来说，此类设计仍然相对常见，这应该会让您认为是的，此类设计在这方面是有效的。