缓存MySQL结果时的收益和性能下降

Question

我已经看到一些框架使用文件系统中的常用文件缓存数据库的结果（不考虑此情况下的内存缓存数据），并且一旦对数据库进行更改或特定TTL结束就会使这些文件无效。由于数据库也是一个文件，除了在一个用例中，来自不同来源的大量并发SELECT查询将负载分配到不同的文件之外，它对我来说似乎是多余的。

除了一个体面的设计和抽象之外，是否有任何理由将这种缓存技术用于小型私有项目，而且流量和并发性几乎可以忽略不计？

Answer 1

缓存有两个方面：

• 大数据集，复杂查询（联接，联合，子查询等）
• 数据库服务器查询解析

在处理缓存时要问自己的问题：

• 我的数据经常更改吗？
• 如果我使用它，我会提高速度吗？

如果您的数据经常更改或性能提升可以忽略不计，我建议您不要使用缓存。维护并确保它没有被破坏等是另一回事。如果性能明显更好，那就去吧。

基于文件的缓存通常很慢，仅用于大数据集

Answer 2

经验法则：不要将缓存放在缓存之前。 MySQL已经做了一些无法避免做I / O的工作;您描述的缓存似乎会添加到I / O负载。

此外，如果缓存机制增加了RAM消耗，那么它会从RAM中消失，否则可能会用来加速MySQL。例如，不要将memcached与MySQL放在同一台服务器上。 Memcached需要大量的RAM。

KISS - 你不是一个小项目吗？为什么要用不太可能带来很多好处的东西来复杂化呢。

如果你的申请很慢，那可能是因为

1. 缺少'复合'索引;
2. 配方不合理SELECT;
3. 十几个不太常见，但很容易修复的原因。

但很少因为没有使用额外的缓存。