最的做的項(xiàng)目中要有到sqlite數(shù)據(jù)存儲(chǔ)，寫了測試程序進(jìn)行測試，存入300萬條記錄，占用flash大小為86.1M，當(dāng)把表中的記錄全部刪除后發(fā)后數(shù)據(jù)庫文件大小依然是 86.1M；
原因是：
sqlite采用的是變長紀(jì)錄存儲(chǔ)，當(dāng)你從Sqlite刪除數(shù)據(jù)后，未使用的磁盤空間被添加到一個(gè)內(nèi)在的”空閑列表”中用于存儲(chǔ)你下次插入的數(shù)據(jù)，用于提高效率，磁盤空間并沒有丟失，但也不向操作系統(tǒng)返回磁盤空間，這就導(dǎo)致刪除數(shù)據(jù)乃至清空整個(gè)數(shù)據(jù)庫后，數(shù)據(jù)文件大小還是沒有任何變化，還是很大
解決方法：兩種
一，在數(shù)據(jù)刪除后，手動(dòng)執(zhí)行VACUUM命令，執(zhí)行方式很簡單
sqlite> vacuum；
VACUUM命令會(huì)清空“空閑列表”，把數(shù)據(jù)庫尺寸壓縮到最小。但是要耗費(fèi)一些時(shí)間。
FQA里面說，在Linux的環(huán)境下，大約0.5秒/M。并且要使用兩倍于數(shù)據(jù)庫文件的空間。
我憎恨此FQA，他只說系統(tǒng)環(huán)境，不說機(jī)器硬件環(huán)境。我在測試手機(jī)上執(zhí)行用了將近13秒時(shí)間壓縮了將近3M的空間。至于它所占用的另一部分空間，是生成了一個(gè).db-journal后綴名的臨時(shí)文件。（這個(gè)問題對我現(xiàn)在來說是無所謂的。）
二，在數(shù)據(jù)庫文件建成中，將auto_vacuum設(shè)置成“1”。
注意：只有在數(shù)據(jù)庫中未建任何表時(shí)才能改變auto-vacuum標(biāo)記。試圖在已有表的情況下修改不會(huì)導(dǎo)致報(bào)錯(cuò)。
cmd.CommandText = 'PRAGMA auto_vacuum = 1;'
cmd.ExecuteNonQuery()
當(dāng)開啟auto-vacuum，當(dāng)提交一個(gè)從數(shù)據(jù)庫中刪除除數(shù)據(jù)的事物時(shí)，數(shù)據(jù)庫文件自動(dòng)收縮。
數(shù)據(jù)庫會(huì)在內(nèi)部存儲(chǔ)一些信息以便支持這一功能，這使得數(shù)據(jù)庫文件比不開啟該選項(xiàng)時(shí)稍微大一些。
我的表結(jié)構(gòu)，不含任何數(shù)據(jù)是，數(shù)據(jù)庫文件大小是25K左右，開了auto_vacuum之后是26K。
插入運(yùn)行基礎(chǔ)數(shù)據(jù)后，文件變成35K，開了auto_vacuum之后是36K。
變化不大，無所謂。
但是第二個(gè)方法同樣有缺點(diǎn)，只會(huì)從數(shù)據(jù)庫文件中截?cái)嗫臻e列表中的頁， 而不會(huì)回收數(shù)據(jù)庫中的碎片，也不會(huì)像
VACUUM
本站僅提供存儲(chǔ)服務(wù)，所有內(nèi)容均由用戶發(fā)布，如發(fā)現(xiàn)有害或侵權(quán)內(nèi)容，請
點(diǎn)擊舉報(bào)。
