应合理使用ORM，通过预加载、批量操作、索引优化、原生SQL、连接池调优及分层缓存提升性能。避免N+1查询，优先selectinload；写多场景用原生SQL；连接池设为并发量1.5–2倍；高频低更数据缓存至Redis。
用ORM简化数据库操作，但别让它拖慢你的程序
SQLAlchemy 或 Django ORM 让 Python 操作数据库变得直观，但默认配置常带来隐式 N+1 查询、过度加载、事务不明确等问题。关键不是不用 ORM，而是清楚它在做什么。
比如查询用户及其订单时，写 user.orders 看似简洁，但若没预加载，每访问一个用户就触发一次订单查询——100 个用户就是 101 次 SQL。用 joinedload 或 selectinload 显式声明关联加载策略，能一步查出全部数据。
- 对一对多关系，优先用
selectinload（发一条 IN 查询），比joinedload更少冗余数据 - 避免在循环里调用
.save()或.query.get()，批量操作改用bulk_insert_mappings或原生executemany - 读多写少场景，给常用查询字段加数据库索引；用
EXPLAIN验证 ORM 生成的 SQL 是否命中索引
该放手时就写原生 SQL：性能瓶颈处不硬扛 ORM
复杂聚合、窗口函数、跨表更新或大批量数据迁移，ORM 表达力有限且易生成低效语句。这时直接写 SQL 反而更清晰、更快、更可控。
SQLAlchemy 提供 text() 和 connection.execute() 安全执行原生语句，支持参数化防止注入。Django 则可用 raw() 或 cursor.execute()。
立即学习“Python免费学习笔记（深入）”；
- 统计报表类查询，用 CTE 或子查询优化逻辑，避免 Python 层拼接大量数据
- 更新上万行记录时，避免 ORM 逐条实例化——用
UPDATE ... WHERE一行搞定 - 临时表、物化视图、存储过程等高级功能，原生 SQL 是唯一选择
连接与事务：小配置，大影响
数据库连接池大小、超时设置、自动提交开关，直接影响并发能力和数据一致性。默认配置往往不适合生产负载。
- 连接池
pool_size建议设为应用并发请求数的 1.5–2 倍，避免排队等待；max_overflow留 10–20 应对突发 - 显式控制事务：用
session.begin()+commit()/rollback()，别依赖自动提交；长事务及时提交，减少锁持有时间 - 读操作尽量用
READ COMMITTED隔离级别，写操作才升级；高并发更新场景考虑SELECT FOR UPDATE配合重试逻辑
缓存不是银弹，但用对地方很管用
数据库是系统瓶颈？先确认是不是重复查相同数据。ORM 层缓存（如 SQLAlchemy 的 Query.set_cache）作用有限，更推荐在合适层级加缓存。
- 高频、低更新的维度表（如省份、状态字典），查完存 Redis，过期时间设合理（如 1 小时）
- 接口级缓存：用
@cache_page（Django）或flask-caching缓存整个响应，注意区分用户上下文 - 慎缓存带 JOIN 或聚合的结果——数据一致性难保障；缓存失效策略要明确，比如订单更新后清对应用户缓存
