直接在Tornado里用SQLAlchemy同步执行SQL，结果就是阻塞IOLoop，所谓“异步框架里写同步数据库代码”，等于白搭。安全执行的关键不是“怎么写SQL”，而是“怎么不卡住事件循环”。
为什么不能在RequestHandler里直接调用session.execute()
因为session.execute()、session.commit()，甚至user.addresses（延迟加载）这些操作，底层都走的是同步DBAPI（比如pymysql或psycopg2），会真实阻塞线程。Tornado的协程无法自动让出控制权——它只对await显式支持的异步对象让步，而原生SQLAlchemy不是其中之一。
有经验的同学都遇到过这样的场景：压测时并发请求响应时间线性增长——10个请求耗时约10秒，self.write()拖到最后一刻才调用，IOLoop看似“空转”，实际上被绑死了。
- ORM的延迟加载、关系访问、flush/commit全部隐式触发同步IO
create_engine(..., echo=True)开启后，能看到日志卡在execute那一行不动，这就是铁证- 哪怕只查一条记录，也足以让一个worker线程停住100ms+，直接毁掉并发吞吐
推荐方案：用run_on_executor + 独立session
这是目前最轻量、最可控、兼容性最好的做法。不改ORM习惯，不引入新消息队列，也不依赖那些尚未成熟的异步驱动（比如asyncpg对PostgreSQL有效，但MySQL的aiomysql生态弱、bug多、长期不维护）。
核心要点：
- 必须用
@tornado.gen.coroutine或async def（Tornado ≥6.0）包装handler方法 - executor必须是全局复用的
tornado.concurrent.futures.ThreadPoolExecutor实例，不能每次new一个 - session必须在executor线程内创建、使用、关闭，绝不能跨线程传递或复用主线程的session
- 所有数据库异常要在executor内捕获并转为普通异常，否则协程await会卡死或静默失败
来看一个示例片段：
from tornado.concurrent import run_on_executor
from concurrent.futures import ThreadPoolExecutor
from sqlalchemy import create_engine
from sqlalchemy.orm import sessionmaker
engine = create_engine('mysql+pymysql://...')
Session = sessionmaker(bind=engine)
executor = ThreadPoolExecutor(max_workers=4)
class UserHandler(tornado.web.RequestHandler):
@run_on_executor(executor=executor)
def _db_query(self, user_id):
with Session() as session:
return session.execute("SELECT * FROM users WHERE id = :id", {"id": user_id}).fetchone()
async def get(self):
user_id = self.get_argument("id")
row = await self._db_query(user_id)
self.write({"user": dict(row) if row else None})
别碰asyncio + SQLAlchemy 2.0的“原生异步”模式
Tornado本身不基于asyncio事件循环（它用自研IOLoop），强行混用asyncio.run()或把create_async_engine()塞进Tornado handler，会产生一系列问题：
RuntimeError: "There is no current event loop in thread"——循环跑不起来- 连接池复用失效，每请求新建连接，快速打爆MySQL的
max_connections - Session在不同线程/loop间穿梭，引发
AttributeError: 'NoneType' object has no attribute 'execute'
如果你真想用SQLAlchemy 2.0的异步特性，那该换框架——用FastAPI或Starlette，它们和asyncio是同源设计。在Tornado里硬套，只会让问题更隐蔽。
MySQL异步驱动（aiomysql）的实际坑
即使你放弃SQLAlchemy、改用aiomysql手写SQL，仍然有几个关键限制：
aiomysql已停止维护（最后release是2022年），Python 3.12+兼容性存疑- 不支持prepared statement复用，高并发下容易触发MySQL的
max_prepared_stmt_count限制 - 连接池
Pool的close()不是协程，需手动await pool.wait_closed()，否则进程退出时连接泄漏 - 错误堆栈常丢失原始SQL上下文，调试起来相当头疼
换句话说：它能跑通简单查询，但经不起线上流量和长期维护的考验。
其实，真正容易被忽略的一点是：无论用哪种方式，只要涉及多表JOIN或复杂WHERE条件，务必先在MySQL CLI里用EXPLAIN看执行计划。异步只是不卡线程，并不能拯救慢SQL——90%的性能问题，根源在没加索引或写了全表扫描语句。
