steelmorgan/db-performance
framework/skills/tool-usage/diagnostics/db-performance/SKILL.md
Use for диагностики производительности БД и запросов 1С. Helps выявить slow query, план СУБД, блокировки, deadlock, TEMPDB/WAL, размеры таблиц и СКД на больших данных.
$ install --global
skillsauthnpx skillsauth add steelmorgan/1c-agent-based-dev-framework db-performanceInstall this skill globally with one command. Works with Claude Code, Cursor, and Windsurf.
Security Scan Results
3 of 9 scanners reported clean
Some scanners were skipped, did not run, or reported a non-clean status. Review each row below.
3
Scanners Passed
9
Scanners in report
Clean
TrivyContainer and dependency vulnerability scanner
95%
Clean
SemgrepStatic code analysis for vulnerabilities
95%
Clean
mcp-scan (Snyk)Model Context Protocol security validation
95%
Skipped
Snyk (dep)Open source security scanning
50%
Skipped
Socket.devSupply chain security analysis
50%
Skipped
VirusTotalMulti-engine malware detection
50%
Skipped
CrowdStrikeAdvanced threat intelligence
50%
Skipped
OSV-ScannerOpen Source Vulnerability database check
50%
Skipped
OWASP Dep-Check
50%
Last scanned: Jun 13, 2026, 5:42 AM137.2s1 file scanned
SKILL.md
- name:
- db-performance
- description:
- Use for диагностики производительности БД и запросов 1С. Helps выявить slow query, план СУБД, блокировки, deadlock, TEMPDB/WAL, размеры таблиц и СКД на больших данных.
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
Related Skills
steelmorgan/source-of-truth
testing
VerifiedTrustedCommunity
MUST use BEFORE making a judgment about the cause of a conflict, a test failure, or an artifact dispute. Defines the end-to-end verification method L1→L6 and the classification of the first broken link.
69SKILL.mdUpdated Jun 13, 2026
steelmorgan/skill-learning
development
VerifiedTrustedCommunity
MUST use AFTER a work cycle with ≥2 iterations (wrote → error → fixed → success). Provides the retrospective procedure and the format for recording practice/anti-patterns in references/learned-patterns.md or {project}/.context/learned-patterns.md.
69SKILL.mdUpdated Jun 13, 2026
steelmorgan/rlm-workflow
tools
VerifiedTrustedCommunity
MUST use WHEN you are writing reusable knowledge into RLM (pattern / architectural decision / stable domain fact) OR reading it before a non-trivial task/solution in the domain. Provides the breakdown of native-push vs RLM-pull, tools for writing and reading RLM, H-MEM levels, and hygiene.
69SKILL.mdUpdated Jun 13, 2026
steelmorgan/quick-fix
testing
VerifiedTrustedCommunity
MUST use WHEN the task is classified as simple (< 20 lines, 1 file, no new metadata objects, no architectural decisions). Provides a short cycle of 3 steps with a guard on the self path and mandatory verify.
69SKILL.mdUpdated Jun 13, 2026