IndexedDB高效查询需用复合索引而非多个单索引叠加，因游标仅支持单索引扫描；复合索引字段顺序决定查询能力，高区分度字段应前置，冗余索引应避免。
IndexedDB 支持多重索引（即复合索引），但直接“用多个索引同时查”并不等于性能提升——反而容易踩坑。真正高效的方式，是把高频联合查询条件合并成一个复合索引，而非依赖多个单字段索引的叠加使用。
为什么“多重索引”不等于“多索引一起用”
IndexedDB 的游标只能基于一个索引打开，无法像 SQL 那样自动组合两个独立索引（如 WHERE status = 'active' AND type = 'image'）。如果只建了 status 和 type 两个单字段索引，浏览器仍需全表扫描或回表过滤，性能不会改善。
- 复合索引
['status', 'type']可直接定位到匹配的键范围，复杂度接近 O(log n) - 两个单索引分别查再取交集，需多次 I/O + 内存过滤，实际是 O(n) 行为
- 浏览器不会自动优化“索引合并”，这完全由开发者建模决定
复合索引的设计原则
顺序决定能力边界：复合索引字段的排列顺序直接影响可支持的查询模式。
- 索引
['userId', 'timestamp']支持：
– 精确查某用户所有记录
– 查某用户某时间之后的记录（IDBKeyRange.lowerBound(['user_123', 1625097600000])）
– 但不支持仅按timestamp查询（前导字段缺失） - 高区分度字段放前面：比如
['tenantId', 'userId']比['userId', 'tenantId']更适合多租户场景，因 tenantId 值更少、分片更粗 - 避免冗余索引：已有
['a', 'b', 'c']，就不必再单独建['a', 'b']（除非查询频率极高且数据量极大）
真实场景中的典型错误与修复
以消息列表为例，原始结构：
{ id: 'msg_001', userId: 'u100', status: 'sent', timestamp: 1718000000000, content: '...' }
-
错误做法：分别建
userId、status、timestamp三个单索引，然后在 JS 中 getAll() 后用 filter 筛选 -
低效做法：用
userId索引查出全部记录，再内存里按status和timestamp过滤 -
推荐做法：建复合索引
['userId', 'status', 'timestamp']，再用 keyRange 精准限定
查询“用户 u100 已发送的最近 20 条消息”只需：
const range = IDBKeyRange.bound( ['u100', 'sent', 0], ['u100', 'sent', Date.now()], true, true ); index.openCursor(range, 'prev').onsuccess = ...
当必须跨维度查询时的替代方案
若业务确实需要灵活组合（如“查所有未读的图片消息”，但 read 和 type 分属不同查询路径），可考虑：
- 增加 denormalized 字段：如加一个
read_type字段，值为'unread_image'，并为其建索引 - 拆分对象存储：将不同类型消息存入不同 store（如
messages_text、messages_image），降低单 store 数据密度 - 引入轻量倒排：对关键词类字段（如标签、分类）用数组索引（
multientry: true），但注意写入开销上升
