Python shelve 怎样回收删除键留下的空间

Python 的 shelve 删除键后，底层文件没有立刻变小，通常不是删除失败，而是 dbm 后端把这段空间标记为空闲区，等待后续键值复用。当前 Python 文档提供了 Shelf.reorganize()：它先同步缓存，再尝试移除删除留下的空白。可以把它安排在没有其它进程打开 shelf 的维护窗口中。

本文只讨论 shelve 的空间回收，不把文件大小变化当成唯一的正确性证明。Shelf.reorganize() 是 Python 3.15 新增的统一入口，具体能否执行仍取决于底层 dbm 后端。

删除键负责改变逻辑数据，reorganize() 才负责尝试重排物理存储；两者可以分开安排，但回收时要确保缓存已同步、磁盘有余量且没有并发写入。

为什么删掉键，shelve 文件还不变小

shelve 是字典式外壳，实际记录由 dbm 后端保存。删除键后，后端往往保留可复用的空闲区，这样下一次写入可以直接利用原位置，避免频繁搬移整个数据库。因此“删除成功”和“文件立即缩小”是两个不同结果。

如果只是删除后继续写入，空闲区可能被复用，文件大小不变并不代表空间没有价值。只有在确实需要回收磁盘占用时，才应执行整理。

在维护窗口中调用 Shelf.reorganize()

先让所有删除动作在同一个上下文中完成，再显式调用整理。with 会负责关闭 shelf；代码中的能力判断用于把不支持该方法的后端变成清晰错误，而不是静默跳过。

import shelve

def remove_and_reorganize(path: str, keys_to_remove: list[str]) -> None:
    # 独占维护窗口运行，避免另一个进程同时读写同一份 shelf。
    with shelve.open(path, flag="c", writeback=False) as db:
        for key in keys_to_remove:
            # 删除不存在的键时跳过，避免一次清理因 KeyError 中断。
            if key in db:
                del db[key]

        # 先同步 shelf 缓存，再由底层 dbm 尝试压缩删除留下的空闲区。
        reorganize = getattr(db, "reorganize", None)
        if reorganize is None:
            raise RuntimeError("当前 Python 或 dbm 后端不提供 Shelf.reorganize()")
        reorganize()

        # 读取少量存活键，确认整理后仍能访问需要保留的数据。
        if db:
            sample_key = next(iter(db))
            _ = db[sample_key]

这段代码的关键不在于把所有键读进内存，而在于把整理动作放在关闭前、把异常当成维护失败处理。reorganize() 会调用 sync()；如果使用了 writeback=True，它还会把缓存中的条目写回，因此可能增加维护时间和内存压力。

后端能力、磁盘和并发是三个边界

官方文档提醒，Shelf.reorganize() 并非所有数据库包都可用，而且整理期间可能临时增加资源使用。底层 dbm.sqlite3、dbm.gnu 和 dbm.dumb 的支持细节并不完全相同；尤其是需要预留的临时磁盘空间，应该按实际后端文档和现场余量安排。

• 后端不支持：不要把 hasattr 判断改成无条件调用；可在旧 Python 中把存活键复制到新 shelf，再在停机窗口切换文件名。
• 磁盘不足：先确认有足够的临时空间。某些后端整理时可能接近原文件体积的额外空间，不能只看删除后释放了多少逻辑记录。
• 并发打开：不要让在线进程和整理脚本同时写同一份 shelf；整理完成后再让服务重新打开它。

如果必须采用“新文件重建”方案，应逐项复制仍然存在的键值，关闭新旧 shelf 后再做文件切换，并保留回滚副本。这个方案的代价是复制时间更长，但不依赖某一个 dbm 后端的整理方法。

怎样确认这次整理值得且没有误伤

维护日志至少记录删除数量、整理开始与结束时间、使用的 Python 版本、底层后端名称以及异常信息。空间大小可以作为运营指标，但不应替代数据抽样：整理前后读取几条必须保留的键，再检查待删键不再出现，才更接近业务需要。

若文件大小没有明显变化，先确认删除量是否足够、后端是否只是复用空闲区，以及是否测量了正确的 dbm 文件。没有必要为了追求更小的数字反复整理。

常见问题

调用 reorganize() 后为什么还要 close()

reorganize() 负责同步并尝试重排，close() 负责结束本次访问并释放资源。使用 with shelve.open() 可以让关闭动作稳定执行。

可以在线上请求里直接整理吗

不建议。整理通常需要独占访问和额外资源，应放到可控的离线窗口；线上请求只做正常读写。

小结：先区分逻辑删除和物理空间，再确认后端是否支持 reorganize()，最后在独占窗口中执行并记录结果。这样既能回收可回收的空间，也不会把一次维护误判成普通的键删除操作。