如果在生产和开发中使用不同的RDBMS（例如PostgreSQL），SQLite何时不应该用于在Django中进行测试？

Question

This article建议使用SQLite进行测试，即使您在开发和生产中使用另一个RDBMS（我使用PostgreSQL）。我在一个测试用例中尝试了SQLite，它确实运行得更快（大约18.8倍，0.5秒对9.4秒！）。

在哪些情况下，使用SQLite会导致不同的测试结果，而不是使用PostgreSQL？

只有我测试一段包含raw SQL query的代码？

Answer 1

任何时候，尽管查询生成器的平台抽象努力，查询生成器可能会生成在不同平台上行为不同的查询。正则表达式，排序规则和排序的差异，关于聚合和分组的不同严格程度，使用全文搜索或其他扩展功能，使用除了最简单的函数和操作符之外的任何东西等。

另外，正如您所指出的，只要您运行原始SQL。

在迭代开发期间在SQLite上运行测试是合理的，但是你真的需要在推送到生产之前在你要部署的同一个数据库上运行它们。否则你将get bitten by some query where different engines have different capabilities to prove transitive equality through joins and GROUP BY或者对查询的许可不同，因此一个查询将在一个查询上运行，然后在另一个查询上失败。

在推送更改之前，您还应该在合理的数据集上对PostgreSQL进行测试，以便找到明显的性能回归，这将是生产中的一个问题。在SQLite上执行此操作毫无意义，因为SQLite通常会有快速或慢速的查询。

我很惊讶你看到你报告的那种速度差异。我想查看为什么测试在PostgreSQL上运行得如此之慢以及你能做些什么，因为在生产中它显然不会有同样的性能差异。我在optimise PostgreSQL for fast testing中写了一些相关内容。

Answer 2

在大多数情况下，性能特征会有很大差异。通常更快。它通常适用于测试，因为SQLite引擎不需要考虑多个客户端访问。 SQLite只允许一个线程一次访问它。与其他RDBMS相比，这大大减少了大量开销和复杂性。

就原始查询而言，与Postgres或其他RDBMS相比，SQLite不支持许多功能。尽可能远离原始查询，以保持代码的可移植性。例外情况是您需要针对生产优化特定查询。在这些情况下，您可以在settings.py中设置一个设置，以检查您是否正在制作并运行通用filters而不是原始查询。有许多类型的通用原始查询，但不需要这种检查。

此外，SQLite DB只是一个文件这一事实，它使得拆卸和重新开始测试变得非常简单。