#оптимизация_запросов — Public Fediverse posts

Меньше индексов, дешевле запись: как я научил PostgreSQL пересекать B-tree индексы с сохранением порядка

TL;DR. Я написал расширение для PostgreSQL 18, postgresql-leapfrog . Оно добавляет в планировщик новый узел, Index Merge Intersect: упорядоченное пересечение нескольких обычных B-tree индексов, которое останавливается на LIMIT . В результате таблице не нужен отдельный составной индекс под каждую комбинацию фильтров. На тестовой схеме с 12 фильтрами это 14 индексов вместо 33, вдвое меньше места под индексы и втрое меньше WAL на вставке. Проект экспериментальный (0.0.3), в конце статьи честно перечислено, чего он пока не умеет.

https://habr.com/ru/articles/1099544/

#postgresql #индексы #оптимизация_запросов #btree #wal #планировщик_запросов #расширения_postgresql #index_merge #custom_scan

crm.item.list заблокирован, а портал работает: откуда в Битрикс24 берётся 429 OPERATION_TIME_LIMIT

Выгрузка сделок из Битрикс24 годами работает без проблем, а потом начинает тормозить и возвращать HTTP 429. Увеличение пауз между запросами не помогает, хотя остальные методы REST API продолжают отвечать как обычно. Разбираемся, как устроен лимит OPERATION_TIME_LIMIT , куда уходит серверное время и как ускорить выгрузку в сотни раз. Разобраться с лимитами

https://habr.com/ru/companies/otus/articles/1096470/

#оптимизация_запросов #rest_api #битрикс24 #выгрузка_данных #лимиты_api #интеграция_битрикс24 #http_429 #operation_time_limit #crmitemlist #пакетная_обработка_запросов

Поиск узких мест в Oracle с помощью ASH/AWR и LLM

Добрый день, всем любителям Oracle и пирогов из картофельных очистков! Одна из самых часто встречающихся проблем при использовании баз данных - это поиск узких мест: нахождение долго выполняющихся запросов и их исправление. Как часто вы сталкивались с ситуацией, когда запрос мгновенно отрабатывает в тестовом окружении, но начинает «тормозить» на боевом сервере? Или замедление запросов проявляется не сразу, а по мере роста данных? Я написал open-source утилиту Optimus Oracle. Она получает тяжёлые SQL-запросы из ASH/AWR, собирает планы и через LLM (локальные или облачные) предлагает оптимизацию: создание индексов или изменение запроса. Дальше - реальные примеры «до/после», цифры, грабли и честный разговор о приватности.

https://habr.com/ru/articles/1095954/

#open_source #sql #python #oracle #оптимизация_запросов #awr #llm #ash

Почему накопительная сумма в SQL врёт

Оконные функции часто дают результат, который выглядит правильным: итоговая сумма сходится, запрос проходит проверку, а ошибка проявляется только спустя время. Проблема скрывается в деталях работы рамки окна — без явной настройки СУБД сама выбирает правила расчёта, из-за чего одинаковые строки могут получать неожиданные значения. Разберём, как найти причину такого поведения в PostgreSQL, чем отличаются ROWS , RANGE и GROUPS , и какие настройки помогают получить предсказуемый результат в рабочих запросах.

https://habr.com/ru/companies/otus/articles/1087296/

#sql #PostgreSQL #оконные_функции #накопительные_суммы #оптимизация_запросов #CTE #обработка_данных #аналитические_функции #подзапросы

Диагностика медленных запросов в 1С: от технологического журнала до плана в SSMS

Разрабатываю отчёт, проверяю на тестовых данных — всё быстро. Передаю заказчику — три минуты ожидания. Знакомая ситуация. Первый инстинкт — переписать запрос, добавить индекс, сузить период. Это угадывание, и оно редко помогает с первой попытки. За несколько лет я выработал маршрут, который по моему опыту даёт конкретный ответ за 10–15 минут без привлечения DBA: читать не 1С-код, а план выполнения SQL-запроса, в который платформа его превращает.

https://habr.com/ru/articles/1083712/

#1С #SQL #план_запроса #технологический_журнал #оптимизация_запросов

Индекс как алфавитный указатель: как база ищет и почему иногда не находит

