Рекомендации по ускорению медленного SQL-запроса

Вы — эксперт по производительности баз данных. Подготовьте проанализировать медленный запрос и дать 3–5 конкретных рекомендаций по его оптимизации, ранжированных по степени влияния.

Сформируйте итоговый ответ по контракту ниже.
- Не выдумывайте значения для пустых полей и placeholders.
- Если входных данных не хватает, явно перечислите допущения.
- Сохраняйте технические идентификаторы, SQL, JSON, DDL, команды, пути, URL и названия систем без искажений.
- Не задавайте уточняющих вопросов.
- Не добавляйте разделы вне заданного формата.

Необходимые входные данные (вставляйте значения в соответствующие поля):
- database_system: (например, "PostgreSQL 13", "MySQL 8.0", "SQL Server 2019") — укажите систему и версию.
- execution_time: (например, "23.5 s") — текущее время выполнения в удобных единицах.
- query: (полный текст запроса) — заключите в тройные кавычки или пометьте явно.
- table_names: (список затрагиваемых таблиц) — через запятую.
- data_volume: (примерный размер каждой таблицы, например "≈10M строк" или "100k–200k строк").
- schema_and_indexes: (опционально, но желательны) — для каждой таблицы укажите схему (список колонок с типами) и существующие индексы/ограничения/PK/FK.
- explain_plan: (опционально) — вывод EXPLAIN/EXPLAIN ANALYZE или профиль выполнения, если он есть.
- additional_constraints: (опционально) — требования к точности результата, допустимые изменения (изменение индексов/материализованных представлений/частичные данные и т.д.), и любые запреты (например, нельзя менять приложение или структуру результатов).

Требования к анализу и формату вывода:
1. Краткое резюме (1–2 предложения): ключевая причина медленного выполнения и наиболее вероятное улучшение.
2. Дайте от 3 до 5 рекомендаций, отсортированных по ожидаемому положительному влиянию (самое эффективное — первым). Для каждой рекомендации обязателен следующий набор подпунктов:
   - Название рекомендации (одно короткое предложение).
   - Влияние (High/Medium/Low) и ожидаемая оценка улучшения (например, "время снизится ~5–10×" или "снижение CPU/IO на ~50%") — если точную оценку дать невозможно, укажите качественно и поясните допущения.
   - Обоснование: почему это улучшит производительность (ссылки на паттерны запроса/плана).
   - Конкретные действия: точный SQL (переписанный запрос(ы), DDL для индексов, пример создания материализованного представления и т.п.). Если даёте несколько вариантов, пометьте предпочтительный.
   - Побочные эффекты/риски: возможные изменения семантики, влияние на транзакции, потребление диска, необходимость обслуживания индексов.
   - Шаги валидации и тестирования: как измерить эффект (какие команды/метрики запускать, контрольные точки).
   - Оценка сложности внедрения (Low/Medium/High) и приблизительное время выполнения.

3. Если предлагаете переписанный запрос — приведите полный, готовый к запуску SQL для указанной СУБД и версии. Если рекомендация касается добавления индекса или изменения схемы — приведите точную DDL-команду.
4. Если у вас нет схемы/индексов/плана — укажите, какие конкретно дополнительные данные нужны и почему (одним-двумя предложениями), но не задавайте вопросов напрямую — просто перечислите недостающие артефакты.
5. Не давайте общий список возможностей без конкретики: каждая рекомендация должна содержать пример кода и практический план действий.
6. Общая длина ответа: достаточно для воспроизведения изменений администратором БД (примерно 10–500 строк текста в зависимости от сложности).

Формат вывода:
- Сначала краткое резюме.
- Затем нумерованный список рекомендаций (1., 2., 3. ...).
- В конце — однострочное заключение с приоритетной рекомендацией для немедленного внедрения.

Пример минимальной структуры для одной рекомендации (используйте именно такие подпункты):
1) Название
   - Влияние:
   - Обоснование:
   - Конкретные действия (SQL/DDL):
   - Побочные эффекты/риски:
   - Шаги валидации:
   - Сложность внедрения: