Entry.objects.filter()与get()工作原理及主键查询机制问询

Hey there! Let's dive into how Entry.objects.filter() and Entry.objects.get() operate in Django, and clear up your questions about full-table scans and primary key search processes.

Core Basics of filter() and get() #

First, it's critical to remember that Django's ORM uses lazy query evaluation. That means when you call filter() or get(), Django doesn't hit the database right away— it builds a QuerySet (for filter()) or prepares the query (for get()) and only executes the SQL when you actually need the results (like iterating over the QuerySet, accessing a model attribute, or calling list() on it).

• Entry.objects.filter(**kwargs): Returns a QuerySet containing all objects that match the given lookup parameters. If no objects match, you get an empty QuerySet. It can handle multiple matching objects without throwing an error.
• Entry.objects.get(**kwargs): Returns a single model object that matches the parameters. If no objects are found, it raises Entry.DoesNotExist; if multiple objects match, it raises Entry.MultipleObjectsReturned.

Do They Scan the Entire Database Line by Line? #

Short answer: Almost never, unless you force it with unindexed queries.

The actual query execution is handled by your database (PostgreSQL, MySQL, etc.), not Django itself. Django just translates your ORM calls into SQL. Here's what happens:

• If your query uses a field that has a database index (like the primary key, unique fields, or fields you've explicitly added db_index=True to), the database will use that index to jump directly to the matching rows— no full-table scan needed.
• If you query on an unindexed field (e.g., a regular CharField without indexes), the database might perform a full-table scan to find matches, but this is a database behavior, not an inherent flaw in Django's filter()/get().

Primary Key Lookup: Step-by-Step #

When you search by primary key (e.g., Entry.objects.get(pk=123) or Entry.objects.filter(pk=123)), here's the detailed process:

1. ORM Query Translation: Django converts your ORM call into a targeted SQL query. For get(pk=123), the SQL looks something like:

   SELECT * FROM entry WHERE id = 123 LIMIT 2;
   

   The LIMIT 2 is a safety check— Django uses it to detect if multiple rows match (which shouldn't happen for a primary key) and raise MultipleObjectsReturned if needed.
2. Database Index Usage: By default, Django adds a unique, clustered (depending on the database) index to the primary key field (id by default). The database uses this index to instantly locate the row with the matching primary key value— it doesn't scan every row in the table.
3. Result Handling:
   • For get(), Django takes the single row returned by the database, converts it into an Entry model instance, and returns it. If no rows are found, it raises the DoesNotExist exception.
   • For filter(pk=123), Django returns a QuerySet containing the single Entry instance. Since QuerySets are lazy, the SQL only runs when you access the contents of the QuerySet.

Quick Note on Performance #

Primary key lookups are the fastest possible database queries in Django (and most databases) because of the built-in index. If you're dealing with large datasets, always prefer indexed fields for your filter conditions to avoid full-table scans and keep your queries snappy.

内容的提问来源于stack exchange，提问作者sweta