การตรวจจับปัญหา N+1

The N+1 problem is when your code runs one query to get a list, then one more query for each item in it. 🐢

It usually hides in a loop over objects, where each pass quietly touches a related row in the database again and again.

Imagine listing books and printing each author. The loop below looks innocent but fires a fresh query on every line.

One query loads all books. Then each book.author access runs its own query, so 100 books means 101 trips to the database.

That is the name: 1 query for the parent list, plus N extra queries, one per related object you touch.

Django loads related rows lazily, only when you ask. Convenient for one object, painful when you ask inside a loop.

The damage grows with your data. Ten rows feel fine, but ten thousand rows turn one page load into a flood of queries.

A template that prints related data inside a for loop causes the exact same storm, even though no Python loop is visible to you.

Watch for a related-object access, like obj.parent, happening inside a loop. That pattern is the warning sign every time.

You can count queries directly with connection.queries during DEBUG, which proves how many round trips a view really makes.

Once you can see the problem, Django gives you two tools to collapse all those queries into just a few. You will meet them next. 🚀

Let us make sure the N+1 pattern is clear.

The N+1 problem is one list query plus one per related object, caused by lazy loading inside loops. Spot it by watching for related access in a loop. ✅