SqlAlchemy 2.0 中文文档（五十五）（3）

SqlAlchemy 2.0 中文文档（五十五）（2）https://developer.aliyun.com/article/1563187

异步 I/O 异常

需要等待

SQLAlchemy 的异步模式需要使用异步驱动程序连接到数据库。尝试使用不兼容的 DBAPI 的情况下，通常会引发此错误。

另请参阅

异步 I/O（asyncio） ### 丢失 Greenlet

对异步 DBAPI 的调用是在通常由 SQLAlchemy AsyncIO 代理类设置的 greenlet spawn 上下文之外启动的。通常情况下，当尝试在意料之外的位置进行 IO 时，会发生此错误，使用的调用模式不直接提供使用await关键字的情况。在使用 ORM 时，几乎总是由于使用了延迟加载，在不经过额外步骤和/或使用成功所需的替代加载器模式的情况下，不直接支持 asyncio。

另请参阅

在使用 AsyncSession 时防止隐式 IO - 涵盖了大多数可能出现此问题的 ORM 方案以及如何进行缓解，包括与延迟加载场景一起使用的特定模式。 ### 无可用检查

直接在AsyncConnection或AsyncEngine对象上直接使用inspect()函数目前不受支持，因为尚未提供Inspector对象的可等待形式。相反，通过使用inspect()函数获取对象，使其引用AsyncConnection对象的底层AsyncConnection.sync_connection属性；然后通过使用AsyncConnection.run_sync()方法以及执行所需操作的自定义函数以“同步”调用样式使用Inspector：

async def async_main():
    async with engine.connect() as conn:
        tables = await conn.run_sync(
            lambda sync_conn: inspect(sync_conn).get_table_names()
        )

另请参阅

使用检查器检查模式对象 - 使用inspect()与 asyncio 扩展的其他示例。

Core 异常类

查看 Core Exceptions 以获取 Core 异常类。

ORM 异常类

查看 ORM Exceptions 以获取 ORM 异常类。

遗留异常

本节中的异常不是由当前 SQLAlchemy 版本生成的，但在此提供以适应异常消息超链接。

在 SQLAlchemy 2.0 中，<某个函数>将不再<某事>。

SQLAlchemy 2.0 代表了 Core 和 ORM 组件中许多关键 SQLAlchemy 使用模式的重大转变。2.0  版本的目标是对 SQLAlchemy 自其早期开始以来的一些最基本假设进行轻微调整，并提供一个新的简化使用模型，希望在 Core 和 ORM  组件之间更加简约一致，同时更具能力。

在 SQLAlchemy 2.0 - 主要迁移指南中介绍的 SQLAlchemy 2.0  项目包含了一个综合的未来兼容性系统，该系统集成到了 SQLAlchemy 1.4  系列中，以便应用程序能够明确、清晰地、逐步地升级路径，将应用程序迁移到完全兼容 2.0 版本。RemovedIn20Warning弃用警告是该系统的基础，用于提供关于现有代码库中需要修改的行为的指导。如何启用此警告的概述在 SQLAlchemy 2.0 弃用模式中。

另请参阅

SQLAlchemy 2.0 - 主要迁移指南 - 从 1.x 系列升级流程的概述，以及 SQLAlchemy 2.0 的当前目标和进展。

SQLAlchemy 2.0 弃用模式 - 如何在 SQLAlchemy 1.4 中使用“2.0 弃用模式”的具体指南。 ### 对象正在通过反向引用级联合并到一个 Session

本消息指的是 SQLAlchemy 中在 2.0 版本中删除的“反向引用级联”行为。这指的是将对象添加到Session中的操作，因为该会话中已经存在的另一个对象与之关联。由于这种行为被证明比有用更令人困惑，因此添加了relationship.cascade_backrefs和backref.cascade_backrefs参数，可以将其设置为False以禁用它，在 SQLAlchemy 2.0 中完全删除了“级联反向引用”行为。

对于较旧的 SQLAlchemy 版本，在当前使用relationship.backref字符串参数配置的反向引用上设置relationship.cascade_backrefs为False，必须首先使用backref()函数声明该反向引用，以便传递backref.cascade_backrefs参数。

或者，可以通过在“未来”模式下使用Session来完全关闭整个“级联反向引用”行为，通过将True传递给Session.future参数。

另请参阅