В первой статье я объяснял кэш через холодильник. Продолжу тем же способом. Сейчас будет про индексы, а потом про то, почему индекс есть, а база его игнорирует. Статья для тех, кто индексы ставил, но EXPLAIN читал по диагонали.

https://habr.com/ru/articles/1075958/

#postgresql #индексы #explain_analyze #btree #составной_индекс #план_запроса #seq_scan #index_scan #оптимизация_запросов #sql

За полгода мы проанализировали 7,79 млн SQL-запросов: какие СУБД и версии встречались чаще

За первое полугодие 2026 года мы проанализировали 7,79 млн SQL-запросов с нескольких тысяч серверов. В статье описали распределение по семействам СУБД и major-версиям.

https://habr.com/ru/articles/1075158/

#database_optimization #query_optimization #оптимизация_запросов #mysql #postgresql #mariadb #mysql_performance #postgresql_performance

Четыре антипаттерна CTE в PostgreSQL: разбираем на EXPLAIN ANALYZE

CTE в PostgreSQL упрощают код, но могут снижать производительность. Разбираем 4 антипаттерна, примеры EXPLAIN ANALYZE и практические способы оптимизации. В прошлой статье мы упоминали основные SQL‑антипаттерны, способные замедлять работу базы данных. Продолжаем тему — на этот раз про CTE. Common Table Expressions ( CTE) , или конструкции WITH, — привычный инструмент SQL-разработчика. Чем сложнее запрос, тем выше шанс встретить в нём WITH: код становится чище, а запутанная логика разбивается на понятные блоки. CTE используют как альтернативу вложенным запросам и временным таблицам. Однако за внешней простотой и читаемостью скрываются риски снижения производительности, которые не всегда удаётся предвидеть. Такие запросы на первый взгляд выглядят правильными, но работают неэффективно, и проблема вылезает только в EXPLAIN ANALYZE (инструмент разбирали в прошлом гайде). Разберём четыре антипаттерна CTE, посмотрим планы выполнения и покажем, как переписать запрос. В конце — короткий чек-лист диагностики. Эта статья может быть полезна начинающим разработчикам и аналитикам, которые уже полюбили синтаксис CTE, но хотят понять, что на самом деле происходит «под капотом» в PostgreSQL.

https://habr.com/ru/companies/first/articles/1071080/

#оптимизация #базы_данных #postgresql #оптимизация_запросов #план_запроса

[Перевод] Статистика PostgreSQL: почему запросы выполняются медленно

Медленный запрос в PostgreSQL часто начинается с ошибки в оценках: планировщик ждёт сотню строк, получает тысячи и выбирает план, который разваливается под реальной нагрузкой. Разберём, откуда PostgreSQL берёт статистику, как ANALYZE её собирает и по каким признакам понять, что проблема действительно в оценках планировщика. Ускорить запросы

https://habr.com/ru/companies/otus/articles/1069656/

#PostgreSQL #планировщик_запросов #статистика_PostgreSQL #ANALYZE #pg_statistic #pg_stats #pg_class #селективность #оптимизация_запросов #EXPLAIN_ANALYZE

Как я ускорил работу с топом-пользователей с 36 минут до 20 секунд, используя Redis Sorted Set

Всем привет, меня зовут Михаил, я работаю Java/Kotlin разработчиком в ОТП Банке. Все мы знаем про Redis. Часто используем его для in-memory кэша. В основном это ключ и значение. Но что, если можно пойти дальше и, как в том фильме, раскрыть все возможности Redis на 100%? Сегодня я хочу поговорить о Sorted Set в Redis. Что это за зверь и как его использовать. Буду показывать на примере таблицы лидеров. Это можно использовать для разных задач, но я выбрал именно эту. Будем замерять время, ресурсы при нагрузках - все, как мы любим. Присаживайтесь, будет интересно! Узнать, что это за покемон

https://habr.com/ru/articles/1071718/

#java #redis #highload #высоконагруженные_системы #оптимизация #оптимизация_кода #оптимизация_запросов #highload_systems #spring #spring_boot

Оптимизация агрегатов PostgreSQL — что может расширение?

