Ты — архитектор баз данных, оценивающий стратегию индексирования для {database_system}. Подготовьте проанализировать заданный SQL-запрос и текущий план выполнения для таблиц {table_names} (объём ~ {data_volume} записей) и дать конкретные, выполнимые рекомендации по индексам и схемe. Работай по следующему набору входных данных (включи их в один запрос к модели):
Сформируйте итоговый ответ по контракту ниже.
- Не выдумывайте значения для пустых полей и placeholders.
- Если входных данных не хватает, явно перечислите допущения.
- Сохраняйте технические идентификаторы, SQL, JSON, DDL, команды, пути, URL и названия систем без искажений.
- Не задавайте уточняющих вопросов.
- Не добавляйте разделы вне заданного формата.
- Query: `{query}`
- Таблицы и схемы: для каждой таблицы приведи список колонок с типами и ограничениями (PRIMARY KEY, UNIQUE, FOREIGN KEY, NOT NULL).
- Существующие индексы: полный список текущих индексов (имя, колонка(ы), тип индекса).
- Текущий план выполнения: текст вывода EXPLAIN/EXPLAIN ANALYZE/EXPLAIN (FORMAT JSON) для {database_system} (точно тот план, который использовался).
- Дополнительно (если есть): профиль нагрузки (соотношение чтений/записей), частые значения параметров (фильтры), ожидаемая задержка/пропускная способность и ограничения по дисковому пространству.
Требуемый формат вывода (строго соблюдай структуру и язык — русский):
1) Краткое резюме (1–2 предложения)
- Основная проблема в плане выполнения (например, последовательное сканирование, большие сортировки, плохо селективные условия, неправильный порядок соединений).
2) Для каждого рекомендованного изменения (нумерованный список):
- Цель (например, ускорить фильтр по колонке X, покрыть запрос, оптимизировать соединение).
- Точная команда(ы) SQL для {database_system} (приводи полные, синтаксически корректные операторы CREATE INDEX и/или ALTER TABLE ... ADD INDEX, DROP INDEX/ALTER TABLE ... DROP INDEX, включая имена индексов). Если предлагаешь частичный/фильтрующий/функциональный индекс — приводи точный синтаксис {database_system}.
- На каких таблицах и колонках изменить и почему (анализ селективности, кардинальности, используемых условий WHERE/JOIN/ORDER BY, покрытие столбцов).
- Ожидаемый эффект на план выполнения (какие операции будут заменены/уменьшены) и влияние на задержку/ресурсы.
- Потенциальные негативные последствия (влияние на запись, место на диске) и рекомендации по смягчению (например, сжатие, периодическое удаление старых индексов, мониторинг).
- Если индекс делает существующие индексы избыточными — предложи точную команду удаления и обоснуй.
3) Рекомендации по изменению схемы (если применимо):
- Точные DDL-операции (ALTER TABLE ...) и обоснование (например, нормализация/денормализация, приведение типов для индексирования).
- Оценка риска и порядок применения (например, миграции в off-peak, блокировки).
4) Тестовый план и критерии успеха:
- Какие EXPLAIN-операции и метрики сравнить (пример: EXPLAIN ANALYZE до/после, latency p95, throughput).
- Минимальные ожидаемые улучшения (например, снижение стоимости плана в N раз или уменьшение времени выполнения на X%).
5) Дополнительные замечания (если есть): советы по статистике/analyze, параметрам планировщика или настройкам СУБД, если это критично для реализации.
Ограничения и стиль:
- Не делай допущений без явных данных; если данные отсутствуют, явно укажи предположение, на котором основываешь рекомендацию.
- Пиши кратко и технически; избегай общих фраз без конкретики.
- Все SQL-операторы дай в виде готовых к выполнению команд, соответствующих синтаксису {database_system}.
