SQLITE_FULL错误排查：149MB SQLite数据库执行查询时报磁盘满

一、优先排查磁盘空间问题 #

• 检查SQLite数据库文件所在磁盘的剩余空间：SQLite执行查询（尤其是排序、分组）时会生成临时文件，哪怕数据库本身只有149MB，磁盘剩余空间不足也会触发SQLITE_FULL。
• 确认系统临时目录的剩余空间：SQLite默认使用系统临时目录存储临时文件，若该目录空间不足，可通过执行PRAGMA temp_store_directory = '/path/to/your/available/temp/folder';指定一个有足够空间的临时目录。

二、调整SQLite配置参数 #

• 增大缓存容量：执行PRAGMA cache_size = 100000;（单位为页，默认每页4KB，此设置约为400MB，可根据服务器内存情况调整），减少磁盘临时文件的依赖。
• 调整同步模式：若对数据一致性要求不是极高，执行PRAGMA synchronous = OFF;，降低磁盘IO压力，避免因IO阻塞导致的错误触发。
• 验证数据库实际容量：执行PRAGMA page_count;和PRAGMA page_size;计算数据库总容量，对比实际文件大小，排除数据库本身达到上限的可能（SQLite单文件最大支持140TB，小型库基本不会触发此限制）。

三、优化查询语句与索引 #

• 避免使用SELECT *，明确指定需要的字段，减少数据传输和内存占用。
• 为关联字段和查询条件字段创建索引，提升查询效率并减少临时文件生成：

  CREATE INDEX idx_death_log_deathDate ON death_log(deathDate);
  CREATE INDEX idx_items_deathDate ON items(deathDate);
  CREATE INDEX idx_death_log_killerUUID ON death_log(killerUUID);
  CREATE INDEX idx_death_log_diedUUID ON death_log(diedUUID);
  

四、关于是否切换到MySQL #

如果以上所有优化都无法解决问题，且错误频繁出现，再考虑切换：

• 优势：MySQL的并发处理、临时空间管理机制更成熟，适合高负载场景。
• 劣势：需要额外部署维护数据库服务器，增加运维成本。
• 建议：149MB的小型数据库完全在SQLite的胜任范围内，优先排查环境配置和做优化，而非直接切换数据库。

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