显式cursor.close（）的必要性

Question

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

我注意到在cursor.close()完成数据库处理后，在某些地方我没有将其称为显式。到目前为止，这还没有导致任何错误或性能问题。我想知道如果不显式关闭游标就可能会遇到什么样的问题，什么会出错？

据我了解，connection并cursor在Django遵循“Python数据库API规范v2.0”（PEP-249）。并且，据此，cursor每当__del__()调用方法时，它将自动关闭。我猜问题可能还在于：不调用时是否存在用例？

仅供参考，我正在使用Python 2.7和Django 1.6.5。

Answer 1

__del__ / .close()：

1. __del__ 不保证会被调用
2. 一些数据库在其数据库中不调用cursor.close（）__del__（不好的做法，但是是真的）
3. 一些数据库实际上并没有在连接功能中创建连接，而是在游标功能中创建了连接（例如，对于2＆3：pyhive的presto [也许他们已经对其进行了修补]）

通常在服务器连接上

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

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

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