做后端这些年，我几乎每个 Python 项目都会跟数据库打交道。早期我也经历过“裸写 SQL”的阶段，后来换到 SQLAlchemy ORM，再到现在把它作为团队里数据库层的标配。坦白说，一开始我对 ORM 是有点抗拒的，总觉得多了一层“翻译官”，性能肯定有损耗，写起来可能还不如直接拼 SQL 来得痛快。但真正用熟之后才发现，问题的关键不在于“用不用 ORM”，而在于“怎么用才能既省事又不掉链子”。这篇内容我打算把自己用 SQLAlchemy ORM 做数据库操作的经验完整梳理一遍，从模型定义、会话管理、查询优化，到异步支持和常见坑位排查，给想入门的朋友一条可以直接照着走的路线，也给已经在用的人一些能提升效率的细节。不管你是用 Python 写爬虫需要存取数据，还是做 Web 后端、量化策略的数据落盘，只要涉及数据库操作，这篇文章值得你花几分钟看完。
1. 搞懂 SQLAlchemy ORM 的定位：它到底替你做了什么
1.1 为什么要用 ORM：从“手写 SQL”到“面向对象”的转变
很多人第一次听到“ORM”这个词，会觉得是个很高深的概念。其实拆开看就一句话：ORM 是把数据库里的一张张表，映射成 Python 里的一个个类；把表里的一行行记录，映射成一个个对象；把表之间的外键关系，映射成对象之间的引用关系。你不再需要把精力花在“把结果集转成字典”“把参数塞进 SQL 语句”这些琐事上，而是直接操作 Python 对象。
举个例子。以前我从用户表里查数据，大概是这样：
import pymysql conn = pymysql.connect(host='127.0.0.1', user='root', password='xxx', database='test') cursor = conn.cursor() cursor.execute("SELECT id, name, age FROM users WHERE age > %s", (18,)) rows = cursor.fetchall() users = [{'id': r[0], 'name': r[1], 'age': r[2]} for r in rows] conn.close()这还没有考虑事务、连接池、SQL 注入、分页等一堆问题。如果查询条件一变，SQL 就要重新拼，一旦拼法不小心，还可能碰上注入风险。要是表再多个几张，代码维护起来简直是一场灾难。
用 SQLAlchemy ORM，过程就变成了：
users = session.query(User).filter(User.age > 18).all()查出来的直接是User对象，字段可以直接通过属性访问，不用关心底层是 MySQL 还是 PostgreSQL。这就是 ORM 最核心的价值：屏蔽了数据库方言的差异，让代码聚焦在业务模型上。
1.2 SQLAlchemy 的两层架构：Core 与 ORM 需要分开理解
SQLAlchemy 最容易被误解的一点，是它把“Core”和“ORM”两套东西放在了同一个库里。Core 是 SQLAlchemy 的底层抽象，它让你用 Python 表达式来构建 SQL，比如select(User).where(User.age > 18)，但它不会帮你把结果变成业务对象。ORM 则是在 Core 之上做了一层对象映射，让你既能使用 OOP 风格的代码，又能在需要时退回到 Core 甚至原生 SQL。
这套设计带来的好处非常实际：性能关键路径上你用 Core 或原生 SQL，业务复杂路径上用 ORM，两者可以无缝衔接。我在做报表查询时就经常这么干，简单 CRUD 全交给 ORM，遇到需要多表 join 的复杂统计，就直接text()写原生 SQL，这样既保证了灵活性，也不牺牲性能。
1.3 和其他 ORM 框架的简单对比
Python 生态里 ORM 不算少，Django 有自带的 ORM，轻量项目也有 Peewee 可选。我个人选择 SQLAlchemy 的原因主要有三点：
- 和框架解耦。Django ORM 绑定在 Django 项目里，而 SQLAlchemy 可以独立使用，无论是 FastAPI、Flask、爬虫脚本还是定时任务，都能无缝接入。
- 灵活性强。Django ORM 的查询 API 简单，但复杂查询时容易绕来绕去；SQLAlchemy 支持从 ORM 到 Core 再到原生 SQL 的渐变式下沉，遇到瓶颈时能直接写 SQL，不需要换库。
- 成熟度和社区生态。SQLAlchemy 出来很多年了，网上资料、避坑帖、工具链（比如 Alembic 迁移）都非常完善，踩到问题基本都能搜到答案。
Peewee 适合做非常轻量的项目，但如果你的项目后期数据模型会变复杂，我还是建议一步到位选 SQLAlchemy，省得换框架时痛一次。这些年在实际项目中我感受到的趋势是，Python 生态里大型一点的 Web 服务，SQLAlchemy 几乎成了事实标准。
2. 模型定义：把数据库表变成 Python 类的关键操作
2.1 声明式基类和 mapped_column 的基础使用
SQLAlchemy 2.0 主推的是声明式映射，也就是用一个继承基类的 Python 类来描述数据库表。不推荐再使用老式的Column搭配Table的方式，虽然老代码里到处都是，但新项目可以直接从 2.0 新风格入手。
第一步是安装 SQLAlchemy，顺便装好对应数据库的驱动：
pip install sqlalchemy # 以 PostgreSQL 为例，还可以考虑 psycopg 或 asyncpg pip install psycopg[binary] # 如果是 MySQL，可以装 pymysql 或 mysqlclient然后定义一个模型：
from sqlalchemy.orm import DeclarativeBase, Mapped, mapped_column from sqlalchemy import String, Integer, DateTime, func class Base(DeclarativeBase): pass class User(Base): __tablename__ = "users" id: Mapped[int] = mapped_column(primary_key=True, autoincrement=True) name: Mapped[str] = mapped_column(String(50)) email: Mapped[str] = mapped_column(String(120), unique=True, index=True) age: Mapped[int] = mapped_column(Integer, default=0) created_at: Mapped[datetime] = mapped_column(DateTime, server_default=func.now())这里有几个细节值得注意：
Mapped[T]是现代 SQLAlchemy 的类型注解风格，配合mapped_column使用，IDE 能自动推断出字段类型，这对开发体验提升非常明显。server_default=func.now()是让数据库自己生成时间，比在 Python 层用datetime.now()更靠谱，因为这样可以避免应用服务器时间不一致的问题。unique=True, index=True直接通过模型定义来加唯一约束和索引，省得单独写 DDL。
2.2 关系映射：ForeignKey 与 relationship 的搭配
单张表不够，业务一定逃不开多表关联。比如用户有订单，订单里有商品。用 ORM 表达这种关系的核心是ForeignKey和relationship。
class Order(Base): __tablename__ = "orders" id: Mapped[int] = mapped_column(primary_key=True, autoincrement=True) user_id: Mapped[int] = mapped_column(ForeignKey("users.id")) total_amount: Mapped[float] = mapped_column(Numeric(10, 2)) user: Mapped["User"] = relationship(back_populates="orders")在User类里加上反向引用：
class User(Base): # ... 其他字段 orders: Mapped[List["Order"]] = relationship(back_populates="user")这里我特别想分享一个经验：不要滥用relationship。老手都知道，ORM 的relationship在访问时才触发懒加载，一旦在循环里访问，就容易出现经典的 N+1 查询问题。如果只是需要 userId 做查询，直接使用user_id字段就行，不必每次加载关联对象。只有在明确需要对象导航时才定义 relationship，并且查询时用joinedload或selectinload提前加载，这样既方便又不伤性能。
2.3 表结构变更：别手动改库，用 Alembic 迁移
在真实项目中，模型改几行字段太常见了。刚开始我图省事，直接去数据库客户端手动 ALTER TABLE，结果团队里其他人拉完代码，本地数据库缺字段直接报错。后来我用 Alembic 做数据库迁移，把这个流程彻底规范化了。
Alembic 是 SQLAlchemy 官方推荐的迁移工具，基本流程是：
pip install alembic alembic init alembic然后修改alembic/env.py指向你的模型 Base 和数据库连接串，之后生成迁移脚本：
alembic revision --autogenerate -m "add user table" alembic upgrade head它会自动根据模型和当前库结构的差异，生成新增或修改字段的迁移脚本。团队里每个人拉完代码执行一下alembic upgrade head，数据库结构就同步了，非常省心。比较大的项目里，我会把迁移脚本也纳入代码审查，确保字段变更都有记录。
3. 会话与事务管理：理解 Session 才能真正用好 ORM
3.1 Session 到底是什么：一个带缓存的工作区
很多初学者把Session理解成“连接”，其实不准确。Session 更像是一个工作区，它管理着一系列数据库操作，并在合适的时机把变更提交到数据库。你可以向 Session 里添加对象、查询对象、修改对象，Session 会跟踪这些对象的状态变化，最后通过commit()一次性把变更持久化。它底层的连接是从连接池里获取的，事务结束后会把连接释放回池中。
创建 Session 的推荐方式是使用sessionmaker：
from sqlalchemy.orm import sessionmaker from sqlalchemy import create_engine engine = create_engine("postgresql+psycopg://user:pass@localhost/dbname", echo=False) SessionLocal = sessionmaker(bind=engine, expire_on_commit=False)expire_on_commit=False这个参数值得专门说一下。默认情况下，commit 之后对象会被标记为过期，下次访问属性时会重新查数据库。我在很多项目里发现，如果提交后还要继续使用对象的数据（比如生成响应返回给前端），这个默认行为会带来多余的 SQL 请求。所以我会主动设成False，让对象在提交后保持已有状态。
3.2 正确使用事务：commit、rollback 和上下文管理器
事务管理是数据库操作的重点，也最容易出问题。一个常见的坏习惯是手动调用session.commit()后就不管了，万一中间抛异常，事务就一直挂着。推荐的方式是使用with上下文管理器：
from sqlalchemy.orm import Session with SessionLocal() as session: with session.begin(): user = User(name="张三", email="zhangsan@example.com", age=20) session.add(user) # 离开 with session.begin() 块时自动 commit它的妙处在于：如果with session.begin()块内部抛异常，事务会自动回滚，不需要你手动写try/except/rollback。如果里面所有操作都成功，块结束时自动提交，非常干净。
如果你用 FastAPI 这类框架，通常的做法是让请求级别的依赖创建 Session，在请求结束时关闭。简单的 Web 项目里，用一个依赖函数即可：
def get_db(): db = SessionLocal() try: yield db finally: db.close()这里我不止一次看到有人忘了db.close()，导致连接池被耗尽。Session 本身不是线程安全的，每个请求都应该有独立的 Session，千万不要把 Session 放在全局变量里共享。
3.3 事务隔离级别的选择
SQLAlchemy 里可以通过engine或连接参数设置隔离级别。以 PostgreSQL 为例：
engine = create_engine( "postgresql+psycopg://user:pass@localhost/dbname", isolation_level="READ COMMITTED", )大部分业务用默认的READ COMMITTED就够了。如果你做的是高并发下单类场景，可能需要用到更高级别的隔离。但值得提醒的是，隔离级别越高，并发性能就越低，死锁的概率也可能增加。与其盲目调高隔离级别，不如把事务做得尽量短，把加锁时间控制在最小范围。我的经验是，先保证事务只包含必要的操作，再考虑隔离级别的问题。
4. 查询操作：命中索引、避免 N+1 的实用技巧
4.1 基础查询操作：filter 和 select 的新写法
SQLAlchemy 2.0 风格中，执行查询有两种主流写法：旧的session.query()风格和新的session.execute(select())风格。我建议新代码直接使用后者，因为它是未来方向，也更容易看懂。
from sqlalchemy import select stmt = select(User).where(User.age > 18).order_by(User.created_at.desc()) users = session.scalars(stmt).all()注意这里的scalars()方法，它会把结果集直接投影成User对象列表。如果只用session.execute()，拿到的是一堆 Row 对象，还需要再取属性，绕了一步。查询单个对象用session.scalar()，比如：
user = session.scalar(select(User).where(User.id == 1))如果查询需要返回部分字段，不想加载整个对象，则可以这样写：
stmt = select(User.id, User.name).where(User.age > 18) rows = session.execute(stmt).all()这样出来的就是(id, name)元组列表，适合做报表或者下拉选项。
4.2 预防 N+1 查询：joinedload 和 selectinload 怎么选
N+1 查询是 ORM 最容易踩进去的性能坑。简单说，你查了 10 个用户，然后循环访问每个用户的订单列表，ORM 就会额外执行 10 次查询。加上最开始那一次，总共 11 次，这就是 N+1 问题的由来。
最好的解决方式是“一次把关联数据取出”。SQLAlchemy 提供了两条路：
from sqlalchemy.orm import joinedload, selectinload # 方式一：用 JOIN 一次性取回 stmt = select(User).options(joinedload(User.orders)).all() # 方式二：先查用户，再一次性查出所有相关订单 stmt = select(User).options(selectinload(User.orders)).all()joinedload对应 SQL 里的 JOIN，数据量一大，返回的重复列也会变多，内存开销上升。selectinload的思路是先查出主表 ID，再用第二个查询把附属数据一次性取出。我的建议是：如果关联数据相对较小、层级不深，用joinedload简单直接；如果关联表数据量大，或者有多层嵌套，优先用selectinload，避免单条 SQL 膨胀得离谱。
4.3 聚合查询与分页：func.count 和 limit/offset 的正确姿势
统计场景里，直接走 ORM 对象可能不太高效。SQLAlchemy 提供了func来使用数据库内置的聚合函数：
from sqlalchemy import func stmt = select(User.age, func.count(User.id)).group_by(User.age) result = session.execute(stmt).all()分页操作看似简单，但数据量大时要留意。常规做法：
page = 2 page_size = 20 stmt = select(User).order_by(User.id).limit(page_size).offset((page - 1) * page_size) users = session.scalars(stmt).all()这里有个经验：如果表非常庞大，偏移量大时，offset会越来越慢。更好的方式是使用“游标分页”，即基于上次最后一条记录的 ID 或时间戳来取下一页数据：
stmt = select(User).where(User.id > last_id).order_by(User.id).limit(page_size)这种方案在千万级表上仍然能保持稳定速率，代价是前端需要配合传递游标参数，而不像页码那样直观。做内部管理系统时我一般用普通分页，做面向用户的列表接口时优先考虑游标分页。
4.4 动态查询条件的组装
Web 接口里最常见的需求是“多条件筛选”，而且条件可能带或不带。比如用户列表要按用户名、年龄、状态筛选。用原生 SQL 拼条件时，要反复判断是否拼接 WHERE，麻烦还容易出错。SQLAlchemy 里可以直接构建条件列表，再统一传给where()：
conditions = [] if keyword: conditions.append(User.name.like(f"%{keyword}%")) if min_age: conditions.append(User.age >= min_age) if status: conditions.append(User.status == status) stmt = select(User).where(*conditions) if conditions else select(User)这种方式写起来很自然，而且能有效避免拼接字符串带来的注入风险。如果真的遇到特别复杂的条件，还可以用or_、and_来组合：
from sqlalchemy import or_ stmt = select(User).where(or_(User.age < 18, User.age > 60))5. 异步 SQLAlchemy 与 psycopg3 时代的同步异步对比
5.1 为什么需要异步：高并发场景下阻塞必须避开
Python 的异步编程这两年越来越普及，尤其是 FastAPI 这类异步框架兴起之后，大家开始关注数据库层是否异步。如果 Web 服务是异步的，但数据库操作是同步阻塞的，那么一旦数据库慢，整个事件循环都会跟着被卡住。这就是为什么 SQLAlchemy 提供了create_async_engine和对应的异步 Session。
在 PostgreSQL 场景下，异步驱动的选择主要有两个：asyncpg和psycopg。新版 psycopg3 支持同步和异步两种模式，而且它对 PostgreSQL 原生的类型支持更好。同步异步切换时，create_engine和create_async_engine的 URL 前缀会稍有差异：
# 同步 engine = create_engine("postgresql+psycopg://user:pass@localhost/dbname") # 异步 async_engine = create_async_engine("postgresql+psycopg://user:pass@localhost/dbname")注意psycopg驱动在异步模式下同样能驱动，因为 psycopg3 内建了对 asyncio 生态的支持。如果你更偏好成熟的asyncpg，则 URL 是postgresql+asyncpg://。
5.2 异步 Session 的写法与常见误区
异步 Session 的创建看起来和同步很类似，但使用方式完全不一样：
from sqlalchemy.ext.asyncio import create_async_engine, async_sessionmaker async_engine = create_async_engine("postgresql+psycopg://user:pass@localhost/dbname") AsyncSessionLocal = async_sessionmaker(async_engine, expire_on_commit=False) async def get_user(user_id: int): async with AsyncSessionLocal() as session: stmt = select(User).where(User.id == user_id) user = await session.scalar(stmt) return user这里最容易踩的坑有两个。第一，忘记await。异步 Session 的execute、scalar等方法都是协程，必须等待执行。新手经常写漏，导致结果不是数据而是一个 coroutine 对象。第二，在异步代码里混用同步 Session。虽然看起来只是对象类型不同，但底层连接池、事务管理的机制完全两回事，混用会造成连接竞争甚至死锁。我一般会在项目里通过类型注解和接口抽象，让业务代码不关心底层是同步还是异步，切换时改动尽量集中。
5.3 同步与异步的选择：性能与复杂度的平衡
很多团队看到“异步”就心痒痒，觉得用了异步性能一定更好。但在我看来，异步并不代表“更快”，它只是让等待数据库响应的时间空出来处理其他任务。如果你的服务本身就是同步的，比如用 Django、Flask，那改成异步不仅要换驱动，还要处理 ORM 事件循环、连接池、任务调度等一系列复杂问题，成本不低。
我给团队定过一条简单原则：优先同步，按需异步。只有在你确定高并发 IO 密集场景下同步阻塞已经成了瓶颈，或者项目本身整体就是 FastAPI/async 风格的，才去引入异步 SQLAlchemy。爬虫、数据分析脚本、内部管理后台，绝大多数用同步就足够了。做对比测试的时候我见过不少项目，把同步改成异步之后，数据库慢查询并没有减少，反而因为复杂的连接管理还引入了一些偶发问题。
6. 实战中的常见问题与避坑经验
6.1 DetachedInstanceError：提交后不能访问未加载属性
这是我自己碰到过很多次的报错。原因很简单：对象已经从 Session 的跟踪范围中“脱离”了，再去访问没有加载过的联动属性时，ORM 没有 Session 可以帮它去数据库查询，就直接抛错。
解决方式通常是：
- 访问属性前，先把对象重新
merge回 Session，但这样会多一次查询。 - 设置
expire_on_commit=False，并且确保查询时就加载好需要的数据。 - 或者直接用
session.get(User, id)重新取一次。
最根治的方法，是在业务边界上想清楚：对象一旦提交，就不应该再依赖隐式加载。需要返回给前端的数据，在提交之前就取好，或者明确用一条查询重新组装数据。
6.2 时间字段的时区坑：为什么存进去是本地时间，读出来是 UTC
这个坑在部署时很容易暴露。应用服务器和数据库服务器在同一时区时，看起来一切正常；一旦跨地域部署，就会看到时间对不上。原因在于 Python 的datetime.now()通常返回的是“无时区信息”的本地时间，而数据库端如果有自动生成的时间（如server_default=func.now()），则取决于数据库的时区设置。
我的习惯是：统一使用带时区的类型DateTime(timezone=True)，并且传入 UTC 时间。如果数据库是 PostgreSQL，可以配合TIMESTAMPTZ，这样读出来就是标准时区时间，展示层再转换为本地时间。MySQL 在这块要弱一些，最好在应用层统一时间标准。为此我在模型层做过一个小封装：所有created_at、updated_at字段都用DateTime(timezone=True)+server_default=func.now()，查询结果保持一致。
6.3 并发插入和唯一约束冲突
Web 服务并发一上来，数据库唯一约束冲突就不可避免。比如注册用户时邮箱唯一，两个请求同时提交，其中一个就会报 IntegrityError。最原始的处理方式是先查询是否存在再插入，但这不是并发安全的。更靠谱的做法是直接捕获异常并做后续处理：
from sqlalchemy.exc import IntegrityError try: session.add(user) session.commit() except IntegrityError: session.rollback() # 走“已经存在”的逻辑这里还有一个细节：在 PostgreSQL 里事务失败后，整个事务都会变成 aborted 状态，后续查询也无法继续，所以一定要先rollback()，再继续其他操作。捕获异常后重新开一个事务，是更稳妥的做法。
6.4 批量插入数据：一次 add_all，不如一次 bulk 有效
做爬虫数据落盘时，我见过不少人写循环add()然后一次性commit()。这种方式数据量大了非常慢，因为 ORM 要对每条记录做状态跟踪。SQLAlchemy 提供了几个批量插入方向：
session.bulk_insert_mappings(User, list_of_dicts)，适合不需要 ORM 对象状态的场景。- 直接使用 Core 的
insert()配合executemany。 - 最新版本里，
session.add_all()配合普通数据库驱动，数据量不大时其实也够用。
我在爬虫场景里常用bulk_insert_mappings，因为爬虫数据基本是一次性写入，不需要回读，也不需要对象关系。需要说明的是，bulk_insert_mappings不会主动触发 ORM 的事件钩子，表里的default和server_default仍然有作用，但如果你依赖 Python 层回调，就得改用其他方案。
这里补充一个实例。假设我写了一个新闻爬虫，每 10 分钟抓取一批文章，入库存到articles表。模型定义好之后，抓取到的每篇文章就是一个词典，批量写入代码看起来像这样：
session.bulk_insert_mappings( Article, [ {"title": item["title"], "url": item["url"], "source": item["source"]} for item in scraped_items ], ) session.commit()这种方式比一条条add()快了不止一个量级，核心原因在于它跳过了很多 Python 层面的对象映射工作，直接把数据结构丢给数据库驱动批量执行。
6.5 连接池耗尽：Session 泄漏是元凶
线上应用偶尔会报TimeoutError: queue pool limit exceeded之类的错，排查后十有八九是 Session 没关。连接池里可用连接全部被占着，新增请求只能排队等。正常情况下，每个请求一个 Session、用后即关，基本不会出现这个问题。所以一开始创建 Session 的代码就要约定好，在 Web 框架里用依赖注入管理生命周期，在脚本里用上下文管理器。这也再次说明with语法不是花架子，而是防止资源泄漏的第一道防线。
如果仍然出现问题，可以排查两方面：一是是否有代码路径忘记关闭 Session，比如异常分支直接 return；二是连接池的大小是否合理配置。SQLAlchemy 里常用参数有pool_size和max_overflow：
engine = create_engine( "postgresql+psycopg://user:pass@localhost/dbname", pool_size=20, max_overflow=10, )pool_size=20表示空闲时维护 20 个连接，max_overflow=10表示最多超出 10 个临时连接。具体数值根据业务并发量调节，不要盲目开很大，数据库服务器资源是有限的。
7. 从 SQLAlchemy 到微服务与大数据生态的扩展思考
最近有不少人在讨论“Python 应用怎么融入 Spring Cloud Alibaba 微服务体系”，我也在调研这类方案。单看 SQLAlchemy 的话，它本身不关心你前面的服务是 Java 还是 Python，重点在于它管理的是数据库层面。如果 Python 微服务要接入统一的注册中心、配置中心和网关，通常要做的中间层适配，SQLAlchemy 依然作为持久层的核心组件留用。因为它的会话管理、事务边界和模型定义都相对独立，不会因为你换了框架就受影响。这一点在做跨语言微服务协作时非常关键。
用量化交易场景举例，策略信号要高频写入 MySQL 或者 PostgreSQL，这时候 SQLAlchemy 的批量写入、事务回滚和异步能力就能发挥价值。你可以在一个服务里对行情数据做批量落盘，另一个服务里实时读取最新状态，中间层完全用 ORM 表达业务，底层连接池再按需扩充。我在一个模拟交易系统里，就是用 SQLAlchemy 统一管理订单表、持仓表和 K 线缓存表，单次批量写入上千条 K 线数据也能很快完成。
数据量继续膨胀后，很多人会考虑引入 ClickHouse、Elasticsearch 或者大数据组件。那时候 SQLAlchemy 不一定直接适合所有访问场景，但你仍然可以通过它管理业务系统的元数据，把需要分析的数据同步到其他存储引擎。ORM 不是银弹，但它能帮你把常规的 CRUD 和事务管理做得更规范，让精力集中到真正需要优化的地方去。
8. 一些值得坚持的实操心得
回到最开始的那个问题——“ORM 到底值不值得用”。我的答案很明确：值得，而且现代业务开发早就不该用手工拼 SQL 的方式维护数据库层了。但要用好 ORM，有几件事值得坚持：
- 不要排斥写原生 SQL。ORM 和 SQL 不是对立关系，而是互补关系。遇到复杂的 join、窗口函数，直接上原生 SQL 或 Core，没必要硬凑 ORM 语法。
- 模型设计要像设计数据库表一样严谨。该加的唯一约束、索引、外键，不要因为“ORM 会自动处理”就得过且过。模型字段类型、命名规则一旦上线，后期改动的成本很高。
- 对 Session 生命周期要有敬畏心。Session 不是普通工具类，它有状态、有连接资源，使用不当会拖垮整个应用。
- 性能调优从查询开始。每一条慢查询都有迹可循，ORM 生成的 SQL 可以打印出来检查，确认是否命中索引、是否产生了 N+1。
最后再分享一个小技巧。调试的时候我习惯给create_engine加上echo=True，这样 SQLAlchemy 会把所有 SQL 语句打印出来。刚开始觉得有点吵，后来发现这个习惯帮了大忙，特别是排查“为什么多了一条查询”这种问题，一眼就能看出是懒加载触发的。等确认无误后，再把echo关掉即可。
Python 的数据库操作会随着生态演进不断出现新工具，但 SQLAlchemy 这套核心思想——对象关系映射、会话管理、事务边界——是经得起时间考验的。把这一层基本功打扎实，后面不管遇到什么框架和存储方案，你都有足够的底气去应对。
