大家的的places.sqlite有多大

我的FF，用了半年，经过手工清理，现在的places.sqlite大小大概为1M。。。

清除所有记录，再用工具压缩一下places.sqlite（就是去除不用的记录），我的只有 300KB 不到。

我写了一个SQL语句，删除一个月以前的所有历史记录，只保存这一个月以来的记录。。然后再进行vacuum压缩。。。呵呵，还保存了书签上的小图标。。。。要是全部记录都删除，肯定也能减小很多空间，300k左右，有没有保存网站的小图标？？？？若没有保存，那就没什么意思了哟。。。

在此推荐一个管理places的好扩展：sqlite manager。有了它之后，你就可以自己编写SQL语句，然后手动清理places了，想怎么整理就怎么整理。。。。


我想改进placescleaner的功能，它没有删除多少天之前的所有历史记录的功能，我想自己添加上去。原因有二：最近的历史记录才比较有价值，太久的历史记录一般都是无关紧要的；删除0天之前的所有历史记录，就等于将所有历史记录清空，适应于一些想隐藏自己足迹的人。

若扩展写好后，不知道到哪里提交。。。GOLF—AT大牛，请赐教一二。

扩展可以直接到 Mozilla 的官方网站提交啊，需要先注册一个用户。英文       中文
右上角有一个按钮“开发者工具”（英文是Developer Tools），点击进入，左边有一个按钮“提交附加组件”（英文是 Submit Add-on）就可以提交扩展了。

书签上的小图标肯定是不删除的。也许是我的书签不是很多吧。删除全部历史记录再压缩，我的只有300KB左右。有些网友的历史记录很大，从来不整理places.sqlite，有次有个人说他的这个文件有200MB

>>我想改进placescleaner的功能，它没有删除多少天之前的所有历史记录的功能
这个是Firefox自己就能做的事情：在选项里把保留天数缩短，则关闭时会把之前的历史记录给挤出去

>>删除一个月以前的所有历史记录，只保存这一个月以来的记录
同理，这个只要设30天就行了


我减肥后从15MB到3MB，书签数目有1200条左右。

kmc：>>我想改进placescleaner的功能，它没有删除多少天之前的所有历史记录的功能
这个是Firefox自己就能做的事情：在选项里把保留天数缩短，则关闭时会把之前的历史记录给挤出去

>>删除一个月以前的所有历史记录，只保存这一个月以来的记录
同理，这个只要设30天就行了


我减肥后从15MB到3MB，书签数目有1200条左右。回到原帖

在选项里把至少保留天数缩短，貌似是不行的，把它改成1，结果重启后还显示上个月的历史记录。。。因为受到下面算法的约束：

Preferences

    * browser.history_expire_days: The maximum number of days kept in history. Default is 180 days.
    * browser.history_expire_days_min: The minimum number of days kept in history. Default is 90 days.
    * browser.history_expire_sites: The maximum number of unique URLs kept in history. Default is 40,000.

Algorithm

History visits are expired using the following criteria:

    * Has a visit date older than browser.history_expire_days ago, or browser.history_expire_days_min, if the latter value is bigger.
    * Has a visit date older than browser.history_expire_days_min ago, if we have more than browser.history_expire_sites unique urls.

选项里“至少保留天数”修改的是browser.history_expire_days_min的值，是为了保护历史记录，而不是为了删除历史记录。。。

刚刚又删除了5000条历史记录，places的大小减少了500K。
可见，1万条历史记录，将会使places的大小增加1M。

某些人的历史记录若达到200万条，places的大小达到200M并不为奇。
一天访问几千条，一年就足以达到200万条，呵呵。。。。大家一起向这个宏伟目标前进

shenyixin99：刚刚又删除了5000条历史记录，places的大小减少了500K。
可见，1万条历史记录，将会使places的大小增加1M。

某些人的历史记录若达到200万条，places的大小达到200M并不为奇。
一天访问几千条，一年就足以达到200万条，呵呵。。。。大家一起向这个宏伟目标前进 回到原帖

默认值不是90天吗？

默认值是180天，呵呵，也就是半年，那一起向100M的目标前进吧，

12.6M
不用刻意去减小places.sqlite的大小也可以很快的
http://mozillalinks.org/wp/2009/08/vacu ... o-restart/

上面的链接好像也是执行VACUUM这条指令，只不过不用重启而已。。。看来有空要对VACUUM这条指令进行研究，不知道它的详细原理是怎样的。。。。

Vacuuming and zero-fill

Sqlite has a VACUUM command to compress unused space from the database. Sqlite works like a memory manager or a file system. When data is deleted, the associated bytes are marked as free but are not removed from the file. This means that the file will not shrink, and some data may still be visible in the file. The way to work around this is to run the VACUUM command to remove this space.

Vacuuming is very slow. The vacuum command is essentially the same as the command line sqlite3 olddb .dump | sqlite3 newdb; mv newdb olddb. On some networked drives, vacuuming a 10MB database has been timed at over one minute. Therefore, you should avoid vacuuming whenever possible.

Some items in databases are privacy sensitive, such as deleted history items. Users have the expectation that deleting items in their history will remove the traces of that from the database. As a result, Mozilla enables the SQLITE_SECURE_DELETE preprocessor flag in db/sqlite3/src/Makefile.in . This flag causes deleted items to be filled with 0s on disk. This eliminates the need to vacuum except to reclaim disk space, and makes many operations much faster.

Zero-filling can have significant performance overhead in some situations. For example, the history service used to delete many database items at shutdown when expiring old history items. This operation is not necessarily slow, but writing 0s to disk in an "ACI" database is still slow. This made shutdown very slow because the AsyncIO thread would block shutdown ( bug 328598). Shutdown times of more than 30 seconds were seen. As a result, this bug introduced incremental history expiration eliminating the need to write many 0s to disk on shutdown.

Unfortunately, this operation cannot be controlled on a per-transaction or per-connection basis. Some operations will benefit, while others will be hurt.


由此看来，加快启动速度的同时，可能会导致关闭速度的减慢。。。。若想要提高启动速度的同时，也提高关闭速度，最好的办法就是采用FF的默认配置，然后每隔一段时间（最好一个月左右）自己清理一下数据库。使得启动的时候不会读取太多的数据，关闭的时候不会写入太多的数据。。。。

我的只有344K,安装好第一次运行我就设置历史记录为1天.

252KB