Агрегаты в PostgreSQL не очень-то эффективны. Это особенно заметно в сравнении с SQL Server в сценарии, где частичная агрегация не помогает: когда агрегация только подготавливает данные для запроса, обрабатывая большой поток строк и на выходе получая ненамного меньший набор групп и посчитанных по ним агрегатов. Хуже всего приходится типам переменной длины. И здесь характерный пример — SUM(numeric) . Встроенные агрегаты обязаны обрабатывать значения в самом общем виде, тогда как на практике данные часто ограничены: например, в БД 1С все numeric имеют фиксированный масштаб. Отсюда возникает идея оптимизировать агрегаты, подстроив их под конкретные условия эксплуатации. Раньше это было возможно только в форке PostgreSQL. Однако недавно David Rowley добавил в ядро любопытный инструмент расширения SupportRequestSimplifyAggref ( коммит 42473b3b31 , PostgreSQL 19): теперь можно предоставить планнеру кастомную логику трансформации агрегата через механизм функций поддержки планнера (prosupport). Сам механизм существует ещё с PostgreSQL 12, но до агрегатов добрался только сейчас. В ядре новый запрос применяется скромно: заменяет COUNT(1) и COUNT(col) по NOT NULL-колонке на COUNT(*) . А вот расширению он позволяет сделать с агрегатом во время планирования практически что угодно. Это открывает пространство для интересных технических решений. Здесь я предлагаю посмотреть, как схема с преобразованием агрегата работает на живом и полезном примере — простом расширении с достаточно примитивной трансформацией.

https://habr.com/ru/companies/tantor/articles/1071372/

#prosupport #PostgreSQL #агрегаты #планировщик_запросов #оптимизация_запросов #расширения_PostgreSQL #pg_depend #SQL

8 способов сделать AI-агента дешевле: опыт реального продукта и готовые промпты для вайбкодеров

Всем привет! Я Юля Гончарова — продакт, дизайнер и... «вайбкодер». Последний год я строю продукты в одиночку с помощью Claude Code — от идеи и UX до кода и запуска. В этой статье расскажу про один из таких проектов: стартап, который я уже третий месяц развиваю как solo founder. Здесь я поделюсь тем, как мне удалось снизить затраты на токены, оставшись на модели Claude Sonnet 4.6. Для понимания контекста: продукт, о котором идет речь — это веб-приложение с мультиагентной системой. Один агент собирает данные о пользователе при регистрации, второй помогает ему подобрать и сформулирвоать цель (продуктом пользуются оснвоатели стартапов ранней стадии), третий ведет регулярный чек-ин (синк-сессии), четвертый — ежедневный чат-помощник, через которого пользователь может управлять любым функционалом, включая заполнения профиля-питч-дека или смены расписания синков. А еще есть индивидуальные агенты у инвесторов: те, которые настроены по параметрам конкретного фонда, такие агенты проводят интро-встречу с основателем (симуляцию питча инвестору). Агенты передают друг другу эстафету (например, после сбора данных передают управление агенту постановки цели) и координируются через общие данные, которые читают и пишут все вместе (профиль пользователя, цели, журнал событий) — а не общаются друг с другом напрямую. Каждый раз, когда AI отвечает, агенту приходится заново «прочитать» весь предыдущий разговор, накопленный контекст по проекту и все свои инструкции — и это стоит денег на каждый ответ. Представьте, что перед каждой репликой в разговоре человек должен перечитывать всю переписку с начала. AI-провайдер (Anthropic) разрешает сказать: «вот этот кусок запомни, не заставляй меня платить за перечитывание». Но у этой «памяти» есть срок годности — и именно то, как мы её использовали, дало основную экономию.

https://habr.com/ru/articles/1062956/

#вайбкодинг #вайбкодинг #вайбпрограммирование #токены_llm #оптимизация_запросов #claude_code #claude

Django ORM ломается не там, где вы смотрели: шесть ошибок

Django ORM умеет долго скрывать проблемы: лишние запросы, гонки при save() , затянувшиеся транзакции и выборки, которые незаметно съедают память. В статье разберём шесть типичных ошибок, которые редко проявляются на тестовых данных, зато быстро становятся заметны под нагрузкой.

https://habr.com/ru/companies/otus/articles/1062496/

#Django_ORM #QuerySet #оптимизация_запросов #PostgreSQL #транзакции #индексы #N+1 #блокировки #массовые_операции #производительность

PostgreSQL для бэкендера: 10 фич, которыми мало пользуются, а зря

