php 文件访问速度 vs 数据库访问速度
声明：本页面是StackOverFlow热门问题的中英对照翻译，遵循CC BY-SA 4.0协议，如果您需要使用它，必须同样遵循CC BY-SA许可，注明原文地址和作者信息，同时你必须将它归于原作者（不是我）：StackOverFlow
原文地址: http://stackoverflow.com/questions/849061/
Warning: these are provided under cc-by-sa 4.0 license. You are free to use/share it, But you must attribute it to the original authors (not me):
StackOverFlow
File access speed vs database access speed
提问by user103219
The site I am developing in php makes many MySQL database requests per page viewed. Albeit many are small requests with properly designed index's. I do not know if it will be worth while to develop a cache script for these pages.
我正在用 php 开发的站点在查看的每个页面上都会发出许多 MySQL 数据库请求。尽管很多都是带有适当设计索引的小请求。我不知道为这些页面开发缓存脚本是否值得。
Are file I/O generally faster than database requests? Does this depend on the server? Is there a way to test how many of each your server can handle?
One of the pages checks the database for a filename, then checks the server to see if it exists, then decides what to display. This I would assume would benefit from a cached page view?
文件 I/O 通常比数据库请求快吗？这取决于服务器吗？有没有办法测试每个服务器可以处理多少个？
其中一个页面检查数据库中的文件名，然后检查服务器以查看它是否存在，然后决定显示什么。我认为这会从缓存的页面视图中受益？
Also if there is any other information on this topic that you could forward me to that would be greatly appreciated.
此外，如果您可以将有关此主题的任何其他信息转发给我，将不胜感激。
采纳答案by James Socol
If you're doing read-heavy access (looking up filenames, etc) you might benefit from memcached. You could store the "hottest" (most recently created, recently used, depending on your app) data in memory, then only query the DB (and possibly files) when the cache misses. Memory access is far, far faster than database or files.
如果您正在进行大量读取访问（查找文件名等），您可能会受益于memcached。您可以将“最热”（最近创建、最近使用，取决于您的应用程序）数据存储在内存中，然后仅在缓存未命中时查询数据库（可能还有文件）。内存访问远远快于数据库或文件。
If you need write-heavy access, a database is the way to go. If you're using MySQL, use InnoDB tables, or another engine that supports row-level locking. That will avoid people blocking while someone else writes (or worse, writing anyway).
如果您需要大量写入访问，那么数据库是您的最佳选择。如果您使用 MySQL，请使用 InnoDB 表或其他支持行级锁定的引擎。这将避免人们在其他人写作时阻塞（或者更糟的是，无论如何写作）。
But ultimately, it depends on the data.
但归根结底，这取决于数据。
回答by Stringent Software
It depends on how the data is structured, how much there is and how often it changes.
这取决于数据的结构方式、数据量和更改频率。
If you've got relatively small amounts, of relatively static data with relatively simple relationships - then flat files are the right tool for the job.
如果您的数据量相对较少、关系相对简单的相对静态数据，那么平面文件就是适合这项工作的工具。
Relational databases come into their own when the connections between the data are more complex. For basic 'look up tables' they can be a bit overkill.
当数据之间的连接更加复杂时，关系数据库就派上用场了。对于基本的“查找表”，它们可能有点矫枉过正。
But, if the data is constantly changing, then it can be easier to just use a database rather than handle the configuration management by hand - and for large amounts of data, with flat files you've got the additional problem of how do you find the one bit that you need, efficiently.
但是，如果数据不断变化，那么仅使用数据库而不是手动处理配置管理会更容易 - 对于大量数据，使用平面文件您会遇到额外的问题，即如何找到您需要的一点，高效。
回答by Daniel Brückner
This really depends on many factors. If you have a fast database with much data cached in the RAM or a fast RAID system, chances are bad, that you will gain much from simple file system caching on the web server. Also think about scalibility. Under high workload a simple caching mechanism might easily become a bottle neck while a database is well designed to handle high work loads.
If there are not so much requests and you (or the operating system) is able to keep the cache in RAM, you might be able to gain some performance. But now the question arises, if it is realy neccessary to perform caching under low work load.
这实际上取决于许多因素。如果您有一个快速的数据库，在 RAM 中缓存了大量数据或一个快速的 RAID 系统，那么机会很糟糕，您将从 Web 服务器上的简单文件系统缓存中获益良多。还要考虑可扩展性。在高工作负载下，一个简单的缓存机制可能很容易成为瓶颈，而数据库经过精心设计以处理高工作负载。
如果没有那么多请求，并且您（或操作系统）能够将缓存保留在 RAM 中，那么您可能会获得一些性能。但是现在问题来了，是否真的有必要在低工作负载下执行缓存。
回答by Csaba Kétszeri
From plain performance perspective, it is wiser to tune the database server and not complicate the data access logic with intermediate file caches. A good database server would do the caching on its own if the results are cacheable. (I'm not sure what is teh case with mysql).
从简单的性能角度来看，调整数据库服务器而不是使用中间文件缓存使数据访问逻辑复杂化是更明智的做法。如果结果是可缓存的，一个好的数据库服务器会自行缓存。（我不确定 mysql 的情况是什么）。
If you have performance problems, you should profile the pages to see the real bottlenecks. Even when you are -like me- a fan of the optimized codes, putting a stronger/more hardware into the equation is cheaper on the long run.
如果您有性能问题，您应该分析页面以查看真正的瓶颈。即使你 - 像我一样 - 优化代码的粉丝，从长远来看，将更强大/更多的硬件放入方程式中会更便宜。
If you still need to use caches, consider using an existing solution, like memcached.
如果您仍然需要使用缓存，请考虑使用现有的解决方案，例如 memcached。