cascade_backrefs 行为在 2.0 中被弃用以移除 - 关于 SQLAlchemy 2.0 变更的背景。### select() 构造以“旧”模式创建；关键字参数等。

select() 构造已在 SQLAlchemy 1.4 中更新，以支持在 SQLAlchemy 2.0 中标准的新调用风格。为了向后兼容在 1.4 系列内，该构造接受“旧”风格和“新”风格的参数。

“新”风格的特性是列和表达式只能按位置传递给select() 构造；对象的任何其他修饰符都必须使用后续的方法链传递：

# this is the way to do it going forward
stmt = select(table1.c.myid).where(table1.c.myid == table2.c.otherid)

对比之下，在 SQLAlchemy 的旧形式中，select() 在像 Select.where() 这样的方法甚至添加之前，可能是这样的：

# this is how it was documented in original SQLAlchemy versions
# many years ago
stmt = select([table1.c.myid], whereclause=table1.c.myid == table2.c.otherid)

或者甚至“whereclause”会按位置传递：

# this is also how it was documented in original SQLAlchemy versions
# many years ago
stmt = select([table1.c.myid], table1.c.myid == table2.c.otherid)

近年来，大多数叙述性文档已经删除了接受的“whereclause”和其他参数，导致调用风格更像是作为列参数传递的列列表，但没有进一步的参数：

# this is how it's been documented since around version 1.0 or so
stmt = select([table1.c.myid]).where(table1.c.myid == table2.c.otherid)

select() 不再接受多样的构造参数，列仅按位置传递 中的文档描述了这一变更的 2.0 迁移。

另请参阅

select() 不再接受多样的构造参数，列仅按位置传递

SQLAlchemy 2.0 - 主要迁移指南 ### 通过旧绑定的元数据找到了一个绑定，但由于该 Session 设置了 future=True，因此该绑定被忽略。

直到 SQLAlchemy 1.4，都存在“bound metadata”的概念；从 SQLAlchemy 2.0 开始已经移除。

此错误指的是MetaData.bind参数，该参数位于MetaData对象上，该对象又允许 ORM Session将特定的映射类与Engine关联起来。在 SQLAlchemy 2.0 中，Session必须直接链接到每个Engine。也就是说，不是实例化Session或sessionmaker而不带任何参数，并将Engine与MetaData关联起来：

engine = create_engine("sqlite://")
Session = sessionmaker()
metadata_obj = MetaData(bind=engine)
Base = declarative_base(metadata=metadata_obj)
class MyClass(Base): ...
session = Session()
session.add(MyClass())
session.commit()

Engine必须直接与sessionmaker或Session关联。MetaData对象不应再关联任何引擎：

engine = create_engine("sqlite://")
Session = sessionmaker(engine)
Base = declarative_base()
class MyClass(Base): ...
session = Session()
session.add(MyClass())
session.commit()

在 SQLAlchemy 1.4 中，当Session.future标志设置在sessionmaker或Session上时，将启用此 2.0 风格行为。 ### 此编译对象未绑定到任何 Engine 或 Connection

此错误指的是“绑定的元数据”概念，这是仅存在于 1.x 版本的传统 SQLAlchemy 模式。当直接在未关联任何Engine的 Core 表达式对象上调用Executable.execute()方法时，会出现此问题：

metadata_obj = MetaData()
table = Table("t", metadata_obj, Column("q", Integer))
stmt = select(table)
result = stmt.execute()  # <--- raises

逻辑期望的是MetaData对象已经绑定到一个Engine上：

engine = create_engine("mysql+pymysql://user:pass@host/db")
metadata_obj = MetaData(bind=engine)

在上述情况下，任何从Table派生的语句，又从MetaData派生的语句将隐式地利用给定的Engine来调用该语句。

请注意，绑定元数据的概念在 SQLAlchemy 2.0 中不存在。调用语句的正确方式是通过Connection.execute()方法的Connection：

with engine.connect() as conn:
    result = conn.execute(stmt)

在使用 ORM 时，可以通过Session获得类似的功能：

result = session.execute(stmt)

另请参阅

语句执行基础知识 ### 此连接处于非活动事务状态。请在继续之前完全回滚()

