SQLite与Mysql有什么区别

这是一篇SQLite官方说明的翻译，这篇文章很好的说明了SQLite的适用场景。

简单的说：SQLite更适合取代本地的文件存储。SQLite也适合给每天几十万点击量的网站提供数据支持。

《SQLite 的适用场景》

注：一些英文单词我在括号中保留原文，以免翻译过程中丢失信息量。

SQLite 不能直接与client/server SQL 数据库引擎相比(如 MySQL、 Oracle、 PostgreSQL 或 SQL Server)，因为 SQLite 试图解决一个不同的问题。

Client/server SQL 数据库引擎力求实现企业数据的共享存储。它们强调可伸缩性、并发性、集中性和可控性。SQLite 致力于为单个应用程序和设备提供本地数据存储。强调经济性、效率、可靠性、独立性和简单性。

SQLite竞争对手不是client/server数据库，而是本地的文件存储 fopen()。

选择正确数据库的原则(Checklist For Choosing The Right Database Engine)

1、数据与应用分离(Is the data separated from the application by a network?) → 选择client/server

关系数据库的作用是减少带宽数据过滤。因此，好将数据库引擎和数据保持在同一个物理设备上，这样高带宽引擎到磁盘的链路就不需要遍历网络，只需要低带宽应用程序到引擎的链路。

但是 SQLite 是内置在应用程序中的。因此，如果数据位于与应用程序分离的独立设备上，则需要跨网络的高带宽引擎到磁盘的链接。这是可行的，但并不理想。因此，当数据位于与应用程序不同的设备上时，通常好选择client/server数据库引擎。

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

2、多个并发写入(Many concurrent writers?) → 选择client/server

如果许多线程或进程需要在同一时刻写入数据库(它们不能排队轮流) ，那么好选择一个支持该功能的数据库引擎，这通常意味着一个client/server数据库引擎。

每个SQLite数据库文件一次只支持一个写入。但在大多数情况下，写事务只需要几毫秒，因此多个写入可以轮流执行。然而，client/server数据库系统因为它们有一个长时间运行的服务器进程来协调访问，所以通常可以处理比 SQLite 更多的写并发性。

3、大数据(Big data? )→ 选择 client/server

如果您的数据将增长到您不适合或无法放入单个磁盘文件的大小，那么您应该选择除 SQLite 之外的解决方案。SQLite 支持大281tb(terabyte) 的数据库，前提是您可以找到一个支持281tb 文件的磁盘驱动器和文件系统。即便如此，当内容的大小看起来可能会达到 tb 的范围时，好考虑使用client/server数据库。

4、其他(Otherwise) → 选择 SQLite!

对于具有低写入并发性和低于 tb(terabyte) 的内容的本地存储，SQLite 几乎总是一个更好的解决方案。SQLite 快速可靠，不需要配置或维护。它让事情变得简单。

SQLite“just works”。

（译者：上面是原文的结论部分，我觉得放在上面对读者更友好一点，所以挪到此处）

SQLite佳工作环境 (Situations Where SQLite Works Well)

• 嵌入式设备和物联网(Embedded devices and the internet of things)
• 因为 SQLite 数据库不需要管理(administration)，所以它在必须在没有专家人工支持的情况下良好的工作。SQLite 适用于手机、机顶盒、电视、游戏机、相机、手表、厨房用具、恒温器、汽车、机床、飞机、遥感器、无人机、医疗设备和机器人: “物联网”。
  Client/server数据库引擎被设计成网络系统的核心：数据中心。虽然 SQLite 也在那里工作，但是 SQLite 也在网络的边缘蓬勃发展，在为应用程序提供快速可靠的数据服务的同时，为自己提供保护，否则这些应用程序的连接就会有问题。
• 应用程序的文件存储格式(Application file format)
  SQLite 经常用应用程序的文件存储格式，例如存储：版本控制系统、财务分析工具、媒体目录和编辑套件、 CAD 包、程序记录等。传统的 File/Open 操作调用 sqlite3_open (数据库文件)。随着应用程序内容的修改，更新会自动发生，所以“文件/保存”菜单选项变得多余。“文件/另存为” 菜单选项可以使用backup API 实现。
  这种方法有许多好处，包括改进性能、降低成本和复杂性以及提高可靠性。有关更多信息，请参见技术说明“ aff_short.html”、“ appfileformat.html”和“ fasterthanfs.html”。此用例与下面的数据传输格式和数据容器用例密切相关。
