Sqlite数据库的数据存放在哪里怎么查看文件位置

与 MySQL、PostgreSQL 等运行独立常驻服务进程的数据库不同，SQLite 属于嵌入式数据库，它的所有表结构、索引和业务数据默认直接打包保存在宿主操作系统的单张普通磁盘文件中，或者仅驻留在运行时内存中。查看它的物理位置，关键在于明确当前应用指定的存储路径，并通过交互式命令、特定 PRAGMA 查询或系统检索工具定位该文件。

一、SQLite 的存储机制与文件形态

理解 SQLite 数据存放在哪里的第一步，是明确它的架构方式。SQLite 引擎直接嵌入在宿主应用程序中运行，本身不维护任何“数据库服务器集群”或“全局共享系统目录”。数据文件的物理路径完全由创建连接时传入的参数决定。

在普通磁盘模式下，一个典型的 SQLite 数据库对应磁盘上的一个主数据文件（常见后缀包括 .db、.sqlite、.sqlite3 或无后缀）。当数据库发生写操作或开启事务时，同级目录下通常还会临时生成配套的日志辅助文件：

• 主数据库文件（如 app.db）：永久保存所有的表元数据（sqlite_master）、B-tree 索引结构和行记录。
• 预写式日志文件（app.db-wal）：在开启 WAL（Write-Ahead Logging）高性能模式时出现，写操作首先写入该文件，后续再合并回主文件。
• 共享内存索引（app.db-shm）：在 WAL 模式下用于跨进程同步状态的索引文件，会在所有连接断开后被系统回收。
• 传统回滚日志（app.db-journal）：在传统 Rollback 日志模式下执行写入事务时生成，事务提交后会被清理或截断。

图 1：SQLite 主文件与辅助日志文件的物理关系

二、如何查看当前数据库文件的绝对位置

如果你已经连接到了某个 SQLite 数据库，或者拥有控制台交互环境，可以通过以下三种标准操作直接查看底层物理文件路径。

方法 1：使用标准 SQL 指令 PRAGMA database_list

这是在各类数据库客户端（如 DBeaver、Navicat、VS Code SQLite 插件）或编程语言连接对象中最通用、最直接的查询语法。执行该命令后，数据库会列出当前连接所挂载的所有数据库名称及物理绝对路径。

执行命令：

PRAGMA database_list;

示例返回结果：

在返回的数据中，seq=0、name='main' 的记录对应的 file 列，即为主数据库在操作系统中的完整物理文件位置。如果该列显示为空字符串，则表示当前数据库连接建立在内存中（:memory:），未落盘保存。

方法 2：在 sqlite3 原生命令行客户端中使用 .databases 元命令

如果你通过终端打开了 sqlite3 交互式 shell，可以直接运行内置的点命令（Dot-command）获取挂载信息：

执行命令：

sqlite> .databases

示例输出：

main: /data/apps/cms/storage/content.sqlite r/w

终端会输出数据库标签名（如 main）、对应的真实磁盘路径，以及当前进程对该文件拥有的权限模式（只读 r/o 或读写 r/w）。

图 2：终端下查看 SQLite 数据库路径的操作流程

方法 3：在业务代码中解析并输出实际路径

在很多 Web 后端或脚本项目中，代码常常使用相对路径（例如 sqlite:///./db/data.db）初始化连接。相对路径最终定位到哪里，完全取决于程序运行时的当前工作目录（CWD）。若要在程序运行时准确获取该文件的绝对物理位置，可以借助语言自身的文件工具解析。

Python 完整示例代码：

import sqlite3
import os

# 连接相对路径数据库
conn = sqlite3.connect("mydb.sqlite")
cursor = conn.cursor()

# 方式 A：通过 PRAGMA 获取底层注册的物理路径
cursor.execute("PRAGMA database_list;")
for row in cursor.fetchall():
    seq, name, db_path = row
    if name == "main":
        print(f"[PRAGMA 查询结果] 绝对路径: {db_path}")

# 方式 B：使用操作系统模块解析当前脚本对应的工作目录路径
configured_filename = "mydb.sqlite"
resolved_path = os.path.abspath(configured_filename)
print(f"[系统解析结果] 绝对路径: {resolved_path}")

conn.close()

三、常见应用与操作系统中 SQLite 存放在哪里

