我很难搞清楚基本的优化,并会欣赏一些见解,或者有人指出我正确的方向。
简化型号:
class TimeStampedModel(models.Model):
created = models.DateTimeField(auto_now_add=True, db_index=True)
modified = models.DateTimeField(auto_now=True)
class Meta:
abstract = True
class Venue(TimeStampedModel):
name = models.CharField(unique=True, max_length=200, db_index=True)
class Offer(TimeStampedModel):
venue_associated = models.ForeignKey(Venue, on_delete=models.CASCADE, db_index=True)
content = models.TextField(max_length=500, db_index=True)
简化视图:
class MapView(ListView):
fields = ["name"]
model = Venue
template_name = "venues/venue_map.html"
简化模板:
{% for venue in venue_list %}
{{ venue.name }}
{{ venue.offer_set.latest.created }}
{{ venue.offer_set.latest.content }}
{% endfor %}
这会产生大量的数据库调用(~400)。遍历整个venue_list只会创建一个单独的呼叫(+1没有关联),但两个offer_set呼叫会创建新的呼叫(每个200)。
因此,我假设为Venue模型创建一个单独的属性“最新”将有所帮助,因为它至少会处理“最新”呼叫加倍而不是。我也尝试过覆盖一般的ListView方法,这些方法没有让我到处找。
我可能没有看到这样做的方法。目前,我能想到的只是在Venue模型中添加其他字段以复制信息,并需要额外的逻辑来管理它。
修改
我试过了: queryset = Venue.objects.prefetch_related('offer_set')
所有这一切都是创建一个额外的查询:
SELECT ••• FROM "offers_offer" WHERE "offers_offer"."venue_associated_id" IN (1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, 20, 21, 22, 23, 24, 25, 26, 27, 28, 29, 30, 31, 32, 33, 34, 35, 36, 37, 38, 39, 40, 41, 42, 43, 44, 45, 46, 47, 48, 49, 50, 51, 52, 53, 54, 55, 56, 57, 58, 59, 60, 61, 62, 63, 64, 65, 66, 67, 68, 69, 70, 71, 72, 73, 74, 75, 76, 77, 78, 79, 80, 81, 82, 83, 84, 85, 86, 87, 88, 89, 90, 91, 92, 93, 94, 95, 96, 97, 98, 99, 100, 101, 102, 103, 104, 105, 106, 107, 108, 109, 110, 111, 112, 113, 114, 115, 116, 117, 118, 119, 120, 121, 122, 123, 124, 125, 126, 127, 128, 129, 130, 131, 132, 133, 134, 135, 136, 137, 138, 139, 140, 141, 142, 143, 144, 145, 146, 147, 148, 149, 150, 151, 152, 153, 154, 155, 156, 157, 158, 159, 160, 161, 162, 163, 164, 165, 166, 167, 168, 169, 170, 171, 172, 173, 174, 175, 176, 177, 178, 179, 180, 181, 182, 183, 184, 185, 186, 187, 188, 189, 190, 191, 192, 193, 194, 195, 196, 197, 198, 199, 200)
相同的400个查询(具有不同的id值)仍在运行:
SELECT ••• FROM "offers_offer" WHERE "offers_offer"."venue_associated_id" = 1 ORDER BY "offers_offer"."order" ASC, "offers_offer"."created" DESC LIMIT 1
答案 0 :(得分:1)
通常情况下,您可以使用 prefetch_related(..)
在额外查询中获取所有相关模型,因此我们可以将其添加到queryset
的{{1}}属性中}:
ListView
答案 1 :(得分:0)
您正在访问关系数据,在django中如果您使用正常查询访问相关数据,它将一次又一次地命中数据库命中。因此,您可以对特定关系使用prefetch_related查询,其中fetech用于该表的所有数据库,当您将迭代该项时,它将不会再次命中数据库。所有数据都将出现在一个查询中。
queryset = Venue.objects.prefetch_related('offer_set')
答案 2 :(得分:0)
Django提供了select_related
和prefetch_related
等结构来优化相关的对象查询操作。在你的情况下,它应该是:
queryset = Venue.objects.all().prefetch_related('offer_set')
对于最新项目,您是否尝试在ordering
模型中添加Venue
元值,如下所示:
class Offer(TimeStampedModel):
......
class Meta:
ordering = ['created']
{% for venue in venue_list %}
{{ venue.name }}
{% with venue.offer_set|first as first_offer %}
{{ first_offer.created }}
{{ first_offer.content }}
{% endwith %}
{% endfor %}
答案 3 :(得分:0)
当您将这些select
company.name,
((sum(compliance.status)/count(compliance.status)) * 100)/ count(gdpr_steps.id_step)
from
compliance, company, gdpr_steps
where
gdpr_steps.id_step = compliance.id_step
and company.id_company = gdpr_steps.id_company
group by
company.id_company;
转换为Queries
时,让我们对 Django 中的幕后实际情况进行更精细的分析。
Django ORM
是懒惰的,意思是:(根据Django Docs)
只有在执行以下任一操作时,才能评估在内部,可以构造,过滤,切片并通常传递QuerySet而不实际访问数据库。在您执行评估查询集的操作之前,实际上不会发生数据库活动。
Querysets
:
Querysets
,iteration
,slicing
,pickling
,repr()
,len()
或list()
好吧,在这里,如果我们看到您正在执行的SQL查询:
PS:您可以通过shell中的这段日志记录查看将访问数据库的SQL查询:
bool()
此处,在上述SQL查询中,除了import logging
l = logging.getLogger('django.db.backends')
l.setLevel(logging.DEBUG)
l.addHandler(logging.StreamHandler())
result_queryset = Venue.objects.all()
SELECT "venue"."id"......(all model fields)......FROM "venue";
的{{1}}之外,您不会看到任何related fields
个对象。
现在,如果您访问上述查询集的任何相关字段,ORM将再次访问数据库以获取它。这可以通过id
或ForeignKeys
(两者之间的差异here)来阻止
prefetch_related()
此外,每当您的模板需要select_related()
,result_queryset = Venue.objects.prefetch_related('offer_set')
# Django creates API accessors for the "other" side of the relationship
# Here, _set is used to access that "other" side i.e. related objects
A NEW SQL QUERY THAT FETCHES YOUR offer_set OBJECTS via a JOIN (that is how prefetch_related works)
,name
时,由于offer_set.latest.created
的惰性评估,它会点击数据库。
修改强>
由于您已编辑了问题,因此您希望所有offer_set.latest.content
个对象作为一个整体,并且不会有400个查询来查找您的数据库,我将建议一种非理想的方法做到了 -
事先评估您的查询集,然后将其作为上下文传递给模板。我已经提到了很多方法可以做到这一点。