如何修复使用 Python ORM 工具 SQLAlchemy 时的常见陷阱
在使用SQLAlchemy时，那些看似很小的选择可能对这种对象关系映射工具包的性能产生重要影响。
对象关系映射Object-relationalmapping（ORM）使应用程序开发人员的工作更轻松，在很大程度是因为它允许你使用你可能知道的语言（例如Python）与数据库交互，而不是使用原始SQL语句查询。
SQLAlchemy是一个PythonORM工具包，它提供使用Python访问SQL数据库的功能。它是一个成熟的ORM工具，增加了模型关系、强大的查询构造范式、简单的序列化等优点。然而，它的易用性使得人们很容易忘记其背后发生了什么。使用SQLAlchemy时做出的看似很小的选择可能产生非常大的性能影响。
本文解释了开发人员在使用SQLAlchemy时遇到的一些最重要的性能问题，以及如何解决这些问题。
只需要计数但检索整个结果集
有时开发人员只需要一个结果计数，但是没有使用数据库计数功能，而是获取了所有结果，然后使用Python中的len完成计数。
count=len(User.query.filter_by(acct_active=True).all())
相反，使用SQLAlchemy的count方法将在服务器端执行计数，从而减少发送到客户端的数据。在前面的例子中调用all()也会导致模型对象的实例化，如果有很多数据，那么时间代价可能会非常昂贵。
除非还需要做其他的事情，否则只需使用count方法：
count=User.query.filter_by(acct_active=True).count()
只需要几列时检索整个模型
在许多情况下，发出查询时只需要几列数据。SQLAlchemy可以只获取你想要的列，而不是返回整个模型实例。这不仅减少了发送的数据量，还避免了实例化整个对象。使用列数据的元组而不是模型可以快得多。
result=User.query.all() foruserinresult: print(user.name,user.email)
反之，使用with_entities方法只选择所需要的内容：
result=User.query.with_entities(User.name,User.email).all() for(username,email)inresult: print(username,email)
每次循环都更新一个对象
避免使用循环来单独更新集合。虽然数据库可以非常快地执行单个更新，但应用程序和数据库服务器之间的往返时间将快速累加。通常，在合理的情况下争取更少的查询。
foruserinusers_to_update: user.acct_active=True db.session.add(user)
改用批量更新方法：
query=User.query.filter(user.id.in_([user.idforuserinusers_to_update]))
query.update({"acct_active":True},synchronize_session=False)
触发级联删除
ORM允许在模型关系上进行简单的配置，但是有一些微妙的行为可能会令人吃惊。大多数数据库通过外键和各种级联选项维护关系完整性。SQLAlchemy允许你使用外键和级联选项定义模型，但是ORM具有自己的级联逻辑，可以取代数据库。
考虑以下模型：
classArtist(Base):
__tablename__="artist"
id=Column(Integer,primary_key=True)
songs=relationship("Song",cascade="all,delete")
classSong(Base):
__tablename__="song"
id=Column(Integer,primary_key=True)
artist_id=Column(Integer,ForeignKey("artist.id",ondelete="CASCADE"))
删除歌手将导致ORM在song表上发出delete查询，从而防止由于外键导致的删除操作。这种行为可能会成为复杂关系和大量记录的瓶颈。
请包含passive_deletes选项，以确保让数据库来管理关系。但是，请确保你的数据库具有此功能。例如，SQLite默认情况下不管理外键。
songs=relationship("Song",cascade all,delete",passive_deletes=True)
当要使用贪婪加载时，应使用延迟加载
延迟加载是SQLAlchemy处理关系的默认方法。从上一个例子构建来看，加载一个歌手时不会同时加载他或她的歌曲。这通常是一个好主意，但是如果总是需要加载某些关系，单独的查询可能会造成浪费。
如果允许以延迟方式加载关系，像Marshmallow这样流行的序列化框架可以触发级联查询。
有几种方法可以控制此行为。最简单的方法是通过relationship函数本身。
songs=relationship("Song",lazy="joined",cascade="all,delete")
这将导致一个左连接被添加到任何歌手的查询中，因此，songs集合将立即可用。尽管有更多数据返回给客户端，但往返次数可能会少得多。
SQLAlchemy为无法采用这种综合方法的情况提供了更细粒度的控制，可以使用joinedload()函数在每个查询的基础上切换连接的加载。
fromsqlalchemy.ormimportjoinedload artists=Artist.query.options(joinedload(Artist.songs)) print(artists.songs)#Doesnotincuraroundtriptoload
使用ORM进行批量记录导入
导入成千上万条记录时，构建完整模型实例的开销会成为主要瓶颈。想象一下，从一个文件中加载数千首歌曲记录，其中每首歌曲都先被转换为字典。
forsonginsongs: db.session.add(Song(`song))
相反，绕过ORM，只使用核心的SQLAlchemy参数绑定功能。
batch=[] insert_stmt=Song.__table__.insert() forsonginsongs: iflen(batch)>1000: db.session.execute(insert_stmt,batch) batch.clear() batch.append(song) ifbatch: db.session.execute(insert_stmt,batch)
请记住，此方法会自然而然地跳过你可能依赖的任何客户端ORM逻辑，例如基于Python的列默认值。尽管此方法比将对象加载为完整的模型实例要快，但是你的数据库可能具有更快的批量加载方法。例如，PostgreSQL的COPY命令为加载大量记录提供了最佳性能。
过早调用提交或刷新
在很多情况下，你需要将子记录与其父记录相关联，反之亦然。一种显然的方法是刷新会话，以便为有问题的记录分配一个ID。
artist=Artist(name="BobDylan") song=Song(title="Mr.TambourineMan") db.session.add(artist) db.session.flush() song.artist_id=artist.id
对于每个请求，多次提交或刷新通常是不必要的，也是不可取的。数据库刷新涉及强制在数据库服务器上进行磁盘写入，在大多数情况下，客户端将阻塞，直到服务器确认已写入数据为止。
SQLAlchemy可以在幕后跟踪关系和管理相关键。
artist=Artist(name="BobDylan") song=Song(title="Mr.TambourineMan") artist.songs.append(song)
总结
我希望这一系列常见的陷阱可以帮助你避免这些问题，并使你的应用平稳运行。通常，在诊断性能问题时，测量是关键。大多数数据库都提供性能诊断功能，可以帮助你定位问题，例如PostgreSQL的pg_stat_statements模块。
声明：本文内容来源于网络，版权归原作者所有，内容由互联网用户自发贡献自行上传，本网站不拥有所有权，未作人工编辑处理，也不承担相关法律责任。如果您发现有涉嫌版权的内容，欢迎发送邮件至：czq8825#qq.com（发邮件时，请将#更换为@）进行举报，并提供相关证据，一经查实，本站将立刻删除涉嫌侵权内容。