IndexedDB与WebSQL相比非常慢，我做错了什么？

我做了一个演示chrome扩展来比较websql和indexeddb，并了解如何在更详细的工作。IndexedDB与WebSQL相比非常慢，我做错了什么？

令我惊讶的是，它表明，即使与最天真的sql命令相比，indexeddb也要慢很多。

由于websql已被弃用，赞成indexeddb我认为indexeddb将会比websql更快或更快。

我假设我在indexeddb代码中做错了什么。因为弃用速度更快的东西会很愚蠢，我认为他们知道他们在弃用websql时赞成使用indexeddb时所做的操作。

的SQL查询码：

// Search entries 
     var term = search_query; 
     db.transaction(function(tx) { 
      tx.executeSql('SELECT * FROM places', [], function (tx, results) { 
       console.log("sql search"); 
       var count = 0; 
       var wm = WordsMatch.init(term.trim().toLowerCase()); 
       var len = results.rows.length 
       for (var i = 0; i < len; ++i) { 
        var item = results.rows.item(i); 
        if (wm.search(item.url.toLowerCase())) { 
         //console.log(item.id, item.url); 
         ++count; 
        } 
       } 
       console.log("Search matches:", count); 
       console.log("\n"); 
      }); 
     }, reportError);

的IndexedDB的搜索代码：

PlacesStore.searchPlaces(search_query, function(places) { 
        console.log("indexedDB search"); 
        var count = places.length; 
        console.log("Search matches:", count); 
        console.log("\n"); 
       }); 

var PlacesStore = { searchPlaces: function (term, callback) { 
     var self = this, 
      txn = self.db.transaction([self.store_name], IDBTransaction.READ_ONLY), 
      places = [], 
      store = txn.objectStore(self.store_name); 
     var wm = WordsMatch.init(term.trim().toLowerCase()); 
     Utils.request(store.openCursor(), function (e) { 
      var cursor = e.target.result; 
      if (cursor) { 
       if (wm.search(cursor.value.url.toLowerCase())) { 
        places.push(cursor.value); 
       } 

       cursor.continue(); 
      } 
      else { 
       // we are done retrieving rows; invoke callback 
       callback(places); 
      } 
     }); 
    } 
}/**/ 


var Utils = { 
    errorHandler: function(cb) { 
     return function(e) { 
      if(cb) { 
       cb(e); 
      } else { 
       throw e; 
      } 
     }; 
    }, 

    request: function (req, callback, err_callback) { 
     if (callback) { 
      req.onsuccess = function (e) { 
       callback(e); 
      }; 
     } 
     req.onerror = Utils.errorHandler(err_callback); 
    } 
};

我也做了镀铬bug报告，并上载有完整的扩展代码： http://code.google.com/p/chromium/issues/detail?id=122831

（我不能在这里上传扩展zip文件，没有这个功能）

我填充了websql和indexeddb数据库，每个数据库都有38862个用作测试数据的URL。

来源

2012-04-11 user1309439

答：你没有做错什么。您的IndexedDB代码是正确的。至于结论，其他have found this to be true以及。

附加说明：需要注意的一点是，IndexedDB在不同浏览器之间的实现方式不同。 Firefox使用SQLLite和Chrome LevelDB，所以即使你在FF中使用IndexedDB，你仍然在使用SQL支持的技术以及类似SQL的开销（加上其他所有内容）。

我会很好奇在不同大小的数据库中看到您的结果。我希望，但还不能证实，IndexedDB可以在更大的数据集上扩展更好（尽管38862似乎足够大）。

来源

2012-04-11 17:48:02 buley

在哪个宇宙是38862一个“大”数据集？ – ocodo 2014-07-23 03:17:47

在客户端存储领域。 – buley 2014-07-27 00:59:32

问题的一部分是IndexedDB实现迄今为止大部分都在努力实现完整规范，并且不太关注性能。我们最近在Firefox中发现了一些非常愚蠢的错误，并且这些错误会让我们更快。

我知道铬团队由于其多进程架构而遭受了一些挑战。我被告知他们最近解决了一些这些问题。

所以我鼓励你尝试所有浏览器的最新版本，可能包括夜间/金丝雀版本。

但是请注意，我们并没有弃用WebSQL，因为IndexedDB速度更快。我们弃用WebSQL是因为它不是未来的证据。 WebSQL被定义为使用特定的SQLite后端（如果你看看它的实际写在那里的规格）。然而，所有的浏览器制造商都需要使用最新版本的SQLite来获取安全性，性能和稳定性修正。最新版本总是以微妙的方式更改SQL语法。这意味着我们会以微妙的方式打破WebSQL使用的Web应用程序。这对我们来说似乎并不合适。

来源

2012-06-15 23:30:40

很有意思！ – buley 2012-08-27 22:36:55

令人惊讶的是，只有Mozilla在SQLite中存在这个问题。 Android，iOS，Symbian和成千上万的其他开发者喜爱SQLite。 – 2012-10-06 06:59:04

chrome和firefox的indexeddb版本仍然很慢？ *相对 – 2012-10-10 05:05:33

IndexedDB与WebSQL相比非常慢，我做错了什么？

回答

相关问题