小。速度很快。可靠。
选择任意三个选项。

编辑注释：本文档是在2004年编写的，用于指导那些从SQLite2过渡到SQLite3。它作为SQLite历史记录的一部分被保留下来。现代程序员应该参考其他地方提供了更多关于SQLite的最新文档在这个网站上。

SQLite版本3概述

SQLite 3.0版对库进行了重要更改，包括：

本文档简要介绍了SQLite 3.0的更改适用于已经熟悉SQLite 2.8版的用户。

命名更改

SQLite 2.8版将继续支持错误修复在可预见的未来。为了允许SQLite版本2.8和SQLite版本3.0和平共存，密钥文件的名称SQLite版本3.0中的API已更改为包括字符“3”。例如，C程序使用的include文件已从“sqlite.h”更改为“sqlite3.h”。还有的名字用于与数据库交互的shell程序已更改从“sqlite.exe”到“sqlite3.exe”。有了这些变化，就有可能在同一系统上安装SQLite 2.8和SQLite 3.0同时。并且同一个C程序可以链接同时使用SQLite 2.8和SQLite 3.0两个库同时运行。

新文件格式

SQLite数据库文件使用的格式已被完全修改。旧版本2.1格式和新的3.0格式与不兼容彼此之间。SQLite 2.8版不会读取3.0版数据库文件和SQLite 3.0版将无法读取2.8版数据库文件。

要将SQLite 2.8数据库转换为SQLite 3.0数据库，请为2.8和3.0版本准备命令行shell。然后输入如下命令：

sqlite旧款。DB.dump|sqlite3新增。数据库

新的数据库文件格式对表使用B+树。在B+树中，所有数据存储在树的叶子中，而不是同时存储在叶子和中间分支节点。使用表的B+树可以无需使用溢出页面。传统的B树仍然用于索引。

新的文件格式还支持512到512之间的可变页面大小65536字节。页面的大小存储在文件头中，因此理论上，同一个图书馆可以读取不同页面大小的数据库，尽管此功能尚未在实践中实现。

新的文件格式省略了磁盘映像中未使用的字段。例如，索引只使用B树记录的关键部分，而不使用数据。所以对于索引，记录数据长度的字段被省略。使用以下命令存储整数值，例如键和数据的长度可变长度编码，因此只需要一个或两个字节即可存储最常见的情况，但最多可以对64位信息进行编码如果需要。整数和浮点数据以二进制格式存储在磁盘上，而不是而不是像SQLite版本2.8那样转换为ASCII。这些更改一起导致数据库文件通常是比SQLite 2.8版本中的等效文件小25%到35%。

SQLite版本3.0中使用的低级B树格式的详细信息可以在标题注释中找到btreeInt公司。小时源文件和中文件格式文档。

清单类型和BLOB支持

SQLite 2.8版将在内部处理各种格式的数据，但当写入磁盘或通过其API进行交互时，SQLite 2.8始终将数据转换为ASCII文本。相反，SQLite 3.0暴露了它向用户提供内部数据表示并存储二进制表示到磁盘（如果合适）。非ASCII表示的公开是添加以支持BLOB。

SQLite 2.8版具有可以存储任何类型数据的功能在任何表列中，无论该列的声明类型如何。这个该功能在3.0版中保留了下来，但形式略有修改。每个表列都将存储任何类型的数据，尽管列具有由其声明的数据类型定义的数据格式的相关性。当数据插入到列中时，该列将尝试将数据格式转换为列的声明类型。所有SQL数据库引擎可以做到这一点。不同之处在于SQLite 3.0将即使不可能进行格式转换，仍然存储数据。

例如，如果有一个表列声明为“INTEGER”类型如果您尝试插入一个字符串，该列将查看文本字符串看看它是否像一个数字。如果字符串看起来像数字它被转换为数字，如果数字没有转换为整数有一个小数部分，并以这种方式存储。但如果字符串不是一个格式良好的数字，它仍然存储为字符串“TEXT”类型试图将数字转换为ASCII-TEXT表示在储存之前。但是BLOB作为BLOB存储在TEXT列中，因为通常不能将BLOB转换为文本。

在大多数其他SQL数据库引擎中，数据类型与保存数据的表列-包含数据容器。在SQLite 3.0中，数据类型与数据本身相关联，而不是及其容器。保罗·格雷厄姆在他的书中ANSI通用Lisp将此属性称为“清单类型”。其他作者对术语“清单类型”有其他定义，所以要小心混淆。但不管用什么名字，这就是数据类型SQLite 3.0支持的模型。

