您正在使用具有“大”数据的数据库-即每个blob使用多个页面。
在接近最佳性能的某个时刻,您将达到无法提高的极限。
检查所有选择后,我看到了不同的行为,而不仅仅是不同的算法。
[1]只要您使用一项交易,这个速度就不会太慢。您需要一次执行两项 *** 作,即查询(获取blob大小)和删除。
[2]这是一个好方法。由于两个查询和一个删除都在一个命令中,因此SQLite引擎将进行优化。
[3]这是与以往不同的行为。与相同
DELETe FROM cache WHERe ts < (SELECt ts FROM cache ORDER BYts LIMIT 1 OFFSETcount)。查询比上一查询便宜,但是我敢打赌删除的行数比上一查询少得多!查询/删除的昂贵部分将被删除!查询优化很重要,但是删除总是会变慢。
[4]这是一个非常糟糕的方法!将所有数据复制到一个新表(可能是另一个数据库)中将非常昂贵。我只能从中得到一个好处:您可以将数据复制到新数据库中,避免使用
VACUUM,因为新数据库是从基础构建的,而且很干净。
关于
VACUUM…最糟的
DELETE是
VACUUM。不应在数据库中经常使用真空。我知道该算法应该“清理”您的数据库,但是清理不应是频繁的 *** 作-
数据库已针对选择/插入/删除/更新进行了优化-不能将所有数据保持在最小大小。
DELETE ... IN (SELECT...)根据预定义的标准,我的选择是使用单个 *** 作。
VACUUM不会被使用,至少不会经常使用。一个不错的选择是Monitor db size-
当该大小超出限制时,运行假定昂贵的清理 *** 作以修剪数据库。
最后,当使用多个命令时,请不要忘记使用事务!
欢迎分享,转载请注明来源:内存溢出
评论列表(0条)