1. 理解数据库连接持久性：为何连接不立即关闭？
在使用SQLAlchemy与PostgreSQL进行异步交互时，开发者可能会观察到一个现象：即使代码逻辑上已经“关闭”了数据库会话，但通过数据库工具查看，仍有多个连接保持开放状态。这并非异常，而是SQLAlchemy连接池（Connection Pooling）机制的正常行为，旨在优化性能和资源利用。
数据库连接的建立和关闭是相对耗时的操作。为了避免每次请求都重新建立连接的开销，SQLAlchemy默认会启用连接池。连接池会在后台维护一定数量的数据库连接，当应用程序需要连接时，它会从池中获取一个可用的连接；当会话结束时，该连接并不会真正关闭，而是被归还到连接池中，供后续请求复用。这种机制显著提高了应用程序的响应速度和效率。
2. SQLAlchemy连接池机制详解
SQLAlchemy的连接池是其核心组件之一，尤其在异步环境中，通过create_async_engine创建的引擎默认就集成了连接池功能。
-
连接池的作用：
- 性能提升：减少了连接建立和断开的开销。
- 资源管理：限制了同时打开的数据库连接数量，防止资源耗尽。
- 连接复用：已建立的连接可以被多个会话复用。
-
pool_size 参数： 连接池会维护一个最小数量的空闲连接，这个数量可以通过 pool_size 参数进行配置。默认情况下，SQLAlchemy的连接池大小通常为5。这意味着即使没有活跃的会话在使用连接，连接池也会尝试保持5个连接处于开放状态，以备不时之需。
要调整连接池的大小，应在创建异步引擎时通过 create_async_engine 函数设置 pool_size 参数。
示例代码：配置连接池大小
from sqlalchemy.ext.asyncio import create_async_engine # 配置一个连接池，最大保持10个空闲连接 db_engine = create_async_engine( '', echo=False, future=True, pool_size=10, # 设置连接池大小为10 max_overflow=5 # 允许连接池在高峰期临时超出pool_size的连接数 ) - pool_size: 连接池中保持的固定连接数。当所有连接都被占用时，如果未达到 pool_size + max_overflow，将创建新连接。
- max_overflow: 允许连接池在 pool_size 基础上额外创建的最大连接数。例如，pool_size=10, max_overflow=5 意味着连接池最多可以有15个活跃连接。
3. 异步会话的正确管理与关闭
在SQLAlchemy的异步编程中，使用上下文管理器（async with 语句）是管理会话和连接的推荐方式。它确保了资源的正确获取和释放。
考虑以下原始代码片段：
from sqlalchemy.ext.asyncio import AsyncSession, create_async_engine, async_sessionmaker
db_engine = create_async_engine('', echo=False, future=True)
async_session = async_sessionmaker(db_engine, class_=AsyncSession, expire_on_commit=False)
async def get_session() -> AsyncSession:
async with async_session() as session:
yield session
await session.close() # 这一行是冗余的！ 上述代码中，await session.close() 这一行是多余的，并且可能导致误解。
上下文管理器的作用：当使用 async with async_session() as session: 语句时，SQLAlchemy的上下文管理器会自动处理会话的生命周期。这意味着当代码块执行完毕或发生异常退出时，上下文管理器会自动调用会话的 close() 方法。对于从连接池获取的会话，close() 操作实际上是将连接归还到连接池中，而不是真正关闭底层的数据库连接。
-
优化后的代码示例： 因此，正确的做法是完全依赖上下文管理器，移除显式的 session.close() 调用。
from sqlalchemy.ext.asyncio import AsyncSession, create_async_engine, async_sessionmaker # 配置连接池大小（示例，可根据实际需求调整） db_engine = create_async_engine( '', echo=False, future=True, pool_size=10, # 连接池中保持的连接数 max_overflow=5 # 允许的额外连接数 ) # 创建异步会话工厂 async_session = async_sessionmaker(db_engine, class_=AsyncSession, expire_on_commit=False) async def get_session() -> AsyncSession: """ 获取一个异步数据库会话。 使用yield作为依赖注入，确保会话在请求结束后被正确关闭（归还到连接池）。 """ async with async_session() as session: yield session # 无需手动调用 session.close()，上下文管理器会自动处理 在这个优化后的 get_session 函数中，yield session 将会话传递给调用者。当调用者完成操作后，控制权返回到 async with 块，此时上下文管理器会自动执行清理工作，将会话关联的连接归还到 db_engine 管理的连接池中。
4. 注意事项与最佳实践
- 合理设置 pool_size：pool_size 的值应根据应用程序的并发需求和数据库服务器的承载能力来决定。过小可能导致连接等待，过大则可能浪费数据库资源或超出数据库最大连接限制。
- 理解 max_overflow：max_overflow 允许连接池在短时间内创建超出 pool_size 的额外连接，以应对突发的连接高峰。但这些溢出连接在空闲一段时间后会被关闭。
- 不要混淆会话关闭与连接关闭：session.close() 将会话标记为关闭，并将其底层连接归还到连接池。它不意味着底层的TCP/IP连接被物理断开。
- 连接池的生命周期：db_engine（及其内部的连接池）通常应在应用程序的整个生命周期中保持单例。频繁地创建和销毁引擎会失去连接池的优势。
- 官方文档是最佳资源：对于更深入的连接池配置和高级用法，请务必查阅SQLAlchemy的官方文档：https://www.php.cn/link/aa16b1e36967dda0f92705a0a1beb710。
5. 总结
SQLAlchemy的连接池机制是其高性能的关键之一，它通过复用数据库连接来减少开销。因此，观察到数据库连接在会话结束后仍然开放是正常且期望的行为。正确的会话管理应依赖 async with 上下文管理器，它会自动处理会话的关闭（即归还连接到连接池），开发者无需手动调用 session.close()。通过合理配置 create_async_engine 中的 pool_size 和 max_overflow 参数，可以有效地管理应用程序的数据库连接资源，确保系统在高并发下的稳定性和效率。