该错误条件是在 SQLAlchemy 版本 1.4 中添加的，不适用于 SQLAlchemy 2.0. 该错误是指将Connection置于使用诸如Connection.begin()之类的方法创建的事务中，然后在该范围内创建进一步的“标记”事务；然后使用Transaction.rollback()回滚或使用Transaction.close()关闭“标记”事务，但是外部事务仍然处于“非活动”状态，必须回滚。

这种模式看起来像：

engine = create_engine(...)
connection = engine.connect()
transaction1 = connection.begin()
# this is a "sub" or "marker" transaction, a logical nesting
# structure based on "real" transaction transaction1
transaction2 = connection.begin()
transaction2.rollback()
# transaction1 is still present and needs explicit rollback,
# so this will raise
connection.execute(text("select 1"))

上述中，transaction2 是一个“标记”事务，表示事务在外部事务内的逻辑嵌套；虽然内部事务可以通过其 rollback() 方法回滚整个事务，但其 commit() 方法除了关闭“标记”事务的范围外，没有其他效果。调用 transaction2.rollback() 的效果是取消激活 transaction1，这意味着它在数据库级别上实际上已回滚，但仍然存在以适应事务的一致嵌套模式。

正确的解决方法是确保外部事务也已回滚：

transaction1.rollback()

这种模式在 Core 中不常用。在 ORM 中，可能会出现类似的问题，这是 ORM 的“逻辑”事务结构的产物；这在“此会话的事务由于刷新期间的先前异常而被回滚。”（或类似内容）的常见问题解答条目中有描述。

SQLAlchemy 2.0 中已删除“子事务”模式，因此不再提供此特定编程模式，从而防止出现此错误消息。

连接和事务

队列池大小限制已达到溢出，连接超时，超时

这可能是最常见的运行时错误，因为它直接涉及应用程序的工作负载超过配置限制，这通常适用于几乎所有 SQLAlchemy 应用程序。

以下几点总结了这个错误的含义，从大多数 SQLAlchemy 用户应该已经熟悉的最基本点开始。

• SQLAlchemy 引擎对象默认使用连接池 - 这意味着当使用Engine对象的 SQL 数据库连接资源，并且释放该资源后，数据库连接本身仍保持连接状态，并返回到内部队列，可以再次使用。尽管代码可能看起来已经结束了与数据库的交互，但在许多情况下，应用程序仍会保持一定数量的数据库连接，直到应用程序结束或显式处理池。
  
• 由于连接池，当应用程序使用 SQL 数据库连接时，通常是通过使用Engine.connect()或使用 ORM Session进行查询时，此活动并不一定在获取连接对象时立即建立新连接到数据库；相反，它会向连接池查询连接，该连接池通常会检索一个现有连接以供重复使用。如果没有可用连接，连接池将创建一个新的数据库连接，但前提是池未超过配置容量。
  
• 大多数情况下使用的默认池称为QueuePool。当您要求此池提供连接但没有可用连接时，它将创建一个新连接如果当前连接总数小于配置值。该值等于池大小加上最大溢出。这意味着如果您已将引擎配置为：

engine = create_engine("mysql+mysqldb://u:p@host/db", pool_size=10, max_overflow=20)

• 上述Engine将允许最多同时有 30 个连接在使用中，不包括从引擎分离或失效的连接。如果新连接请求到达并且应用程序的其他部分已经使用了 30 个连接，连接池将阻塞一段固定时间，然后超时并引发此错误消息。
  为了允许更多的连接同时使用，可以使用传递给create_engine()函数的create_engine.pool_size和create_engine.max_overflow参数来调整池。等待连接可用的超时时间是使用create_engine.pool_timeout参数配置的。
• 可以通过将create_engine.max_overflow设置为值“-1”来配置池以具有无限溢出。使用此设置，池仍将维护一组固定的连接池，但如果没有可用的连接，则永远不会阻止新连接的请求；相反，如果没有可用的连接，它将无条件地建立一个新连接。
  然而，以这种方式运行时，如果应用程序存在使用所有可用连接资源的问题，它最终将达到数据库本身可用连接的配置限制，这将再次返回错误。更严重的是，当应用程序耗尽数据库连接时，通常会在失败之前使用大量资源，并且还可能干扰其他依赖于能够连接到数据库的应用程序和数据库状态机制。
  根据上述情况，连接池可以被视为连接使用的安全阀，为防止一个恶意应用导致整个数据库对所有其他应用不可用提供了至关重要的保护层。当收到此错误消息时，最好修复使用过多连接和/或适当配置限制的问题，而不是允许无限溢出，因为这实际上并不能解决潜在问题。
  

