П’ять SQL-патернів, які замінюють цикл на Python — і чому вони виграють

Найдорожчий Python, який я рев’юю, — не хендлер FastAPI без типів. Це for order in orders, який живе, бо ніхто не написав віконну функцію. Цикл виглядає чесно. Так само звіт, що тривав чотири секунди, стає сорока, а в понеділок після вдалого вікенда продажів — таймаутом.

Я вже писала, як обираю тип бази. Це наступний шар: SQL, який я справді пишу, коли питання продукту — «останнє замовлення клієнта», «виручка цього місяця проти минулого» або «встав бронювання, якщо слот вільний». Postgres відповідає за один round trip. Python теж — після того як завантажив таблицю. Парна стаття — як цей запит має вийти з Python, не тягнучи купу назад.

1. Цикл, який завантажує таблицю

Типовий скрипт: SELECT * FROM orders, далі групування в dict, далі найсвіжіший created_at на customer_id. На 800 рядках здається нормальним. На 800 000 — це тікет у підтримку. База вже має індекс, сортування і пам’ять для цього. Ви за це заплатили. Python як другий рушій запитів — так вартість вилазить у затримці, не в рахунку, який планували.

• Якщо результат менший за джерело, а правило має назву — last, sum, rank, exists — це запит.
• Якщо правило — бізнес-есе (повернення з людським винятком, абзац політики) — може лишитись у Python.

2. Останній рядок у групі — DISTINCT ON і ROW_NUMBER

Поточна підписка на робочий простір. Останній статус інвойсу на замовлення. Водій, який пінгував востаннє. Це перший цикл, який я видаляю. У Postgres пишу DISTINCT ON (workspace_id) і ORDER BY workspace_id, created_at DESC. Портативний родич — ROW_NUMBER() OVER (PARTITION BY workspace_id ORDER BY created_at DESC), далі лишаю rn = 1.

DISTINCT ON коротший, і я ставлю його, коли Postgres мій. ROW_NUMBER пишу, коли той самий запит має пережити переїзд, або коли потрібні ранг 1 і 2 — попередній план, другий результат. Не тягніть усі підписки й не зводьте їх у Python. На нічиїх помилитеся і завантажите колонки, які ніколи не малюєте.

3. Накопичувальні суми і «з минулого місяця» — SUM OVER і LAG

Місяць до місяця — не джойн таблиці на себе всередині циклу. LAG(revenue) OVER (PARTITION BY workspace_id ORDER BY month) кладе минулий місяць у той самий рядок. SUM(amount) OVER (PARTITION BY customer_id ORDER BY created_at) — накопичувальний баланс. Віконні функції лишають зерно рядка і все одно бачать сусідів. GROUP BY згортає. Цикл на Python збирає сусідів у dict і забуває часові пояси.

Якщо потрібні і детальний рядок, і підсумок групи, SUM(amount) OVER (PARTITION BY order_id) б’є другий запит і б’є N+1 з ORM. Увесь трюк: лишити зерно, яке малюватимете, а сусідство порахувати в рушії.

4. Умовні лічильники — FILTER замість if

COUNT(*) FILTER (WHERE status = paid) поруч із COUNT(*) FILTER (WHERE status = refunded) — один прохід. Версія на Python — один прохід і два лічильники, доки хтось не додасть третій статус у другому циклі або експорт не виросте і ви не пройдете двічі. FILTER читається. CASE у SUM працює на рушіях без FILTER. У Postgres я ставлю FILTER, бо намір на сторінці: цей підрахунок має предикат.

5. Upsert замість select-потім-insert

Гонка: прочитати «чи вільний цей email», потім вставити. Дві вкладки, два воркери, один unique, який знаходите в проді. INSERT ... ON CONFLICT (email) DO UPDATE — або DO NOTHING — транзакція, яку база вже вміє. Та сама родина: UPDATE ... WHERE version = $version для оптимістичного лока. Check-then-write у Python — це гірша база, написана вручну.

• Слоти бронювання, ключі ідемпотентності, «створи клієнта, якщо немає» — це upsert, не if.
• Унікальний індекс — частина продукту. Без нього ON CONFLICT — театр.

6. Як я перевіряю, що не вигадала повільніший запит

EXPLAIN (ANALYZE, BUFFERS) на повільному шляху. Якщо бачите sequential scan на таблиці, яка виросла, потрібен індекс під партицію і порядок — (workspace_id, created_at DESC) для DISTINCT ON. Віконна функція не безкоштовна. Вона все одно дешевша за відправку купи в застосунок. Якщо план сортує два мільйони рядків для дашборда на двадцять — додайте межу по даті. SQL, що замінює цикл, усе ще може бути поганим циклом усередині рушія.

Висновок: назвіть результат — напишіть запит

Python — добре місце для HTTP, політик і речення, яке бачить користувач. Погане місце, щоб заново винаходити GROUP BY. П’ять форм — last-per-group, lag, накопичувальна сума, умовні агрегати, upsert — і більшість «розумних» скриптів, які я рев’юю, стають в’ю або одним запитом у функції репозиторію. Інша стаття — Python, який відмовляється це скасувати.