查看“SQLite的适用场合”的源代码

由于SQLite试图解决不同的问题，因此它不能直接与MySQL、Oracle、PostgreSQL或SQL Server等客户端/服务器SQL数据库引擎进行比较。

客户/服务器SQL数据库引擎致力于实现企业数据的共享存储库。它们强调可扩展性、并发性、集中化和控制。SQLite则致力于为单个应用程序和设备提供本地数据存储。SQLite强调经济性、效率、可靠性、独立性和简单性。

SQLite并不与客户/服务器数据库竞争。SQLite与fopen()竞争。


==SQLite在以下情况下表现良好==
===嵌入式设备和物联网===
由于SQLite数据库不需要任何管理，因此它非常适合在必须在没有专家人员支持的情况下运行的设备中使用。SQLite非常适合用于手机、机顶盒、电视、游戏主机、相机、手表、厨房电器、恒温器、汽车、机床、飞机、远程传感器、无人机、医疗设备和机器人等物联网设备。

客户/服务器数据库引擎是专门设计用于在网络核心的精心维护的数据中心运行的。SQLite也可以在这样的环境中运行，但它也可以在网络边缘茁壮成长，在为那些通常存在不稳定连接的应用程序提供快速可靠的数据服务的同时，也能够独立生存。


===应用程序文件格式===

SQLite通常被用作桌面应用程序（如版本控制系统、财务分析工具、媒体编目和编辑套件、CAD包、记录程序等）的本地文件格式。传统的“文件/打开”操作会调用sqlite3_open()来连接数据库文件。由于应用程序内容的更改会自动触发更新，因此“文件/保存”菜单选项变得多余。“文件/另存为”菜单选项可以通过备份API实现。

这种方法有很多好处，包括提高性能、降低成本和复杂性，以及提高可靠性。此用例与下面的数据传输格式和数据容器用例密切相关。


===网站===

SQLite作为大多数低至中等流量网站的数据库引擎表现得非常好（也就是说，大多数网站都是如此）。SQLite能够处理的网站流量量取决于网站如何使用其数据库。一般来说，每天收到的访问量少于10万次的网站应该可以很好地使用SQLite。10万次访问量这个数字是一个保守的估计，而不是一个严格的上限。SQLite已经证明可以处理10倍于此的流量。

SQLite官方网站（https://www.sqlite.org/）自然也使用 SQLite 本身，截至2015年，该网站每天处理约40万至50万个HTTP请求，其中约15-20%是动态页面，涉及数据库操作。动态内容每页使用约200条SQL语句。该配置运行在一台虚拟机上，该虚拟机与23台其他虚拟机共享同一台物理服务器，但大多数情况下仍能将负载平均值保持在0.1以下。


===数据分析===

懂得SQL的人可以使用sqlite3命令行外壳（或各种第三方SQLite访问程序）来分析大型数据集。可以从CSV文件导入原始数据，然后对数据进行切片和切块，生成大量摘要报告。也可以使用Tcl或Python（两者均内置于SQLite中）编写简单的脚本来进行更复杂的分析，或者使用其他语言（如R）和现成的适配器进行分析。可能的应用包括网站日志分析、体育统计分析、编程指标汇总以及实验结果分析。许多生物信息学研究人员就是通过这种方式使用SQLite的。

当然，企业级的客户/服务器数据库也可以这样做。SQLite的优势在于它更易于安装和使用，生成的数据库是一个单个文件，可以写入USB闪存棒或通过电子邮件发送给同事。


===企业数据缓存===

许多应用程序使用SQLite作为企业RDBMS的相关内容缓存。这可以减少延迟，因为大多数查询现在都是针对本地缓存进行的，从而避免了网络往返时间。它还可以减少网络和中央数据库服务器的负载。在许多情况下，这意味着在网络中断期间客户端应用程序可以继续运行。


===服务器端数据库===

系统设计师报告称，在数据中心运行的服务器应用程序中使用SQLite作为数据存储，或者换句话说，将SQLite作为特定应用程序的数据库底层存储引擎。

