查询集是惰性的，这意味着它们在被评估之前不会调用数据库。对他们进行评估的一种方法是序列化它们，这是cache.set在幕后进行的。因此，这不是浪费时间：如果您想要的话，Tournament模型的全部内容将被缓存。可能不是：并且如果您进一步过滤查询集，Django将只返回数据库，这会使整个过程变得毫无意义。您应该只缓存实际需要的模型实例。
请注意，初始设置中的第三点不太正确，因为这与Apache或预分叉无关。一个视图就是一个函数，就像其他函数一样，当函数返回时，在函数内部的局部变量中定义的任何内容都超出范围。因此，当视图返回响应时，在视图内部定义和评估的查询集将超出范围，并且在下次调用该视图时（即在下一个请求时）将创建一个新的查询集。无论您采用哪种方式服务Django，都是如此。
，这很重要，如果您执行类似的操作，例如将queryset设置为全局（模块级）变量，它将 在请求之间保持 不变。Django的大多数服务方式（当然包括mod_wsgi）都可以在回收之前使许多请求保持活动状态，因此对所有这些请求而言，queryset的值将相同。这可以用作某种讨价还价的基础缓存，但很难正确处理，因为您不知道该进程将持续多长时间，另外，可能会有并行运行的其他进程具有各自的全局变量版本。
您的问题表明，您仍然不太了解查询集的工作方式。这与评估它们的时间有关：如果您列出，迭代或切片查询集，然后对其进行评估，那么就在该时刻进行数据库调用（我在此处计算迭代的序列化），并将结果存储在queryset的内部缓存。因此，如果您已经对查询集执行了其中一项操作，然后将其设置为（外部）缓存，则不会导致其他数据库命中。
但是 ，查询集上的每个filter()操作，即使是已经评估过的操作，都是另一个数据库命中。这是因为它的基础SQL查询的修改，所以Django的可以追溯到数据库- 并返回一个 新 的查询集，拥有自己的内部缓存。
602392714
清零编程群