想要提升 IndexedDB 查询速度，核心在于精准创建索引，并配合正确的查询方式。应当只在 WHERE 条件中高频使用的字段上建立索引，优先使用以高选择性字段开头的复合索引。执行查询时，需要严格匹配索引结构，同时结合 readonly 事务与 IDBKeyRange 来进一步优化读取性能。
如果想让 IndexedDB 查询性能真正提升，重点其实只有两点：索引要建得合理，查询要写得准确。索引设计不合理，或者查询条件没有命中索引，即使数据量只有几千条，也可能出现明显卡顿，影响前端数据读取效率。
索引不是越多越好，而是要“按需创建”
IndexedDB 索引并非越多越有效。每增加一个索引，都会拖慢写入速度，同时占用更多存储空间。Mars 项目实测显示，索引过多会让新增一条记录的耗时增加 30% 以上。
- 只为真正用于 WHERE 条件 的字段建立索引，例如经常用于 filter、sort 或分页查询的字段
- 避免给低区分度字段单独建索引（如 status: "active"/"inactive"），这类字段独立索引命中价值低，优化效果有限，还会浪费资源
- 优先使用复合索引替代多个单字段索引——例如查询“城市+年龄区间”时，相比单独建立 city 和 age 索引，复合索引通常更高效
复合索引顺序很关键：高选择性字段应放在前面
复合索引并不是简单把多个字段拼接起来，它的字段顺序会直接影响 IndexedDB 查询是否能够高效命中索引。比如，['city', 'age'] 这样的顺序，既能高效支持“查询北京的用户”，也能支持“查询北京且年龄在 25-35 岁的用户”；但如果反过来写成 ['age', 'city']，那么仅按城市查询时就无法获得理想的加速效果。
- 所谓“高选择性”，就是字段取值越分散越好——通常用户ID > 城市 > 状态
- 如果查询里经常附带排序（如
ORDER BY timestamp DESC），可把该字段放在复合索引末尾，以减少额外排序开销 - 测试时可以通过
index.openCursor()+IDBKeyRange.bound()验证是否真正走了索引，而不要只凭经验判断
查询时必须“对号入座”：让条件精确匹配索引结构
建立索引并不代表查询一定会自动生效。IndexedDB 不会主动帮你重写查询逻辑，你编写的查询条件必须与索引键路径保持一致，才能触发索引扫描并提升查询效率。
- 使用
index.get()查询唯一值（如 email），使用index.getAll()查询重复值（如 userId） - 多条件查询应当使用
IDBKeyRange构造查询范围，例如：IDBKeyRange.bound([‘Beijing’, 20], [‘Beijing’, 35]) - 不要先
store.getAll()再用 JS 过滤——如果 10 万条数据先全部加载到内存再筛选，性能问题会立刻暴露出来
读操作尽量统一使用 readonly 事务，避免无谓性能损耗
只读事务不会加写锁，也不需要承担额外的一致性校验开销，因此执行速度通常更快，使用上也更安全。很多项目默认直接使用 readwrite，其实在大多数读取场景下完全没有必要。
- 凡是列表展示、详情查看、统计计数等读取场景，都应显式指定
'readonly' - 不要在同一个事务里混合读写操作；对于读多写少的应用，可拆分为两个并行事务以提升整体吞吐能力
- 注意：游标遍历本身不会阻塞 UI，但如果在 onsuccess 回调中执行大量同步计算，依然会导致页面卡顿——建议借助
setTimeout或queueMicrotask进行分片处理