应用程序耗尽所有可用连接的原因是什么？

• 应用程序正在处理过多的并发请求，以根据池的配置值进行工作 - 这是最直接的原因。如果您的应用程序在允许 30 个并发线程的线程池中运行，并且每个线程使用一个连接，则如果您的池未配置为允许同时至少检出 30 个连接，一旦您的应用程序接收到足够的并发请求，您将会收到此错误。解决方法是提高池的限制或降低并发线程数。
  
• 应用程序没有将连接归还到池中 - 这是接下来最常见的原因，即应用程序正在使用连接池，但程序未能将这些连接释放并且仍然保持打开状态。连接池以及 ORM Session 都有逻辑，当会话和/或连接对象被垃圾回收时，底层连接资源将被释放，但不能依赖这种行为及时释放资源。
  这种情况发生的常见原因是应用程序使用 ORM 会话但在完成使用该会话的工作后没有调用 Session.close()。解决方案是确保在完成工作时显式关闭 ORM 会话（如果使用 ORM）或引擎绑定的 Connection 对象（如果使用 Core），通过适当的 .close() 方法或使用其中一个可用的上下文管理器（例如，“with:”语句）来正确释放资源。
  
• 应用程序试图运行长时间事务 - 数据库事务是一种非常昂贵的资源，绝对不能让其空闲等待某些事件发生。如果一个应用程序正在等待用户按下按钮，或者等待长时间运行的作业队列中的结果，或者正在保持与浏览器的持久连接打开，请不要在整个时间段保持数据库事务处于打开状态。当应用程序需要与数据库交互并处理事件时，在那一点上打开一个短暂的事务，然后关闭它。
  
• 应用程序发生死锁 - 这也是这个错误的常见原因之一，也更难以理解，如果一个应用程序无法完成其对连接的使用，无论是由于应用程序端还是数据库端的死锁，应用程序都会使用完所有可用的连接，这样会导致其他请求收到这个错误。死锁的原因包括：

• 如果使用隐式异步系统（例如 gevent 或 eventlet）而没有正确地 monkeypatch 所有的  socket 库和驱动程序，或者在没有完全覆盖所有被 monkeypatch 的驱动程序方法的情况下存在漏洞，或者更少见的情况是异步系统正在用于  CPU 密集型工作负载且 greenlets  使用数据库资源的等待时间过长。对于绝大多数关系型数据库操作来说，隐式或显式的异步编程框架通常是不必要或不合适的；如果应用程序必须在某些功能区域使用异步系统，最好是数据库导向型业务方法在传统线程中运行，然后将消息传递给应用程序的异步部分。
  
• 数据库端死锁，例如行之间相互死锁
  
• 线程错误，例如互相死锁的互斥锁，或者在同一线程中调用已锁定的互斥锁
  

请记住，使用池的另一种选择是完全关闭池。请参阅切换池实现部分以了解相关背景信息。但是，请注意，当出现此错误消息时，总是由应用程序本身的更大问题引起；池只是帮助更快地暴露问题。

另请参见

连接池

使用引擎和连接 ### 池类不能与 asyncio 引擎一起使用（反之亦然）

QueuePool池类在内部使用thread.Lock对象，并且与 asyncio 不兼容。如果使用create_async_engine()函数创建AsyncEngine，则适当的队列池类是AsyncAdaptedQueuePool，它会自动使用，无需指定。

除了AsyncAdaptedQueuePool之外，NullPool和StaticPool池类不使用锁，并且也适用于与异步引擎一起使用。

在极少数情况下，如果使用create_engine()函数显式指定了AsyncAdaptedQueuePool池类，则也会引发此错误。

另请参见

连接池 ### 在无效事务回滚之前无法重新连接。请在继续之前完全回滚()

这个错误条件指的是当一个Connection无效时，无论是因为数据库断开检测还是因为显式调用Connection.invalidate()，但仍然存在一个事务，该事务由Connection.begin()方法明确启动，或者由于连接在发出任何 SQL 语句时自动开始一个事务，如 SQLAlchemy 2.x 系列中发生的情况。当连接无效时，任何正在进行中的Transaction现在处于无效状态，必须明确回滚才能将其从Connection中移除。### QueuePool 大小为的限制溢出，连接超时，超时

