IndexedDB索引是条件检索的硬性前提,必须在onupgradeneeded中随版本升级创建;命名需语义化唯一,支持嵌套路径与复合键;仅用于高频查询字段,避免冗余索引影响写入性能。

IndexedDB 的索引不是“锦上添花”,而是条件检索的硬性前提。没建索引,就只能靠主键查或全量遍历——后者在几十条数据时还凑合,上百条就开始卡顿,上千条基本不可用。
索引必须在 onupgradeneeded 中创建
索引不能事后添加,只能随数据库版本升级一并定义。版本号不变,这个事件根本不会触发。
- 首次打开数据库(version 为 1)→ 触发 onupgradeneeded → 可创建索引
- 想新增索引?必须把 version 改成 2 或更高 → 再次触发该事件 → 才能调用 createIndex()
- 已存在的索引不会被覆盖或删除,除非你在 onupgradeneeded 里显式调用 deleteIndex()
按查询需求选字段,命名要语义化
索引名是后续查询时的“钥匙”,必须唯一,且不能和对象仓库名重复。建议直接反映用途,比如:
- emailIndex:用于按邮箱精确查找
- statusTimeIndex:复合索引,支持先筛状态再按时间范围查
- tagsMultiIndex:带 multiEntry: true,适配数组字段如 ["urgent", "bug"]
字段路径(keyPath)支持嵌套写法,如 "profile.city" 或 ["status", "createdAt"],但务必确保数据中该路径始终存在、类型稳定。
用索引做真正高效的条件操作
建好索引后,所有高效动作都围绕它展开:
- 精确匹配:用 IDBKeyRange.only("active") + index.openCursor(),直接跳到目标位置
- 范围查询:IDBKeyRange.bound("2025-01-01", "2025-12-31") 查时间段,不遍历无关记录
- 排序输出:游标默认按索引键升序;加 { direction: "desc" } 即倒序,无需 JS sort()
- 分页基础:配合 cursor.continue(key) 跳过前 N 条,比手动计数更精准、更省资源
别盲目建索引,写入和空间都有代价
每多一个索引,add()/put() 就得多维护一份结构,写入变慢,存储也变大。
- 只给高频查询字段建索引,比如列表页总按 category 筛,那就建 category 索引
- 避免给 lastSeenAt、updatedAt 这类更新频繁但几乎不查的字段建索引
- 没有原生复合索引的“OR”能力,真要查 status IN ["draft","pending"],得分别查再合并结果
Java免费学习笔记:立即使用
解锁 Java 大师之旅:从入门到精通的终极指南











