IndexedDB写入操作是否真的支持并行执行？

核心结论 #

IndexedDB规范确实允许非重叠范围的readwrite事务并行，但主流浏览器的实际实现对同一个数据库的readwrite事务采用全局串行处理，这是你测试时无法实现并行的根本原因。

关键细节解释 #

• 规范中的"非重叠范围并行"是理想定义，但浏览器为了避免并发冲突、简化底层实现，对同一个数据库的所有readwrite事务强制执行串行队列——不管你操作的是不同对象仓库还是相同仓库，只要是同一个数据库的写事务，都会排队依次执行。这就导致你单独写一个仓库耗时3秒，同时写两个仓库时，第二个事务要等第一个完成才开始，总耗时约6秒。

• 你尝试的几种方案为什么没效果：

  • 直接写入/Web Worker写入：只要操作的是同一个数据库，就逃不开数据库级别的串行事务锁，Web Worker只是隔离了主线程，但IndexedDB的事务锁是跨线程生效的。
  • 单事务多仓库写入：单事务内部的所有操作本身就是串行执行的，相当于把两个仓库的写入任务放在同一个队列里，总时间自然是累加。
  • 写入不同数据库：理论上这个方案应该能实现并行，如果你的测试没生效，大概率是测试方法问题——比如没有同时启动两个数据库的写事务，或者计时逻辑没准确捕获并行执行的时间。

可行的优化方案 #

• 拆分到多个独立数据库：将需要并行写入的对象仓库分别放到不同的IndexedDB数据库中（比如db_store1、db_store2），每个数据库的写事务是完全独立的，浏览器会并行处理它们的写入操作。
• 批量写入优化：即使只能串行，也可以通过批量操作提升单仓库写入速度——比如将多条记录打包成数组，调用一次objectStore.put(recordsArray)，而不是循环调用单个put，能减少事务的IO开销，把单仓库写入时间从3秒压缩到更短。
• 控制事务粒度：避免在单个事务中执行过多操作，拆分多个小事务（但注意同一个数据库下还是串行，所以这个优化主要是提升响应性，不是并行）。

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