问indexedDB与HTML5本地存储在概念上有何不同？

EN

与本地存储不同，IndexedDB不是键值存储。本地存储只存储字符串，所以要将对象放入本地存储，通常的方法是对其进行JSON.stringify：

myObject = {a: 1, b: 2, c: 3};
localStorage.setItem("uniq", JSON.stringify(myObject));

这对于查找带有键uniq的对象来说很好，但是从本地存储中获取myObject属性的唯一方法是对对象执行JSON.parse操作并检查它：

var myStorageObject = JSON.parse(localStorage.getItem("uniq"));
window.alert(myStorageObject.b);

如果您在本地存储中只有一个或几个对象，这是很好的。但是假设你有一千个对象，所有这些对象都有一个属性b，而你只想对那些b==2属性的对象做一些事情。使用本地存储时，您必须遍历整个存储并检查每个项目的b，这是大量浪费的处理。

使用IndexedDB，您可以存储stuff other than strings in the value：“这包括简单类型，如DOMString和Date，以及对象和数组实例。”不仅如此，您还可以对存储在值中的对象的属性执行create indexes操作。因此，使用IndexedDb，您可以将相同的数千个对象放入其中，但在b属性上创建一个索引，并使用该索引仅检索b==2所在位置的对象，而无需扫描存储中的每个对象。

至少这是我的想法。IndexedDB应用编程接口不是很直观。

它们似乎运行在进行异步调用的同一线程中。这怎么不会阻塞UI呢？

异步和多线程不是一回事，JavaScript, as a rule, is not multi-threaded。你在JS中做的任何繁重的处理都会阻塞UI，如果你想尽量减少UI阻塞，可以试试Web Workers。

indexedDB允许使用更大的存储空间。为什么不增加HTML5存储的大小呢？

因为，没有适当的索引，它会变得越来越慢，它变得越大。

我偶然看到了一篇很好的文章，讨论了localstorage与indexeddb的区别，以及其他可能的选择。

(以下所有值均以毫秒为单位)

https://nolanlawson.com/2015/09/29/indexeddb-websql-localstorage-what-blocks-the-dom/

​

​

从文章中总结(完全是作者的观点)，

1. 在Chrome、Firefox和Edge这三种浏览器中，LocalStorage在你写数据时都会完全阻塞DOM 2.这种阻塞比内存中的阻塞明显得多，因为浏览器实际上必须刷新到磁盘。
2. 并不奇怪，因为任何同步代码都是阻塞的，内存中的操作也是阻塞的。在长时间运行的插入过程中，DOM会阻塞，但除非你正在处理大量数据，否则你不太可能注意到，因为内存中的操作真的很快。
3. 在火狐和Chrome中，IndexedDB在基本的键值插入方面比LocalStorage慢，而且它仍然会阻塞DOM。在Chrome中，它也比WebSQL慢，后者会阻塞DOM，但没有那么多。只有在Edge和Safari中，spec.
4. IndexedDB才能在不中断UI的情况下在后台运行，更糟糕的是，这两个浏览器仅部分实现了IndexedDB web，在web worker中运行得很好，运行速度大致相同，但不会阻塞DOM。唯一的例外是Safari，它不支持worker内部的IndexedDB，但如果数据是简单和最小的

，它仍然不会阻塞UI.

• localmemory是理想的

除了robertc之外，indexedDB还知道“范围”，因此您可以搜索和检索所有以“ab”开头并以“abd”结尾的记录，以找到“abc”等。