Skill v1.0.1
Automated scan100/100+1 new
version: "1.0.1" name: db-performance description: "Use for диагностики производительности БД и запросов 1С. Helps выявить slow query, план СУБД, блокировки, deadlock, TEMPDB/WAL, размеры таблиц и СКД на больших данных." target_agents:
- debugger
- developer-code
- architect
DB Performance — диагностика производительности БД
Навык работает на двух уровнях одновременно: платформа 1С (запрос, метаданные, СКД) и СУБД (план, локи, ожидания, temp storage). Диагноз без обоих уровней — неполный.
Когда применять
| Симптом | Первый шаг | |
|---|---|---|
| Медленный отчёт / проведение / обмен | Шаг 1: назвать сценарий | |
SQL в ТЖ с большим Duration | Шаг 2: извлечь запрос + метаданные | |
Блокировки TLOCK / TDEADLOCK | Шаг 3: собрать СУБД-evidence | |
| TEMPDB/WAL растёт при «только чтение» | Шаги 3-4: red flags + причины | |
| Таблица выросла — отчёт стал медленнее | Полный алгоритм (шаги 1-5) |
Этот навык — нижний доказательный слой. Для переписывания текста запроса или СКД — передать в query-optimize.
Инструменты
| Задача | Инструмент | |
|---|---|---|
| Поиск запроса в коде | rg (ripgrep) по тексту BSL | |
| Навигация к символу / процедуре | code-navigation | |
| Получить SQL из ТЖ | tech-log-analysis → search_tech_log с name: DBMSSQL / DBPOSTGRS | |
| Прогон теста / синтаксис | v8-runner | |
| Информация о метаданных | code-navigation → структура регистра / справочника |
Нет прямого доступа к EXPLAIN ANALYZE, pg_stat_statements, sys.dm_exec_query_stats — инструкции по получению передаются пользователю/администратору.
Алгоритм (5 шагов)
Шаг 1. Назвать сценарий
Точно определить: что делает пользователь / какой фоновый процесс / какой шаг обмена / какой отчёт с какими отборами. Без конкретного сценария диагностика невозможна.
Зафиксировать: название, ожидаемое время, фактическое время, условия (объём данных, организация, период).
Шаг 2. Извлечь запрос + метаданные
Платформенный слой:
- Найти текст запроса в BSL:
rg "Запрос.Текст\s*=" --type-add "bsl:*.bsl" -t bsl - Для СКД — найти
.xmlсхемы компоновки данных черезcode-navigation - Проверить метаданные: тип регистра (накопления / сведений), периодичность, ресурсы, измерения, табличные части
- Зафиксировать: контекст вызова, граница транзакции, цикл вокруг запроса, параметры виртуальных таблиц
Требование: текст запроса 1С обязательно в паре с хотя бы одним СУБД-артефактом (шаг 3). Анализ только текста запроса без СУБД-evidence не даёт доказательной базы.
Шаг 3. Собрать СУБД-evidence
Категории доказательств (нужна хотя бы одна):
| Категория | PostgreSQL | MS SQL Server | Что доказывает | |
|---|---|---|---|---|
| План запроса | EXPLAIN (ANALYZE, BUFFERS) | SET STATISTICS IO, TIME ON + actual plan | Seq scan vs index scan, hash join cost, actual rows | |
| Блокировки / ожидания | pg_locks, pg_stat_activity | sys.dm_exec_requests, sys.dm_os_waiting_tasks | Lock holder, waiter, тип блокировки | |
| Temp storage | WAL size, pg_stat_bgwriter | TEMPDB usage, VLF count | Скрытая запись при «только чтение» | |
| Статистика таблиц | pg_stat_user_tables | sys.dm_db_index_usage_stats | Seq scans vs index seeks, stale stats | |
| ТЖ-артефакты | DBPOSTGRS events | DBMSSQL events | Duration, SQL текст, context |
Файловая ИБ — отдельная модель: нет СУБД-плана, производительность определяется структурой dbf-файлов, блокировки через платформенный менеджер.
Правило missing evidence: если СУБД-артефакт получить невозможно — зафиксировать явно: «СУБД-evidence отсутствует, причина: <...>». Не заменять предположениями.
Шаг 4. Разделить причины
Классифицировать причину по категории:
| Категория | Признаки | |
|---|---|---|
| Неэффективный запрос | Seq scan на большой таблице, отсутствие фильтра в виртуальной таблице, dot-dereference без ВЫРАЗИТЬ | |
| Пропущенный / вредный индекс | Full table scan по полю без индекса; или индекс есть, но не используется из-за типа условия | |
| Широкое чтение виртуальной таблицы | Остатки() без параметров периода / измерений | |
| Query-in-loop | N запросов на N строк: Duration * N в ТЖ, повторяющийся SQL с разными параметрами | |
| Lock contention | TLOCK / TDEADLOCK в ТЖ; блокирующий запрос в pg_locks / sys.dm_exec_requests | |
| СУБД-обслуживание | Autovacuum, index rebuild, статистика устарела — план деградировал | |
| Рост данных | Запрос корректен, но объём таблицы вырос — план поменялся |
Одна причина на итерацию. Если причин несколько — начать с наиболее вероятной по evidence.
Шаг 5. Одно измеримое изменение + верификация
- Предложить одно изменение: переписать запрос / добавить параметр виртуальной таблицы / добавить индекс / переместить запрос из цикла
- Для каждого изменения — ожидаемый эффект измеримо: «Duration снизится с X до Y» / «Seq scan заменится на Index Seek»
- Верификация: прогон того же сценария + сравнение СУБД-evidence до и после
- Синтаксис — через
v8-runner
Stop rules
- Не рекомендовать индекс без конкретного предиката / JOIN / сортировки / группировки + оценки write-cost tradeoff.
- Не убирать `РАЗРЕШЕННЫЕ` и не отключать RLS/фильтры прав ради производительности без явного согласования безопасности.
- Не утверждать причину на уровне СУБД без СУБД-evidence. Зафиксировать missing evidence.
- Не обобщать PostgreSQL-специфичный вывод на MS SQL Server и наоборот.
- Не предлагать несколько изменений одновременно — невозможно измерить вклад каждого.
Модели доказательств по СУБД
PostgreSQL
- Основной инструмент:
EXPLAIN (ANALYZE, BUFFERS, FORMAT TEXT) - Паттерны проблем: Seq Scan на таблице > 100K строк, Hash Join с большим
rows=, высокийshared hitпри маломactual rows - Temp files:
work_memпереполнен → temp file в плане → WAL pressure - Блокировки:
pg_stat_activity.wait_event_type = 'Lock'
MS SQL Server
- Основной инструмент: Actual Execution Plan +
SET STATISTICS IO ON - Паттерны: Table Scan / Clustered Index Scan вместо Seek, Key Lookup, Implicit conversion из-за типов
- TEMPDB: spill to disk в Sort / Hash Match →
tempdb.sys.dm_db_task_space_usage - Блокировки:
sys.dm_exec_requests.blocking_session_id
Файловая ИБ
- Нет СУБД-плана
- Производительность зависит от размера dbf-файлов и платформенных индексов
- Блокировки — платформенный механизм, виден в ТЖ (
TLOCK) - Рекомендация: миграция на клиент-серверный вариант при росте объёма
Вывод (формат ответа)
## Сценарий и evidence<Сценарий: ...><СУБД-evidence: план / ТЖ / отсутствует (причина)>## Корневая причина (по убыванию вероятности)1. <Категория> — <факт из evidence>2. ...## Изменение<Одно конкретное изменение: текст / индекс / параметр><Ожидаемый измеримый эффект>## Верификация<Как измерить: команда / сценарий / сравнение ТЖ>## Остаточные риски<Объём данных / блокировки / СУБД-специфика>
Red flags (немедленные маркеры)
- Отчёт фильтрует по дате / организации / тенанту после соединения больших таблиц
- Виртуальная таблица вызвана без параметров периода / измерений
- Один и тот же SQL в ТЖ повторяется N раз с разными параметрами (query-in-loop)
- Долгие локи совпадают с большими записями: проведение, обмен, фоновые задания
- Temp storage или лог транзакций растёт при «только чтение» сценарии
depends_on:
- framework/skills/tool-usage/diagnostics/tech-log-analysis/SKILL.md
- framework/skills/tool-usage/code-analysis/code-navigation/SKILL.md
- framework/skills/tool-usage/v8-runner/SKILL.md
- framework/skills/bsl-practices/query-optimize/SKILL.md