SQLite执行DROP TABLE报错database or disk is full问题求助

出现原因 #

• SQLite为了保证事务的原子性，所有写入操作（包括DROP TABLE）都会先写回滚日志或者预写日志（WAL），用于操作失败时回滚数据。删除80GB的大表时，需要记录的页映射、元数据修改等日志内容占用的临时空间超过了当前磁盘剩余的18GB，因此触发磁盘已满报错。
• 额外说明：即使DROP TABLE执行成功，SQLite默认也不会直接释放表占用的磁盘空间，只会将对应磁盘页标记为空闲，后续新增数据时会优先复用这些空闲页，数据库文件大小不会立刻缩小。

解决方案 #

方案1：临时关闭日志模式（操作速度快，适合可接受短时间风险的场景） #

1. 操作前先手动备份数据库文件，有外接存储的话建议将备份存到外接存储，避免占用当前磁盘空间
2. 连接SQLite后执行以下命令关闭日志和同步校验：

PRAGMA journal_mode = OFF;
PRAGMA synchronous = OFF;

3. 执行DROP TABLE listens;完成表删除，该过程不会生成回滚日志，不需要额外临时磁盘空间
4. 删除完成后执行PRAGMA journal_mode = WAL;恢复默认的安全日志配置

方案2：导出有效数据重建数据库（更安全，同时能释放多余磁盘空间） #

1. 准备一个剩余空间大于167GB的外接存储或者其他磁盘分区
2. 命令行执行导出命令，跳过要删除的listens表：

sqlite3 你的数据库文件名.db ".dump '!listens'" > backup.sql

3. 导入备份到新数据库：

sqlite3 new_database.db < backup.sql

4. 验证新数据库数据无误后，替换旧数据库文件即可。该方式最终生成的数据库仅包含有效数据，不会有多余的空白占用。

方案3：提前释放磁盘空间后操作 #

• 先清理当前磁盘的无用文件，预留至少30GB以上的空闲空间后再执行DROP TABLE操作
• 如果后续需要收回数据库未使用的空白空间，可以执行VACUUM;命令，注意该操作需要和当前数据库大小相当的临时磁盘空间，需要提前预留足够空间。

内容的提问来源于stack exchange，提问作者Nik