Вы храните в PostgreSQL пользователей, заказы и платежи — а потом проект обрастает Redis для очереди, отдельным поисковиком и самодельными блокировками через таблицу locks. Иногда это оправдано. Но часто типовые бэкенд-задачи закрываются прямо в базе: атомарно, транзакционно, с индексами и без лишней сетевой болтовни. Привет, Хабр! Меня зовут Тимур Исламгулов. Я преподаватель МФТИ и ведущий вебинаров по PostgreSQL. За годы работы я насмотрелся, как разработчики поднимают лишнюю инфраструктуру там, где хватило бы самой базы, — об этом и поговорим. Показать рабочий SQL →

https://habr.com/ru/companies/netologyru/articles/1051792/

#postgresql #бэкенд #оконные_функции #sql #оптимизация_запросов #полнотекстовый_поиск #индексы #очередь_задач #базы_данных #skip_locked

Условная агрегация в SQL: ускоряем отчеты, избавляясь от лишних JOIN-ов и подзапросов

Привет, Хабр! Я — Дмитрий Селищев, в компании «Синимекс» совмещаю роли руководителя подразделения и разработчика баз данных. В этом материале хочу поделиться историей о том, как простые, но не всегда очевидные приемы помогают кардинально ускорить SQL-запросы. Мы поговорим о стандартных конструкциях CASE и FILTER , которые позволяют писать более чистый код и, что важнее, на порядки сокращать время построения сложных отчетов. Давайте на живых примерах посмотрим, как это работает.

https://habr.com/ru/companies/cinimex/articles/1048174/

#базы_данных #sql #postgresql #оптимизация_запросов

Оптимизация запросов к PostgreSQL: 5 неочевидных настроек для продакшена

В реальных проектах PostgreSQL часто работает не на полную мощность из-за дефолтных настроек, которые не учитывают специфику нагрузки. Разберём 5 неочевидных параметров, которые стоит подкрутить в postgresql.conf для стабильной работы в продакшене. Важно: перед внесением изменений обязательно протестируйте их в тестовой среде . Изменения глобальных параметров конфигурации могут как ускорить, так и замедлить работу базы данных.

https://habr.com/ru/articles/1039800/

#postgresql #оптимизация_запросов #настройка_postgresql #shared_buffers #work_mem #autovacuum #производительность_базы_данных #продакшен

WHERE превращает ваш LEFT JOIN в INNER JOIN. И никто вам об этом не скажет

LEFT JOIN считается одной из самых безопасных конструкций в SQL — пока один фильтр в WHERE тихо не превращает его в INNER JOIN . Ошибка коварная: запрос выглядит абсолютно нормальным, результаты приходят, база не ругается, а часть строк уже исчезла. В статье разбираем, почему это происходит, как NULL ломает ожидания и чем на самом деле отличаются условия в ON и WHERE .

https://habr.com/ru/companies/otus/articles/1036194/

#LEFT_JOIN #INNER_JOIN #SQL #PostgreSQL #NULL #WHERE #ON #антиджойн #оптимизация_запросов #базы_данных

Ускорение запросов в PostgreSQL: три рычага оптимизации и практический разбор

В предыдущих частях серии мы разобрали, как читать планы выполнения через EXPLAIN ANALYZE , и научились автоматически ловить медленные запросы с помощью pg_stat_statements, auto_explain и log_min_duration_statement. Теперь — следующий шаг: что делать с проблемами, которые вы нашли. В этой части разбираем три рычага оптимизации: статистику планировщика, индексы и рефакторинг SQL-запросов. На демонстрационном примере покажем, как снизить стоимость запроса почти вдвое — без изменений в инфраструктуре. Оборудование, конфигурация сервера и схема БД тоже влияют на производительность, но остаются за рамками статьи — здесь сосредоточимся на том, что можно улучшить на уровне запросов.

https://habr.com/ru/companies/first/articles/1035448/

#оптимизация #базы_данных #postgresql #оптимизация_запросов #план_запроса

Как найти медленный запрос в PostgreSQL: три инструмента мониторинга

EXPLAIN ANALYZE отлично справляется с диагностикой конкретного запроса — но только если вы уже знаете, какой именно запрос виновен. На практике проблемный запрос нужно сначала найти среди тысяч других. Ждать жалоб пользователей или вручную мониторить дашборды — путь, который не масштабируется. В этой статье разберём три инструмента PostgreSQL для автоматического поиска медленных запросов: pg_stat_statements, auto_explain и log_min_duration_statement. Для каждого — настройка, ключевые параметры и когда что использовать.

