¿Cómo localizarías y arreglarías un problema de consultas N+1 en una aplicación Django?

Primero confírmalo contando consultas, con Django Debug Toolbar en local o con assertNumQueries en un test. El patrón es un bucle que toca un objeto relacionado, lo que dispara una consulta por fila porque los querysets son perezosos. Arregla las relaciones directas con select_related, que hace un join, y las inversas o de muchos a muchos con prefetch_related, que lanza una consulta extra.

Lo primero es medir, porque adivinar el rendimiento de un ORM es tirar una tarde. En local activo la debug toolbar o logueo las consultas a nivel debug, y si ya está en producción miro la traza, donde un endpoint que lanza cuatrocientos selects casi idénticos es inconfundible. La causa es que un queryset no toca la base de datos hasta que lo iteras, y acceder a una clave foránea en cada fila trae esa relación de forma perezosa. Para una clave foránea directa añado select_related, que lo convierte en un join y una sola consulta. Para relaciones inversas o de muchos a muchos uso prefetch_related, que lanza una segunda consulta y cose los resultados en Python. Una vez arreglado, escribo un test que envuelve la vista en assertNumQueries con el número esperado, porque si no la siguiente persona añade un campo en la plantilla y vuelve a degradarse en silencio. En un panel interno pasamos una página de unas trescientas consultas a cuatro, y el tiempo de carga bajó de unos dos segundos a menos de doscientos milisegundos.