说了这么多，没进主题，我的主题是给Sqlite在删除数据后擦屁股。
大家或许发现了，当你在sqlite中删除了大量数据后，数据库文件的大小还是那样，没有变。
就用我的项目来说，3M的数据删除后，sqlite的.db文件依然是3M，而我要的结果实际上只有35K，在压缩一下也就10几K了。为什么会出现这个问题，SqlCe的.sdf文件是即删即减的。
原因是：
当你从Sqlite删除数据后，未使用的磁盘空间被添加到一个内在的”空闲列表”中用于存储你下次插入的数据。磁盘空间并没有丢失。但是也不向操作系统返回磁盘空间。（嘿嘿，Sqlite.org的FAQ中提到过这个问题）
解决方法：两种
一，在数据删除后，手动执行VACUUM命令，执行方式很简单
objSQLHelper.ExecuteNonQuery(CommandType.Text,"VACUUM")
VACUUM命令会清空“空闲列表”，把数据库尺寸压缩到最小。但是要耗费一些时间。
FQA里面说，在Linux的环境下，大约0.5秒/M。并且要使用两倍于数据库文件的空间。
我憎恨此FQA，他只说系统环境，不说机器硬件环境。我在测试手机上执行用了将近13秒时间压缩了将近3M的空间。至于它所占用的另一部分空间，是生成了一个.db-journal后缀名的临时文件。（这个问题对我现在来说是无所谓的。）
二，在数据库文件建成中，将auto_vacuum设置成“1”。
注意：只有在数据库中未建任何表时才能改变auto-vacuum标记。试图在已有表的情况下修改不会导致报错。
cmd.CommandText = "PRAGMA auto_vacuum = 1;"
cmd.ExecuteNonQuery()
当开启auto-vacuum，当提交一个从数据库中删除除数据的事物时，数据库文件自动收缩。
数据库会在内部存储一些信息以便支持这一功能，这使得数据库文件比不开启该选项时稍微大一些。
我的表结构，不含任何数据是，数据库文件大小是25K左右，开了auto_vacuum之后是26K。
插入运行基础数据后，文件变成35K，开了auto_vacuum之后是36K。
变化不大，无所谓。
但是第二个方法同样有缺点，只会从数据库文件中截断空闲列表中的页， 而不会回收数据库中的碎片，也不会像VACUUM命令那样重新整理数据库内容。实际上，由于需要在数据库文件中移动页， auto-vacuum 会产生更多的碎片。而且，在执行删除操作的时候，也有那个.db-journal文件产生。
要使用 auto-vacuum，需要一些前题条件。 数据库中需要存储一些额外的信息以记录它所跟踪的每个数据库页都找回其指针位置。 所以，auto-vacumm 必须在建表之前就开启。在一个表创建之后， 就不能再开启或关闭 auto-vacumm。
其实按照运行时间上的比较，两个在做了大删除操作后，从3M变到35K的时间其实差不多，执行VACUUM命令稍微长一点，但是也长不了多少，相对而言，这种一点点的长可以忽略不计。
加上AUTO的方式对碎片的造成情况，如果数据交换次数多的话，这种方式很不合适。
还是决定用第一种方式，在大数据删除后，向服务器送信前。执行VACUUM命令。这样做比较划算。