扩展这个线程- 我只想知道为什么从文件系统而不是 MySQL 数据库中检索文件更快。如果要对这两者进行基准测试，看看哪一个会在 10 分钟内检索到最多的数据（多种类型的数据）——哪一个会赢？
如果文件系统真的更快，那么为什么不将所有内容存储在文件系统中并用 csv 或 xml 替换数据库呢？
编辑1：
我为 java 的备用存储选项找到了一个很好的资源
编辑2：
我正在寻找具有 SQL 数据库服务器引擎（或至少其中一些）功能的 Java API/Jar，它使用 XML 进行数据存储（最好）。如果您知道什么，请在下面发表评论。
归根结底，数据库只是将数据存储在文件系统中。除了原始数据之外，所有有用的东西都让您决定使用数据库。
如果您可以使用 CSV 复制数据库系统的功能、可伸缩性、稳健性、完整性等，并且仍然使其比关系数据库执行得更快，那么是的，我建议您按照自己的方式进行操作。
不过，你需要几年的时间才能到达那里。
当然，关系系统并不是存储数据的唯一方式。有面向对象的数据库系统（db4o、InterSystems Cache）和基于文档的系统（RavenDB）。
性能也与您正在使用的数据的样式和数量以及您打算如何处理它有关——我什至不打算讨论这个问题，它太开放了。
我也不会开始下面的讨论：如果内存真的比文件系统快，为什么不把所有东西都存储在内存中呢？:-)
这似乎也类似于我很久以前回答的另一个问题：
基本上，事情并不总是仅仅为了性能而做的。
MySQL 使用文件系统与计算机上的其他所有内容相同。要检索单个数据或数据表，没有比直接从文件系统更快的方法了。MySQL 只是添加到该文件系统拉取的一小部分开销。
如果您需要进行一些智能选择、匹配某些行或过滤该数据，MySQL 将比大多数其他选项更快地做到这一点。数据库服务器为您提供文件系统无法提供的计算和数据操作能力。
当您拥有混合/结构化数据时，DBMS 是唯一的解决方案。例如。尝试将所有客户的姓名、姓氏和国家/地区存储到您的数据库中，但仅限于 1981 年出生并居住在罗马的客户。如果您将这些数据保存到文件系统上的文件中，如何在不扫描所有文件的情况下轻松获取所需数据，以及如何加入返回的数据？
DBMS 给您的远不止这些。许多 DBMS 将数据存储到文件中。
这个抽象层将使您以一种非常容易、标准和结构化的方式检索数据。
不同之处在于所需数据的位置。
在文件系统中，定位所需数据意味着搜索所有现有数据，直到找到为止。
数据库提供索引，无论数据量如何，几乎可以立即（在约 12 次比较内）找到所需的数据。
我们想要的是一个索引文件系统——幸运的是，我们拥有它们。它们被称为数据库。