firefox会定期优化数据库的，一般不需要什么软件压缩，而且这些软件都已经比较旧，可能对较新版本的sqlite数据库造成坏的影响，反效果。

10MB是预占空间，现在places.sqlite文件大小只会是10MB的整数倍，目的是减少磁盘碎片

别说什么用全新配置！如果系统正常重启系统还是不行的话就重新捣鼓吧是王道！把火狐觉得要备份的先备份一下，在我的足迹里导出书签到HTML的bookmarks再备一份，然后用卸载程序彻底删除火狐Firefox所有的，重启系统后把火狐在系统盘C盘里面两份隐藏的（先打开）Mozilla文件夹也删除如果卸载不彻底有的话（一定要找找看有木有），然后重新全新安装Firefox可以原路径，安装好后看看简单设置一下，由于楼主折腾的是书签就打开我的足迹导入恢复备份的HTML的bookmarks书签即可算第一步完成了（可以备份一份配置Mozilla文件夹），第二部就先重复你上面关心出现的问题就慢慢捣鼓书签吧不要压缩（全新安装的Firefox浏览器places.sqlite默认的貌似现在就是10M），觉得正常了再一步步有序重新全新安装其他的东西扩展什么的（不要用备份来恢复那只是以防万一而已要全新重新一个个安装），顺带在注意观察你关心的书签如果出现问题就容易发现了同时做好即时配置文件夹Mozilla文件夹的整个备份以便出问题可以从全新这样备份的开始复制后节约时间继续捣鼓折腾。没有比这更加干净的方法了，没有，没有……。

teredarguiterep：places.sqlite-shm、places.sqlite-wal  不会消失无关重要，因为在firefox启动时，其内容也会合并。回到原帖

我知道啊
但是这2个在firefox退出时没有被删除
就表示哪里有错误导致而没有正确关闭sqlite connection
只是数据不丢失所以大部分人都不在乎而已

aaaa007cn：https://bugzilla.mozilla.org/show_bug.cgi?id=686237
看起来是从34.0转async开始重现的回到原帖

places.sqlite-shm、places.sqlite-wal  不会消失无关重要，因为在firefox启动时，其内容也会合并。

lonely_8：这两个文件是SQLite 3.7某个版本后的特性，不是FF的问题。
我“退出”(三道杠菜单上面的)FF后，这两个文件也没删除。
但其它的数据库的却删除了。
我猜想是FF故意为之吧？

我备份时都用speedyfox这软件“优化”后...回到原帖

看上面贴的那堆文本
wal(.sqlite-wal)和shared-memory file(.sqlite-shm)会在Checkpoint操作后被合并进.sqlite文件

如果firefox没有做特别设置
在firefox退出时
正确关闭最后一个到sqlite的connection会自动引发一次checkpoint操作并删除wal和shm
从之前的版本来看
firefox不应该有做过特别设置

不清楚speedyfox是怎么处理的
但是要备份
可以连同wal和shm一起备份
或者手动对sqlite进行操作（比如你说的VACUUM）并正确退出
就会引发之前说讲的checkpoint

https://bugzilla.mozilla.org/show_bug.cgi?id=686237
看起来是从34.0转async开始重现的

https://www.sqlite.org/wal.html

By default, SQLite does a checkpoint automatically when the WAL file reaches a threshold size of 1000 pages. (The SQLITE_DEFAULT_WAL_AUTOCHECKPOINT compile-time option can be used to specify a different default.) Applications using WAL do not have to do anything in order to for these checkpoints to occur. But if they want to, applications can adjust the automatic checkpoint threshold. Or they can turn off the automatic checkpoints and run checkpoints during idle moments or in a separate thread or process.

Automatic Checkpoint
By default, SQLite will automatically checkpoint whenever a COMMIT occurs that causes the WAL file to be 1000 pages or more in size, or when the last database connection on a database file closes. The default configuration is intended to work well for most applications. But programs that want more control can force a checkpoint using the wal_checkpoint pragma or by calling the sqlite3_wal_checkpoint() C interface. The automatic checkpoint threshold can be changed or automatic checkpointing can be completely disabled using the wal_autocheckpoint pragma or by calling the sqlite3_wal_autocheckpoint() C interface. A program can also use sqlite3_wal_hook() to register a callback to be invoked whenever any transaction commits to the WAL. This callback can then invoke sqlite3_wal_checkpoint() or sqlite3_wal_checkpoint_v2() based on whatever criteria it thinks is appropriate. (The automatic checkpoint mechanism is implemented as a simple wrapper around sqlite3_wal_hook().)

In normal cases, new content is appended to the WAL file until the WAL file accumulates about 1000 pages (and is thus about 4MB in size) at which point a checkpoint is automatically run and the WAL file is recycled. The checkpoint does not normally truncate the WAL file (unless the journal_size_limit pragma is set). Instead, it merely causes SQLite to start overwriting the WAL file from the beginning. This is done because it is normally faster to overwrite an existing file than to append. When the last connection to a database closes, that connection does one last checkpoint and then deletes the WAL and its associated shared-memory file, to clean up the disk.

dsznyrvzn：我备份的places.sqlite是我从用火狐时就有的文件，每次用SQLite Manager压缩一下。我想是不是places.sqlite太老了。它压缩后只有几百k，而新建配置后的places.sqlite有10M。我发现我用的place...回到原帖

可能也有这方面的原因，中间跨版本太大了。
我的places.sqlite文件是从FF3.4时代沿用到现在的nightly40，
但一切正常，可能是一个个版本升级上来的原因吧。