我遇到了大量插入（100.000 - 200.000条记录）的问题。我已经使用Dexie库解决了所有的IndexedDB性能问题。它有以下重要功能：
Dexie的性能非常出色。它的批量方法利用了indexedDB中一个不太知名的特性，该特性可以在不监听每个onsuccess事件的情况下存储内容。这将性能提升到了最大。
尺寸：https://github.com/dfahlander/Dexie.js

一些相当糟糕的IndexedDB性能问题可能是由于浏览器长时间只调用onsuccess回调，并在工作实际完成后运行到事件循环开销中造成的。我的应用观察到的性能模式是，它做了一堆工作，然后它只是非常低效地回答了数千个回调：

这张图片的右边部分是每个请求的回调。当然，解决这个问题的办法是不对每个请求都进行回调，但我以前不清楚如何做到这一点。
Dexie.js实现这一点的方法（详细信息请参见src/dbcore/dbcore-indexeddb.ts）是保存最后发送的请求（例如IDBObjectStore.put等），并在 * 那个请求 * 上设置一个onsuccess回调，然后从其余请求中收集结果，这样就避免了回调地狱。
另一种方法是使用IDBTransaction.oncomplete事件，完全不用担心单个请求的回调。
(note：是的，我知道这个问题有多老了，我今天遇到了这个问题，想为这个问题放一些更有用的东西，这在谷歌结果中很高）

你的数据是如何存储在indexeddb中的？所有的东西都在一个对象存储中吗？你是否使用多个对象存储？你是否立即需要所有缓存的数据？
如果您只有一个对象存储，您可以从存储最初需要的所有数据开始，提交该事务，然后为所有其余数据启动一个新的。这样，您可以在插入其余数据的同时开始检索初始数据。IndexedDB是异步的，因此它应该会阻止您。
如果您有多个对象存储，您可以使用相同的策略。首先填充您需要立即填充的对象存储，然后延迟其他对象存储。
或者可以考虑使用AppCache API而不是indexeddb API，使用它你可以只缓存一个javascript文件，其中包含你想要缓存的所有json对象，当你不需要对数据进行大量查询时，这种情况更常见。