有关SQLite版本3.0中数据类型的其他信息是可获得的分别地.

支持UTF-8和UTF-16

SQLite 3.0的新API包含接受文本为UTF-8和UTF-16均按主机的本机字节顺序排列。每个数据库文件都将文本管理为UTF-8、UTF-16BE（big-endian）、，或UTF-16LE（小发动机）。在内部和磁盘文件中到处都使用相同的文本表示。如果文本表示数据库文件（在文件头中）指定的不匹配接口例程所需的文本表示，然后是文本在飞行中转换。不断地将文本从一种表示转换为另一种表示可以是计算成本高，因此建议程序员选择单一表示并在整个应用程序中坚持使用它。

在SQLite的当前实现中，SQL解析器只工作UTF-8文本。因此，如果您提供UTF-16文本，它将被转换。这只是一个实施问题，没有什么可以阻止的SQLite的未来版本通过解析UTF-16本机编码的SQL实现。

创建新的用户定义SQL函数和排序序列时，每个函数或排序序列都可以指定它是否与一起工作UTF-8、UTF-16be或UTF-16le。可以注册单独的实现对于每个编码。如果需要SQL函数或排序序列但当前文本编码的版本不可用，则文本将自动转换。如前所述，此转换需要计算时间，因此建议程序员选择一个编码并坚持使用，以最大限度地减少不必要的数量格式杂耍。

SQLite对它接收到的文本并不挑剔乐于处理未规范化甚至未规范化的文本字符串格式良好的UTF-8或UTF-16。因此，想要存储ISO8859数据可以使用UTF-8接口实现这一点。只要没有尝试使用UTF-16排序序列或SQL函数，文本的字节序列不会以任何方式修改。

用户定义的排序序列

排序序列只是定义的文本顺序。当SQLite 3.0排序（或使用类似“<”或“>=”的比较运算符）顺序首先由数据类型决定。

排序序列用于比较两个文本字符串。排序序列不会更改NULL、数字、，或BLOB，仅限文本。

排序序列是作为一个函数实现的，该函数接受将两个字符串作为输入进行比较，并返回负数、零或如果第一个字符串小于、等于或大于，则为正第二个。SQLite 3.0附带一个名为“BINARY”的内置排序序列它是使用标准C库中的memcmp（）例程实现的。BINARY排序序列适用于英语文本。对于其他语言或地区，可能首选替代排序序列。

使用哪个排序序列的决定由SQL中的COLLATE子句。COLLATE子句可以出现在表定义上，为表列或字段定义默认排序规则或在SELECT语句的ORDER BY子句中。计划对SQLite的增强包括标准CAST（）语法以允许定义表达式的排序序列。

64位ROWID

表的每一行都有一个唯一的rowid。如果表定义了类型为“INTEGER PRIMARY KEY”的列，则列成为rowid的别名。但有或没有整数主KEY列中，每一行仍然有一个rowid。

在SQLite版本3.0中，rowid是一个64位有符号整数。这是SQLite版本2.8的扩展，仅允许32位的rowids。

为了最小化存储空间，64位rowid被存储为可变长度整数。0到127之间的行ID仅使用单个字节。0到16383之间的行ID仅使用2个字节。最多2097152使用三个字节。等等。允许使用负行ID，但它们始终使用九个字节的存储，因此不鼓励使用它们。当rowids由SQLite自动生成，它们将始终为非负数。

改进的并发性

SQLite 2.8版允许多个同时读卡器或单个读卡器作家，但不是两者都有。SQLite版本3.0允许启动一个进程在其他进程继续读取的同时写入数据库。这个编写器仍必须获得数据库的排他锁间隔以提交其更改，但独占锁不是整个写操作需要更长的时间。A类更详细的报告在锁上SQLite版本3.0的行为是单独提供的。

SQLite中现在还提供了一种有限形式的表级锁定。如果每个表存储在单独的数据库文件中文件可以附加到主数据库（使用ATTACH命令）合并后的数据库将作为一个整体发挥作用。但锁只会根据需要从单个文件中获取。所以如果你重新定义“数据库”如果是指两个或多个数据库文件，则完全可以两个进程同时写入同一数据库。为了进一步支持此功能，提交涉及两个或多个ATTACHed数据库现在是原子数据库。

信用

SQLite版本3.0部分是由AOL开发人员实现的支持和拥抱伟大的开源软件。

此页面上次修改时间2023-10-10 17:29:48联合技术公司