Django:select_lated() 和内存使用

Question

我正在开发 API，我有一个问题。我正在研究 select_lated() 的用法，以便为自己节省一些数据库查询，实际上它确实有助于减少执行的数据库查询量，但代价是更大、更复杂的查询.

我的问题是，使用 select_lated() 是否会导致内存使用量增加？进行一些实验后，我注意到确实是这样，但我想知道为什么。无论我是否使用 select_lated()，响应都将包含完全相同的数据，那么为什么使用 select_lated() 会导致使用更多内存？

是因为缓存吗？也许单独的数据对象用于缓存相同的模型实例？我不知道还能想什么。

Answer 1

这是一个权衡。将查询发送到数据库、数据库准备结果，然后将这些结果发回需要时间。 select_lated 的工作原理是，此过程中最昂贵的部分是请求和响应周期，而不是实际的查询，因此它允许您将原本不同的查询合并到一个查询中，这样就可以只有一个请求和响应，而不是多个。

但是，如果您的数据库服务器动力不足(没有足够的 RAM、处理能力等)，则较大的查询实际上可能会比请求和响应周期花费更长的时间。如果是这种情况，您可能需要升级服务器，而不是不使用 select_lated。

经验法则是，如果您需要相关数据，请使用 select_lated。如果实际上并没有更快，则表明您需要优化数据库。

更新(添加更多解释)

查询数据库实际上涉及多个步骤:

1. 应用程序生成查询(可忽略)
2. 查询被发送到数据库服务器(毫秒到秒)
3. 数据库处理查询(毫秒到秒)
4. 查询结果发送回应用程序(毫秒到秒)

在经过良好调整的环境(足够的服务器资源、快速连接)下，整个过程只需几毫秒即可完成。但是，步骤 2 和 4 通常仍然比步骤 3 花费更多时间。这就是为什么发送更少的更复杂的查询比发送多个更简单的查询更有意义:瓶颈通常是传输层而不是处理。

但是，在具有大型且复杂的表的动力不足的计算机上，优化不佳的数据库可能需要很长时间才能运行查询，从而成为瓶颈。这最终会抵消发送一个复杂查询而不是多个简单查询所带来的时间减少，即数据库会对更简单的查询做出更快的响应，并且整个过程将花费更少的净时间。

尽管如此，如果是这种情况，正确的应对措施是修复数据库端:优化数据库及其配置、添加更多服务器资源等，而不是恢复为发送多个简单查询。