这可能是最常见的运行时错误，因为它直接涉及应用程序的工作负载超过了配置的限制，这个限制通常适用于几乎所有的 SQLAlchemy 应用程序。

以下几点总结了这个错误的含义，从大多数 SQLAlchemy 用户应该已经熟悉的最基本的点开始。

• SQLAlchemy Engine 对象默认使用连接池 - 这意味着当一个Engine对象的  SQL  数据库连接资源被使用，并且释放了该资源后，数据库连接本身仍然保持连接状态，并返回到一个内部队列中，可以再次使用。尽管代码可能看起来已经结束了与数据库的交互，但在许多情况下，应用程序仍将保持一定数量的数据库连接，直到应用程序结束或显式释放池为止。
  
• 由于连接池，当应用程序使用 SQL 数据库连接时，通常是通过使用Engine.connect()或通过使用 ORM Session进行查询时，这个活动并不一定在获取连接对象时立即建立到数据库的新连接；它实际上是向连接池查询连接，这通常会从池中检索一个现有的连接以便重新使用。如果没有可用的连接，池将创建一个新的数据库连接，但只有在池没有超过配置容量时才会这样做。
  
• 在大多数情况下使用的默认池称为QueuePool。当您要求此池提供连接，而没有可用连接时，它将创建一个新连接如果当前使用的连接总数少于配置值。这个值等于池大小加上最大溢出。这意味着如果您已将引擎配置为：

engine = create_engine("mysql+mysqldb://u:p@host/db", pool_size=10, max_overflow=20)

• 上述Engine允许最多 30 个连接同时存在，不包括已从引擎分离或失效的连接。如果请求新连接，并且应用程序的其他部分已使用 30 个连接，连接池将阻塞一段固定时间，然后超时并引发此错误消息。
  为了允许更多连接同时使用，池可以使用传递给create_engine()函数的create_engine.pool_size和create_engine.max_overflow参数进行调整。等待可用连接的超时时间由create_engine.pool_timeout参数配置。
• 通过将create_engine.max_overflow设置为值“-1”，可以配置池具有无限溢出。使用此设置，池仍将维护一组固定的连接，但如果请求新连接时没有可用连接，它将无条件地创建一个新连接。
  然而，在这种方式下运行时，如果应用程序存在使用所有可用连接资源的问题，则最终会达到数据库本身可用连接的配置限制，这将再次返回错误。更严重的是，当应用程序耗尽数据库连接时，通常会在失败之前使用大量资源，并且还可能干扰其他依赖于能够连接到数据库的应用程序和数据库状态机制。
  鉴于上述情况，连接池可以被视为连接使用的安全阀，提供了对于恶意应用程序使整个数据库对于所有其他应用程序不可用的关键保护层。当收到此错误消息时，最好修复使用太多连接和/或适当配置限制的问题，而不是允许无限溢出，这实际上并没有解决潜在问题。
  

什么原因会导致应用程序耗尽所有可用的连接？

• 应用程序正在处理太多并发请求以执行基于池配置的工作 -  这是最直接的原因。如果您有一个运行在允许 30 个并发线程的线程池中的应用程序，每个线程使用一个连接，并且如果您的池没有配置为允许至少同时检出  30 个连接，则在您的应用程序接收到足够的并发请求时，您将收到此错误。解决方法是提高池的限制或降低并发线程的数量。
  
• 应用程序未将连接返回到池中 - 这是接下来最常见的原因，即应用程序正在使用连接池，但程序未能释放这些连接，而是保持它们处于打开状态。连接池以及 ORM Session确实具有逻辑，使得当会话和/或连接对象被垃圾回收时，导致底层连接资源被释放，但不能依赖此行为及时释放资源。
  这种情况经常发生的原因是应用程序使用 ORM 会话，但在完成涉及该会话的工作后未调用Session.close()。解决方法是确保 ORM 会话（如果使用 ORM）或绑定到引擎的Connection对象（如果使用 Core）在完成工作后明确关闭，可以通过适当的.close()方法或使用其中一个可用的上下文管理器（例如“with:”语句）来正确释放资源。
  