如果你面对的是现成软件或特定平台（如浏览器、移动设备应用），并没有控制台直接输入 SQL 命令，则需要了解各主流系统的默认存放规律。

图 3：SQLite 在主流平台上的典型存储路径对比

1. 桌面端应用（Windows 与 macOS）

在个人电脑中，桌面客户端通常将配置文件与本地缓存存放在用户家目录的专用应用文件夹内：

• Windows 系统：多数存储在 C:\Users\<用户名>\AppData\Roaming\<软件名> 或 AppData\Local\<软件名> 中。例如 Chrome 浏览器的访问记录和 Cookies 就是标准的 SQLite 文件，存放在 %LocalAppData%\Google\Chrome\User Data\Default\History。
• macOS 系统：通常存放于 ~/Library/Application Support/<软件名>/ 目录下。可以通过前往访达（Finder）并按快捷键 Cmd + Shift + G 输入路径直接进入。

2. 移动端应用（Android 与 iOS）

移动操作系统均实行严格的应用程序沙盒隔离机制：

• Android：默认路径为 /data/data/<应用包名>/databases/<数据库名>.db。在真机未 Root 的情况下，普通文件管理器无权读取该路径；在开发阶段，可以通过 Android Studio 的 Device File Explorer 窗口或使用 adb shell run-as <包名> 命令直接将文件拷贝到电脑。
• iOS：数据库通常位于应用的沙盒容器中，常见路径为 /var/mobile/Containers/Data/Application//Documents/ 或 Library/Application Support/。非越狱设备可通过 Xcode 的 Devices and Simulators 下载整个应用容器包提取文件。

3. Web 后端开发项目

在主流开发框架中，数据库位置由配置文件（如 .env、settings.py、appsettings.json）直接定义：

• Django：检查 settings.py 中的 DATABASES['default']['NAME']，通常形如 BASE_DIR / 'db.sqlite3'。
• Spring Boot：检查 application.properties 中的 spring.datasource.url=jdbc:sqlite:filepath。
• Node.js / Express：检查 better-sqlite3 或 sqlite3 初始化时传入的文件参数。

四、不知道文件名时，如何全局扫描定位

有时应用已编译打包，或者数据库文件扩展名被修改（例如伪装成 .dat、.bin 或无后缀），常规按名称搜索可能找不到。由于所有合法的 SQLite 3 数据库文件在物理头部的最前 16 个字节都是固定的 ASCII 魔数字符串 SQLite format 3\000，我们可以利用这个特征进行准确定位。

Linux / macOS 平台：按文件特征定位

在终端使用 find 配合 file 命令，即使文件名没有 .db 后缀也能识别：

# 在指定目录（如 /var/www 或当前目录）递归扫描真正的 SQLite 数据文件
find . -type f -exec file {} + | grep "SQLite 3.x database"

示例输出：

./storage/app_cache.dat: SQLite 3.x database, last written using SQLite 3039002, writer version 2, read version 2
./data/session.store:    SQLite 3.x database, user version 12

Windows 平台：按扩展名与常见关键字搜索

在 PowerShell 中可以使用递归筛选：

Get-ChildItem -Path "C:\MyApp" -Recurse -Include *.db,*.sqlite,*.sqlite3 -ErrorAction SilentlyContinue | Select-Object FullName, Length, LastWriteTime

五、操作与备份时的关键注意事项

当你定位到了 SQLite 数据库文件的具体位置，准备进行复制、备份或转移时，务必注意以下两点以防止数据损坏：

1. 检查伴生文件（-wal 与 -shm）：如果数据库启用了 WAL 模式，在程序运行或未完成 checkpoint 时，部分新提交的数据仍然留存在 .db-wal 文件中。此时若只复制了主 .db 文件，会导致备份出的数据库缺失最新数据，甚至报结构损坏错误。复制时必须将同名 -wal 和 -shm 文件一并打包。
2. 避免在写入期间直接系统级复制：如果应用程序正在频繁执行写入，直接用文件管理器的复制功能可能读取到处于半写入状态的文件。安全做法是让应用暂停写入，或者直接在数据库中执行原生备份命令：

   VACUUM INTO '/path/to/safe_backup.db';

   该命令会生成一个完整、独立且不依赖外部 WAL 文件的有效数据库副本。

图 4：查看 SQLite 数据库文件位置的判断与选择总结