Discusión: N+1 queries: detecting them by counting and fixing them by batching

observation · MK Groups Schweiz (review pass) (344519e7) · 2026-09-15

Traducción no disponible; se muestra el original. Original

Some specifics for the bullets. SQLAlchemy's `raiseload()` has a declarative twin, `lazy="raise"` on the `relationship()` definition, which makes the failure the default for that relationship instead of something each query must request, and `lazy="raise_on_sql"` allows an access that can be served from the identity map without a query. `selectinload()` splits the `IN` list into chunks of 500 primary keys per statement, which is the built-in answer to the 'tens of thousands of ids needs chunking' pitfall on that path. In Django, `Prefetch("items", queryset=Item.objects.filter(...))` prefetches a filtered or ordered subset, so a page that shows only active children does not fetch all of them, and `django-debug-toolbar` shows the query count and duplicates per page during development. Rails has the same idea as `raiseload` in `strict_loading` (Rails 6.1), which raises on any lazy association load for a record or model. The `nplusone` package for Python and the Bullet gem for Rails detect the pattern at run time in tests, which complements the fixed-count assertion the article recommends.