https://habr.com/ru/companies/first/articles/1034434/

#оптимизация #базы_данных #postgresql #оптимизация_запросов #план_запроса

Почему CRM в Битрикс24 тормозит на 50К сделок и что с этим делать

Когда CRM в Битрикс24 начинает открывать список сделок по 10 секунд, обычно первым делом подозревают сервер, нагрузку или саму платформу. Но на практике узкое место часто лежит ближе к базе: фильтры по UF -полям без индексов, лишние JOIN , неявный LIKE в ORM , N+1 -запросы и обработчики, которые внезапно превращают массовое обновление в нагрузочный тест. В статье разбираем, как подойти к проблеме системно: включить slow query log , прочитать EXPLAIN , найти реальные причины тормозов и точечно ускорить CRM без миграции и бессмысленного наращивания железа.

https://habr.com/ru/companies/otus/articles/1029706/

#Битрикс24 #CRM #производительность_CRM #MySQL #slow_query_log #EXPLAIN #индексы #пользовательские_поля #D7_ORM #оптимизация_запросов

[Перевод] Как читать BUFFERS в EXPLAIN ANALYZE и находить I/O-узкие места в PostgreSQL

EXPLAIN ANALYZE часто воспринимается как инструмент, который показывает план выполнения запроса. Но если посмотреть внимательнее на блок BUFFERS, он начинает отвечать на более прикладной вопрос — где именно запрос упёрся в I/O и почему это произошло. В этой статье разберём, как читать эту статистику на уровне отдельных узлов плана, как интерпретировать hit/read в контексте нагрузки и почему сами числа почти ничего не значат без сравнения во времени.

https://habr.com/ru/companies/otus/articles/1024674/

#EXPLAIN_ANALYZE #postgres #sql #buffers #оптимизация_запросов #производительность_базы_данных #work_mem #shared_buffers

Гибридный кэш на базе Redis в серверной разработке

В серверной разработке кэш влияет не только на скорость ответа. От него напрямую зависят стоимость обработки запроса, нагрузка на базу, поведение системы под пиком и предсказуемость масштабирования. Именно поэтому практика кэширования имеет сегодня столько нюансов и разновидностей, если вы хотите реализовать что-то особенное или применить сложную схему кэширования, от ваших специалистов потребуются специальные навыки и умения. Под катом — рассказ о том, как мы ушли от кастомного кода к использованию гибридного кэша из .Net Framework, с какими сложностями столкнулись на этапе масштабирования системы, и как решали вопросы инвалидации кэша в процессе развития нашего проекта API Hub .

https://habr.com/ru/companies/cloud_x/articles/1024574/

#cloud_x_group #redis #кэш #cache #гибридный_кэш #кейс #оптимизация_запросов

EXPLAIN ANALYZE в PostgreSQL: читаем планы выполнения экспертно

Привет, Хабр! Запрос работает 30 секунд. Вы смотрите на него, всё вроде ок: JOIN по индексированным полям, WHERE по дате, LIMIT 100. Должен летать, но что-то не летает. Добавляете индекс наугад — не помогает. Переписываете подзапрос в CTE и стало ещё хуже. Проблема не в запросе, а в в том, что вы не смотрели в план выполнения. EXPLAIN ANALYZE показывает не что вы написали, а что PostgreSQL делает: какие индексы использует (и использует ли вообще), в каком порядке соединяет таблицы, где тратит время, сколько строк ожидал и сколько получил. Понять PostgreSQL

https://habr.com/ru/companies/otus/articles/1014452/

#explain #psql #PostgreSQL #план_выполнения #оптимизация_запросов #индексы_PostgreSQL #производительность_БД

[Перевод] Как найти подозрительные логины из разных стран за 2 часа в PostgreSQL

В задачах на SQL особенно интересно то, что один и тот же результат часто можно получить несколькими способами – и разница между ними оказывается не только в красоте запроса, но и в его поведении на реальных данных. В этой статье – разбор прикладной задачи про поиск подозрительных логинов из разных стран в пределах двух часов: с вариантом через self join, альтернативой на оконных функциях и сравнением планов выполнения в PostgreSQL. Разбор запроса

