高性能关键在连接复用、事务粒度和查询构造：避免 orm 全量加载，用 yield_per、values() 优化读取；批量写入改用 bulk_insert_mappings 或原生 sql；delete 需显式控制级联并确认 innodb 引擎；连接池须调优 pool_size、pre_ping 和 recycle。
直接用 SQLAlchemy 的 BaseCRUD 封装是可行的，但「高性能」的关键不在框架选型，而在连接复用、事务粒度和查询构造方式——尤其当你要支撑 FastAPI 接口或 pandas 批量分析时，db.get() 和 db.query().filter().all() 这类默认写法很容易成为瓶颈。
为什么不能直接用 session.query(Model).filter(...).all()？
这个写法看似简洁，但每调一次都触发完整 ORM 加载：字段反序列化、关系预加载（哪怕没声明）、实例化开销。对单条记录还好，批量查 1000 行时，内存和 CPU 消耗会翻倍。
- 避免
query.all()，改用query.yield_per(100)流式读取，尤其适合导出或 ETL 场景 - 查列表时优先用
query.values()或query.with_entities()，只取需要的列，跳过 ORM 实例化 - 不要在
get_multi里默认加order_by，排序字段缺失或索引不匹配时，MySQL 会全表扫描
如何让 create() 和 update() 真正支持高并发写入？
create() 方法里用 self.model(**data) 解包初始化没问题，但要注意两个隐性陷阱：一是 MySQL 的 INSERT ... ON DUPLICATE KEY UPDATE 场景无法覆盖；二是批量插入时，session.add() + commit() 是单条提交，吞吐极低。
- 对幂等写入，改用
session.execute(text("INSERT ... ON DUPLICATE KEY UPDATE ..."))，绕过 ORM 层 - 批量创建必须用
session.bulk_insert_mappings()或session.execute(insert(...).values([...]))，比循环 add 快 5–10 倍 -
update()中若传入的是 dict，别直接setattr(obj, k, v)，而应先session.refresh(obj)再赋值，否则脏数据可能被忽略
delete() 容易被忽略的事务与级联风险
很多封装把 delete() 写成 session.delete(obj); session.commit()，这在 FastAPI 的依赖注入里极易出错——因为 session 生命周期由依赖管理，手动 commit 可能干扰外层事务。
- 删单条记录时，用
session.get(Model, id)先查再删，避免session.delete(None)报错 - 涉及关联删除（如用户连带订单），不要靠 ORM 的
cascade="all, delete-orphan"自动处理，而应在 service 层显式控制顺序，并用session.execute(delete(Order).where(Order.user_id == user_id))绕过对象加载 - 物理删除前务必确认表引擎是 InnoDB，MyISAM 不支持事务回滚，
rollback()无效
最常被跳过的点：连接池配置。哪怕 CRUD 类写得再漂亮，如果 create_engine(..., pool_size=5, max_overflow=10) 没调优，高峰期照样连接超时。特别是用在 FastAPI 时，要配合 pool_pre_ping=True 和 pool_recycle=3600 防僵死连接。
Python免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 Python 的核心概念和高级技巧！
