我对缓存策略和实现都很陌生。我正在开发一个数据库密集型项目，但也会定期更新和更改信息。
我已经找到足够的信息来了解如何开发缓存功能，但我不确定的是一般策略。
如果我缓存所有查询结果并按逻辑事项对它们进行分组，我可以在有意义的触发器上清除它，我的缓存中可能会有数万个（至少）微小的文件。仅缓存大型查询结果会更有意义吗？
我知道这是一个特定于硬件的问题，但一般来说，缓存变得毫无意义的文件量是多少？这意味着，如果您正在使用所有这些微小的文件加载文件系统，那么对它们的访问最终会变得足够慢，以至于您可能还没有缓存信息开始吗？
谢谢大家，我对您提供的任何意见感兴趣
编辑：根据有关这一点的答复绝对是特定于应用程序的，让我以这种方式提出问题应该是普遍的：
假设我的应用程序依赖于一个包含1,000,000个项目的表...
是否可以更快地执行查询以直接从数据库中检索其中一个项目，或者从我的缓存目录中检索其中一个项目，其中包含1,000,000个文件，每个文件都包含其中一个项目的详细信息？
编辑：显然100,000不足以得到有效的答案，让它成为1,000,000。有人想要1000,000,000？因为我能做到......
答案 0 :(得分：10)
使用MySQL的内置查询缓存，而不是尝试自己维护它。它会在写入时自动清除对表的缓存查询。此外，它在内存中工作，因此它应该非常有效......
此外，不要只缓存查询。尝试在渲染周期的不同阶段缓存应用程序的整个段。因此，您可以让MySQL缓存查询，然后缓存每个单独的视图（呈现），每个单独的块和每个页面。然后，您可以根据请求选择是否从缓存中提取。
例如，未登录的用户可以直接从缓存中获取整个页面。但是登录用户可能无法（由于用户名等）。因此对于他来说，您可以从缓存中在页面上呈现1/2的视图（因为它们不依赖于用户对象）。你仍然可以获得缓存的好处，但它会根据需要进行分层。
如果您真的希望获得大量流量，那么绝对值得研究Memcached。让MySQL为您存储查询，然后将所有用户域缓存项存储在memcache中......
修改：要回答您的修改：
如果单个目录变大，文件系统可能会变慢。只要您按目录“命名”（因此每个目录只有一小部分缓存文件），从这个角度来看应该没问题。至于确切的阈值，它实际上将取决于您的硬件和文件系统。我知道如果单个目录中有大量文件，EXT3会变得非常慢（我的目录中包含数十万个文件，而且只需要半秒钟就可以只需{1}}其中一个文件，更别说做任何类型的目录了...）
但是要意识到如果你添加另一台服务器，你将要么拥有重复的缓存（这不是一件好事），要么必须重写整个缓存层。是否有理由不从一开始就使用stat()？
编辑2 ：要回答您的最新修改：
打电话仍然太难了。我有一个应用程序，其数据库大约有15亿行（每天增长约50万）。我们根本不使用任何缓存，因为我们没有并发问题。即使我们这样做了，我们最好不要再添加MySQL服务器而不是添加缓存，因为任何形式的缓存都会有如此低的命中率，以至于不值得花时间来添加它。
这就是我如此坚持不加速度缓存的原因。总会有一个不在缓存中的对象。因此，如果您使用其中一个对象访问某个页面，它仍然需要很快。根据经验，我尝试在接下来的几分钟内缓存任何可以再次访问的内容（无论如何，我在其他应用程序上保留了约5分钟的生存时间）。因此，如果物品在该时间跨度内没有超过几次点击，或者命中率非常低（低于90％），我不打算缓存该项目......
答案 1 :(得分：2)
一般规则是：在没有必要时不进行缓存，只缓存需要缓存的内容。
答案 2 :(得分：0)
这取决于硬件和应用程序。您需要执行基准测试以确定操作系统索引大于数据存储/检索持续时间的阈值（在MySQL级别和缓存文件访问级别）。而且您还需要将其与受众的可接受（非常主观）阈值进行比较。