什么更好/更快？MySQL或文件系统？

假设一个网站是一个人的目录。对于每个人，可能会有个人资料照片和传记。

我承认我的SQL查询可能会更好，但总的来说会更快并且使用更少的处理能力。

要检查文件是否存在，然后将其打开或

检查MySql以查看生物是否存在并显示它。

我很确定在上述情况下，文件系统会占用mysql数据库。

如果我使数据库成为只读的分隔txt文件怎么办？

在这种情况下，什么更快？

如果txt文件中有太多记录，是否有某个特定点，最好使用MySql？

如果您要查找特定文件，则文件系统很有用，因为操作系统会维护某种索引。但是，txt文件的内容不会被索引，这是数据库的主要优点之一。另一个是理解关系模型，因此不需要一遍又一遍地重复数据。另一个是理解类型。如果您有txt文件，则需要解析数字，日期等。

因此-在某些情况下，文件系统可能会为您工作，但肯定不是全部。

这实际上取决于您在做什么。通常，打开文件进行读取的速度将比建立网络连接的速度要好。因此，对于非常简单的操作，文件系统肯定更快。由于开销较小，因此文件系统的原始读取吞吐量也可能会超过RDBMS。实际上，如果您考虑一下，就原始吞吐量而言，数据库永远不会比其上的文件系统快。

对于非常复杂的操作，文件系统可能会非常慢。例如：

从这个10亿行文件中读取10行，然后在另一个文件中搜索匹配的行。如果您必须这样做，我很遗憾。好的数据库服务器具有快速而又有效地执行此操作的策略，因此您无需费力就可以了。

另外，您确实需要弄清楚自己在做什么。您要存储什么数据？您将如何改变它？如果它是10万个图像文件，则解决方案看上去将与10万个目录不同。（也许是LDAP？还是SQL数据库？取决于您的工作。）这里的关键是选择与您的工作相匹配的工具，这些工具将为您提供更多使用的空间，而不是看起来有些最快的工具。相当抽象的用例。数据库是很棒的工具，但是您不能很好地回答这样的问题。

最后，过早的优化是万恶之源。现在选择有用的工具，然后再找出其余的工具。

文件系统最初可能会更快，但是我对此表示怀疑。但是，随着数据大小的增加，您可能必须重组文件系统以保持性能。除了具有明显的索引多个属性的能力外，数据库还具有更好的扩展性。

与您所考虑的类似的Web缓存使用目录树来保持性能。它们的规模也往往相对固定，因此不必应对规模不断扩大的情况。

对于这种应用程序，我将从数据库开始，因为它更适合您的需求。从长远来看，它将更好地扩展。与大多数文件系统相比，数据库还将更加节省空间。

我一直很喜欢参加这些论坛并阅读所有繁琐的数据库专家报告，指出文件系统无法像数据库一样快地完成它。相反，经过适当布局的树，设计良好的哈希表并将其保存为对象到文件中，将产生与数据库相同的速度，并且来自我的测试。正确设计的哈希表和目录树每次都会取胜。方式开销更少。最近，为了简化程序和移植性，我不再使用数据库驱动的编程，而是转向文件树。没有数据库意味着轻松备份，只需将您的树拉上拉链即可。对于曾经使用小型应用程序的客户，以这种方式进行编程是非常好的建议。看大图，我有时间设计自己的照片还是只是利用数据库等已有的东西。我个人喜欢将对象保存到文件中，以后再使用它们，只需注意表的大小，然后考虑使用RandomAccessFile，以便能够像数据库一样快速查找并分解成哈希表对象。请享用。记住，存储在文件中的数据有时会消耗两倍的内存使用量，具体取决于您的代码。哈希表本身，通常是您在其中使用它进行查看的地方。