• 应用程序正试图运行长时间事务 - 数据库事务是一种非常昂贵的资源，不应该空闲等待某个事件发生。如果应用程序正在等待用户按下按钮，或者等待长时间作业队列的结果，或者保持持久连接打开以与浏览器交互，不要保持数据库事务始终处于打开状态。当应用程序需要与数据库一起工作并与事件交互时，在那一点上打开一个短暂的事务，然后关闭它。
  
• 应用程序发生死锁 - 这也是此错误的常见原因，更难以理解。如果应用程序由于应用程序端或数据库端的死锁而无法完成其对连接的使用，那么应用程序可能会耗尽所有可用连接，然后导致其他请求收到此错误。死锁的原因包括：

• 如果没有正确地对所有套接字库和驱动程序进行猴子补丁，或者对所有猴子补丁驱动程序方法的覆盖不完全，或者在异步系统正在用于  CPU 密集型工作负载并且使用数据库资源的绿色线程等待太长时间时，则使用隐式异步系统，例如 gevent 或  eventlet，会出现问题。通常，隐式或显式异步编程框架通常对绝大多数关系数据库操作都不是必要的或合适的；如果应用程序必须对某些功能区域使用异步系统，则最好是数据库导向的业务方法在传统线程中运行，然后将消息传递到应用程序的异步部分。
  
• 数据库端发生死锁，例如行相互死锁
  
• 线程错误，例如互斥体在相互死锁，或在同一线程中调用已锁定的互斥体
  

请记住，除了使用池化技术的替代方法是完全关闭池化技术。请参阅切换池实现部分了解背景信息。但是，请注意，当出现此错误消息时，通常是由于应用程序本身存在更大的问题；池仅帮助更早地暴露问题。

另请参阅

连接池

与引擎和连接一起工作

无法将 Pool 类与 asyncio 引擎一起使用（反之亦然）

QueuePool 池类在内部使用 thread.Lock 对象，并且与 asyncio 不兼容。如果使用 create_async_engine() 函数创建 AsyncEngine，则适当的队列池类是 AsyncAdaptedQueuePool，它会自动使用，无需指定。

除了 AsyncAdaptedQueuePool，NullPool 和 StaticPool 池类不使用锁，并且也适用于与异步引擎一起使用。

在极少数情况下，如果使用 create_engine() 函数明确指定 AsyncAdaptedQueuePool 池类，则还会引发此错误。

另请参阅

连接池

无法重新连接直到无效事务被完全回滚。请在继续之前完全回滚()

此错误条件指的是 Connection 被作废的情况，可能是由于检测到数据库断开连接或由于显式调用 Connection.invalidate()，但仍然存在已经由 Connection.begin() 方法显式启动的事务，或者由于连接在发出任何 SQL 语句时自动开始事务，这在 SQLAlchemy 的 2.x 系列中发生。当连接被作废时，任何正在进行的 Transaction 现在处于无效状态，必须显式回滚以将其从 Connection 中移除。

DBAPI 错误

Python 数据库 API，或 DBAPI，是一种用于数据库驱动程序的规范，可以在 Pep-249 找到。此 API 指定了一组异常类，以适应数据库的所有故障模式。

SQLAlchemy 不会直接生成这些异常。相反，它们是从数据库驱动程序拦截并由 SQLAlchemy 提供的异常 DBAPIError 包装的，但异常中的消息是由驱动程序生成的，而不是 SQLAlchemy。

InterfaceError

与数据库接口而不是数据库本身相关的错误引发的异常。

此错误是 DBAPI 错误 ，源自数据库驱动程序（DBAPI），而不是 SQLAlchemy 本身。

InterfaceError 有时会由驱动程序在数据库连接断开或无法连接到数据库的情况下引发。有关如何处理此问题的提示，请参阅 处理断开连接 部分。 ### DatabaseError

与数据库本身相关而不是接口或传递的数据的错误引发的异常。

此错误是 DBAPI 错误 ，源自数据库驱动程序（DBAPI），而不是 SQLAlchemy 本身。 ### DataError

由于处理的数据问题引发的异常，例如除以零，数值超出范围等。

此错误是 DBAPI 错误，源自数据库驱动程序（DBAPI），而不是 SQLAlchemy 本身。 ### OperationalError

与数据库操作相关的错误引发的异常，不一定在程序员控制之下，例如出现意外断开连接，找不到数据源名称，无法处理事务，处理过程中发生内存分配错误等。

此错误是 DBAPI 错误，源自数据库驱动程序（DBAPI），而不是 SQLAlchemy 本身。

