SQLite数据库那些常见的文件后缀名你知道几个，来看看都有哪些吧

说到SQLite数据库,它最突出的特点就是轻量、无需安装独立的服务器进程，整个数据库就是一个文件，这个特点使得它在移动应用、嵌入式设备和小型桌面应用中非常受欢迎，围绕着这个“单一文件”，SQLite其实还有几个常见的“伙伴”文件，它们通过不同的后缀名来区分各自的作用，下面我们就来一个个看看。

最核心、最常见的后缀名当然是 .db 或 .sqlite 或 .sqlite3，这可以说是SQLite数据库的主数据库文件，是真正存储你所有数据（如表、索引、数据记录）的地方，你可能会问，为什么会有三种？其实这更多是开发者的个人或项目习惯。.db是一个非常通用的数据库文件后缀，很多数据库系统都可能使用；.sqlite和.sqlite3则更具指向性，明确表示这是一个SQLite数据库文件，而.sqlite3通常用来强调该数据库文件是由SQLite 3.x版本的库创建的，但它们在本质上是同一种东西，你在网上找到的SQLite数据库，或者很多应用程序创建的数据库，大概率就是这三个后缀名之一，你手机上的很多App，其数据就存储在一个命名为“databases”的文件夹里，里面都是.db文件。

在数据库进行操作时,尤其是在处理事务（你可以简单理解为一系列要么全部成功、要么全部失败的数据库操作）时，SQLite会创建一些临时文件，其中一个重要的临时文件后缀是 .db-journal，这个文件是SQLite用于实现“原子提交”的关键，什么是原子提交呢？举个例子，比如银行转账，从A账户扣钱和向B账户加钱必须同时成功或失败，不能只发生一半，当SQLite开始一个事务并要修改数据时，它并不会直接去改动主数据库文件（.db），而是先将原本要修改的页面的内容复制到.db-journal文件中，然后再去修改主文件，如果在这个过程中程序崩溃或断电，当数据库下次打开时，SQLite会发现这个.db-journal文件存在，就知道上一次的事务可能没有完成，于是它会根据journal文件里的记录，把数据“回滚”到事务开始前的状态，从而保证数据不会错乱，事务成功完成后，这个.db-journal文件就会被删除，你通常只在数据库进行写操作时才能看到它，它是一个来无影去无踪的“安全卫士”。

与.db-journal类似，但用于另一种模式（WAL模式）的文件是 .db-wal，WAL的全称是Write-Ahead Logging，这是一种更高级的事务日志模式，在这种模式下，SQLite不再将修改前的数据备份到.db-journal文件，而是将所有修改先顺序追加到.db-wal这个文件中，只有在特定时机（如事务提交、文件大小达到阈值），才会将这些修改批量写回主数据库文件，这种模式的优点是读操作和写操作可以很大程度上并发进行，性能更好，如果你看到一个数据库文件旁边有一个同名的.db-wal文件，就说明这个数据库开启了WAL模式，这个文件也是临时性的，但它的生命周期可能比.db-journal更长一些。

除了事务日志文件,还有一个常见的临时文件后缀是 .db-shm，这个文件是专门与.db-wal文件配合使用的，shm是“共享内存”的缩写，在WAL模式下，为了高效管理.wal文件，多个数据库连接需要共享一些元信息（比如当前WAL文件写到哪个位置了）。.db-shm文件就是用来在多个进程之间同步这些信息的内存映射文件，它通常体积很小，并且会随着数据库连接的关闭而消失。

有时候你可能还会看到一个后缀名为 .db-temp 的文件，这个文件顾名思义，就是一个临时数据库，它通常在哪些场景下出现呢？比如当数据库执行一些复杂的ALTER TABLE语句（修改表结构）时，SQLite可能会采用一种策略：创建一个新的临时数据库（.db-temp），将原数据库的数据和新的结构导入到这个临时库中，然后删除原库，再将临时库重命名为原库，这样做是为了保证在修改表结构过程中的安全性，并非所有操作都会创建.temp文件，它只是某些特定操作下的产物。

我们认识了SQLite数据库家族中常见的几位成员：存储核心数据的.db/.sqlite/.sqlite3主文件，保障事务安全的.db-journal文件，提升性能的.db-wal和它的搭档.db-shm文件，以及用于特殊操作的.db-temp临时文件，了解这些后缀名，不仅能帮助你在电脑或设备上识别出SQLite数据库及其相关文件，更能让你对SQLite如何可靠、高效地工作有一个直观的认识。 综合参考了SQLite官方文档中关于文件格式和临时文件的说明部分，以及众多技术社区如Stack Overflow上关于SQLite文件后缀的常见讨论。）