Django查询优化何时使用sql和何时使用python

Question

我在寻找一个通用的经验法则，即何时可以更快地重新查询数据库，何时可以更快地使用python并从缓存中提取数据。在

假设我需要同时从数据库中提取两个东西：所有的披萨和pk=5的特定披萨。在

更优化的是：

pizzas = Pizza.objects.all()   
specific_pizza = Piazza.objects.get(pk=5)

或者

^{pr2}$

当然这取决于数据库。例如，如果pizzas是1000万行，那么重新查询sql显然更好；如果pizza是10行，即使字段被索引，python可能更快。在

有人能帮到中档更优化的吗？例如，披萨是成百上千的行？几千排？在

Answer 1

这个问题没有明确的答案——正如你所说，这取决于数据库（可能还有它的位置、表的数量和大小……）。你必须在特定的环境下进行测试。在

除了原始速度外，使用第一个版本还有一些重要的优点：

• 它更短更清晰
• ORM确切地知道您想要什么，因此可以在该级别上进行任何进一步的优化，而不是将它们推送到应用程序中
• 它可以避免在您的web服务器上进行（潜在的）密集计算

另外，一些值得思考的问题：如果您的表足够小，以至于python比DB快，那么速度是否重要？在

您可能需要阅读过早优化

Answer 2

我很感激@ch3ka和@goncalopp的回答，但我不认为他们直接回答了这个问题，所以我给自己拍了一张照片：

总而言之，我发现python查找与sql的查找差不多，大约有1000个条目：

假设我已经查询了数据库，收到了1000个比萨饼：

pizzas = Pizza.objects.all()

我做了两个测试：

测试1： 在1000个披萨中找到一个特定的披萨，使用pk：

^{pr2}$

用了0.2毫秒

测试2： 根据pizza的成员进行筛选，然后创建一个新列表：

mushroom_pizzas=[pizza for pizza in pizzas if pizza.topping==Pizza.MUSHROOM]

蘑菇是一种可能的配料。我选择了enum，因为我认为它与索引DB字段进行了正确的比较

用了0.3毫秒

使用Django调试工具栏，一个简单的索引sql查询所需的时间大约为0.3毫秒。在

我确实认为像@goncalopp和@ch3ka一样，由于简单的索引查询已经是0.3毫秒，所以使用python进行优化是没有意义的。因此，即使我事先知道条目数将少于1000条，甚至远远少于1000条，我仍然会使用sql。

如果我计算错误或得出错误的结论，我将非常感谢你的评论。在

Answer 3

for example, if pizzas are 10 million rows, it's obvious that re-querying sql is better, and if pizzas are 10 rows, even if the field is indexed, python is probably faster.

好吧。。。第一句话：是的。第二句话：不确定，但也不重要。 因为当比萨很少的时候，“奈特”的指挥会花很长时间。在

Can anyone help what's more optimized in the middle range?

我想并不像你预期的那样，但是是的：因为我们同意当有很多披萨的时候使用.get()会更快，而且我们看到当有很多比萨饼的时候，性能只是一个问题，考虑到将来比萨的数量可能会增长，我想我们可以同意使用.get()是正确的做法。在

撇开性能不谈——它显然也更具可读性，所以你真的应该走这条路。在

另外，请注意，您可以在QuerySet（.all()返回QuerySet！）过滤你想要的。它的工作原理是“幕后的魔力”——因此假设在找到与该假设不符的证据之前会得到优化。所以你应该使用这些方法，直到你达到了真正需要优化的时候。如果你达到了这一点，你就可以进行基准测试，得到一个可靠的答案。在