使用dexie.js操作IndexedDB时UPSERT性能低下问题排查

核心结论 #

你测得的性能数据明显不符合预期——对于仅50条记录的IndexedDB表，基于主键的单条查询、更新/插入操作都应该在几毫秒内完成，不管使用Dexie.js还是原生IndexedDB API。

性能瓶颈分析 #

你的代码存在一个关键问题：get和后续的add/update操作是两个独立的事务。IndexedDB的事务本身有启动和提交的开销，分开执行两次操作会重复产生这些开销，这是导致耗时偏高的主要原因。

另外，你对比原生API的测试结果显示Dexie有明显开销，这是封装库的正常特性（Dexie会做Promise包装、类型处理、错误兼容等额外工作），但正常情况下这个开销应该在10ms以内，你测得的差距过大可能和Dexie版本过旧、浏览器缓存状态或其他并发事务干扰有关。

优化方案 #

1. 将操作合并到单个事务中 #

使用Dexie的事务API，把get和写操作放在同一个读写事务里，消除重复的事务开销：

async updateFavorite(showId: number) {
  const t1 = performance.now();
  // 开启读写事务，指定操作的表
  await this.transaction('rw', this.shows, async () => {
    const found = await this.shows.get(showId);
    const t2 = performance.now();
    if (found) {
      await this.shows.update(showId, { favorite: !found.favorite });
    } else {
      await this.shows.add({ id: showId, favorite: true });
    }
    const t3 = performance.now();
    console.log(`GET query took ${t2 - t1}ms`);
    console.log(`Write operation took ${t3 - t2}ms`);
  });
}

2. 简化代码逻辑（可选） #

如果不需要先读取数据的其他字段，可以用modify方法简化更新逻辑，同时保持事务原子性：

async updateFavorite(showId: number) {
  const t1 = performance.now();
  const found = await this.shows.get(showId);
  const t2 = performance.now();
  if (found) {
    // 直接修改目标字段
    await this.shows.modify(show => show.favorite = !show.favorite, showId);
  } else {
    await this.shows.add({ id: showId, favorite: true });
  }
  const t3 = performance.now();
  console.log(`GET: ${t2 - t1}ms, Write: ${t3 - t2}ms`);
}

3. 其他优化建议 #

• 升级Dexie.js到最新版本：新版本通常会有性能优化和Bug修复，能缩小与原生API的性能差距。
• 排除测试干扰：循环测试时，排除前几次的预热开销（比如跳过前10次，取后90次的平均值），避免初始化成本影响结果。
• 检查浏览器存储状态：在开发者工具的Application标签中查看IndexedDB的存储情况，确认没有冗余数据或异常占用。

补充说明 #

即使使用Dexie，在优化后单条操作的耗时应该能降到10ms以内，和原生API的差距会大幅缩小。如果优化后性能仍无改善，建议排查是否有其他代码在占用IndexedDB连接（比如并发的事务操作）。

内容的提问来源于stack exchange，提问作者vixducis