IndexedDB object store 没有索引时怎么优化按字段查询

IndexedDB 的 IDBObjectStore 没有按字段建立二级索引时，最直接的优化不是把 getAll() 读出来后再用 JavaScript 过滤，而是升级数据库版本，在 onupgradeneeded 中调用 createIndex()，然后通过 store.index() 进入索引查询。这样查询条件会落在 status、updatedAt 等稳定字段上，只有需要的记录才进入结果处理。

如果一个字段会被反复用于筛选或排序，就为它建立命名索引；如果只是偶尔查询，先保留主键读取或小规模扫描，避免为了少量请求增加写入和迁移成本。

先确认慢点是全量扫描还是索引缺失

一个 object store 自带的是主键路径，例如 id；它并不会因为记录里存在 status 或 updatedAt 字段，就自动拥有这些字段的查询入口。直接调用 store.getAll() 再过滤，浏览器需要先复制全部匹配前的记录，数据越多，主线程上的对象处理和内存压力越明显。

先把查询字段分成两类：唯一定位字段适合主键或唯一索引，状态、租户、标签、时间等可能重复的字段应使用普通索引。IndexedDB 的索引可以保存 JavaScript 数据类型，但 keyPath 必须是有效键路径；数组字段还要明确是否需要 multiEntry。

在 onupgradeneeded 中升级并创建索引

已有数据库不能在普通业务查询中直接修改结构。打开数据库时把版本号从 1 提高到 2，浏览器触发 onupgradeneeded；已有 object store 要从升级事务中取出，再按名称检查并创建索引。

const request = indexedDB.open("notes-db", 2);

request.onupgradeneeded = (event) => {
  const db = event.target.result;
  // 旧数据库升级时复用已有仓库，不要重复 createObjectStore。
  const store = event.target.transaction.objectStore("notes");

  // 重复执行升级脚本时先检查名称，避免 ConstraintError。
  if (!store.indexNames.contains("statusIndex")) {
    store.createIndex("statusIndex", "status", { unique: false });
  }
  if (!store.indexNames.contains("updatedAtIndex")) {
    store.createIndex("updatedAtIndex", "updatedAt", { unique: false });
  }
};

request.onsuccess = (event) => {
  const db = event.target.result;
  // 业务结束后关闭连接，给后续版本升级留下机会。
  db.onversionchange = () => db.close();
};

这里的关键不是索引名称好不好看，而是 keyPath 与实际记录字段一致。statusIndex 的键路径是 status，所以之后只能用状态值进入这个索引。重复值并不冲突，因此状态字段不能误设为 unique: true；该选项适合邮箱、业务编号这类不允许重复的字段。

用 IDBIndex 和 IDBKeyRange 缩小读取范围

索引建好后，读取事务仍然要声明正确的 object store。精确筛选可以直接把值传给 getAll()；时间范围则用 IDBKeyRange.bound()，避免把所有年份的数据都交给 JavaScript 判断。

function findOpenNotes(db) {
  const tx = db.transaction("notes", "readonly");
  const store = tx.objectStore("notes");
  // 通过命名索引按 status 精确筛选，允许多个记录返回。
  return store.index("statusIndex").getAll("open");
}

function findNotesBetween(db, start, end) {
  const tx = db.transaction("notes", "readonly");
  const store = tx.objectStore("notes");
  const index = store.index("updatedAtIndex");
  // 业务数据统一使用可比较的数字或 ISO 日期键，范围才稳定。
  const range = IDBKeyRange.bound(start, end);
  return index.openCursor(range, "prev");
}

getAll() 适合结果数量可控的场景；当范围可能返回很多记录时，游标可以逐条消费并在达到页面大小后停止。store.index("missing") 会抛出找不到索引的异常，所以索引名称应由版本升级脚本集中维护，不要在查询函数里临时拼接。

检查索引代价与版本迁移边界

索引不是免费的缓存。每次新增或更新记录时，相关索引也要维护；索引越多，写入和升级成本越高。因此只给稳定、高频、能明显缩小结果集的字段建索引，展示用的临时组合条件不必全部落成索引。

• 数组字段需要“数组中的每个值都可查询”时再考虑 multiEntry: true，否则会把整个数组当成一个键。
• 打开旧页面连接时，升级可能被其他连接阻塞；处理 onblocked，并让旧连接响应 onversionchange 后关闭。
• 可选字段可能没有索引键，这些记录不会出现在该索引中；不要把“查不到”直接等同于记录不存在。
• 数据量很小时，主键读取后的小范围过滤更简单；不要为了理论上的索引命中增加无用迁移。

可以用 objectStore.indexNames 在调试信息中确认升级是否真的写入索引，但不要把开发环境的全量扫描结果当作生产性能结论。正式上线前应按真实字段分布、结果数量和写入频率决定索引组合。

相关问题

createIndex 为什么不能写在普通查询函数里？

它只能在 versionchange 事务中调用，通常就是 onupgradeneeded。查询函数属于普通读写事务，结构变更会触发 InvalidStateError。

status 索引需要设置 unique 吗？

通常不需要。多个笔记共享 open、closed 等状态是正常的，使用默认的 unique: false 即可。

有了索引还需要 IDBKeyRange 吗？

需要。索引负责提供字段入口，IDBKeyRange 负责描述等值之外的区间、上下界和复合条件范围。

索引查询没有返回所有旧记录怎么办？

检查旧记录是否真的包含对应 keyPath，以及数据库是否已完成版本升级。没有该字段的记录不会凭空生成索引键。

相关事实可对照 MDN 的 createIndex 说明、IDBObjectStore.index 说明 和 getAll 参考。