SQLite 的显着特征
本页重点介绍了 SQLite 的一些不寻常的特征，这些特征使 SQLite 与许多其他 SQL 数据库引擎不同。
零配置
SQLite 在使用前不需要“安装”。没有“设置”程序。没有需要启动、停止或配置的服务器进程。管理员无需创建新的数据库实例或为用户分配访问权限。SQLite 不使用配置文件。不需要做任何事情来告诉系统 SQLite 正在运行。系统崩溃或电源故障后无需执行任何操作即可恢复。没有什么可以解决的。SQLite 只是工作。
其他更熟悉的数据库引擎在您启动后运行良好。但是进行初始安装和配置可能会非常复杂。
无服务器
（另请参阅无服务器文档页面。）
大多数 SQL 数据库引擎都是作为单独的服务器进程实现的。想要访问数据库的程序使用某种进程间通信（通常是 TCP/IP）与服务器通信，以向服务器发送请求并接收返回结果。SQLite 不是这样工作的。使用 SQLite，想要访问数据库的进程直接从磁盘上的数据库文件读取和写入。没有中间服务器进程。
无服务器有优点也有缺点。主要优点是没有单独的服务器进程来安装、设置、配置、初始化、管理和故障排除。这就是 SQLite 是“零配置”数据库引擎的原因之一。使用 SQLite 的程序在运行前不需要管理支持来设置数据库引擎。任何能够访问磁盘的程序都能够使用 SQLite 数据库。
另一方面，使用服务器的数据库引擎可以更好地防止客户端应用程序中的错误 - 客户端中的杂散指针不会破坏服务器上的内存。而且因为服务器是一个单一的持久进程，它能够更精确地控制数据库访问，允许更细粒度的锁定和更好的并发性。
大多数 SQL 数据库引擎都是基于客户端/服务器的。在那些无服务器的数据库中，SQLite 是作者所知道的唯一允许多个应用程序同时访问同一数据库的数据库。
单个数据库文件
SQLite 数据库是一个普通的磁盘文件，可以位于目录层次结构中的任何位置。如果 SQLite 可以读取磁盘文件，那么它就可以读取数据库中的任何内容。如果磁盘文件及其目录是可写的，则 SQLite 可以更改数据库中的任何内容。数据库文件可以轻松复制到 USB 记忆棒或通过电子邮件发送以进行共享。其他 SQL 数据库引擎倾向于将数据存储为大量文件。这些文件通常位于只有数据库引擎本身才能访问的标准位置。这使数据更安全，但也更难访问。一些 SQL 数据库引擎提供直接写入磁盘并完全绕过文件系统的选项。这提供了额外的性能，但代价是相当大的设置和维护复杂性。
稳定的跨平台数据库文件
SQLite 文件格式是跨平台的。可以将在一台机器上编写的数据库文件复制到具有不同体系结构的另一台机器上并在其上使用。大端或小端，32 位或 64 位都无所谓。所有机器都使用相同的文件格式。此外，开发人员已承诺保持文件格式稳定和向后兼容，因此新版本的 SQLite 可以读写旧的数据库文件。大多数其他 SQL 数据库引擎要求您在从一个平台移动到另一个平台时转储和恢复数据库，并且通常在升级到软件的较新版本时。
袖珍的
当针对大小进行优化时，启用所有功能的整个 SQLite 库的大小小于 500KiB （使用 GNU 编译器套件中的“size”实用程序在 ix86 上测量。）可以在编译时禁用不需要的功能以进一步减少如果需要，将库的大小设置为 300KiB 以下。大多数其他 SQL 数据库引擎都比这大得多。IBM 吹嘘其最近发布的 CloudScape 数据库引擎“仅”是一个 2MiB 的 jar 文件——即使在压缩后也比 SQLite 大一个数量级！Firebird 自夸其客户端库只有 350KiB。它和 SQLite 一样大，甚至不包含数据库引擎。来自 Oracle 的 Berkeley DB 库是 450KiB，它省略了 SQL 支持，只为程序员提供简单的键/值对。
清单打字
大多数 SQL 数据库引擎使用静态类型。数据类型与表中的每一列相关联，并且只允许该特定数据类型的值存储在该列中。SQLite 通过使用清单类型放宽了这个限制。在清单类型中，数据类型是值本身的属性，而不是存储值的列的属性。因此，SQLite 允许用户将任何数据类型的任何值存储到任何列中，而不管该列的声明类型如何。（这条规则有一些例外：一个 INTEGER PRIMARY KEY 列可能只存储整数。SQLite 会在可能的时候尝试将值强制转换为该列声明的数据类型。）据我们所知，SQL 语言规范允许使用清单类型。尽管如此，大多数其他 SQL 数据库引擎都是静态类型的，因此有些人认为使用清单类型是 SQLite 中的一个错误。但是 SQLite 的作者非常强烈地认为这是一个特性。在 SQLite 中使用清单类型是一项深思熟虑的设计决策，实践证明它可以使 SQLite 更可靠、更易于使用，尤其是与动态类型编程语言（如 Tcl 和 Python）结合使用时。
变长记录
大多数其他 SQL 数据库引擎为大多数表中的每一行分配固定数量的磁盘空间。它们使用特殊的技巧来处理长度可能千差万别的 BLOB 和 CLOB。但是对于大多数表，如果您将一列声明为 VARCHAR(100)，那么数据库引擎将分配 100 字节的磁盘空间，而不管您在该列中实际存储了多少信息。相比之下，SQLite 仅使用实际需要的磁盘空间来存储一行中的信息。如果在 VARCHAR(100) 列中存储单个字符，则只会占用一个字节的磁盘空间。（实际上是两个字节——在每一列的开头有一些开销来记录它的数据类型和长度。）
SQLite 使用可变长度记录有很多优点。显然，它会产生更小的数据库文件。它还使数据库运行得更快，因为要移入和移出磁盘的信息更少。而且，可变长度记录的使用使 SQLite 可以使用清单类型而不是静态类型。
可读的源代码
SQLite 的源代码旨在让普通程序员可读和访问。所有过程和数据结构以及许多自动变量都经过仔细注释，并附有关于它们的作用的有用信息。省略样板注释。
SQL语句编译成虚拟机代码
每个 SQL 数据库引擎都将每个 SQL 语句编译成某种内部数据结构，然后用于执行语句的工作。但在大多数 SQL 引擎中，内部数据结构是由相互关联的结构和对象组成的复杂网络。在 SQLite 中，语句的编译形式是一种类似于机器语言的表示形式的短程序。 数据库用户可以通过在查询前添加EXPLAIN关键字来 查看此 虚拟机语言。在 SQLite 中使用虚拟机对库的开发有很大好处。虚拟机在 SQLite 的前端（解析 SQL 语句并生成虚拟机代码的部分）和后端（执行虚拟机代码并计算结果的部分）之间提供了清晰、定义明确的连接。 ) 虚拟机允许开发人员以一种易于阅读的形式清楚地看到 SQLite 试图用它编译的每条语句做什么，这对调试有很大帮助。根据编译方式的不同，SQLite 还具有跟踪虚拟机执行的能力——在执行时打印每条虚拟机指令及其结果。
公共区域
SQLite 的源代码属于公共领域。核心源代码的任何部分均未提出版权声明。（文档和测试代码是另一回事——文档和测试逻辑的某些部分受开源许可的约束。）SQLite 核心软件的所有贡献者都签署了宣誓书，明确否认对代码的任何版权利益。这意味着任何人都可以合法地使用 SQLite 源代码做任何他们想做的事情。还有其他具有自由许可的 SQL 数据库引擎，允许广泛和自由地使用代码。但是那些其他引擎仍然受版权法管辖。SQLite 的不同之处在于版权法根本不适用。
其他 SQL 数据库引擎的源代码文件通常以说明您查看和复制该文件的合法权利的注释开头。SQLite 源代码不包含许可证，因为它不受版权保护。SQLite 源代码提供了一个祝福而不是许可证：
愿你行善而不作恶
愿你为自己找到宽恕并宽恕他人
愿你自由分享，永远不要索取超过你给予的。
SQL 语言扩展
SQLite 为 SQL 语言提供了许多通常在其他数据库引擎中找不到的增强功能。上面已经提到了 EXPLAIN 关键字和清单类型。SQLite 还提供了诸如 REPLACE和 ON CONFLICT子句之类的语句，它们允许对解决约束冲突进行更多控制。SQLite 支持ATTACH和 DETACH命令，允许多个独立的数据库在同一个查询中一起使用。SQLite 定义了允许用户添加新 SQL 函数 和整理序列的 API 。