我应该使用 SQLite 而不是 MySQL 吗？

Question

我需要改进一个PHP-MySQL网络应用程序，它仅使用MySQL进行REPL操作（和一些搜索功能）。 我所处理的99％应用程序从未使用过高级的MySQL功能，例如复制，跨表约束，锁定等。

据我了解，我应该改用SQLite。

如果我这样做，是否有任何实际好处？ 我会看到显着（> 100ms）的速度提升吗？ 我是否应该期望在超过1,000,000行的表中遇到问题？

- Silviu-Marian

---

你在使用MySQL时遇到了什么问题吗？ - PeeHaa

@PeeHaa 不是的。但我很好奇是否会有任何好处——性能、简单性——那种东西。 - Silviu-Marian

虽然这篇文章是2008年的，但它仍然有参考价值：http://stackoverflow.com/questions/3630/sqlite-vs-mysql - PeeHaa

它们是为不同场景设计的两个不同的数据库.. 不具建设性。快速的谷歌搜索应该能够澄清何时一个或另一个或两者在特定任务/方法中最合适。 - user166390

Answer 1

没有一个通用的答案，但需要考虑一个主要问题：一个很好的经验法则是，并发程度越高，你从MySQL中获得的利益就越大，反之亦然。

这意味着，在数据库请求永远不会并发的情况下，使用SQlite可能会看到加速，尽管我怀疑它的数量级不会达到100ms。

其背后的原因是（非常粗略地）：

在数据库服务器环境中，例如MySQL、PostgreSQL、MS SQL、Oracle和朋友们，专用进程（或一组进程）专门触碰数据库文件 - 重要的部分是专用。这意味着，并发问题可以通过进程内解决。

在基于文件的数据库中，例如SQlite、MS Access（Jet Engine）和朋友们，多个进程将触及DB文件而不知道对方 - 这意味着并发问题必须通过将它们写入DB或帮助文件来解决。这通常要慢得多，不太健壮。作为交换，数据库客户端（Web应用程序）与数据库服务器（位于进程内）之间的通信开销不存在。

编辑

在评论之后，我想更清楚地表明，我谈论的是并发写入，而不是并发读取。未更改数据集的并发读取不是一个严重的问题 - 它根本不需要任何锁定。

- Eugen Rieck

---

@pst 更新了我的答案，更清楚地表明我谈论的是写入而不是读取。 - Eugen Rieck

关于健壮性，我的观点是，故障弹性和性能之间的权衡仍然更有利于数据库服务器而不是基于文件的数据库。每个遇到过SQlite在非正常关闭后出现“数据库锁定”并需要手动干预的人可能会持有相同的观点，而我还没有开始研究其他基于文件的数据库成员。这绝对不是对SQlite的批评：我认为SQlite是这个家族中非常优秀的成员，我经常使用它。 - Eugen Rieck

SQLite是符合ACID标准的，非常健壮。极少数边缘情况已在http://sqlite.org上有所记录 - 除了硬件或关键文件系统故障（这对MySQL等也同样适用），没有任何问题。 - user166390

我希望现在已经表达得足够清楚了！请理解，英语不是我的母语。 - Eugen Rieck

我认为这是一个公正的回答（我给了+1，尽管我怀疑这个问题会被关闭）。我正在反驳“这通常会慢得多且不够健壮。” :) SQLite 的支持者（比如我）强烈反对这一点；如果 SQLite 不够健壮，那么它就不能声称自己是 ACID。 - user166390

Answer 2

SQLite的主要优势在于它是一个基于文件的关系型数据库，使用SQL作为其查询语言。基于文件的部署方式极大地简化了部署过程，使得它非常适合应用程序需要一个小型数据库但必须在无法使用数据库服务器的环境中运行的情况。（例如，许多浏览器使用SQLite来管理其Cookie存储；在这种情况下使用数据库服务器会在很多方面都变得非常疯狂。）

MySQL（使用合理的表类型）的主要优势在于它是一个使用SQL作为其查询语言的数据库服务器。基于服务器的方式允许处理许多文件系统无法简单处理的功能（例如复制），但也使得部署变得更加复杂。

无论是否比起基于文件的数据库引擎（如SQLite），使用数据库服务器（例如MySQL）的额外复杂性的好处是否超过成本，都取决于许多因素，尤其是预计有多少安装以及谁将执行这些安装。

- Donal Fellows