Python SQLite3单表莫名消失问题求调试思路

问题现象 #

开发环境中，SQLite3数据库的单张表在服务重启几天后毫无征兆地"消失"：数据库文件仍存在且可正常连接，但执行SELECT name FROM sqlite_schema WHERE type='table' ORDER BY name;无返回结果，随后服务开始抛出sqlite3.OperationalError: no such table: MY_CACHE_TABLE错误。该场景仅出现在低流量的开发服务器（仅自身测试使用）。

日志中无任何指向表删除的操作记录，仅在报错时间点突然出现表不存在的提示。此表用于多Uvicorn进程间的缓存同步，存储进程PID与缓存数据哈希值，部署时会重建数据库，运行时理论上不会调用建表/删表逻辑。

调试思路与排查方向 #

一、排查数据库文件本身的异常 #

• 检查文件权限与路径一致性：
  确认所有进程对数据库文件及所在目录拥有读写权限，避免因权限不足导致进程无法写入原文件，转而创建空的临时数据库。同时强制输出所有进程连接的数据库绝对路径，验证是否存在不同进程因工作目录差异连接到不同文件的情况。
• 验证数据库完整性：
  执行SQLite内置命令检查数据库状态：

  sqlite3 /some_path/mydatabase.db "PRAGMA integrity_check;"
  

  同时查看sqlite_schema的完整输出，确认表是否被误改名或因数据库损坏导致元数据丢失。
• 追踪文件大小变化：
  对比表消失前后的数据库文件大小，若文件突然变小，大概率是有进程执行了删表并提交操作，或数据库被重新初始化。

二、排查多进程并发引发的竞态问题 #

• 强制追踪DROP TABLE操作：
  全局搜索代码中的DROP TABLE语句，给create_table()函数添加强制日志（即使你认为运行时不会调用），确保任何删表操作都被记录：

  def create_table() -> None:
      logger.critical("CREATE_TABLE CALLED - PID: %d", os.getpid())
      database_connection: sqlite3.Connection = get_database_connection()
      cursor: sqlite3.Cursor
  
      try:
          cursor = database_connection.cursor()
          cursor.execute(f"DROP TABLE IF EXISTS {TABLE_NAME}")
          logger.critical("DROPPED TABLE %s - PID: %d", TABLE_NAME, os.getpid())
          cursor.execute(f"CREATE TABLE {TABLE_NAME} (PID INTEGER, CACHE_HASH TEXT)")
          logger.critical("CREATED TABLE %s - PID: %d", TABLE_NAME, os.getpid())
      except sqlite3.Error as err:
          raise RuntimeError("Error creating database.") from err
      finally:
          cursor.close()
          database_connection.commit()
          database_connection.close()
  

• 修复事务提交逻辑：
  SQLite默认连接的isolation_level="DEFERRED"，所有写操作需显式commit()才会持久化。你的代码中_set_cache_data_up_to_date()、invalidate_cache_for_all_other_processes()等写操作未提交事务，可能引发多进程锁冲突或状态异常，需补充conn.commit()：

  def _set_cache_data_up_to_date(pid: int) -> None:
      cache_data_hash: Union[str, None] = _get_hash_for_pid(pid)
      with get_database_connection() as conn:
          if cache_data_hash is None:
              conn.execute(f"insert into {TABLE_NAME} values (?, ?)", (pid, settings.cache_data.hash))
          else:
              conn.execute(f"update {TABLE_NAME} set cache_data_hash = ? where pid = ?", (settings.cache_data.hash, pid))
          conn.commit()  # 显式提交事务
  

• 启用WAL模式优化多进程并发：
  SQLite默认的DELETE日志模式不适合多进程场景，修改连接逻辑启用WAL模式，减少锁冲突与异常：

  def get_database_connection() -> sqlite3.Connection:
      db_path = os.path.abspath(settings.DB_FILE_NAME)
      logger.info("Connecting to DB: %s (PID: %d)", db_path, os.getpid())
      try:
          connection = sqlite3.connect(db_path)
          connection.execute("PRAGMA journal_mode=WAL;")
      except sqlite3.Error as exc:
          raise RuntimeError(f"Cannot connect to {db_path}") from exc
  
      return connection
  

三、排查开发环境的自动操作 #

• 检查是否存在自动部署、定时重启脚本，这类脚本可能在不知情的情况下重新执行create_db()，覆盖现有数据库。
• 查看SQLite临时文件（*.db-journal）是否存在异常，进程意外崩溃可能导致日志文件未正常合并，但一般不会直接删表。

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