在使用SQLAlchemy时做出的看似很小的选择可能对ORM的性能产生重要影响。
对象-关系映射(ORM)使应用程序开发人员的工作更加轻松，这在很大程度上是因为它允许您使用您可能知道的语言(如Python)与数据库交互，而不是使用原始的SQL查询。SQLAlchemy是一个Python ORM工具包，提供使用Python访问SQL数据库的功能。它是一个成熟的ORM工具，增加了模型关系、强大的查询构造范式、容易序列化等优点。然而，它的易用性使得人们很容易忘记幕后发生的事情。使用SQLAlchemy做出的看似很小的选择可能具有重要的性能影响。
本文解释了开发人员在使用SQLAlchemy时遇到的一些最重要的性能问题，以及如何解决这些问题。
仅需要计数时检索整个结果集
有时，开发人员只需要对结果进行计数，但不是利用数据库计数，而是获取所有结果，并使用python中的len完成计数。
相反，使用SQLAlchemy的计数方法将在服务器端进行计数，从而减少发送到客户机的数据。在前面的例子中调用all()也会导致模型对象的实例化，如果有足够多的行，模型对象的实例化会很快变得非常昂贵。除非需要更多的计数，否则只需使用count方法。
当您只需要几个列时，就可以检索整个模型
在许多情况下，发出查询时只需要几列。无需返回整个模型实例，SQLAlchemy只能获取您感兴趣的列。这不仅减少了发送的数据量，而且避免了实例化整个对象的需要。使用列数据的元组而不是模型可以更快。
在循环内一次更新一个对象
避免使用循环来单独更新集合。尽管数据库可以非常快速地执行单个更新，但是应用程序与数据库服务器之间的往返时间将迅速增加。通常，在合理的情况下，争取减少查询次数。
请使用批量更新方法代替。
触发级联删除
ORM允许对模型上的关系进行简单的配置，但是有一些微妙的行为可能会令人吃惊。大多数数据库通过外键和各种级联选项来维护关系完整性。SQLAlchemy允许您使用外键和级联选项定义模型，但是ORM有自己的级联逻辑，可以抢占数据库。
观察下面的模型：
如果删除一个Artist记录将导致ORM对Song表发出delete查询，从而防止由于外键而导致的删除。这种行为可能成为具有复杂关系和大量记录的瓶颈。
包括passive_deletes选项以确保数据库正在管理关系。但是，请确保您的数据库具有此功能。例如，SQLite默认情况下不管理外键。
在使用急加载时，应使用延迟加载
延迟加载是处理关系的默认SQLAlchemy方法。从上一个例子构建，这意味着加载一个艺术家（Artist）并不同时加载他或她的歌曲（Song）。这通常是一个好主意，但是如果总是需要加载某些关系，则单独的查询可能会造成浪费。
如果允许以延迟方式加载关系，那么像Marshmallow这样的流行序列化框架可以触发级联查询。
有几种方法可以控制这种行为。最简单的方法是通过关系函数本身。
这将导致左联接被添加到对艺术家（Artist）的任何查询中，因此，歌曲（Song）集合将立即可用。尽管有更多数据返回给客户端，但往返次数可能会少得多。
SQLAlchemy为无法采用这种全面方法的情况提供了更细粒度的控制。joinload（）函数可用于在每个查询的基础上切换联合加载。
使用ORM进行批量记录导入
构建完整模型实例的开销成为导入数千条记录时的主要瓶颈。想象一下，例如，从一个文件中加载数千首歌曲记录，其中每首歌曲都首先被转换成字典。
相反，绕过ORM，仅使用核心SQLAlchemy的参数绑定功能。
提前调用commit或flush
在很多情况下，您需要将子记录与其父记录关联起来，反之亦然。一种明显的方法是刷新会话，以便为有问题的记录分配一个ID。
每个请求提交或刷新多次通常是不必要的，也是不希望的。数据库刷新涉及强制在数据库服务器上进行磁盘写入，并且在大多数情况下，客户端将阻塞，直到服务器可以确认已写入数据为止。
SQLAlchemy可以跟踪关系并在后台管理键。
小结：
我希望这一系列常见的陷阱可以帮助您避免这些问题，并使您的应用程序平稳运行。通常，在诊断性能问题时，度量是关键。大多数数据库都提供了性能诊断，可以帮助您定位问题，比如PostgreSQL pg_stat_statements模块。
原文链接：
https://opensource.com/article/19/9/common-pitfalls-python