采用这种模式后，整个系统仍然是客户端/服务器结构：客户端通过网络向服务器发送请求，并从服务器接收回复。但是，客户端的请求和服务器的回复不再是通用的SQL语句和原始的表内容，而是针对特定应用程序的高级请求和回复。服务器将请求转换为多个SQL查询，收集结果，进行后处理、过滤和分析，然后构建一个高级回复，只包含必要的信息。

开发人员报告称，在这种情况下，SQLite通常比客户机/服务器SQL数据库引擎更快。由于数据库请求由服务器进行序列化，因此并发性不是问题。“数据库分片”也可以提高并发性：为不同的子域使用不同的数据库文件。例如，服务器可以为每个用户单独使用一个SQLite数据库，这样服务器可以同时处理数百或数千个连接，但每个SQLite数据库仅由一个连接使用。


===数据传输格式===

因为SQLite数据库是一个在定义良好的跨平台格式下的单一紧凑文件，因此它经常被用作在不同系统之间传输内容的容器。发送者将内容汇集到一个SQLite数据库文件中，然后将该文件传输给接收者。接收者可以使用SQL根据需要提取所需的内容。

SQLite数据库能够在不同字节大小和/或字节序的端点之间实现数据传输。数据可以是各种复杂的混合体，包括大型二进制数据块、文本和小数值或布尔值。可以通过添加新的表和/或列来轻松扩展数据格式，而不会破坏现有接收方。SQL查询语言意味着接收方无需一次性解析整个传输内容，而是可以根据需要查询接收到的内容。数据格式具有“透明性”，可以使用来自多个供应商的多种通用、开源工具轻松进行解码，以便供人类查看。


===文件归档和/或数据容器===

SQLite Archive的概念展示了如何将SQLite用作ZIP归档或Tarballs的替代品。存储在SQLite中的文件的归档文件仅略大于或实际上小于等效的ZIP归档文件。SQLite归档还具有增量和原子更新功能，并且可以存储更丰富的元数据。

化石版本2.5及其更高版本除了提供传统的tarball和ZIP归档格式外，还提供了SQLite Archive文件作为下载格式。sqlite3.exe命令行shell版本3.22.0及其更高版本可以使用`.archive`命令创建、列出或解压缩SQL归档。

SQLite是一种适用于任何需要将多种内容打包成一个自包含且自描述的包，以便在网络上传输的情况的良好解决方案。内容被编码为一种定义明确、跨平台且稳定的文件格式。编码效率很高，接收者可以仅提取部分内容，而无需读取和解析整个文件。

SQL 存档是一种有用的分发格式，用于向许多客户端广播软件或内容更新。例如，可以使用这种方法向机顶盒传输电视节目指南，向车载导航系统发送空中更新。


===临时文件的替代品===

许多程序使用fopen()，fread()和fwrite()等函数来创建和管理以自定义格式存储的数据文件。SQLite特别适合作为这些临时数据文件的替代品。与直觉相反的是，SQLite在读写磁盘内容时可能比文件系统更快。


===内部或临时数据库===

对于需要对大量数据进行筛选和分类的各种程序，通常将数据加载到内存中的SQLite数据库中，并使用带有连接和ORDER BY子句的查询来提取所需的数据格式和顺序，这通常更加容易和快捷。以这种方式在程序内部使用SQL数据库还可以使程序具有更大的灵活性，因为可以随时添加新的列和索引，而无需重新编写每个查询。


===在演示或测试期间为企业数据库提供临时替代方案===

客户端应用程序通常使用通用的数据库接口，可以连接到各种SQL数据库引擎。将SQLite包含在支持的数据库列表中，并静态链接SQLite引擎到客户端，这是很有意义的。这样，客户端程序就可以独立运行，并使用SQLite数据文件进行测试或演示。


===教育与培训===

因为其安装和使用简单（安装非常简单：只需将sqlite3.exe可执行文件复制到目标机器上并运行即可），SQLite是一个适用于教学SQL的数据库引擎。学生可以轻松创建任意数量的数据库，并将数据库发送给教师供其评论或评分。对于对研究关系数据库管理系统（RDBMS）实现感兴趣的高级学生，模块化、注释良好且文档齐全的SQLite代码可以作为良好的基础。


===实验性 SQL 语言扩展===

SQLite的简单、模块化设计使其成为开发新的、实验性数据库语言功能或想法的理想平台。


