1. 的支持 添加对无内容删除 FTS5 索引 。 这是一个品种 FTS5 内容 全文搜索索引省略存储正在索引的 同时还允许删除记录。
2. 的增强 日期和时间功能 ：
3. 新 时移修饰符 形式的 添加了±YYYY-MM-DD HH:MM:SS.SSS 。
4. 添加了 timeff() SQL 函数 。
5. 添加了 octet_length(X) SQL 函数。
6. 添加了 sqlite3_stmt_explain() API。
7. 查询计划器增强功能：
8. 推广 LEFT JOIN 强度降低优化，使其发挥作用 也适用于 RIGHT JOIN 和 FULL JOIN。 将其重命名为 OUTER JOIN 强度降低 。
9. 中的定理证明 增强OUTER JOIN 强度折减 优化 以便返回更少的假阴性。
10. 的增强 小数扩展 ：
11. 新函数decimal_pow2(N) 返回整数 N 的 2 次方 -20000 到 +20000 之间。
12. 新函数decimal_exp(X) 的工作方式与decimal(X) 类似，只是它返回 结果采用指数表示法 - 末尾带有“e+NN”。
13. 如果 X 是浮点值，则十进制（X）函数现在执行完整的操作 将该值扩展为其精确的十进制等值。
14. 性能增强 JSON 处理的 导致性能提高 2 倍 改进了对大型 JSON 字符串的某些处理。
15. 新的 makefile 目标“验证源”检查以确保没有 源树中的无意更改。 （效劳于 规范源代码 仅 - 不适用于 预编译的合并 tarball 。）
16. 添加了 启用结构化的SQLITE_USE_SEH 编译时选项 使用内存映射时 Windows 上的异常处理 shm 文件 是 WAL 模式 处理的一部分。 该选项已启用 默认情况下，在 Windows 上使用 Makefile.msc 进行构建时。
17. 现在 unix的 VFS 假设 nanosleep() 系统调用是 除非使用 -DHAVE_NANOSLEEP=0 编译，否则可用。
18. 哈希值：
19. SQLITE_SOURCE_ID：2023-08-24 12:36:59 0f80b798b3f4b81a7bb4233c58294edd0f1156f36b6ecf5ab8e83631d468778c
20. sqlite3.c 的 SHA3-256：a6fc5379891d77b69a7d324cd24a437307af66cfdc3fef5dfceec3c82c8d4078

列表 SQLite 版本的完整 单页和 年表 还提供 两种形式。 每一个的详细历史 办理入住手续的时间为 SQLite 版本控制站点 。 

关于SQLite 用途，官网说明，这让我觉得一般的管理软件 sqlite 用起来就够了，我真是小看他了 :D

SQLite 运行良好的情况

