复合索引字段顺序影响查询性能，须按等值、范围、排序字段从前到后排列；动态创建需用list构造字段元组，设background=True并显式命名；sparse与unique选项需谨慎启用且不可在线修改。
复合索引字段顺序影响查询性能，不能随意排列
MongoDB 复合索引的字段顺序直接决定它能支持哪些查询模式。比如 {'status': 1, 'created_at': -1} 能高效服务 find({'status': 'active'}) 和 find({'status': 'active'}, {'sort': [('created_at', -1)]})，但对 find({'created_at': {'$gt': ...}}) 几乎无效。动态创建时，必须先明确查询高频路径，再按「等值字段在前、范围字段在后、排序字段靠右」原则排字段。
常见错误是把时间字段放最左——结果所有带 status 的查询都用不上这个索引。实际中建议用 explain('executionStats') 验证索引是否被命中。
用 create_index() 动态传入字段列表和选项
Python 驱动（pymongo）不支持 SQL 式字符串拼接建索引，必须构造合法的字段元组列表。动态场景下，推荐用变量组装：
fields = [('user_id', 1), ('category', 1), ('updated_at', -1)]
collection.create_index(fields, name='dynamic_compound_idx', background=True)
注意以下几点：
立即学习“Python免费学习笔记（深入）”；
让 macOS 自动化像说话一样简单 —— 用代码控制你的 Mac，无需学习 AppleScript 系统要求 macOS 14+ (Sonoma) Python 3.9+ 需要开启：辅助功能 + 屏幕录制权限
-
fields必须是list或tuple，每个元素为(field_name, direction)，direction只能是1（升序）、-1（降序）或pymongo.TEXT等特殊类型 -
background=True强烈建议加上，避免建索引阻塞线上读写（尤其大数据集） - 重复调用
create_index()不会报错，但也不会刷新已有索引；如需更新排序方向，得先drop_index() - 索引名（
name）最好显式指定，否则 pymongo 自动生成的名含字段哈希，难以识别和管理
避免在循环里反复调用 create_index()
有人写脚本批量为多个集合建同类索引，习惯在 for 循环里直接调用 create_index()。这会导致每次请求都走一次 MongoDB 的索引元数据检查，开销叠加明显。更稳妥的做法是：
- 先用
list_indexes()检查目标索引是否存在（比对key字段内容，而非仅靠名字） - 只对缺失的集合执行创建
- 若需跨多个数据库操作，确保连接复用，不要为每个库新建
MongoClient
特别注意：MongoDB 5.0+ 对同一集合上相同字段组合、不同方向的索引视为不同索引，比如 {a: 1, b: -1} 和 {a: 1, b: 1} 共存是允许的，但业务上通常只需其一。
复合索引与稀疏性、唯一性需按需开启
动态创建时容易忽略 sparse 和 unique 参数的实际影响：
-
sparse=True会让索引跳过所有字段为None或缺失的文档——适合高稀疏度字段（如可选的verified_at），但查询时{'verified_at': {'$exists': False}}无法利用该索引 -
unique=True要求组合值全局唯一，插入重复值会抛duplicate key错误；如果字段本身可能为空（None），MongoDB 把多个None视为相等，导致唯一约束意外失败 - 二者同时启用（
sparse=True, unique=True）可缓解空值冲突，但务必确认业务逻辑允许“空值不参与去重”
这些选项一旦设定就无法在线修改，后续调整必须删重建。生产环境上线前，最好在副本集的从节点上先验证索引构建行为和资源占用。
