我有一个场景，最初使用 Web 应用程序可能需要下载大约 2K 记录并将其存储在 IndexedDB 中以供离线使用。在我的测试中，一旦所有记录都被加载和索引，性能似乎很快。但是，有一段时间它显然是索引并且在那段时间没有响应。这是可以理解的，但是有没有办法找出 IndexedDB 是否“正在索引”或某种程度？我似乎在 IndexedDB 文档中找不到任何内容。如果他们意识到这一点，这样的事情会提供更好的用户体验。
【问题讨论】：
标签： javascript performance indexing indexeddb offline-caching
规范中确实没有关于能够观察索引的内容；它打算在幕后发生，并且只有在完成时才能观察到（例如，如果事务由于现有数据中的键约束错误而提交或中止）。如果您在创建新索引时发现特定浏览器变得无响应，您应该针对浏览器提交错误。
至少在 Chrome 中，createIndex() 调用应该是“即时的”，并且在后台通过遍历对象存储中的值以计算索引条目来异步填充索引。这发生在调用 createIndex() 的同一进程和线程中，因此将与同一线程上的其他活动竞争（例如，如果我们没有适当地确定工作的优先级，您可能会看到动画变慢）。
【讨论】：
您使用的是同步 API 还是异步 API？如果是异步的，它可能不应该冻结浏览器。也许你可以添加一个超时事件，比如每 100 毫秒输出一次。如果它的执行时间超过 100 毫秒，那么您的浏览器可能正忙于处理索引。
【讨论】：
这里有同样的问题。只使用铬。不知道其他浏览器。
很好，直到我开始创建索引。然后缓慢爬行。当我通过开发人员工具-> 应用程序选项卡清除 indexeddb 时，轻松重复。并刷新页面。
就我而言，我需要添加一些“承诺”逻辑，以获得更多“异步”逻辑与直接同步。并在其中分解每个“存储”创建/“索引”创建/初始将数据添加到各个存储到它们自己的承诺逻辑中。我想说 www.promisesjs.com 可能值得一读。
我试图远离各种打包的脚本。但是他们中的一些人在使用他们的“bulkadd”功能时有一些更好的“bulkadd”而不是“add”，并带有提高性能的声明。 pouchdb、localforge、db.js、dexie.js、骨干？、书架？是我想到的一些打包脚本。警告之前：一些打包的脚本有自己的承诺，比如内置的逻辑。如果您使用或不使用内置的承诺逻辑，可能会出现问题。
注意：其他数据库上的 sql 会因突然大量添加或转储数据而陷入爬网，indexeddb 也不例外。一旦您因为缺少更好的短语而克服了最初的“安装滞后”。一切都应该顺利进行。或者更少您的应用程序本身是 CPU 密集型的。现在我想起来了，大多数带有数据转储/导出和/或导入的 sql 数据库都内置了超时脚本。由于大型数据库表可能需要大量时间。
【讨论】：