文件访问速度与数据库访问速度

Question

我在php中开发的网站每页查看了许多MySQL数据库请求。虽然许多是具有适当设计索引的小请求。我不知道为这些页面开发缓存脚本是否值得。

1. 文件I / O通常比数据库请求快吗？这取决于服务器吗？有没有办法测试服务器可以处理的数量？

2. 其中一个页面检查数据库是否有文件名，然后检查服务器是否存在，然后决定要显示的内容。我认为这将受益于缓存的页面视图？

此外，如果有关于此主题的任何其他信息，您可以转发给我，我们将不胜感激。

Answer 1

如果您正在进行大量读取访问（查找文件名等），您可能会从memcached中受益。您可以将“最热门”（最近创建的，最近使用的，取决于您的应用程序）数据存储在内存中，然后只在缓存未命中时查询数据库（以及可能的文件）。内存访问远远快于数据库或文件。

如果您需要大量访问权限，那么数据库就是您的选择。如果您使用的是MySQL，请使用InnoDB表或其他支持行级锁定的引擎。这将避免人们在其他人写作时阻塞（或者更糟糕的是，无论如何写作）。

但最终，这取决于数据。

Answer 2

这取决于数据的结构，数量以及更改的频率。

如果你的数量相对较少，相对静态的数据与相对简单的关系 - 那么平面文件就是这项工作的正确工具。

当数据之间的连接更复杂时，关系数据库就会出现。对于基本的“查找表”，它们可能有点矫枉过正。

但是，如果数据不断变化，那么只使用数据库而不是手工处理配置管理会更容易 - 对于大量数据，使用平面文件你会遇到额外的问题你有效地找到了你需要的那一点。

Answer 3

这实际上取决于很多因素。如果你有一个快速的数据库，在RAM或快速RAID系统中缓存了大量数据，那么很可能会从Web服务器上的简单文件系统缓存中获得很多收益。还要考虑可扩展性。在高工作负载下，简单的缓存机制可能很容易成为瓶颈，而数据库设计得很好，可以处理高工作负载 如果没有那么多请求而您（或操作系统）能够将缓存保留在RAM中，您可能会获得一些性能。但现在问题出现了，如果真的需要在低工作负载下执行缓存。

Answer 4

从简单的性能角度来看，调整数据库服务器更明智，而不是使用中间文件缓存使数据访问逻辑复杂化。如果结果是可缓存的，那么一个好的数据库服务器将自己进行缓存。 （我不确定mysql是什么情况）。

如果您遇到性能问题，则应对页面进行分析以查看真正的瓶颈。即使你像我一样 - 优化代码的粉丝，从长远来看，将更强大/更多硬件放入等式中会更便宜。

如果您仍然需要使用缓存，请考虑使用现有的解决方案，例如memcached。