==客户端/服务器关系数据库管理系统可能在以下情况下表现更好==
===客户端/服务器应用程序===

如果有多个客户端程序通过网络向同一数据库发送SQL语句，那么使用客户机/服务器数据库引擎而不是SQLite。SQLite可以在网络文件系统上运行，但由于大多数网络文件系统都存在延迟问题，因此性能可能不会很好。此外，许多网络文件系统实现（包括Unix和Windows）的文件锁定逻辑存在缺陷。如果文件锁定功能不能正常工作，那么两个或多个客户端可能会在同一时间尝试修改同一数据库的同一部分，从而导致数据损坏。由于这个问题是由底层文件系统实现中的漏洞引起的，SQLite无法防止它。

一个基本的规则是避免在以下情况下使用SQLite：在同一个数据库需要同时从多个计算机（通过网络）直接（不经过中间的应用服务器）访问的情况。


===高流量网站===

SQLite通常可以作为网站的数据库后端，正常运行。但如果网站需要频繁写入数据或者业务繁忙，需要多台服务器，那么可以考虑使用企业级客户端/服务器数据库引擎，而不是SQLite。


===非常大的数据集===

SQLite数据库的大小受到限制，最大为281太字节（248字节，256太字节）。即使它能够处理更大的数据库，SQLite也会将整个数据库存储在一个单独的磁盘文件中，而许多文件系统会将文件的最大大小限制在小于这个值的范围内。因此，如果您正在考虑此类规模的数据库，最好考虑使用一种将内容分散到多个磁盘文件或多个卷中的客户端/服务器数据库引擎。


===高并发===

SQLite支持无限数量的并发读取操作，但在任何给定时刻只允许一个写入操作。对于许多情况来说，这没有问题。写入操作会排队等待。每个应用程序迅速完成其数据库操作并继续执行其他任务，而且锁的持续时间不会超过几百毫秒。但是有些应用程序需要更高的并发性，这些应用程序可能需要寻找其他解决方案。


==选择合适的数据库引擎的检查清单==

===数据是否通过网络与应用程序分离？ → 选择客户端/服务器架构===

关系型数据库引擎充当了数据过滤器，以减少带宽消耗。因此，最好将数据库引擎和数据放置在同一物理设备上，这样高带宽的引擎到磁盘的链接就不必穿越网络，只需较低带宽的应用程序到引擎链接即可。

但是 SQLite 是应用程序的一部分。因此，如果数据存储在与应用程序不同的设备上，则需要通过网络建立更高带宽的引擎到磁盘的链接。这可以工作，但不是最优方案。因此，通常情况下，当数据存储在与应用程序不同的设备上时，最好选择客户机/服务器数据库引擎。

注意：在此规则中，“应用程序”指的是执行SQL语句的代码。如果“应用程序”是一个应用服务器，并且数据存储在与应用服务器位于同一物理机器上，那么即使最终用户位于另一个网络节点上，SQLite仍然可能适用。


===许多并发的写入操作？ → 选择客户端/服务器模式===

如果有多个线程和/或进程在同一时刻需要写入数据库（并且它们无法排队等待轮流操作），那么最好选择支持此功能的数据库引擎，这意味着总是需要选择客户端/服务器数据库引擎。

SQLite仅支持每个数据库文件中同时只有一个写入者。但在大多数情况下，写入事务仅需几毫秒，因此多个写入者可以轮流操作。SQLite可以处理的写入并发性比许多人想象的要多。然而，由于客户端/服务器数据库系统拥有一个长期运行的服务器进程来协调访问，因此通常可以处理比SQLite多得多的写入并发性。


===大数据?→选择客户机/服务器===

如果您的数据将增长到您感到不舒服或无法放入单个磁盘文件的大小，那么您应该选择SQLite以外的解决方案。假设您可以找到支持281tb文件的磁盘驱动器和文件系统，那么SQLite支持的数据库大小可达281tb。即便如此，当内容的大小看起来可能会达到tb级时，最好还是考虑使用集中式客户机/服务器数据库。


===否则→选择SQLite!===

对于写入器并发性较低且内容小于1tb的设备本地存储，SQLite几乎总是更好的解决方案。SQLite是快速和可靠的，它不需要配置或维护。它使事情变得简单。SQLite“只是工作”。