• 嵌入式设备和物联网 因为 SQLite 数据库不需要管理， 它适用于必须在没有专家人员支持的情况下运行的设备。 SQLite 非常适合用于 手机、机顶盒、电视、游戏机、 相机、手表、厨房用具、恒温器、汽车、 机床、飞机、远程传感器、无人机、医疗设备、 和机器人：“物联网”。
• 客户端/服务器数据库引擎被设计为存在于 位于网络核心的备受关注的数据中心。 SQLite 也可以在那里工作，但 SQLite 也在网络边缘蓬勃发展， 在提供快速且可靠的服务的同时自力更生 为应用程序提供可靠的数据服务 连接不可靠。
• 申请文件格式
• SQLite 通常用作磁盘文件格式 对于版本控制系统等桌面应用程序， 财务分析工具、媒体编目和编辑套件、CAD 包、记录保存程序等等。 传统的 文件/打开操作调用 sqlite3_open() 附加到数据库 文件。 当应用程序内容修改时，更新会自动发生 因此“文件/保存”菜单选项就变得多余了。 文件/另存为 来实现 菜单选项可以使用备份 API 。
• 这种方法有很多好处，包括改进 性能、降低成本和复杂性，以及 提高了可靠性。 查看技术说明 “aff_short.html” 和 “appfileformat.html” 和 “fasterthanfs.html” 了解更多信息。 该用例与以下密切相关 数据传输格式 和 下面的数据容器 用例。
• 网站
• SQLite 作为数据库引擎非常适用于大多数低端到 中等流量网站（也就是说，大多数网站）。 SQLite 可以处理的 Web 流量取决于 关于网站使用其数据库的程度。 一般来说 也就是说，任何每天点击量少于 10 万次的网站都应该可以工作 使用 SQLite 没问题。 每天 10 万次点击的数字是保守估计，并非准确数字 硬上限。 SQLite 已被证明可以处理 10 倍的数据 的流量。
• SQLite 网站 ( https://www.sqlite.org/ ) 使用 SQLite 本身， 当然，截至撰写本文时（2015 年），它可以处理大约 400K 到 500K 每天的HTTP请求，其中大约15-20%是动态页面接触 数据库。 每个网页的动态内容使用 大约 200 个 SQL 语句 。 此设置在单个虚拟机上运行，​​该虚拟机与其他 23 台虚拟机共享物理服务器 但大多数时间仍将平均负载保持在 0.1 以下。
• 另请参阅： 黑客 2022 年 12 月 13 日起的新讨论 。
• 数据分析
• 了解 SQL 的人可以使用 sqlite3 命令行 shell （或各种第三方 SQLite访问程序）来分析大型 数据集。 可以从CSV文件导入原始数据，然后 数据可以被切片和切块以生成无数的摘要 报告。 可以使用编写的简单脚本完成更复杂的分析 在 Tcl 或 Python 中（两者都内置 SQLite）或在 R 或 使用现成适配器的其他语言。 可能的用途包括网站日志分析、体育 统计分析、编程指标的汇编，以及 实验结果分析。 许多生物信息学研究人员 以这种方式使用 SQLite。
• 企业客户端/服务器也可以完成同样的事情 当然是数据库。 SQLite的优点是 它更容易安装和使用以及生成的数据库 是一个可以写入 USB 记忆棒的单个文件 或通过电子邮件发送给同事。
• 企业数据缓存
• 许多应用程序使用 SQLite 作为相关内容的缓存 企业 RDBMS。 这减少了延迟，因为现在大多数查询都是针对本地进行的 缓存并避免网络往返。 也减轻了负担 在网络和中央数据库服务器上。 并且在很多情况下， 这意味着客户端应用程序可以在 网络中断。
• 服务器端数据库
• 系统设计师 报告使用 SQLite 作为服务器应用程序上的数据存储的成功情况 运行在数据中心，或者换句话说，使用 SQLite 作为底层 用于特定于应用程序的数据库服务器的存储引擎。
• 在这种模式下，整个系统仍然是客户端/服务器： 客户端向服务器发送请求并通过网络获取回复。 但不是发送通用 SQL 并返回原始表内容， 客户端请求和服务器响应是高级别的 特定于应用程序。 服务器将请求转换为多个 SQL 查询，收集 对结果进行后处理、过滤、分析，然后构建 仅包含基本信息的高级答复。
• 开发人员报告 SQLite 通常比客户端/服务器更快 此场景中的 SQL 数据库引擎。 数据库请求由服务器序列化，因此并发性不高 一个问题。 并发性也通过“数据库分片”得到了提高： 对不同的子域使用单独的数据库文件。 为了 例如，服务器可能有一个单独的 SQLite 数据库用于每个 用户，以便服务器可以同时处理数百或数千个用户 连接数，但每个 SQLite 数据库仅由一个连接使用。
• 数据传输格式
• 因为 SQLite 数据库是一个压缩文件 定义明确的跨平台格式 ，经常使用 作为将内容从一个系统传输到另一个系统的容器。 发送者将内容收集到 SQLite 数据库文件中，传输 将该文件发送给接收者，然后接收者使用 SQL 来提取 根据需要的内容。
• SQLite 数据库甚至可以促进系统之间的数据传输 当端点具有不同的字大小和/或字节顺序时。 数据可以是大型二进制 blob、文本和小型数据的复杂组合。 数字或布尔值。 数据格式可以轻松扩展 通过添加新的表和/或列，而不破坏旧的接收器。 SQL查询语言意味着接收者不需要解析 一次完成整个传输，但可以查询 收到需要的内容。 数据格式是“透明”的 感觉它很容易被解码以供人类观看 各种普遍可用的开源工具，来自多个 供应商。
• 文件存档和/或数据容器
• SQLite Archive 的 想法展示了如何 SQLite 可以用作 ZIP 存档或 Tarball 的替代品。 存储在 SQLite 中的文件存档仅稍大一些，并且 在某些情况下，实际上比同等的 ZIP 存档要小。 SQLite 存档具有增量和原子更新功能 以及存储更丰富的元数据的能力。
• Fossil 2.5 版及更高版本提供 SQLite Archive 文件 作为下载格式，此外 到传统的 tarball 和 ZIP 存档。 sqlite3.exe 命令行 shell 版本 3.22.0 及更高版本将创建， 列表，或使用以下命令解压 SQL 归档 .存档命令 。
• 对于任何需要捆绑的情况，SQLite 都是一个很好的解决方案 将不同的内容放入一个独立且自描述的包中 通过网络运输。 内容被编码在 定义明确、跨平台且稳定的文件格式 。 编码效率高，接收者可以提取小子集 的内容，而无需读取和解析整个文件。
• SQL 归档文件作为软件的分发格式非常有用 或向许多客户端广播的内容更新。 变化 例如，基于此想法的信息可用于传输电视节目指南 机顶盒并向车辆导航发送无线更新 系统。
• 替换 临时 磁盘文件
• 很多程序都使用 fopen() , fread() 和 fwrite() 创建并 管理本土格式的数据文件。 SQLite 可以工作 特别好作为 替换这些 临时 数据文件。 与直觉相反，SQLite 可能 比文件系统更快 用于将内容读取和写入磁盘。
• 内部或临时数据库
• 对于具有大量必须进行筛选和排序的数据的程序 通过多种方式，通常可以更轻松、更快速地将数据加载到 内存中的 SQLite 数据库并使用带有连接和 ORDER BY 的查询 子句以所需的形式和顺序提取数据，而不是 尝试手动编写相同的操作代码。 以这种方式在内部使用 SQL 数据库也为程序提供了 更大的灵活性，因为可以添加新的列和索引，而无需 必须重新编码每个查询。
• 在演示或测试期间替代企业数据库
• 客户端应用程序通常使用通用数据库接口，允许 与各种 SQL 数据库引擎的连接。 这是有道理的 将 SQLite 包含在支持的数据库组合中并静态地 将 SQLite 引擎与客户端链接起来。 这样客户端程序就可以了 可以与 SQLite 数据文件独立使用以进行测试或 示威活动。
• 教育和培训
• 因为它的设置和使用都很简单（安装很简单：只需 将 sqlite3 或 sqlite3.exe 可执行文件复制到目标计算机 并运行它）SQLite 是一个很好的数据库引擎，可用于 SQL 教学。 学生可以轻松创建任意数量的数据库 通过电子邮件将数据库发送给教师以征求意见或评分。 了解更多 有兴趣研究 RDBMS 的高级学生 实现了模块化、经过良好注释和记录的 SQLite 代码 可以作为一个良好的基础。
• 实验性 SQL 语言扩展
• SQLite 简单、模块化的设计使其成为一个很好的平台 制作新的实验性数据库语言功能或想法的原型。

客户端/服务器 RDBMS 可能工作得更好的情况

• 客户端/服务器应用程序
<
>>
• 如果有很多客户端程序向同一个客户端程序发送SQL 通过网络建立数据库，然后使用客户端/服务器数据库 引擎而不是 SQLite。 SQLite 将在网络文件系统上工作， 但由于大多数网络文件系统存在延迟， 性能不会很好。 此外，文件锁定逻辑存在错误 许多网络文件系统实现（在 Unix 和 Windows 上）。 如果文件锁定无法正常工作， 两个或多个客户端可能会尝试修改 同时访问同一数据库的同一部分，从而导致 腐败。 因为这个问题是由错误引起的 底层文件系统实现，没有什么 SQLite 可以做些什么来预防它。
• 一个好的经验法则是避免使用 SQLite 在直接访问同一数据库的情况下 （无需介入应用程序服务器）并且同时 来自网络上的许多计算机。
• 大容量网站
• SQLite 通常可以作为网站的数据库后端正常工作。 但是如果网站是写入密集型的或者非常繁忙以至于需要 多个服务器，然后考虑使用企业级客户端/服务器 数据库引擎而不是 SQLite。
• 非常大的数据集
• SQLite 数据库的大小限制为 281 TB (2 ⁴⁸ 字节，256 tibibytes）。 即使它可以处理更大的数据库，SQLite 也会存储整个数据库 单个磁盘文件中的数据库和许多文件系统限制最大 文件大小小于此值。 所以如果你正在考虑 对于这种规模的数据库，您最好考虑使用 客户端/服务器数据库引擎，将其内容传播到多个 磁盘文件，并且可能跨多个卷。
• 高并发
• SQLite 支持无限数量的并发读取器，但它 在任何时刻都只允许一位作家。 对于许多情况，这不是问题。 作家们排队。 每个申请 它的数据库是否快速工作并继续运行，并且没有锁可以持续更多 不到几十毫秒。 但有一些应用需要 更多的并发性，并且这些应用程序可能需要寻求不同的 解决方案。

选择正确数据库引擎的清单

1. 数据与应用程序是否通过网络分开？ → 选择客户端/服务器
2. 关系数据库引擎充当减少带宽的数据过滤器。 所以最好保持数据库引擎和数据开启 相同的物理设备，以便高带宽引擎到磁盘 链路不必遍历网络，只需要较低的带宽 应用程序到引擎的链接。
3. 但 SQLite 内置于应用程序中。 所以如果数据在 将设备与应用程序分开，要求较高 带宽引擎到磁盘的链路可以跨网络。 这可行，但是 这是次优的。 因此，通常最好选择客户端/服务器 当数据位于与数据库不同的设备上时的数据库引擎 应用。
4. 诺塔·贝尼： 在此规则中，“应用程序”是指发出 SQL 语句的代码。 如果“应用程序”是 应用程序服务器 并且 如果内容与应用程序服务器驻留在同一台物理机上， 那么即使最终用户是 另一个网络跳远。
5. 许多并发作家？ → 选择客户端/服务器
6. 如果许多线程和/或进程需要编写 同一时刻的数据库（并且它们不能排队并轮流） 那么最好选择支持该功能的数据库引擎 能力，这始终意味着客户端/服务器数据库引擎。
7. SQLite 仅支持每个数据库文件一次只有一个写入器。 但在大多数情况下，写事务只需要几毫秒，并且 所以多个作家可以轮流写。 SQLite 将处理 写入并发量比许多人想象的要多。 尽管如此， 客户端/服务器数据库系统，因为它们有长期运行的 手头的服务器进程协调访问，通常可以处理 比 SQLite 更高的写入并发性。
8. 大数据？ → 选择客户端/服务器
9. 如果您的数据增长到令您感到不舒服的规模 或者无法放入单个磁盘文件，那么您应该选择 SQLite 以外的解决方案。 SQLite 支持的数据库最多 大小为 281 TB，假设您可以找到磁盘驱动器和文件系统 将支持 281 TB 的文件。 即便如此，当尺寸 内容看起来可能会进入 TB 范围，它会 最好考虑集中式客户端/服务器数据库。
10. 否则→选择 SQLite！
11. 对于具有低写入并发度且小于 对于 TB 级的内容，SQLite 几乎总是更好的解决方案。 SQLite 快速可靠，无需配置或维护。 它让事情变得简单。 SQLite“正常工作”。