Wie würdest du ein N+1-Query-Problem in einer Django-App aufspüren und beheben?

Bestätige es zuerst, indem du Queries zählst, lokal mit der Django Debug Toolbar oder mit assertNumQueries in einem Test. Das Muster ist eine Schleife, die ein verknüpftes Objekt anfasst, was pro Zeile eine Query auslöst, weil Querysets lazy sind. Vorwärtsbeziehungen behebst du mit select_related, das einen Join macht, umgekehrte oder Many-to-Many-Beziehungen mit prefetch_related, das eine zusätzliche Query fährt.

Messen kommt zuerst, denn ORM-Performance zu raten ist ein verschwendeter Nachmittag. Lokal schalte ich die Debug Toolbar ein oder logge Queries auf Debug-Level, und wenn es schon in Produktion ist, schaue ich in den Trace, wo ein Endpunkt, der vierhundert fast identische Selects abfeuert, unverkennbar ist. Die Ursache ist, dass ein Queryset die Datenbank erst anfasst, wenn du darüber iterierst, und der Zugriff auf einen Foreign Key pro Zeile diese Beziehung lazy nachlädt. Für einen Vorwärts-Foreign-Key ergänze ich select_related, was daraus einen Join und eine Query macht. Für umgekehrte oder Many-to-Many-Beziehungen nehme ich prefetch_related, das eine zweite Query absetzt und die Ergebnisse in Python zusammennäht. Nach dem Fix schreibe ich einen Test, der die View in assertNumQueries mit der erwarteten Zahl wickelt, denn sonst fügt der Nächste ein Template-Feld hinzu und es regressiert still. In einem internen Dashboard sind wir bei einer Seite von rund dreihundert Queries auf vier gekommen, und die Ladezeit ging von etwa zwei Sekunden auf unter zweihundert Millisekunden.