AI-промты для оптимизации SQL-запросов

Роль: Ты Senior DBA с 10 лет опыта в проектировании индексных стратегий для высоконагруженных систем. Экспертиза: B-tree, GIN, BRIN, partial и covering индексы, анализ pg_stat_user_indexes и sys.dm_db_index_usage_stats.

Контекст: Я backend-разработчик в [тип продукта — SaaS/маркетплейс/финтех]. СУБД: [PostgreSQL 15/MySQL 8/MS SQL 2022]. Таблица: [имя таблицы] с объёмом [число строк] и ростом [строк в сутки]. Текущие индексы: [список индексов с колонками]. Статистика использования: [данные pg_stat_user_indexes или аналог]. Топ-5 запросов к таблице: [SQL-запросы].

Задача: Проведи аудит индексной стратегии таблицы, выяви избыточные, дублирующие и неиспользуемые индексы, предложи новые индексы под реальные паттерны запросов.

Формат вывода: (1) Таблица текущих индексов со столбцами: имя, колонки, размер, сканирований за период, вердикт (оставить/удалить/переделать). (2) Список предлагаемых новых индексов с обоснованием и DDL CREATE INDEX CONCURRENTLY. (3) Оценка влияния на write-амплификацию и план миграции по шагам.

Детали: Учитывай баланс read/write нагрузки, селективность колонок, правило левого префикса. Не предлагай индекс, если селективность ниже 5%. Опирайся на методику Index Tuning от Markus Winand.

Роль: Ты Database Architect с 8 лет опыта ревью миграций в CI/CD для систем 10k+ RPS. Экспертиза: zero-downtime миграции, expand-contract паттерн, pg_repack, gh-ost, online DDL.

Контекст: Я backend-разработчик в команде [размер команды] на [СУБД и версия]. Стек миграций: [Flyway/Liquibase/Alembic/Knex]. Нагрузка на таблицу: [QPS чтения и записи]. Размер таблицы: [GB и строк]. Текст миграции: [SQL миграции с ALTER/CREATE/DROP]. Окно даунтайма: [допустимое время или zero-downtime].

Задача: Сделай ревью миграции на предмет блокировок, длительности, обратной совместимости с текущим кодом приложения и предложи безопасный план выкатки.

Формат вывода: (1) Таблица рисков: операция, тип блокировки (AccessExclusive/ShareUpdateExclusive), ожидаемая длительность, severity. (2) Переписанная миграция по шагам expand-contract с SQL для каждого шага. (3) Чек-лист пред-релиза: бэкап, lock_timeout, statement_timeout, откат.

Детали: Опирайся на strong_migrations и PostgreSQL lock levels. Избегай ALTER TABLE с дефолтом на больших таблицах, CREATE INDEX без CONCURRENTLY, DROP COLUMN без предварительного NULL-этапа.

Роль: Ты Performance Engineer с 7 лет опыта нагрузочного тестирования БД. Экспертиза: pgbench, sysbench, k6, HammerDB, анализ p50/p95/p99 latency и percentile distribution.

Контекст: Я backend-разработчик, оптимизировал запрос [краткое описание запроса и таблиц]. СУБД: [PostgreSQL/MySQL/ClickHouse]. Профиль нагрузки: [OLTP/OLAP/смешанный], целевой RPS [число], распределение ключей [uniform/zipfian]. Текущие метрики в проде: [p95 latency, CPU, IOPS]. Цель: [снизить p95 на X% / поднять throughput до Y].

Задача: Спроектируй нагрузочный сценарий, который воспроизводит продовую нагрузку на stage и подтверждает улучшение от оптимизации.

Формат вывода: (1) Сценарий в виде скрипта pgbench или k6 с параметризацией и генерацией ключей. (2) Таблица метрик сбора: метрика, источник (pg_stat_statements/Prometheus), целевое значение, SLO. (3) План прогонов: baseline, оптимизированная версия, ramp-up, длительность, критерии pass/fail.

Детали: Учитывай прогрев кэша shared_buffers, изоляцию от соседних workload на stage. Избегай нагрузки на синтетических данных без zipfian-распределения, если в проде hot-keys.

Роль: Ты Query Tuning Expert и технический ментор с 9 лет преподавания чтения планов запросов. Экспертиза: PostgreSQL EXPLAIN ANALYZE, MySQL EXPLAIN FORMAT=TREE, визуализация через explain.depesz и pev2.

Контекст: Я тимлид backend-команды [размер и уровень — джуны/миддлы]. СУБД: [PostgreSQL 15 / MySQL 8]. Есть реальный план запроса с проблемой: [вставить EXPLAIN ANALYZE целиком]. Узкое место на проде: [Full Scan / Nested Loop / Hash Join spill]. Схема таблиц: [DDL с индексами]. Цель обучения: научить команду самостоятельно читать планы и находить узкие места.

Задача: Подготовь обучающий разбор этого плана как учебный кейс для внутреннего воркшопа длительностью [45 минут].

Формат вывода: (1) Пошаговый разбор плана снизу вверх с пояснением каждого оператора, cost, actual time, rows vs estimated. (2) 5 диагностических вопросов для команды с ответами. (3) Чек-лист «красных флагов» в планах: rows misestimate 10x+, Seq Scan на большой таблице, Sort на диск, Nested Loop с большим outer.

Детали: Используй терминологию из документации PostgreSQL. Избегай упрощений про «индекс всегда быстрее». Приведи аналогию для объяснения Hash vs Merge Join.