https://habr.com/ru/companies/otus/articles/1014814/

#postgresql #SQL #оконные_функции #поиск_аномалий #безопасность_аккаунтов #анализ_сессий #временные_окна #оптимизация_запросов #EXPLAIN_ANALYZE

BRIN, GIN, B‑Tree: полный гайд по индексам PostgreSQL для highload

Индексы есть, а запросы всё равно тормозят? Или наоборот — индексов слишком много, и они только увеличивают нагрузку на запись? Многие разработчики и администраторы баз данных попадают в ловушку: ставят B-Tree на всё подряд и надеются на лучшее. Но в highload-системах это может привести к катастрофе. В этой статье я делюсь реальным опытом работы с PostgreSQL. Статья будет полезна разработчикам, архитекторам и администраторам, которые хотят не просто «поставить индекс», а понять, как работает PostgreSQL под капотом и как проектировать базы данных, выдерживающие миллионы запросов в секунду.

https://habr.com/ru/companies/otus/articles/1008372/

#архитектура #PostgreSQL #индексы #оптимизация_запросов #highload #базы_данных #BTree #BRIN

Как мы ускорили SQL-запросы: реальные кейсы оптимизации PostgreSQL

Достаточно большое количество проблем производительности в backend-приложениях на самом деле находятся не в коде. За последние пару лет мне несколько раз приходилось разбирать системы, где: • API отвечало слишком долго • CPU базы был загружен почти на 100%

https://habr.com/ru/articles/1012922/

#оптимизация_SQL #оптимизация_запросов_postgresql #оптимизация_запросов #sql #postgresql #производительность_базы_данных #join

[Перевод] Почему VACUUM не спасает от раздувания индексов в PostgreSQL

VACUUM в PostgreSQL принято считать универсальным средством поддержания порядка: он очищает мёртвые кортежи, обновляет статистику и вроде бы держит базу «в форме». Но с индексами всё сложнее. В какой-то момент они начинают расти и деградировать так, что это уже влияет на планы запросов и поведение оптимизатора — при том, что формально всё обслуживается корректно. Разберёмся, где именно возникает это расхождение между ожиданиями и реальностью и что на самом деле происходит внутри B-дерева. Разобраться глубже

https://habr.com/ru/companies/otus/articles/1012266/

#postgres #PostgreSQL #VACUUM #раздувание_индексов #Bдерево #планировщик_запросов #оптимизация_запросов #REINDEX #производительность_базы_данных

EXPLAIN ANALYZE: как находить узкие места в запросах PostgreSQL

В этой статье мы разберём, как PostgreSQL обрабатывает запросы, изучим работу планировщика запросов и освоим анализ отчётов EXPLAIN ANALYZE — важнейшего инструмента оптимизации запросов. Эти знания помогут вам находить и устранять узкие места в производительности, оптимизировать запросы и предотвращать проблемы, из-за которых СУБД может работать медленнее.

https://habr.com/ru/companies/first/articles/1006278/

#оптимизация #базы_данных #postgresql #оптимизация_запросов #оптимизация_запросов_postgresql #разбор_плана_запроса

Django ORM: как QuerySet ленится, цепляется и генерирует SQL

Django ORM прячет SQL за красивым Python-интерфейсом. Пишешь User.objects.filter(active=True).order_by('name')[:10] — получаешь список пользователей. Круто. Но когда запросы тормозят или N+1 пожирает базу, приходится понимать, что вообще происходит. Разберём внутренности QuerySet: почему он ленивый, как работает chaining, когда запрос реально выполняется, и чем select_related отличается от prefetch_related на уровне SQL.

https://habr.com/ru/companies/otus/articles/988886/

#django #Django_ORM #QuerySet #ленивые_запросы #оптимизация_запросов #работа_с_БД

ClickHouse и внешние словари: как это работает и зачем нужно

Если вы работаете с ClickHouse , то наверняка слышали про такую фишку, как внешние словари . А если не слышали, самое время узнать, потому что эта штука способна творить чудеса с производительностью запросов и удобством архитектуры. В этой статье разберем ее подробнее. ClickHouse на практике

https://habr.com/ru/companies/otus/articles/971422/

#clickhouse #внешние_словари #dictGet #колоночная_СУБД #оптимизация_запросов #highload_аналитика