steelmorgan/query-optimize

Query Optimize — оптимизация запросов и СКД

Навык для оптимизации существующих запросов и схем компоновки данных. Для написания запросов с нуля — query-patterns. Для СУБД-диагностики (план, блокировки, evidence) — db-performance.

---

Связь с другими навыками

db-performance          ← нижний доказательный слой (СУБД-evidence, план, блокировки)
    ↓ передаёт запрос + причину
query-optimize          ← переписывание (этот навык)
    ↓ использует правила написания
query-patterns          ← базовые паттерны (параметризация, NULL, циклы)

Без db-performance-evidence оптимизация — предположение. Если причина неизвестна — сначала db-performance.

---

Алгоритм

1. Извлечь запрос и контекст выполнения

• Найти текст запроса: rg "Запрос.Текст\s*=" --type-add "bsl:*.bsl" -t bsl
• Для СКД — найти .xml схемы через code-navigation, определить набор данных
• Зафиксировать:
  • Модуль / СКД-датасет
  • Параметры виртуальных таблиц (переданы / не переданы)
  • Цепочка временных таблиц
  • Вызывающий цикл (есть / нет)
  • Ожидаемое количество строк / реальное

2. Проверить метаданные

Прежде чем переписывать — проверить структуру объекта метаданных:

• Регистр: тип (накопления / сведений), периодичность, измерения, ресурсы
• Справочник / документ: реквизиты, табличные части
• Индексированные реквизиты (влияет на применимость условий)

Инструмент: code-navigation → структура объекта.

3. Определить одну причину

Выбрать из категорий (одну на итерацию):

| Причина | Признак | |---------|---------| | Широкое чтение виртуальной таблицы | Остатки() / Обороты() без параметров периода или измерений | | Query-in-loop | Запрос внутри Для Каждого / Пока / рекурсии | | Dot-dereference без ВЫРАЗИТЬ | Движения.Регистратор.Контрагент при составном типе | | Избыточные временные таблицы | Промежуточные таблицы с полным набором полей вместо минимального | | Лишние итоги | ИТОГИ в запросе, когда нужна плоская выборка | | Фильтрация после соединения | Условия ГДЕ на полях большой таблицы вместо параметров виртуальной таблицы | | Неявное умножение строк через JOIN | LEFT JOIN без агрегации дублирует строки | | РАЗЛИЧНЫЕ маскирует проблему | ВЫБРАТЬ РАЗЛИЧНЫЕ скрывает лишний JOIN вместо его исправления |

4. Применить правило оптимизации

Для каждой причины — конкретное правило (см. раздел «Правила» ниже).

5. Проверить синтаксис и семантику

• Синтаксис: v8-runner после любого изменения
• Семантику: фильтры РАЗРЕШЕННЫЕ не убирать молча, правила безопасности сохраняются
• Для join-изменений: убедиться, что количество строк не изменилось неожиданно

6. Запросить СУБД-верификацию при неочевидном эффекте

Если изменение влияет на план СУБД (индекс, параметры виртуальной таблицы, тип соединения) — запросить у пользователя EXPLAIN / ТЖ до и после. Без измерения — зафиксировать как «ожидаемый эффект, требует проверки».

---

Правила переписывания

Конкретные правила «как писать правильно» — канон в query-patterns. Здесь — соответствие причины (шаг 3) правилу из query-patterns; применяй правило оттуда, не дублируй запрос-паттерны в этом навыке.

| Причина (шаг 3) | Правило query-patterns | |---|---| | Широкое чтение виртуальной таблицы | Правило 5 — параметры периода/измерений внутрь виртуальной таблицы, не в ГДЕ | | Query-in-loop | Правило 1 — один запрос + Соответствие для доступа | | Dot-dereference без ВЫРАЗИТЬ | Правило 12 — ВЫРАЗИТЬ(… КАК …) + ССЫЛКА для составного типа | | Избыточные ВТ / нет индекса соединения | Правила 2, 8 — минимальные поля, ИНДЕКСИРОВАТЬ ПО только по полю соединения | | Лишние итоги | Правило 16 — ИТОГИ только для Выбрать(ПоГруппировкам), иначе СГРУППИРОВАТЬ ПО | | Фильтрация после соединения | Правила 5, 13 — параметры ВТ / ПО vs ГДЕ | | РАЗЛИЧНЫЕ маскирует лишний JOIN | Правило 11 — подзапрос В (…) вместо JOIN + РАЗЛИЧНЫЕ |

Специфика оптимизации (сверх общих правил query-patterns):

• Виртуальная таблица без параметров допустима только при явном обосновании (например, отчёт по всем складам без фильтра); иначе всегда параметризуй период и измерения.
• Переписывай одну причину за итерацию (см. Stop rules) — иначе вклад каждого изменения неизмерим.

---

СКД: специфика оптимизации

Параметры датасета

• Параметры СКД, передаваемые в виртуальные таблицы датасета, работают так же как параметры запроса: передавать внутрь, не фильтровать через отбор после
• Для условий по периоду регистра — всегда параметризовать в тексте запроса датасета

Ресурсы и вычисляемые поля

• Вычисляемые поля СКД, обращающиеся к другим наборам данных через связи — потенциальный query-in-loop на уровне платформы
• Связи наборов данных (СВЯЗЬ) с условиями без индекса на ведомой стороне — проверить метаданные

Отборы в СКД

• Отборы, накладываемые пользователем через настройки, могут не попадать в параметры виртуальных таблиц — это архитектурное ограничение; задокументировать
• Для критичных фильтров (период, организация) — передавать как параметры запроса датасета, не полагаться только на отборы СКД

---

Чек-лист ревью запроса

• [ ] Виртуальные таблицы получают параметры периода и измерений (не фильтрация в ГДЕ)
• [ ] Временные таблицы содержат только поля, нужные следующим этапам
• [ ] Поля соединения во временных таблицах проиндексированы (ИНДЕКСИРОВАТЬ ПО)
• [ ] Нет повторяющихся подзапросов и query-in-loop
• [ ] JOIN не умножает строки; итоги и группировки соответствуют бизнес-смыслу
• [ ] Фильтры по дате и организации применены как можно раньше
• [ ] Составные типы раскрыты через ВЫРАЗИТЬ перед dot-dereference
• [ ] ЛЕВОЕ СОЕДИНЕНИЕ не превращается в ВНУТРЕННЕЕ из-за условия в ГДЕ
• [ ] РАЗЛИЧНЫЕ не маскирует лишний JOIN
• [ ] РАЗРЕШЕННЫЕ и прочие фильтры прав сохранены

---

Stop rules

1. Не убирать РАЗРЕШЕННЫЕ без явного согласования безопасности.
2. Не рекомендовать индекс без конкретного предиката + write-cost оценки — это задача db-performance.
3. Не переписывать несколько причин за один шаг — нельзя измерить вклад каждой.
4. Не заменять LEFT JOIN на INNER JOIN без проверки бизнес-требования: все строки нужны или только совпадающие.
5. Не переносить оптимизацию по данным одной СУБД на другую без проверки: PostgreSQL и MS SQL Server имеют разные модели планировщика.

---

depends_on:

• framework/skills/bsl-practices/query-patterns/SKILL.md
• framework/skills/tool-usage/diagnostics/db-performance/SKILL.md
• framework/skills/tool-usage/code-analysis/code-navigation/SKILL.md
• framework/skills/tool-usage/v8-runner/SKILL.md

---