Small. Fast. Reliable.
Choose any three.
Choose any three.
SQLite的默认配置假定基础文件系统支持长文件名。
SQLite对数据库文件没有任何命名要求。SQLite可以愉快地使用具有任何文件扩展名或根本没有扩展名的数据库文件。当回滚日志或预写日志或其他类型的 临时磁盘文件之一需要辅助文件时，通常通过在数据库文件名的末尾附加一个后缀来构造辅助文件的名称。例如，如果原始数据库称为“ app.db ”，则回滚日志将称为“ app.db-journal ”，而预写日志将称为“ app.db-wal”“。这种辅助文件命名方法在支持长文件名的系统上非常有用。但是，在施加8 + 3文件名约束的系统上，即使原始数据库文件支持，辅助文件也不适合8 + 3格式。
推荐的解决此问题的方法是选择其他文件系统。如今，支持长文件名的高性能，可靠，免专利的文件系统种类繁多。在可能的情况下，建议嵌入式设备使用这些其他文件系统之一。这样可以避免兼容性问题，以及由于不一致使用8 + 3文件名而导致数据库损坏的危险 。
为了向后兼容或由于其他非技术因素，某些设备被迫使用文件名限制为8 + 3的旧文件系统。在这种情况下，SQLite可以被强制使用符合8 + 3模式的辅助文件，如下所示：
使用编译时选项SQLITE_ENABLE_8_3_NAMES = 1或 SQLITE_ENABLE_8_3_NAMES = 2编译SQLite库。默认情况下，SQLite不包括对8 + 3文件名的支持，因为这确实会带来一些开销。开销很小，但是即使如此，我们也不想负担不需要8 + 3文件名支持的数十亿个SQLite应用程序的负担。
如果使用了SQLITE_ENABLE_8_3_NAMES = 1选项，则SQLite能够使用8 + 3文件名，但是该功能已禁用，必须在打开或 附加数据库文件时使用URI文件名为每个数据库连接分别启用该功能，并包括URI中的“ 8_3_names = 1 ”查询参数。如果使用SQLITE_ENABLE_8_3_NAMES = 2编译SQLite，则 默认启用8 + 3个文件名，并且可以跳过此步骤。
确保数据库文件名遵循8 + 3文件名格式，并且没有空名称或扩展名。换句话说，数据库文件名的基本名称必须包含1到8个字符，扩展名必须包含1到3个字符。不允许使用空白扩展名。
使用上述步骤时，SQLite将仅使用扩展名的后3个字符来缩短文件扩展名。因此，例如，通常称为“ app.db-journal ”的文件将缩短为“ app.nal ”。同样，“ app.db-wal ”将变为“ app.wal ”，“ app.db-shm ”将变为“ app.shm ”。
请注意，数据库文件名具有某种扩展名非常重要。如果没有扩展名，则SQLite会通过附加到文件的基本名称来创建辅助文件名。因此，一个名为“ db01 ”的数据库将具有一个名为“ db01-journal ”的回滚日志文件。并且由于该文件名没有扩展名，不能缩短到3个字符，因此将按原样使用，并且会违反8 + 3命名规则。
如果使用8 + 3命名而不是默认的长文件名来访问数据库文件，则每次打开数据库时，每个数据库连接都必须使用8 + 3命名来一致地访问该文件，否则存在数据库损坏的风险。对于要从崩溃中恢复的SQLite，辅助回滚日志和预写日志文件是必不可少的。如果应用程序使用8 + 3名称且崩溃，则从崩溃中安全恢复所需的信息将存储在扩展名为“ .nal ”或“ .wal ”的文件中。如果下一个打开数据库的应用程序未指定“ 8_3_names = 1“ URI参数，然后SQLite将使用长文件名来尝试查找回滚日志或预写日志文件。它将找不到它们，因为它们是由崩溃的应用程序使用8 + 3名称保存的，因此是数据库将无法正确恢复，并且很可能会损坏。
在某些情况下，使用文件名为8 + 3的数据库文件，而在其他情况下，使用长文件名等效于 删除热日志。