显式 cursor.close() 的必要性

Posted 2023-02-23

【中文标题】显式 cursor.close() 的必要性

【英文标题】：Necessity of explicit cursor.close()

【发布时间】：2014-08-30 22:55:53

【问题描述】：

有时，我会使用 connection.cursor() 而不是 ORM 执行原始查询（因为它绝对不是灵丹妙药）。

我注意到，在我使用完数据库后，在几个地方我不会显式调用cursor.close()。到目前为止，这还没有导致任何错误或性能问题。我想知道如果不显式关闭光标，我可能会遇到什么样的问题，会出现什么问题？

据我了解，Django 中的connection 和cursor 遵循“Python 数据库API 规范v2.0”（PEP-249）。而且，根据它，每当调用__del__() 方法时，cursor 都会自动关闭。我想问题也可能是：是否有不调用的用例？

仅供参考，我使用的是 Python 2.7 和 Django 1.6.5。

【问题讨论】：

我猜这和***.com/questions/5669878/…这个问题很相似？？

@AamirAdnan 谢谢，不完全 - 在发布之前看到它。我知道如何关闭光标。问题是不关闭它有多糟糕以及后果是什么。

【参考方案1】：

Django 的cursor 类只是底层DB 的cursor 的包装器，因此保持cursor 处于打开状态的效果基本上与底层DB 驱动程序相关。

根据 psycopg2（psycopg2 是 Django 用于 PostgreSQL DB 的 DB 驱动程序）FAQ，它们的游标是轻量级的，但会缓存您使用游标对象进行的查询返回的数据，这可能会浪费内存：

游标是轻量级对象，不应创建大量游标 提出任何问题。但请注意，用于获取结果的游标 集合将缓存数据并与结果成比例地使用内存 设置大小。我们的建议是几乎总是创建一个新光标并 不再需要数据时立即处理旧数据（致电 close() 。）唯一的例外是紧循环，其中一个通常 对一大堆 INSERT 或 UPDATE 使用相同的光标。

Django 使用mysqldb 作为 MySQL 的后端，它有几种不同类型的游标，包括一些实际上将其结果集存储在服务器端的游标。 MySQLdb documentation for Cursor.close 指出，当你完成它们时关闭服务器端光标非常重要：

如果你使用服务器端游标，关闭是非常重要的 完成后和创建新光标之前的光标。

但是，这与 Django 无关，因为它使用 MySQLdb 提供的默认 Cursor 类，它将结果存储在客户端。让使用过的游标处于打开状态只会有浪费存储结果集使用的内存的风险，就像psycopg2 一样。游标上的close method只是删除了对db连接的内部引用，并耗尽了存储的结果集：

def close(self):
    """Close the cursor. No further queries will be possible."""
    if not self.connection: return
    while self.nextset(): pass
    self.connection = None

据我所知，Django 使用的所有其余后端（cx_oracle、sqlite3/pysqlite2）都遵循相同的模式；通过删除/重置存储的结果/对象引用来释放内存。 sqlite3 docs 甚至没有提到 Cursor 类有一个 close 方法，它只是在包含的示例代码中偶尔使用。

当__del__() 在cursor 对象上调用时，cursor 将被关闭是正确的，因此只有在您保持对@ 的长期引用时，才需要显式关闭是一个问题987654344@;例如一个 self.cursor 对象，您作为类的实例方法保留。

【讨论】：

但是，如果将游标重新用于第二个查询，它为第一个查询缓存的数据将不再被引用。因此，从某种意义上说，不必要地创建一大堆游标可能会适得其反，除非您专门删除使用过的游标。

@holdenweb 对，如果您要在短时间内进行一大堆查询，那么使用相同的光标可能是有意义的。如果您要进行查询，然后在将来某个未知的时间进行另一个查询，您可能应该关闭/删除游标，这样您就不会保留它用于缓存结果集的任何内存。跨度>

看来我们达成了暴力协议。

最近对 django (1.5+) 如何以原子方式处理事务的变化值得注意，尤其是在您经常使用原始查询的情况下。查看最新的开发文档：docs.djangoproject.com/en/dev/topics/db/transactions

contextlib.closing 将确保光标按预期关闭，同时代码看起来仍然很紧凑。

【参考方案2】：

__del__/.close():

不保证会调用__del__ 某些数据库不会在其__del__ 中调用 cursor.close()（不好的做法，但确实如此） 有些数据库实际上并没有在连接函数中创建连接，而是在游标函数中创建连接（例如，对于 2&3：pyhive 的 presto [也许他们已经修补了它]）

一般在服务器连接上

大多数服务器都有一个空闲超时配置属性（我们称之为 T）。如果连接空闲超过 T 秒，服务器将删除该连接。大多数服务器还具有设置工作线程池 (W) 大小的属性。如果您已经有 W 连接到您的服务器，则在尝试新连接时它可能会挂起。再想象一下，您没有明确关闭连接的选项。在这种情况下，您必须将超时设置得足够小，以至于您的工作池永远不会被完全使用，这是您拥有多少并发连接的函数。

但是，如果您确实关闭了游标/连接（即使与上述 [3] 不等效，它们的行为也类似），那么您不必管理这些服务器配置属性，您的线程池只需要足够大以管理所有并发连接（可以选择偶尔等待新资源）。我已经看到一些服务器（例如 Cassandra 上的 Titan）无法从线程池中的工作线程用完中恢复，因此整个服务器在重新启动之前停止运行。

TL/DR 如果您使用的是非常完善的库，例如 dano 提到的那些，那么您不会有问题。如果您使用的原始库较少，如果您不调用 .close()，最终可能会阻止服务器获取工作线程，具体取决于您的服务器配置和访问速率。

【参考方案3】：

虽然通常可以依靠操作系统来释放资源，但关闭数据库连接之类的东西以确保在不再需要时释放资源始终是一种良好的卫生习惯，从数据库的角度来看，真正重要的是确保任何更改都是commit()ed。

【参考方案4】：

cursor.close() 的显式调用可能有两个原因：

__del__ 不保证会被调用，并且有一些问题您可以阅读 here 和 here 显式优于隐式 (Zen of Python)

【参考方案5】：

这个问题我有点晚了。也许你想要一个关闭退出范围。

from contextlib import closing
from django.db import connection

with closing(connection.cursor()) as cursor:
    cursor.execute(...)
    cursor.execute(...)
    cursor.execute(...)

【讨论】：

他们提到使用 Django 1.6 并且文档说上下文管理器（例如您的示例）直到 1.7 才明确添加，但是，文档似乎表明它在此之前以任何方式工作到“魔术方法查找中的意外行为”。