在使用 Odoo 19 时，性能瓶颈很少源于“大型功能模块”，而多来自细微、反复出现的低效问题。其中最常见的元凶之一，就是 ORM 中的 N+1 查询问题。该问题隐蔽性强、极易引入，且会随着数据集增长悄然降低系统性能。
本文将详细讲解什么是 N+1 查询问题、其在 Odoo 中的产生原因，以及如何通过设计数据模型与编写代码来规避该问题。
理解 N+1 查询问题
N+1 问题的产生场景：
- 执行 1 条查询获取主记录；
- 再执行 N 条额外查询——每条主记录对应 1 条——来获取关联数据。
示例（存在问题的代码）
orders = self.env['sale.order'].search([]) for order in orders: print(order.partner_id.name)
表面上看这段代码完全正常。在简单场景下，Odoo ORM 的处理效果甚至比预期更好，但这仍是需要你理解的典型反模式。
Odoo 底层实际执行逻辑
Odoo ORM 内置预取缓存机制。当你在第一次循环中访问 partner_id 时，Odoo 会一次性批量获取当前记录集中所有记录的关联数据。因此，即便你有 1000 条销售订单——按常规逻辑会产生 1000 条单独的合作伙伴查询外加 1 条主查询——Odoo 也会通过批量处理将总查询数降至约 2 条。
但预取缓存会在以下几种常见场景中失效：
- 遍历经过筛选的子记录集 —— orders.filtered(...) 会生成更小的记录集，丢失原有预取上下文
- 在循环内重新浏览记录 —— 每次循环调用 self.env['res.partner'].browse(id) 会完全绕过缓存
- 链式访问深度嵌套关联字段 —— 跨多层级访问 order.partner_id.country_id.name 仍可能触发多次数据库交互
- 在循环内使用 sudo() 或 with_context() —— 这些方法会创建新的 ORM 环境，导致预取缓存失效
此时，N+1 问题就会成为生产环境中的真实性能隐患。
该问题在 Odoo ORM 中产生的原因
Odoo ORM 采用懒加载机制：
- 关联字段（多对一、一对多等）均为按需加载
- 若预取缓存被破坏，每次字段访问都可能触发独立查询
- 仅当以批量友好的方式访问字段时，预取机制才能高效运行
优化策略
策略 1：合理使用预取机制
使用 mapped() —— 这是符合 Odoo 规范、缓存安全的写法，可确保无论何种上下文都能实现批量获取。
优化写法
orders = self.env['sale.order'].search([])
partners = orders.mapped('partner_id.name')
原理
mapped() 会触发批量预取，Odoo 仅通过 1 条查询即可获取所有关联的合作伙伴数据。
策略 2：使用 read() 进行批量数据读取
若仅需原始数据（无需完整记录集对象），read() 速度更快，可避免 ORM 额外开销。
orders_data = self.env['sale.order'].search([]).read(['partner_id']) for data in orders_data: print(data['partner_id'])
该方式可减少：
- ORM 方法调用
- 重复的字段解析
非常适合无需使用记录集方法的只读操作场景。
策略 3：避免会触发查询的循环操作
常见反模式
for order in orders: total = sum(line.price_total for line in order.order_line)
该代码可能导致：
- 每条订单触发 1 条查询获取订单行数据
优化版本
orders.mapped('order_line.price_total')
或更优方案，通过单条批量查询获取所有订单行：
lines = self.env['sale.order.line'].search([
('order_id', 'in', orders.ids)
])
策略 4：使用 read_group 实现数据聚合
避免在 Python 循环中执行求和计算：
for order in orders: total = sum(line.price_total for line in order.order_line)
将计算逻辑交由 PostgreSQL 处理，使用 read_group()：
data = self.env['sale.order.line'].read_group(
[('order_id', 'in', orders.ids)],
['order_id', 'price_total:sum'],
['order_id']
)
该方式效率大幅提升——由数据库承担核心计算工作，而非 Python。
策略 5：适当时为计算字段设置 store=True
未设置 store=True 的计算字段，每次访问都会重新计算，极易引发 N+1 问题。
问题代码
total_amount = fields.Float(compute='_compute_total')
未存储时：
- 每条记录都会重新计算
- 可能触发多次查询
解决方案
total_amount = fields.Float( compute='_compute_total', store=True )
设置 store=True 后，字段值仅计算一次并存储至数据库，无需每次读取时重复计算。适用于无需实时动态计算的字段。
策略 6：批量处理业务逻辑
不良写法
for record in records: record._compute_something()
优化写法
def _compute_something(self):
for record in self:
...
更优方案
- 使用基于集合的逻辑
- 最小化单记录级别的查询
策略 7：通过 with_context 控制预取行为
部分场景下需要限制不必要的预取操作：
self.with_context(prefetch_fields=False)
谨慎使用：
- 处理超大数据集时可提升性能
- 误用会导致查询数量增加
策略 8：ORM 无法满足需求时使用原生 SQL
对于复杂报表或大数据量操作，ORM 抽象层可能成为性能瓶颈。此类场景下，原生 SQL 是最优选择：
self.env.cr.execute("""
SELECT order_id, SUM(price_total)
FROM sale_order_line
WHERE order_id = ANY(%s)
GROUP BY order_id
""", [orders.ids])
results = self.env.cr.fetchall()
适用场景：
- 优先追求性能而非抽象封装
- 处理 ORM 无法高效实现的大规模聚合操作
N+1 问题排查方法
启用 SQL 日志定位问题：
--log-level=debug_sql
重点关注：
- 重复执行的 SELECT 语句
- 循环中多次执行的相同查询
也可使用以下工具：
- Odoo 性能分析工具
- PostgreSQL EXPLAIN ANALYZE 分析查询执行计划
总结
N+1 查询问题是典型的“隐形隐患”。代码看起来整洁、测试通过、功能正常，但随着数据量增长，系统会突然变得卡顿。理解 Odoo ORM 预取缓存的工作原理，尤其是其失效场景，能让你编写的代码在任意数据规模下保持高效。
本文介绍的优化策略并非临时补救或技巧，而是使用 Odoo ORM 的正确方式：以记录集思维替代循环思维，将计算逻辑交由 PostgreSQL 处理，并有意识地控制关联数据的获取方式与时机。持续应用这些模式，你的 Odoo 模块将始终保持高性能、可维护性，且适配生产环境——无论数据规模增长到何种程度。
