File Format Changes in SQLite

SQLite数据库的底层文件格式不会以不兼容的方式更改。SQLite数据库文件有数百亿甚至数万亿的流通量，而SQLite开发人员承诺在未来数十年内支持这些文件。

本文档描述了2004年以前在SQLite中发生的不兼容问题。自2004年以来，SQLite得到了增强，因此较旧版本的SQLite库无法读取较新的数据库文件。但是，最新版本的SQLite库应该能够读写任何较旧的SQLite数据库文件而不会有任何问题。

换句话说，自2004年以来，所有的SQLite版本都向后兼容，但不一定向前兼容。

下表总结了自版本1.0.0以来发生的SQLite文件格式更改：

版本更改约。文件格式的日期说明将1.0.32更改为2.0.0 2001-09-20 SQLite的版本1.0.X使用GDBM库作为磁盘的后端接口。从版本2.0.0开始，GDBM被一个专门为SQLite编写的自定义B-Tree库所取代。新的B-Tree后端的速度是GDBM的两倍，支持原子提交和回滚，并将整个数据库存储在单个磁盘文件中，而不是像GDBM那样使用单独的文件作为每个表。这两种文件格式甚至不是很相似。2.0.8到2.1.0 2001-10-12使用了相同的基本B-Tree格式，但索引键的详细信息已更改以提供更好的查询优化机会。某些标题也进行了更改，以将行的最大大小从64KB增加到24MB。此更改是上述版本号规则的例外，因为它既不是向前兼容的，也不是向后兼容的。需要完整的数据库重新加载。这是唯一的例外。2.1.7至2.2.0 2001-12-21从版本2.2.0开始，SQLite不再为INTEGER PRIMARY KEY列建立索引。相反，它使用该列作为主表的实际B-Tree键。库的版本2.2.0及更高版本将自动检测何时正在读取2.1.x数据库并禁用新的INTEGER PRIMARY KEY功能。换句话说，版本2.2.x向后兼容版本2.1.x. 但版本2.1.x与版本2.2.x不兼容。如果您尝试使用较旧的2.1.x库打开2.2.x数据库，并且该数据库包含INTEGER PRIMARY KEY，则可能会收到一个coredump。如果数据库模式不包含任何INTEGER PRIMARY KEY，那么版本2.1.x和版本2.2.x数据库文件将完全相同且完全可互换。2.2.5到2.3.0 2002-01-30从版本2.3.0开始，SQLite在存储在SQLITE_MASTER表中的CREATE TABLE和CREATE INDEX语句中支持一些额外的语法（“ON CONFLICT”子句）。如果你创建一个包含这个新语法的数据库，然后尝试使用版本2.2.5或更早的版本读取该数据库，那么解析器将不会理解新的语法，并且会得到一个错误。否则，2.2.x和2.3.x的数据库是可以互换的。2.3.3至2.4.0 2002-03-10从版本2.4.0开始，SQLite添加了对视图的支持。有关视图的信息存储在SQLITE_MASTER表中。如果旧版本的SQLite尝试读取SQLITE_MASTER表中包含VIEW信息的数据库，解析器将无法理解新语法，并且初始化将失败。此外，SQLite跟踪数据库文件中未使用的磁盘块的方式略有改变。如果旧版本的SQLite尝试写入以前由版本2.4.0或更高版本编写的数据库，则可能会泄露磁盘块。2.4.12到2.5.0 2002-06-17从版本2.5.0开始，SQLite添加了对触发器的支持。有关触发器的信息存储在SQLITE_MASTER表中。如果旧版本的SQLite尝试读取SQLITE_MASTER表中包含CREATE TRIGGER的数据库，解析器将无法理解新语法，并且初始化将失败。2.5.6至2.6。0 2002-07-17索引布局中的设计缺陷需要更正文件格式。此更改出现在版本2.6.0中。如果使用库的2.6.0或更高版本打开最初由版本2.5.6或更低版本创建的数据库文件，则会自动尝试将数据库重建为新格式。这对于大型数据库可能需要一些时间。（在Unix下每兆字节数据库允许1或2秒 - 在Windows下更长）。这种格式转换是不可逆的。它是（在Unix下每兆字节数据库允许1或2秒 - 在Windows下更长）。这种格式转换是不可逆的。它是（在Unix下每兆字节数据库允许1或2秒 - 在Windows下更长）。这种格式转换是不可逆的。它是非常建议您在使用该库的2.6.0或更高版本打开较早的数据库文件之前制作备份副本，以防格式转换逻辑中出现错误。库的版本2.6.0或更高版本无法打开版本2.5.6或更低版本的只读数据库文件，因为只读文件无法升级到新格式。2.6.3到2.7.0 2002-08-13从版本2.7.0开始，SQLite理解两种不同的数据类型：文本和数字。文本数据按照memcmp（）顺序排序。如果数字数据看起来像一个数字，则按数字顺序排序;如果不是，则按memcmp（）顺序排序。当SQLite 2.7.0或更高版本打开2.6.3或更早版本的数据库时，它假定所有表的所有列都具有“数字”类型。对于2.7.0及更高版本的数据库，列的类型为“文本” 如果它们的数据类型字符串包含子字符串“char”或“clob”或“blob”或“text”。否则，它们是“数字”类型。由于“文本”列与数字的排序顺序不同，“文本”列上的索引对于2.7.0版和更高版本的数据库按不同的顺序发生。因此，版本2.6.3及更低版本的SQLite将无法读取2.7.0或更高版本的数据库。但SQLite 2.7.0及更高版本将读取较早的数据库。2.7.6到2.8.0 2003-02-14版本2.8.0引入了对回滚日志文件格式的更改。主数据库文件格式不变。版本2.7.6及更早版本可以读写2.8.0数据库，反之亦然。版本2.8.0可以回滚由2.7.6及更早版本启动的事务。但是版本2.7。6及更早版本无法回滚由2.8.0或更高版本启动的事务。唯一会遇到这个问题的是当你有一个使用2.8.0版或更高版本的程序崩溃时发生一个不完整的事务，那么你尝试使用2.7.6或更早版本来检查数据库。2.7.6代码将无法读取日志文件，因此将无法回滚未完成的事务以恢复数据库。2.8.14到3.0.0 2004-06-18版本3.0.0是SQLite的一项重要升级，它包含对UTF-16，BLOB的支持以及更紧凑的编码，这些编码导致数据库文件的数据文件通常为25％到50％小。新的文件格式非常不同，并且与第2版文件格式完全不兼容。唯一会遇到这个问题的是当你有一个使用2.8.0版或更高版本的程序崩溃时发生一个不完整的事务，那么你尝试使用2.7.6或更早版本来检查数据库。2.7.6代码将无法读取日志文件，因此将无法回滚未完成的事务以恢复数据库。2.8.14到3.0.0 2004-06-18版本3.0.0是SQLite的一项重要升级，它包含对UTF-16，BLOB的支持以及更紧凑的编码，这些编码导致数据库文件的数据文件通常为25％到50％小。新的文件格式非常不同，并且与第2版文件格式完全不兼容。唯一会遇到这个问题的是当你有一个使用2.8.0版或更高版本的程序崩溃时发生一个不完整的事务，那么你尝试使用2.7.6或更早版本来检查数据库。2.7.6代码将无法读取日志文件，因此将无法回滚未完成的事务以恢复数据库。2.8.14到3.0.0 2004-06-18版本3.0.0是SQLite的一项重要升级，它包含对UTF-16，BLOB的支持以及更紧凑的编码，这些编码导致数据库文件的数据文件通常为25％到50％小。新的文件格式非常不同，并且与第2版文件格式完全不兼容。6或更早。2.7.6代码将无法读取日志文件，因此将无法回滚未完成的事务以恢复数据库。2.8.14到3.0.0 2004-06-18版本3.0.0是SQLite的一项重要升级，它包含对UTF-16，BLOB的支持以及更紧凑的编码，这些编码导致数据库文件的数据文件通常为25％到50％小。新的文件格式非常不同，并且与第2版文件格式完全不兼容。6或更早。2.7.6代码将无法读取日志文件，因此将无法回滚未完成的事务以恢复数据库。2.8.14到3.0.0 2004-06-18版本3.0.0是SQLite的一项重要升级，它包含对UTF-16，BLOB的支持以及更紧凑的编码，这些编码导致数据库文件的数据文件通常为25％到50％小。新的文件格式非常不同，并且与第2版文件格式完全不兼容。

 SQLite在公共领域。