我正在开发一个 API，我有一个问题。我正在研究select_related() 的用法，以便为自己节省一些数据库查询，实际上它确实有助于减少执行的数据库查询量，但代价是更大和更复杂的查询。
我的问题是，使用select_related() 会导致更重的内存使用吗？运行一些实验我注意到确实是这种情况，但我想知道为什么。不管我是否使用select_related()，响应都会包含完全相同的数据，那么为什么使用select_related()会导致使用更多的内存呢？
是因为缓存吗？也许单独的数据对象用于缓存相同的模型实例？我不知道还有什么想法。
【问题讨论】：
标签： django memory django-select-related
这是一个权衡。向数据库发送查询，数据库准备结果，然后将这些结果发回需要时间。 select_related 的工作原理是，此过程中最昂贵的部分是请求和响应周期，而不是实际的查询，因此它允许您将原本不同的查询组合成一个，因此只有一个请求和响应而不是多个。
但是，如果您的数据库服务器功率不足（没有足够的 RAM、处理能力等），则较大的查询实际上最终可能会花费比请求和响应周期更长的时间。如果是这种情况，您可能需要升级服务器，而不是不使用select_related。
经验法则是，如果您需要相关数据，请使用select_related。如果它实际上并没有更快，那么这表明您需要优化数据库。
更新（添加更多解释）
查询数据库实际上涉及多个步骤：
在经过良好调整的环境（充足的服务器资源、快速的连接）中，整个过程只需几毫秒即可完成。但是，步骤 2 和 4 总体上仍然通常比步骤 3 花费更多时间。这就是为什么发送更少的更复杂的查询比发送多个更简单的查询更有意义：瓶颈通常是传输层而不是处理。
但是，如果数据库优化不佳，则在具有大型复杂表的动力不足的机器上运行查询可能需要很长时间，从而成为瓶颈。这最终会抵消发送一个复杂查询而不是多个简单查询所获得的时间减少，即数据库会对更简单的查询做出更快的响应，整个过程将花费更少的净时间。
尽管如此，如果是这种情况，正确的响应是修复数据库端：优化数据库及其配置、添加更多服务器资源等，而不是恢复为发送多个简单查询。
【讨论】：