关于 SQLite 的基础介绍本文就不再赘述，想要了解的请自行百度。接下来说一下一些使用经历。
SQLite 数据库在一开始学习 Flask 的时候我就使用过，那时候用它是因为在 Windows 环境下搭建 MySQL 环境过于复杂，同时为了方便调试程序方便而折中采用了这个方案。
随着接触的东西变多，慢慢的更加认识到 SQLite 魅力所在。其实很多时候完全没必要上 MySQL 数据库，因为很多程序、网站实际的数据量并不多，而且是运行在单机环境下的。很多的小型网站、甚至是中型网站完全也可以采用 SQLite 作为数据库。
在搭建网站的时候，关于数据库可以有以下几种选项
- 购买一台服务器，搭建网站，数据库选择 SQLite。
- 购买一台服务器，既搭建 MySQL，又搭建网站。
- 购买两台服务器，一台搭建 MySQL，一台搭建网站。
- 购买云数据库，再购买一台服务器搭建网站。
我目前做的项目均是采用最后一种方式，因为这种方式可以一个数据库给多个后端应用程序调用。但如果是一个小型网站的话，完全可以采用第一种方式，既省钱（每个月60），又可以提升服务器的性能（减少一次数据库调用）。
TIP
数据量在 10W 以下，每日调用在 10W 次以下，都可以理解为小型网站。实际上数据量与调用次数提升 10 倍，SQLite 数据库也是可以支撑的住。
同时在单机的情况下，可以少去搭建 MySQL 数据库的麻烦、减少服务器资源消耗。同时作为文件型数据库，操作起来非常方便，同时不会暴露端口也没有被黑客攻击的危险。
SQLite 与 MySQL 对比
在做网站的时候，很多时候大家都会选择 MySQL 作为数据库，然后在大多数情况下，其实都可以使用 SQLite 代替 MySQL，接下来我们就对比一下它们俩在做网站程序的差异。
| MySQL | SQLite | |
|---|---|---|
| 版权 | 开源免费 | 开源免费 |
| 运行环境 | 需要一个服务器，遵循客户端/服务器架构。 | 文件型数据库，不需要服务器。 |
| 内存占用 | 需要大约 600Mb 的内存空间(可优化)。 | 需要大约 (250Kb-300Kb)的空间。 |
| 处理方式 | 可以同时处理多个连接。 | 一次只能处理一个连接。 |
| 拓展性 | 具有高度可扩展性，可以非常高效地处理大量数据。 | 随着数据量上升，其性能会下降（建议100W以下） |
| 使用方式 | 需要安装第三方库。 | 编程语言原生支持。 |
在当你的网站不是很大时，完全可以采用 SQLite 代替 MySQL 。同时因为关系对象模型（ORM）的存在，在会使用 MySQL 的情况下，ORM 工具完全可以抹平新技术的学习成本。
我一般是使用 flask-SQLAlchemy 开发 Web 程序，使用 MySQL 还是 SQLite 只要修改一下 SQLAlchemy 的数据库连接地址就可以实现自由切换。而对于数据库的操作，只要专注于模型的定义与方法的使用即可，一点儿也不用担心 SQLite 与 MySQL 之间的语法差异。
SQLite 的使用场景（翻译）
翻译不完整，更多详情请见原文。原文地址见附录。
SQLite 不能直接与 C/S 架构的 SQL 数据库（如 MySQL、Oracle、PostgreSQL 或 SQL Server）相比较，因为 SQLite 试图解决的是不同的问题。
C/S 架构的数据库致力于实现数据的共享存储，它们强调可扩展性、并发性、集中化和控制。 SQLite 致力于为单个应用程序和设备提供本地数据存储。 SQLite 强调经济、效率、可靠性、独立性和简单性。
适合 SQLite 的场景
网站
SQLite 作为大多数中低流量网站的数据库引擎非常好用。SQLite 能够处理的网络流量数量取决于网站对其数据库的使用程度。一般来说，任何一个点击率低于 100K/天 的站点都可以使用 SQLite。10万点击量/天数 是一个保守的估计，而不是一个硬上限。SQLite 已经被证明可以处理 10 倍于此的流量。
当然，SQLite 网站( https://www.SQLite.org/)也是使用 SQLite ，在撰写本文(2015)时，它每天处理大约 40 万到 50 万个 HTTP 请求，其中大约 15% 到 20% 是触及数据库的动态页面。动态内容每个网页使用大约 200 个 SQL 语句。这个设置运行在一个与其他 23 个服务共享一个物理服务器的虚拟机上，但大多数时候仍然将平均负载保持在0.1以下。
嵌入式与物联网设备
因为 SQLite 数据库几乎不需要管理，因此对于那些无人值守运行或者无人工技术支持的设备，SQLite是一个很好的选择。SQLite 非常适合运行在手机、机顶盒、电视、游戏机、照相机、厨房电器、恒温器、汽车、飞机、遥控器、无人机、医疗设备和机器人等物联网设备之中。
C/S 架构的数据库就是为网络数据中心而精心设计。SQLite 也可以运行在网络环境里面，并且在一些场景下蓬勃发展，为一些原本不可靠的连接提供数据服务。
应用程序文件格式
SQLite 通常作为桌面应用程序的本地磁盘文件格式，例如版本控制系统、金融财务分析工具、视频媒体编目和编辑套件、 CAD 包、记录保存程序等。
数据分析
了解 SQL 的人可以使用 SQLite 命令行（或者第三方工具）来分析大量的数据。也可以从 CSV 文件导入原始数据，然后对这些数据进行处理，用来生成无数的简要报告。更复杂的分析也可以通过使用 Tcl 或者 Python 编写脚本，使用 R 语言或其他语言进行处理，大多数语言都已经适配了 SQLite 可以直接使用。可以完成的任务包含网站日志分析、体育统计分析、编程指标汇编和实验结果分析。许多生物信息学研究人员以这种方式使用 SQLite。
当然，对于 C/S 架构的数据库也可以这样做。SQLite 的优点是更容易安装和使用，并且生成的数据库是一个单独的文件，可以写入 USB 或通过电子邮件发送给同事。
企业数据缓存
许多应用程序使用 SQLite 作为企业数据库管理工具中相关内容的缓存。这减少了延迟，因为现在大多数查询都是针对本地缓存进行的，可以避免网络延迟。它还减少了网络和中央数据库服务器上的负载。在许多情况下，这意味着客户端应用程序可以在网络中断期间继续运行。
服务器数据库
系统设计人员报告称，成功地将 SQLite 用作数据中心中运行的服务器应用程序的数据存储，或者换句话说，使用 SQLite 作为特定于应用程序的数据库服务的底层存储引擎。
使用这种模式，整个系统仍然是 C/S 架构：客户端向服务器发送请求，并通过网络得到回复。但是，客户端请求和服务器响不是发送一般的 SQL 和获取原始表内容，而是高级的、特定于应用程序的指令（译者推测是类似 RPC 协议的东西）。服务器将请求转换为多个 SQL 查询，收集结果，进行后处理、筛选和分析，然后构造只包含基本信息的高级回复。
开发人员报告说，在这种情况下，SQLite 通常比 C/S 架构数据库引擎更快。数据库请求是由服务器序列化的，因此并发性不是问题。并发性也通过“数据库分片”得到了改善：为不同的子域使用单独的数据库文件。例如，服务器可能为每个用户都有一个单独的 SQLite 数据库，这样服务器就可以处理数百或数千个同时连接，但每个 SQLite 数据库只能由一个连接使用。
在 Demo 或测试的时候作为企业级数据库的替代品
如果你正在编写一个使用企业级数据库引擎的客户端程序，使用一个允许你连接不同 SQL 数据库引擎的通用型数据库后台将是很有意义的。 这样，客户机程序就可以与 SQLite 数据文件独立使用，用于测试或演示。
教育与培训
因为它的设置和使用很简单（安装很简单：只需将 sqlite3 或 sqlite3.exe 可执行文件复制到目标计算机并运行即可），SQLite 是一个很好的数据库引擎，可用于 SQL 教学。学生可以轻松创建任意数量的数据库，并可以通过电子邮件将数据库发送给讲师进行评论或评分。对于那些有兴趣研究如何实现 RDBMS 的高级学生来说，模块化的、注释良好的和文档化的 SQLite 代码可以作为一个很好的基础。
适合 C/S 架构数据库的场景
C/S 架构的应用程序
如果有许多客户端程序通过网络将 SQL 指令发送到同一个数据库，那么使用 C/S 架构的数据库引擎而不是 SQLite。SQLite 将在网络文件系统上工作，但是由于与大多数网络文件系统相关的延迟，性能不会很好。此外，在许多网络文件系统实现中(在 Unix 和 Windows 上) 文件锁定逻辑存在错误。如果文件锁定无法正常工作，两个或多个客户端可能会尝试同时修改同一数据库的相同部分，就会导致损坏。因为这个问题是由底层文件系统实现中的错误引起的，所以 SQLite 无法阻止它。
一个很好的经验法则是，在同一数据库可以直接访问(没有中间的应用程序服务器)并且可以从网络上的多台计算机同时访问的情况下，避免使用 SQLite。
多个网站
SQLite 作为网站的数据库后端，通常可以正常工作。但是，如果网站是读写密集型或者繁忙到需要多台服务器，那么可以考虑使用 C/S 架构数据库而不是 SQLite。
非常大的数据集
SQLite 数据库的大小限制为 281 TB (2的48次方字节，256tibibytes)。而且即使 SQLite 可以处理更大的数据库，它也会将整个数据库存储在一个磁盘文件中，而且许多文件系统将文件的最大大小限制在不超过这个值的地方。因此，如果您正在考虑这种规模的数据库，那么最好考虑使用一个 C/S架构的数据库引擎，该引擎可以将其内容分散到多个磁盘文件中，也许还可以分散到多个卷中。
如何正确的选择数据库？
1、数据是否通过网络与应用程序分离? → 选择 C/S 架构数据库
关系数据库引擎起到减少带宽的数据过滤器的作用。因此，最好将数据库引擎和数据保持在同一个物理设备上，这样高带宽引擎到磁盘的链接就不必穿越网络，只需穿越低带宽应用程序到引擎的链接。
但是 SQLite 是内置在应用程序中的。因此，如果数据位于与应用程序分开的设备上，则需要跨网络的更高带宽引擎到磁盘的链路。这是有效的，但是不是最优的。因此，当数据位于与应用程序分离的设备上时，通常最好选择 C/S 架构的数据库引擎。
2、高并发写入? → 选择 C/S 架构数据库
如果许多线程和/或进程需要同时编写数据库(它们不能排队轮流编写) ，那么最好选择支持这种功能的数据库引擎，这就意味着是 C/S 架构的数据库引擎。
SQLite 对每个数据库文件一次只支持一个编写器。但在大多数情况下，写事务只需要几毫秒，因此多个写入器可以简单地轮流执行。SQLite 将处理比许多人想象的更多的写并发。然而，由于 C/S 架构的数据库系统有一个长时间运行的服务器进程来协调访问，因此它们通常可以处理比 SQLite 更多的写并发。
3、大量的数据? → 选择 C/S 架构数据库
如果你的数据将增长到不适合或无法放入单个磁盘文件的大小，那么您应该选择 SQLite 以外的解决方案。SQLite 支持最大 281TB 的数据库，前提是您可以找到支持 281TB 文件的磁盘驱动器和文件系统。即便如此，当内容的大小看起来可能会慢慢进入 TB 范围时，最好考虑一个集中的 C/S 结构的数据库。
4、否则 → 选择 SQLite！
对于具有低并发性写入和少于 1TB 内容的设备本地存储，SQLite 几乎总是一个更好的解决方案。SQLite 快速可靠，不需要配置或维护。这样事情就简单多了。
附录
SQLite 官网： https://www.sqlite.org/index.html
SQLite 的使用场景： https://www.sqlite.org/whentouse.html