SQLAlchemy性能劣于pyodbc且阻塞更严重，是否使用方式有误？

你的SQLAlchemy使用方式存在明显问题 #

你当前的代码每次请求都创建新引擎并销毁连接池，完全浪费了SQLAlchemy连接池的性能优势，这是导致性能下降和锁阻塞加剧的核心原因之一：

• create_engine 应全局初始化一次，而非每次执行SQL都重复创建
• conn.dispose() 会直接销毁整个连接池，导致每次请求都要重新建立数据库物理连接，额外开销极大

优化后的SQLAlchemy代码示例 #

正确做法是全局初始化引擎、复用连接池，Session按需创建：

# 全局初始化（仅执行一次）
engine = create_engine(connstr, pool_size=10, max_overflow=20)  # 根据业务场景调整连接池参数
SessionLocal = sessionmaker(autocommit=False, autoflush=False, bind=engine)

# 单次SQL执行逻辑
def execute_sql(sqlt):
    rc = None
    session = SessionLocal()
    try:
        session.execute(sqlt)
        session.commit()
    except Exception as ex:
        rc = ex
        session.rollback()
    finally:
        session.close()  # 将连接归还至连接池，而非关闭物理连接
    return rc

锁阻塞（schema-M锁）额外排查点 #

• 检查sqlt语句差异：确认SQLAlchemy对SQL的解析/处理是否和pyodbc存在不同，比如是否自动触发了额外的元数据查询，进而引发schema锁
• 核对事务隔离级别：确认SQLAlchemy默认隔离级别是否与pyodbc一致，隔离级别差异可能导致锁持有时间变长
• 存储过程调用方式：如果涉及存储过程，检查SQLAlchemy的写法是否和pyodbc一致（比如是用callproc还是直接执行EXEC ...）

其他开发者的类似遭遇 #

不少开发者切换至SQLAlchemy时都遇到过性能问题，常见诱因包括：

• 错误地频繁创建/销毁引擎，放弃连接池优势
• 未根据业务需求合理配置连接池参数（如pool_size太小导致等待连接，太大导致数据库连接数过载）
• 误启用ORM特性带来额外开销（你当前使用核心层execute，因此主要排查连接池和执行逻辑问题）

内容的提问来源于stack exchange，提问作者Michael W