• 网站(Websites)
  SQLite适用于大多数中低流量网站(也就是说，大多数网站)。SQLite 能够处理的网络流量取决于网站使用其数据库的程度。一般来说，任何日访问量低于10万 的站点都可以使用 SQLite。每天10万点击量是一个保守的估计，而不是一个硬上限。已经被证明可以处理10倍于这个数量的流量。
  当然，SQLite官网(https://www.sqlite.org/) 使用 SQLite 本身，截止到本文发表(2015年) ，它每天处理大约40万 到50万 的 HTTP 请求，其中大约15-20% 是触及数据库的动态页面。动态内容每个网页使用约200条 SQL 语句。这种设置运行在一个虚拟机上，该虚拟机与其他23个虚拟机共享一个物理服务器，但大多数时候仍然保持平均负载低于0.1。
• 数据分析Data analysis
  了解 SQL 的人可以使用 sqlte3命令行 shell (或者各种第三方 SQLite 访问程序)来分析大型数据集。原始数据可以从 CSV 文件导入，然后可以对数据进行分片和切割，以生成大量的摘要报告。更复杂的分析可以通过使用 Tcl 或 Python (两者都是 SQLite 内置的)编写的简单脚本，或者使用 R 或其他语言来完成。可能的用途包括网站日志分析，体育统计分析，编译程序量度，和实验结果的分析。许多生物信息学研究人员就是这样使用 SQLite 的。
  当然，对于企业 client/server数据库也可以做同样的事情。SQLite 的优点在于它更容易安装和使用，而且所得到的数据库是一个单独的文件，可以写入一个 USB 记忆棒或者通过电子邮件发送给同事。
• 企业数据缓存(Cache for enterprise data)
  许多应用程序使用 SQLite 作为来自企业 RDBMS 的相关内容的缓存。这样可以减少延迟，因为现在大多数查询都是针对本地缓存进行的，从而避免了网络往返。它还降低了网络和中央数据库服务器的负载。在许多情况下，这意味着客户端应用程序可以在网络中断期间继续运行。
• 服务器端数据库(Server-side database)
  系统设计人员报告了成功使用 SQLite 作为数据中心运行的服务器应用程序上的数据存储，或者换句话说，使用 SQLite 作为特定于应用程序的数据库服务器的底层存储引擎。
  使用这种模式，整个系统仍然是client/server: 客户端向服务器发送请求，并通过网络获得回复。但是，客户端请求和服务器响应是的、特定于应用程序的，而不是发送通用的 SQL 并返回原始表内容。服务器将请求转换为多个 SQL 查询，收集结果，进行后处理、筛选和分析，然后构造一个只包含基本信息的应答。
  开发人员报告说，在这个场景中 SQLite 通常比client/server SQL 数据库引擎快。数据库请求由服务器进行序列化，因此并发性不是问题。通过“数据库分片”也可以改进并发性: 为不同的子域使用单独的数据库文件。例如，服务器可能为每个用户都有一个单独的 SQLite 数据库，这样服务器就可以处理数百或数千个并发连接，但是每个 SQLite 数据库只被一个连接使用。
• 数据传输格式(Data transfer format)
  因为 SQLite 数据库是一个定义良好的跨平台格式的单个压缩文件，所以它通常被用作从一个系统向另一个系统传输内容的容器。发送方将内容收集到一个 SQLite 数据库文件中，将一个文件传输到接收方，然后接收方根据需要使用 SQL 提取内容。
  SQLite 数据库促进了系统之间的数据传输，即使端点具有不同的word sizes和byte orders。数据可以是大型二进制 blob、文本和小型数值或布尔值的复杂混合。通过添加新的表或列，可以很容易地扩展数据格式，而不会破坏旧的接收器。SQL 查询语言意味着接收方不需要一次性解析整个传输，而是可以根据需要查询接收到的内容。数据格式是“透明的”，因为它可以很容易地被解码，以便使用来自多个供应商的各种普遍可用的开放源码工具进行人工查看。
• 文件归档或数据容器(File archive / data container)
  SQLite Archive 的想法展示了 SQLite 如何可以作为 ZIP 归档或 Tarballs 的替代品。存储在 SQLite 中的文件的归档文件只比等效的 ZIP 归档文件稍微大一点，在某些情况下甚至更小。SQLite 存档文件具有增量式和原子式更新以及存储更丰富的元数据的能力。
  Fossil 2.5及以后版本提供 SQLite Archive files 作为下载格式，以及传统的 tarball 和 ZIP 压缩文件。Exe 命令行 shell 版本3.22.0及更高版本将使用 archive command。
  SQLite 是一个很好的解决方案，可以用于任何需要将不同的内容捆绑到一个自包含和自描述的包中，以便通过网络装运的情况。内容以定义良好、跨平台和稳定的文件格式编码。编码是有效的，接收者可以提取内容的小子集，而不必读取和解析整个文件。
  SQL 归档作为向许多客户端广播的软件或内容更新的发布格式非常有用。这个想法的变种有许多场景，例如，传输电视节目指南到机顶盒，发送无线更新到车辆导航系统。
• 替换临时磁盘文件(Replacement forad hocdisk files)
  
  Many programs use fopen(), fread(), and fwrite() to create and manage files of data in home-grown formats. SQLite works particularly well as a replacement for these ad hoc data files. Contrary to intuition, SQLite can be faster than the filesystem for reading and writing content to disk.
  许多程序使用 fopen ()、 fread ()和 fwrite ()来创建和管理本地格式的数据文件。SQLite 作为这些特殊数据文件的替代品工作得特别好。与直觉相反，SQLite 可以比文件系统更快地将内容读写到磁盘。
• 内部或临时数据库(Internal or temporary databases)
  
  对于需要以不同方式筛选和排序大量数据的程序，将数据加载到内存 SQLite 数据库，并使用带有连接和 ORDER BY 子句的查询以所需的形式和顺序提取数据，而不是尝试手动编写相同的操作，这样做通常更简单、更快捷。以这种方式在内部使用 SQL 数据库还使程序具有更大的灵活性，因为可以添加新的列和索引，而不必重新编码每个查询。
• 测试期间代替企业数据库(Stand-in for an enterprise database during demos or testing)
  客户端应用程序通常使用通用数据库接口，该接口允许连接到各种 SQL 数据库引擎。将 SQLite 包含在支持的数据库组合中，并将 SQLite 引擎与客户机静态链接起来，这样做是很有意义的。通过这种方式，客户端程序可以与 SQLite 数据文件独立使用，用于测试或演示。
• 教育及培训(Education and Training)
  因为SQLite设置和使用非常简单(安装非常简单: 只需将 sqlite3或 sqlite3.exe 可执行文件复制到目标计算机并运行它) ，SQLite 为教授 SQL 提供了一个很好的数据库引擎。学生可以很容易地创建任意多的数据库，并且可以通过电子邮件将数据库发送给教师进行评论或打分。对于那些有兴趣学习如何实现 RDBMS 的学生来说，模块化的、注释良好的、文档化的 SQLite 代码可以作为一个很好的基础。
• 实验性 SQL 语言扩展(Experimental SQL language extensions)
  SQLite 简单、模块化的设计使它成为原型化新的、实验性的数据库语言特性或想法的好平台。

Client/Server RDBMS 可能工作得更好的情况

• 客户端/服务器应用程序(Client/Server Applications)
  如果有许多客户端程序通过网络将 SQL 发送到同一个数据库，那么使用client/server数据库引擎代替 SQLite。SQLite 将在网络文件系统上工作，但是由于大多数网络文件系统的延迟，性能将不会很好。此外，文件锁定逻辑在许多网络文件系统实现(在 Unix 和 Windows 上)中都存在缺陷。如果文件锁定不能正常工作，两个或多个客户端可能会同时修改同一数据库的同一部分，从而导致损坏。因为这个问题是由底层文件系统实现中的错误导致的，所以 SQLite 无法阻止它。
  一个好的经验法则是避免在可以直接访问同一个数据库(不需要中间的应用服务器)的情况下使用 SQLite，同时还可以从网络上的多台计算机上访问。
• 大容量网站(High-volume Websites)
  作为网站的数据库后端，SQLite 通常可以正常工作。但是，如果网站是写密集型的，或者太忙而需要多个服务器，那么可以考虑使用企业级client/server 数据库引擎，而不是 SQLite。
• 大数据量(Very large datasets)
  SQLite 数据库的大小限制为281 tb (terabytes)。即使它可以处理更大的数据库，SQLite 将整个数据库存储在一个单独的磁盘文件中，并且许多文件系统将文件的大大小限制在小于这个值的范围内。因此，如果您正在考虑这种规模的数据库，那么好考虑使用client/server数据库引擎，该引擎将其内容分散到多个磁盘文件，或许还可以分散到多个卷。
• 高并发(High Concurrency)
  SQLite支持无限数量的并发读取，但是它在任何时间只允许一个写入。在许多情况下，这不是一个问题。写入可以排队，因为大多数应用程序的数据库工作速度很快，锁持续时间小于几十毫秒。但是有些应用程序需要更多的并发性，这些应用程序可能需要寻找不同的解决方案。
• 来源 

https://zhuanlan.zhihu.com/p/440247972