OperationalError 是由驱动程序在数据库连接断开或无法连接到数据库的情况下使用的最常见（但不是唯一）错误类别。有关如何处理此问题的提示，请参阅处理断开连接部分。 ### IntegrityError

当数据库的关系完整性受到影响时引发的异常，例如外键检查失败。

此错误是 DBAPI 错误，源自数据库驱动程序（DBAPI），而不是 SQLAlchemy 本身。 ### InternalError

当数据库遇到内部错误时引发的异常，例如游标不再有效，事务不同步等。

此错误是 DBAPI 错误，源自数据库驱动程序（DBAPI），而不是 SQLAlchemy 本身。

InternalError 有时会由驱动程序在数据库连接断开或无法连接到数据库的情况下引发。有关如何处理此问题的提示，请参阅处理断开连接部分。 ### ProgrammingError

由于编程错误引发的异常，例如未找到表或已存在，SQL 语句中的语法错误，指定的参数数量错误等。

此错误是 DBAPI 错误，源自数据库驱动程序（DBAPI），而不是 SQLAlchemy 本身。

ProgrammingError 有时会由驱动程序在数据库连接断开或无法连接到数据库的情况下引发。有关如何处理此问题的提示，请参阅处理断开连接部分。 ### NotSupportedError

当使用数据库不支持的方法或数据库 API 时引发的异常，例如在不支持事务或已关闭事务的连接上请求.rollback()。

此错误是 DBAPI 错误，源自数据库驱动程序（DBAPI），而不是 SQLAlchemy 本身。 ### InterfaceError

与数据库本身而不是数据库接口相关的错误引发的异常。

此错误是 DBAPI 错误，源自数据库驱动程序（DBAPI），而不是 SQLAlchemy 本身。

InterfaceError有时由驱动程序在数据库连接断开或无法连接到数据库的情况下引发。有关如何处理此问题的提示，请参见处理断开连接部分。

DatabaseError

由于与数据库本身相关的错误而引发的异常，而不是与传递的接口或数据相关。

此错误是 DBAPI 错误，源自数据库驱动程序（DBAPI），而不是 SQLAlchemy 本身。

DataError

由于处理数据的问题（例如除零，数值超出范围等）引发的错误。

此错误是 DBAPI 错误，源自数据库驱动程序（DBAPI），而不是 SQLAlchemy 本身。

OperationalError

由于与数据库操作相关的错误而引发的异常，不一定在程序员的控制之下，例如发生意外断开连接，数据源名称未找到，无法处理事务，处理过程中发生内存分配错误等。

此错误是 DBAPI 错误，源自数据库驱动程序（DBAPI），而不是 SQLAlchemy 本身。

OperationalError是驱动程序在数据库连接断开或无法连接到数据库的情况下最常见（但不是唯一）使用的错误类。有关如何处理此问题的提示，请参见处理断开连接部分。

IntegrityError

当数据库的关系完整性受到影响时引发异常，例如外键检查失败。

此错误是 DBAPI 错误，源自数据库驱动程序（DBAPI），而不是 SQLAlchemy 本身。

InternalError

当数据库遇到内部错误时引发异常，例如游标不再有效，事务不同步等。

此错误是 DBAPI 错误，源自数据库驱动程序（DBAPI），而不是 SQLAlchemy 本身。

InternalError有时由驱动程序在数据库连接断开或无法连接到数据库的情况下引发。有关如何处理此问题的提示，请参见处理断开连接部分。

ProgrammingError

由于编程错误而引发的异常，例如表未找到或已存在，在 SQL 语句中存在语法错误，指定的参数数量错误等。

此错误是 DBAPI 错误，源自数据库驱动程序（DBAPI），而不是 SQLAlchemy 本身。

ProgrammingError有时由驱动程序在数据库连接断开或无法连接到数据库的情况下引发。有关如何处理此问题的提示，请参见处理断开连接部分。

NotSupportedError

在使用数据库不支持的方法或数据库 API 时引发异常，例如在不支持事务或已关闭事务的连接上请求 .rollback()。

这个错误是一个 DBAPI 错误，源自数据库驱动程序（DBAPI），而不是 SQLAlchemy 本身。

SqlAlchemy 2.0 中文文档（五十五）（4）https://developer.aliyun.com/article/1563191