导读
在查看 Odoo 字段定义时，你可能会注意到字段声明里有个小东西：index=True。看上去像个默认选项，但它实际上会影响数据库检索的效率，尤其是在数据量很大时，能显著改善界面响应和搜索速度。
本指南围绕 Odoo 数据模型中的索引字段展开：解释它具体指的是什么，会如何改变数据库行为，以及在定制模块或审查实现时应何时启用。无论是开发新模块还是维护现有系统，理解索引的作用能帮助你做出更稳健的性能决策。
什么是 Odoo 中的索引字段？
在 Odoo 的 ORM 中，当字段定义包含 index=True 时，表示要求在该字段对应的数据库列上建立索引。安装或升级模块时，Odoo 会向 PostgreSQL 发出创建索引的指令。
下面用一句话概括常见的定义方式：在声明字段时加上 index=True，ORM 会负责把这层意图同步到底层数据库。
举例：在订单模型中常能看到类似的写法：reference = fields.Char(string='Reference', index=True)、state = fields.Selection([...], index=True)、以及像partner_id = fields.Many2one('res.partner', index=True)这样的外键字段，这些都是把数据库检索性能考虑进来的常见做法。
对最终用户而言，索引是“看不见”的优化。表单、列表或报表界面上并无任何标识提示该字段是否建立了索引——这是纯粹的数据库层面改进。
索引真正影响的是速度。在有索引的情况下，PostgreSQL 可以快速定位匹配的记录；没有索引时则需做全表扫描。随着表中行数从数千增长到数百万，索引带来的检索加速尤为明显。
哪些 Odoo 字段类型支持 index=True？
大多数标量类型字段都支持索引属性，常见包括：
- Char 与 Text 字段（文本类）
- Integer 与 Float 字段（数值类）
- Date 与 Datetime 字段（日期时间类）
- Selection 字段（枚举类）
- Many2one 关联字段（最常被索引的一类）
- Boolean 布尔字段
需要注意的是，One2many、Many2many 等关系型集合字段并没有对应的单一列来建立普通索引；同时未存储的计算字段也无法被索引，因为它们并不在数据库中占据列。
索引字段的工作原理
当 Odoo 初始化或升级模块时，会读取字段定义并同步数据库结构，对于标注了 index=True 的字段，Odoo 会向 PostgreSQL 发出建索引的 SQL。
默认情况下，PostgreSQL 使用 B-tree 索引，这是最通用的索引类型，适合等值比较（=）、范围查询（>、<、BETWEEN）和排序，大多数 Odoo 的筛选和域查询都能从中受益。
索引与 Odoo ORM 的交互方式
Odoo ORM 会把 Python 的域（domain）条件翻译成 SQL 语句。比如 [('state', '=', 'sale')] 会变成 WHERE state = 'sale'。如果 state 字段有索引，数据库就能利用索引快速定位匹配记录，而无需全表扫描。
Many2one 字段是最典型的应用场景之一：像订单里的 partner_id 存储的是关联对象的整数 ID，按客户过滤订单时 SQL 会带上 WHERE partner_id = X，若该列有索引，即使订单量很大也能迅速返回结果。
索引对写入性能的影响
索引并非免费的：每次插入、更新或删除记录时，PostgreSQL 都需要更新相关索引。因此索引越多，写操作开销越大。对于大多数 Odoo 场景，这种读写权衡是可接受的，但无需把每个字段都索引化。
index='trigram' 选项说明
在 Odoo 16 及以后，可以把 index 设置为字符串 'trigram'，此时会创建基于 pg_trgm 扩展的 GIN trigram 索引，专门加速 ILIKE 类型的模糊文本匹配，适合按部分字符串查找产品名或客户名等场景。
示例：name = fields.Char(string='Product Name', index='trigram')
这种索引常用于系统自带模块中，针对那些经常需按部分文本搜索的字段进行优化。
实际业务场景举例
下面列出几个常见的、在实际业务中能明显受益于索引的例子。
1. CRM：按销售负责人筛选线索
销售经理常按负责人划分销售漏斗。crm.lead 的 user_id 字段在 Odoo 中默认被索引，这保证了在几千甚至几万条线索下按负责人过滤仍能快速响应。自定义指向用户或团队的关联字段同理应考虑索引。
2. 销售：按订单状态查询
像 sale.order 的 state 字段通常被索引，这让筛选已确认订单或待发货订单在大批量业务中也能迅速加载。那些常被用作筛选条件的枚举型字段是索引的典型候选。
3. 库存：按产品追踪库存移动
在分销或制造型企业中，库存移动记录会迅速膨胀。把 product_id 索引，可以高效查询某件产品的所有动向，否则库存追溯类报表在繁忙仓库里会变得很慢。
4. 会计：按客户/供应商筛选分录
会计人员经常需要查看某个客户或供应商的账目。account.move.line 的 partner_id 索引让按往来方筛选在历史数据累积多年后依然能迅速返回结果。
5. 自定义模块：用于追踪的参考字段
在自建模块里，常会添加跨模型引用或外部系统编号等字段。如果这些字段将被频繁用于搜索或筛选，给它们加上 index=True 能在数据增长时保持查询性能。
如何创建或自定义索引字段
在 Python 中添加索引（自定义模块开发）
在 Python 模块里给字段加 index=True 非常直接：在声明字段时加上该关键字参数即可。
示例写法：from odoo import models, fields
class ProjectTask(models.Model):
_inherit = 'project.task'
x_external_ref = fields.Char(
string='External Reference',
index=True,
help='Reference number from the external system'
)
添加字段后，需要运行 odoo-bin -u your_module_name 或通过后台升级模块。升级过程会触发数据库同步并创建相应索引。
也可以通过继承并重写已有字段来为其添加索引，但这需要谨慎，避免影响原字段的其他行为或引发兼容性问题。
在 Odoo Studio 中的限制
Odoo Studio 允许非技术用户通过界面新增字段，但当前 Studio 并不直接提供开关来设置 index=True。Studio 创建的手工字段默认不会被标记为索引。
如果需要为 Studio 创建的字段加索引，最稳妥的做法是把该自定义项迁移为标准的 Python 模块，并在代码中加入 index=True；这通常需要开发人员配合完成。
直接在 PostgreSQL 中添加索引的场景
在某些情况下，例如需要在生产库上优化而不方便做模块升级，DBA 可以直接用 SQL 建索引以提升性能。
示例 SQL：CREATE INDEX CONCURRENTLY idx_sale_order_partner_id
ON sale_order (partner_id);
使用 CONCURRENTLY 可以在创建索引时避免长时间锁表，适合生产环境。但要注意，这种数据库层面的变更应与 Odoo 模块定义保持一致，否则未来模块升级时可能导致同步不一致。
最佳实践建议
优先为出现在搜索域中的字段建索引
凡是频繁出现在域过滤、视图筛选、自动化动作或计划任务中的字段，都是很好的索引候选。常见的有 Many2one 关联字段、状态字段以及各种代码/参考号字段。
遵循 Odoo 官方的约定
参考 Odoo 自带模块的字段定义是一个可靠的做法：查看 sale.order、account.move、stock.move 等模块，看看哪些字段被索引——这些选择基于大量真实生产环境的使用模式与性能数据。
对高流量模型始终索引 Many2one 字段
对于随时间累积大量记录的模型（如会计分录、库存移动、销售订单行），凡是用于过滤的 Many2one 字段几乎总是值得索引：写入时的额外开销通常能被显著的读取性能提升抵消。
对文本搜索考虑 trigram 索引
在 Odoo 16+ 环境下，如果用户经常在产品名、客户名或引用号中输入部分词串搜索，优先考虑使用 index='trigram'，因为它能显著加速 ILIKE 模糊匹配。
验证索引是否被实际使用
添加索引后，用 EXPLAIN ANALYZE 检查查询计划可以确认 PostgreSQL 是否利用了该索引。如果查询仍然选择顺序扫描，可能是表太小、统计信息未更新，或查询条件与索引类型不匹配。
把索引决策记录在案
在自定义模块中为字段加索引时，写一两句注释说明原因和使用场景，有助于未来的开发者理解初衷，避免在重构时误删关键索引。
常见误区与陷阱
不应默认给所有字段建索引
学习索引时常见的错误是“为了保险起见把每个字段都加上 index=True”。这是不明智的：索引占用存储并增加写入成本。在高并发写入的表上，不必要的索引会明显拖慢系统。
在小表上盲目索引没有收益
对只有几百条记录的小表，查询优化器通常会选择顺序扫描而非索引访问。为此类小型查找表或极少被填充的自定义模型创建索引，通常得不偿失。
添加 index=True 后忘记升级模块
仅在 Python 代码里加上 index=True 并不会自动在数据库创建索引——必须执行模块升级（-u module_name）或通过后台更新。忽略这一步是开发过程中常见的困惑来源。
误以为普通 B-tree 索引能加速任意 ILIKE 搜索
普通 B-tree 索引无法优化像 ILIKE '%关键字%' 这类前导通配符的查询。若需要对任意位置的子串匹配提速，应使用 index='trigram' 或考虑全文检索方案。
忽视可存储的计算字段
被设置为 store=True 的计算字段在数据库中有实际列，因此可以被索引。有时开发者忽略这点，错失对经常用于筛选的派生字段做索引以提升性能的机会。
总结
小结：index=True 是一个看似小的字段属性，但随着数据增长会对系统性能产生实实在在的影响。合理使用让搜索更快、视图更流畅；滥用则只会增加写入开销而无收益。
关键结论非常直接：为经常出现在域筛选里的字段建立索引，尤其是高流量模型上的 Many2one 关系字段；遵循 Odoo 自带模块的做法；避免在小表或从未用于筛选的字段上过度索引；在 Odoo 16+ 上对模糊文本搜索考虑 index='trigram'。
在项目初期就把索引策略规划好，比事后在生产环境里定位慢查询要容易得多。
正在进行 Odoo 实施项目？
关于我们：Dasolo 提供 Odoo 实施、定制与性能优化服务。无论是开发模块、提升现有实例性能，还是从零规划 Odoo 项目，我们都能提供落地的技术支持。
如果你遇到慢查询、复杂定制问题，或需要 Odoo 开发方面的最佳实践建议，我们可以协助诊断并提供解决方案。 欢迎联系 Dasolo 团队， 告诉我们你的项目需求与挑战。