`.
| Параметр безопасности SQL | Представление | Materialized View |
| ------------------------- | ---------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------- |
| `DEFINER alice` | У `alice` должен быть grant `SELECT` на исходную таблицу представления. | У `alice` должен быть grant `SELECT` на исходную таблицу представления и grant `INSERT` на целевую таблицу представления. |
| `INVOKER` | У пользователя должен быть grant `SELECT` на исходную таблицу представления. | `SQL SECURITY INVOKER` нельзя указывать для materialized view. |
| `NONE` | - | - |
`SQL SECURITY NONE` — устаревший параметр. Любой пользователь, имеющий права на создание представлений с `SQL SECURITY NONE`, сможет выполнять любые произвольные запросы.
Поэтому для создания представления с этим параметром требуется `GRANT ALLOW SQL SECURITY NONE TO `.
Если `DEFINER`/`SQL SECURITY` не указаны, используются значения по умолчанию:
* `SQL SECURITY`: `INVOKER` для обычных представлений и `DEFINER` для materialized view ([настраивается через settings](/ru/reference/settings/session-settings#default_normal_view_sql_security))
* `DEFINER`: `CURRENT_USER` ([настраивается через settings](/ru/reference/settings/session-settings#default_view_definer))
Если представление присоединено без указания `DEFINER`/`SQL SECURITY`, по умолчанию используется `SQL SECURITY NONE` для materialized view и `SQL SECURITY INVOKER` для обычного представления.
Чтобы изменить безопасность SQL для существующего представления, используйте
```sql theme={null}
ALTER TABLE MODIFY SQL SECURITY { DEFINER | INVOKER | NONE } [DEFINER = { user | CURRENT_USER }]
```
### Примеры
```sql theme={null}
CREATE VIEW test_view
DEFINER = alice SQL SECURITY DEFINER
AS SELECT ...
```
```sql theme={null}
CREATE VIEW test_view
SQL SECURITY INVOKER
AS SELECT ...
```
## Live View
Эта возможность объявлена устаревшей и будет удалена в будущем.
Для вашего удобства старая документация находится [здесь](https://pastila.nl/?00f32652/fdf07272a7b54bda7e13b919264e449f.md)
## Refreshable Materialized View
```sql theme={null}
CREATE MATERIALIZED VIEW [IF NOT EXISTS] [db.]table_name [ON CLUSTER cluster]
REFRESH EVERY|AFTER interval [OFFSET interval]
[RANDOMIZE FOR interval]
[DEPENDS ON [db.]name [, [db.]name [, ...]]]
[SETTINGS name = value [, name = value [, ...]]]
[APPEND]
[TO[db.]name] [(columns)] [ENGINE = engine]
[EMPTY]
[DEFINER = { user | CURRENT_USER }] [SQL SECURITY { DEFINER | NONE }]
AS SELECT ...
[COMMENT 'comment']
```
где `interval` — последовательность простых интервалов:
```sql theme={null}
number SECOND|MINUTE|HOUR|DAY|WEEK|MONTH|YEAR
```
Периодически выполняет соответствующий запрос и сохраняет его результат в таблице.
* Если указано `APPEND`, при каждом обновлении в таблицу добавляются новые строки без удаления существующих. Вставка не является атомарной, как и в обычном запросе `INSERT INTO ... SELECT`.
* В противном случае при каждом обновлении предыдущее содержимое таблицы атомарно заменяется.
Отличия от обычных non-refreshable materialized views:
* Нет insert trigger. Когда новые данные вставляются в таблицу, указанную в `SELECT`, они *не* передаются автоматически в refreshable materialized view. Вместо этого данные вставляются только во время периодических или ручных обновлений.
* Для запроса `SELECT` нет ограничений. Допускаются table functions (например, `url()`), views, UNION, JOIN.
Настройки в части запроса `REFRESH ... SETTINGS` — это настройки обновления (например, `refresh_retries`), а не обычные настройки (например, `max_threads`). Обычные настройки можно указать с помощью `SETTINGS` в конце запроса.
### Расписание обновления
Примеры расписаний обновления:
```sql theme={null}
REFRESH EVERY 1 DAY -- каждый день, в полночь (UTC)
REFRESH EVERY 1 MONTH -- в 1-й день каждого месяца, в полночь
REFRESH EVERY 1 MONTH OFFSET 5 DAY 2 HOUR -- в 6-й день каждого месяца, в 2:00
REFRESH EVERY 2 WEEK OFFSET 5 DAY 15 HOUR 10 MINUTE -- каждую вторую субботу, в 15:10
REFRESH EVERY 30 MINUTE -- в 00:00, 00:30, 01:00, 01:30 и т.д.
REFRESH AFTER 30 MINUTE -- через 30 минут после завершения предыдущего обновления, без привязки к времени суток
-- REFRESH AFTER 1 HOUR OFFSET 1 MINUTE -- синтаксическая ошибка: OFFSET не допускается с AFTER
REFRESH EVERY 1 WEEK 2 DAYS -- каждые 9 дней, без привязки к конкретному дню недели или месяца;
-- а именно: когда номер дня (начиная с 1969-12-29) кратен 9
REFRESH EVERY 5 MONTHS -- каждые 5 месяцев, в разные месяцы каждого года (так как 12 не кратно 5);
-- а именно: когда номер месяца (начиная с 1970-01) кратен 5
```
`RANDOMIZE FOR` случайным образом смещает время каждого обновления, например:
```sql theme={null}
REFRESH EVERY 1 DAY OFFSET 2 HOUR RANDOMIZE FOR 1 HOUR -- каждый день в случайное время между 01:30 и 02:30
```
Для одного представления одновременно может выполняться не более одного обновления. Например, если обновление представления с `REFRESH EVERY 1 MINUTE` занимает 2 минуты, оно будет обновляться раз в 2 минуты. Если затем оно начнёт выполняться быстрее и обновляться за 10 секунд, оно снова вернётся к обновлению раз в минуту. (В частности, оно не будет обновляться каждые 10 секунд, чтобы наверстать пропущенные обновления — никакой очереди таких обновлений не существует.)
Кроме того, обновление запускается сразу после создания materialized view, если только в запросе `CREATE` не указано `EMPTY`. Если указано `EMPTY`, первое обновление произойдёт по расписанию.
### В базе данных Replicated
Если refreshable materialized view находится в [базе данных Replicated](/ru/reference/engines/database-engines/replicated), реплики координируют работу между собой так, что в каждый запланированный момент обновление выполняет только одна реплика. Для этого требуется движок таблицы [ReplicatedMergeTree](/ru/reference/engines/table-engines/mergetree-family/replication), чтобы все реплики видели данные, полученные в результате обновления.
В режиме `APPEND` координацию можно отключить с помощью `SETTINGS all_replicas = 1`. В этом случае реплики выполняют обновления независимо друг от друга. Тогда ReplicatedMergeTree не требуется.
В режиме без `APPEND` поддерживается только координируемое обновление. Для нескоординированного обновления используйте базу данных `Atomic` и запрос `CREATE ... ON CLUSTER`, чтобы создать refreshable materialized view на всех репликах.
Координация выполняется через Keeper. Путь znode определяется настройкой сервера [default\_replica\_path](/ru/reference/settings/server-settings/settings#default_replica_path).
### Зависимости обновления
`DEPENDS ON` синхронизирует обновление разных таблиц. Например, предположим, что существует цепочка из двух refreshable materialized view:
```sql theme={null}
CREATE MATERIALIZED VIEW source REFRESH EVERY 1 DAY AS SELECT * FROM url(...)
CREATE MATERIALIZED VIEW destination REFRESH EVERY 1 DAY AS SELECT ... FROM source
```
Без `DEPENDS ON` оба представления начнут обновляться в полночь, и в `destination` обычно будут попадать вчерашние данные из `source`. Если добавить зависимость:
```sql theme={null}
CREATE MATERIALIZED VIEW destination REFRESH EVERY 1 DAY DEPENDS ON source AS SELECT ... FROM source
```
тогда обновление `destination` начнется только после того, как в этот день завершится обновление `source`, поэтому `destination` будет основан на актуальных данных.
Того же результата также можно добиться с помощью:
```sql theme={null}
CREATE MATERIALIZED VIEW destination REFRESH AFTER 1 HOUR DEPENDS ON source AS SELECT ... FROM source
```
где `1 HOUR` может быть любой длительностью, меньшей, чем период обновления `source`. Зависимая таблица не будет обновляться чаще, чем любая из её зависимостей. Это корректный способ настроить цепочку refreshable views, не указывая фактический период обновления более одного раза.
Ещё несколько примеров:
* `REFRESH EVERY 1 DAY OFFSET 10 MINUTE` (`destination`) зависит от `REFRESH EVERY 1 DAY` (`source`)
Если обновление `source` занимает больше 10 минут, `destination` будет его ждать.
* `REFRESH EVERY 1 DAY OFFSET 1 HOUR` зависит от `REFRESH EVERY 1 DAY OFFSET 23 HOUR`
Аналогично примеру выше, хотя соответствующие обновления происходят в разные календарные дни.
Обновление `destination` в день `X+1` будет ждать обновления `source` в день `X` (если оно занимает более 2 часов).
* `REFRESH EVERY 2 HOUR` зависит от `REFRESH EVERY 1 HOUR`
Обновление `2 HOUR` выполняется после обновления `1 HOUR` через каждый второй час, например после полуночного
обновления, затем после обновления в 2 часа ночи и т. д.
* `REFRESH EVERY 1 MINUTE` зависит от `REFRESH EVERY 2 HOUR`
`destination` обновляется один раз после каждого обновления `source`, то есть каждые 2 часа. `1 MINUTE` фактически игнорируется.
* `REFRESH AFTER 1 HOUR` зависит от `REFRESH AFTER 1 HOUR`
В настоящее время это не рекомендуется.
`DEPENDS ON` работает только между refreshable materialized views. Если указать обычную таблицу в списке `DEPENDS ON`, view вообще никогда не будет обновляться (зависимости можно удалить с помощью `ALTER`, см. [Изменение параметров обновления](#changing-refresh-parameters)).
### Настройки обновления
Доступные настройки обновления:
* `refresh_retries` - Сколько раз повторять попытку, если запрос обновления завершается исключением. Если все повторные попытки завершаются неудачей, обновление пропускается до следующего запланированного времени. 0 означает отсутствие повторных попыток, -1 — бесконечное число повторных попыток. Значение по умолчанию: 2.
* `refresh_retry_initial_backoff_ms` - Задержка перед первой повторной попыткой, если `refresh_retries` не равно нулю. При каждой следующей повторной попытке задержка удваивается, вплоть до `refresh_retry_max_backoff_ms`. Значение по умолчанию: 100 мс.
* `refresh_retry_max_backoff_ms` - Ограничение на экспоненциальный рост задержки между попытками обновления. Значение по умолчанию: 60000 мс (1 минута).
* `all_replicas` - В [Replicated database](/ru/reference/engines/database-engines/replicated) с `APPEND` определяет, будут ли все реплики обновляться независимо или в каждый запланированный момент обновление будет выполнять только одна реплика. Не может быть изменено после создания представления. Значение по умолчанию: `false`.
* `prefer_dependency_replica` - Если у представления есть `DEPENDS ON`, приоритет на выполнение зависимого обновления получает реплика, выполнившая обновление родительского объекта; остальные реплики откладывают свою попытку на `prefer_dependency_replica_delay_ms`. Полезно при использовании `SharedMergeTree`, чтобы избежать ситуаций, когда отставание репликации приводит к отсутствию данных в цепочках зависимых обновлений. Значение по умолчанию: `false`.
* `prefer_dependency_replica_delay_ms` - Как долго неприоритетные реплики ждут перед попыткой выполнить зависимое обновление, когда включен параметр `prefer_dependency_replica`. Значение по умолчанию: 2000 мс.
### Изменение параметров обновления
Параметры обновления существующей refreshable materialized view изменяются командой [`ALTER TABLE ... MODIFY REFRESH`](/ru/reference/statements/alter/view#alter-table--modify-refresh-statement):
```sql theme={null}
ALTER TABLE [db.]name MODIFY REFRESH EVERY|AFTER ... [RANDOMIZE FOR ...] [DEPENDS ON ...] [SETTINGS ...]
```
Расписание (`EVERY` или `AFTER`) обязательно: этот оператор всегда заменяет *все* параметры обновления — расписание, `RANDOMIZE FOR`, `DEPENDS ON` и настройки обновления — на указанные в нём. Всё, что опущено, сбрасывается к значению по умолчанию (настройки) или удаляется (зависимости, рандомизация).
* Чтобы изменить только настройки обновления (например, `refresh_retries`), заново укажите текущее расписание:
```sql theme={null}
ALTER TABLE rmv MODIFY REFRESH EVERY 1 HOUR SETTINGS refresh_retries = 5;
```
* `ALTER TABLE ... MODIFY SETTING refresh_retries = ...` не поддерживается для materialized view; нужно использовать `MODIFY REFRESH`.
* Добавлять или удалять `APPEND` не поддерживается.
* Настройку `all_replicas` нельзя изменить после создания.
Примеры:
```sql theme={null}
-- Изменить расписание, удалить существующие настройки и зависимости.
ALTER TABLE rmv MODIFY REFRESH EVERY 30 MINUTE;
-- Изменить расписание и настроить поведение повторных попыток.
ALTER TABLE rmv MODIFY REFRESH EVERY 30 MINUTE
SETTINGS refresh_retries = 5,
refresh_retry_initial_backoff_ms = 500,
refresh_retry_max_backoff_ms = 60000;
-- Сохранить зависимость при изменении периода.
ALTER TABLE rmv MODIFY REFRESH EVERY 6 HOUR DEPENDS ON other_rmv;
-- Удалить зависимость, опустив `DEPENDS ON`.
ALTER TABLE rmv MODIFY REFRESH EVERY 6 HOUR;
```
### Другие операции
Статус всех refreshable materialized view доступен в таблице [`system.view_refreshes`](/ru/reference/system-tables/view_refreshes). В частности, в ней содержатся прогресс обновления (если оно выполняется), время последнего и следующего обновления, а также сообщение об исключении, если обновление завершилось ошибкой.
Чтобы вручную остановить, запустить, инициировать или отменить обновления, используйте [`SYSTEM STOP|START|REFRESH|WAIT|CANCEL VIEW`](/ru/reference/statements/system#managing-refreshable-materialized-views).
Чтобы дождаться завершения обновления, используйте [`SYSTEM WAIT VIEW`](/ru/reference/statements/system#wait-view). Это особенно полезно, если нужно дождаться первого обновления после создания представления.
Интересный факт: запросу обновления разрешено читать из обновляемого представления, при этом он видит версию данных до обновления. Это означает, что вы можете реализовать игру «Жизнь» Конвея: [https://pastila.nl/?00021a4b/d6156ff819c83d490ad2dcec05676865#O0LGWTO7maUQIA4AcGUtlA==](https://pastila.nl/?00021a4b/d6156ff819c83d490ad2dcec05676865#O0LGWTO7maUQIA4AcGUtlA==)
## Оконное представление
Это экспериментальная возможность, которая в будущих выпусках может измениться обратно несовместимым образом. Чтобы включить использование оконных представлений и запроса `WATCH`, включите настройку [allow\_experimental\_window\_view](/ru/reference/settings/session-settings#allow_experimental_window_view). Введите команду `set allow_experimental_window_view = 1`.
```sql theme={null}
CREATE WINDOW VIEW [IF NOT EXISTS] [db.]table_name [TO [db.]table_name] [INNER ENGINE engine] [ENGINE engine] [WATERMARK strategy] [ALLOWED_LATENESS interval_function] [POPULATE]
AS SELECT ...
GROUP BY time_window_function
[COMMENT 'comment']
```
Оконное представление может агрегировать данные по временному окну и выводить результаты, когда окно готово выдать их. Оно хранит частичные результаты агрегации во внутренней (или указанной) таблице, чтобы уменьшить задержку, и может записывать результат обработки в указанную таблицу или отправлять уведомления с помощью запроса WATCH.
Создание оконного представления похоже на создание `MATERIALIZED VIEW`. Для хранения промежуточных данных оконному представлению требуется внутреннее хранилище. Его можно указать с помощью предложения `INNER ENGINE`; по умолчанию оконное представление использует `AggregatingMergeTree` в качестве внутреннего движка.
При создании оконного представления без `TO [db].[table]` необходимо указать `ENGINE` — движок таблицы для хранения данных.
### Функции временных окон
[Функции временных окон](/ru/reference/functions/regular-functions/time-window-functions) используются для получения нижней и верхней границ окна для записей. Оконное представление необходимо использовать вместе с функцией временного окна.
### АТРИБУТЫ ВРЕМЕНИ
Оконное представление поддерживает обработку по **времени обработки** и **времени события**.
**Время обработки** позволяет оконному представлению формировать результаты на основе локального времени машины и используется по умолчанию. Это наиболее простое понятие времени, однако оно не обеспечивает детерминированность. Атрибут времени обработки можно задать, установив `time_attr` функции временного окна в столбец таблицы или используя функцию `now()`. Следующий запрос создает оконное представление с временем обработки.
```sql theme={null}
CREATE WINDOW VIEW wv AS SELECT count(number), tumbleStart(w_id) as w_start from date GROUP BY tumble(now(), INTERVAL '5' SECOND) as w_id
```
**Время события** — это время, когда каждое отдельное событие произошло на устройстве-источнике. Обычно эта временная метка записывается в запись в момент её создания. Обработка по времени события позволяет получать согласованные результаты даже при нарушении порядка событий или при позднем поступлении событий. Оконное представление поддерживает обработку по времени события с помощью синтаксиса `WATERMARK`.
Оконное представление поддерживает три стратегии водяной метки:
* `STRICTLY_ASCENDING`: Выдаёт водяную метку, равную максимальной наблюдаемой на текущий момент временной метке. Строки, у которых временная метка меньше максимальной, не считаются опоздавшими.
* `ASCENDING`: Выдаёт водяную метку, равную максимальной наблюдаемой на текущий момент временной метке минус 1. Строки, у которых временная метка равна максимальной или меньше неё, не считаются опоздавшими.
* `BOUNDED`: WATERMARK=INTERVAL. Выдаёт водяные метки, равные максимальной наблюдаемой временной метке минус указанная задержка.
Следующие запросы — примеры создания оконного представления с `WATERMARK`:
```sql theme={null}
CREATE WINDOW VIEW wv WATERMARK=STRICTLY_ASCENDING AS SELECT count(number) FROM date GROUP BY tumble(timestamp, INTERVAL '5' SECOND);
CREATE WINDOW VIEW wv WATERMARK=ASCENDING AS SELECT count(number) FROM date GROUP BY tumble(timestamp, INTERVAL '5' SECOND);
CREATE WINDOW VIEW wv WATERMARK=INTERVAL '3' SECOND AS SELECT count(number) FROM date GROUP BY tumble(timestamp, INTERVAL '5' SECOND);
```
По умолчанию окно срабатывает при поступлении водяной метки, а элементы, поступившие позже водяной метки, отбрасываются. Оконное представление поддерживает обработку опоздавших событий с помощью настройки `ALLOWED_LATENESS=INTERVAL`. Пример обработки опоздавших событий:
```sql theme={null}
CREATE WINDOW VIEW test.wv TO test.dst WATERMARK=ASCENDING ALLOWED_LATENESS=INTERVAL '2' SECOND AS SELECT count(a) AS count, tumbleEnd(wid) AS w_end FROM test.mt GROUP BY tumble(timestamp, INTERVAL '5' SECOND) AS wid;
```
Обратите внимание, что элементы, выдаваемые при позднем срабатывании, следует рассматривать как обновлённые результаты предыдущего вычисления. Вместо срабатывания в конце окна оконное представление срабатывает сразу при поступлении позднего события. Таким образом, для одного и того же окна будет сформировано несколько результатов. Пользователям нужно учитывать эти дублирующиеся результаты или выполнять их дедупликацию.
Вы можете изменить `SELECT` запрос, указанный в оконном представлении, с помощью оператора `ALTER TABLE ... MODIFY QUERY`. Структура данных, получающаяся в результате выполнения нового `SELECT` запроса, должна быть такой же, как у исходного `SELECT` запроса, как с предложением `TO [db.]name`, так и без него. Обратите внимание, что данные в текущем окне будут потеряны, поскольку промежуточное состояние нельзя использовать повторно.
### Мониторинг новых окон
Оконное представление поддерживает запрос [WATCH](/ru/reference/statements/watch) для мониторинга изменений, либо можно использовать синтаксис `TO` для вывода результатов в таблицу.
```sql theme={null}
WATCH [db.]window_view
[EVENTS]
[LIMIT n]
[FORMAT format]
```
Можно указать `LIMIT`, чтобы задать количество обновлений, которые нужно получить до завершения запроса. Предложение `EVENTS` позволяет использовать сокращённую форму запроса `WATCH`: вместо результата запроса вы получите только последнюю водяную метку запроса.
### Настройки
* `window_view_clean_interval`: Интервал очистки оконного представления в секундах для удаления устаревших данных. Система сохраняет окна, которые ещё не были полностью активированы в соответствии с системным временем или конфигурацией `WATERMARK`, а остальные данные удаляются.
* `window_view_heartbeat_interval`: Интервал heartbeat-сигнала в секундах, показывающий, что watch-запрос активен.
* `wait_for_window_view_fire_signal_timeout`: Тайм-аут ожидания сигнала срабатывания оконного представления при обработке по времени события.
### Пример
Предположим, нам нужно подсчитать количество записей о кликах за каждые 10 секунд в таблице журналов `data`, и структура этой таблицы такова:
```sql theme={null}
CREATE TABLE data ( `id` UInt64, `timestamp` DateTime) ENGINE = Memory;
```
Сначала создадим оконное представление с окном tumble с 10-секундным интервалом:
```sql theme={null}
CREATE WINDOW VIEW wv as select count(id), tumbleStart(w_id) as window_start from data group by tumble(timestamp, INTERVAL '10' SECOND) as w_id
```
Затем с помощью запроса `WATCH` получаем результаты.
```sql theme={null}
WATCH wv
```
При вставке логов в таблицу `data`,
```sql theme={null}
INSERT INTO data VALUES(1,now())
```
Запрос `WATCH` должен вывести результаты в следующем виде:
```text theme={null}
┌─count(id)─┬────────window_start─┐
│ 1 │ 2020-01-14 16:56:40 │
└───────────┴─────────────────────┘
```
Либо можно направить вывод в другую таблицу, используя синтаксис `TO`.
```sql theme={null}
CREATE WINDOW VIEW wv TO dst AS SELECT count(id), tumbleStart(w_id) as window_start FROM data GROUP BY tumble(timestamp, INTERVAL '10' SECOND) as w_id
```
Дополнительные примеры можно найти в тестах ClickHouse с сохранением состояния (там они называются `*window_view*`).
### Использование оконного представления
Оконное представление полезно в следующих сценариях:
* **Мониторинг**: Агрегируйте и вычисляйте метрики по журналам во времени и выводите результаты в целевую таблицу. Панель мониторинга может использовать целевую таблицу в качестве исходной.
* **Анализ**: Автоматически агрегируйте и предварительно обрабатывайте данные в пределах временного окна. Это может быть полезно при анализе большого количества журналов. Предварительная обработка устраняет повторяющиеся вычисления в нескольких запросах и уменьшает задержку выполнения запросов.
## Связанные материалы
* Блог: [Работа с временными рядами в ClickHouse](https://clickhouse.com/blog/working-with-time-series-data-and-functions-ClickHouse)
* Блог: [Создание решения для обсервабилити на ClickHouse — часть 2 — трейсы](https://clickhouse.com/blog/storing-traces-and-spans-open-telemetry-in-clickhouse)
## Временные представления
ClickHouse поддерживает **временные представления** со следующими характеристиками (где применимо — аналогично временным таблицам):
* **Срок жизни сеанса**
Временное представление существует только в рамках текущего сеанса. По завершении сеанса оно удаляется автоматически.
* **Без базы данных**
Для временного представления **нельзя** указывать имя базы данных. Оно существует вне баз данных (в пространстве имен сеанса).
* **Не реплицируется / без ON CLUSTER**
Временные объекты локальны для сеанса и **не могут** создаваться с `ON CLUSTER`.
* **Разрешение имен**
Если временный объект (таблица или представление) имеет то же имя, что и постоянный объект, и запрос ссылается на это имя **без** указания базы данных, используется **временный** объект.
* **Логический объект (без хранения)**
Временное представление хранит только текст своего `SELECT` (внутри используется хранилище `View`). Оно не сохраняет данные и не поддерживает `INSERT`.
* **Предложение ENGINE**
Указывать `ENGINE` **не** требуется; если указать `ENGINE = View`, оно будет проигнорировано / обработано как то же логическое представление.
* **Безопасность / привилегии**
Для создания временного представления требуется привилегия `CREATE TEMPORARY VIEW`, которая неявно предоставляется через `CREATE VIEW`.
* **SHOW CREATE**
Используйте `SHOW CREATE TEMPORARY VIEW view_name;`, чтобы вывести DDL временного представления.
### Синтаксис
```sql theme={null}
CREATE TEMPORARY VIEW [IF NOT EXISTS] view_name AS
```
`OR REPLACE` **не** поддерживается для временных представлений (по аналогии с временными таблицами). Если вам нужно «заменить» временное представление, удалите его и создайте заново.
### Примеры
Создайте временную исходную таблицу и временное представление на её основе:
```sql theme={null}
CREATE TEMPORARY TABLE t_src (id UInt32, val String);
INSERT INTO t_src VALUES (1, 'a'), (2, 'b');
CREATE TEMPORARY VIEW tview AS
SELECT id, upper(val) AS u
FROM t_src
WHERE id <= 2;
SELECT * FROM tview ORDER BY id;
```
Показать DDL:
```sql theme={null}
SHOW CREATE TEMPORARY VIEW tview;
```
Удалить её:
```sql theme={null}
DROP TEMPORARY VIEW IF EXISTS tview; -- временные представления удаляются с использованием синтаксиса TEMPORARY TABLE
```
### Недопустимые варианты / ограничения
* `CREATE OR REPLACE TEMPORARY VIEW ...` → **не допускается** (используйте `DROP` + `CREATE`).
* `CREATE TEMPORARY MATERIALIZED VIEW ...` / `WINDOW VIEW` → **не допускается**.
* `CREATE TEMPORARY VIEW db.view AS ...` → **не допускается** (без указания базы данных).
* `CREATE TEMPORARY VIEW view ON CLUSTER 'name' AS ...` → **не допускается** (временные объекты локальны для сеанса).
* `POPULATE`, `REFRESH`, `TO [db.table]`, внутренние движки и все специфичные для MV секции → **не применимы** к временным представлениям.
### Примечания о распределённых запросах
Временное **представление** — это лишь определение; передавать здесь нечего. Если ваше временное представление ссылается на временные **таблицы** (например, `Memory`), их данные могут передаваться на удалённые серверы при выполнении распределённого запроса — так же, как и в случае временных таблиц.
#### Пример
```sql theme={null}
-- Таблица в памяти в рамках сеанса
CREATE TEMPORARY TABLE temp_ids (id UInt64) ENGINE = Memory;
INSERT INTO temp_ids VALUES (1), (5), (42);
-- Представление в рамках сеанса над временной таблицей (исключительно логическое)
CREATE TEMPORARY VIEW v_ids AS
SELECT id FROM temp_ids;
-- Замените 'test' именем вашего кластера.
-- GLOBAL JOIN заставляет ClickHouse *отправлять* небольшую сторону JOIN (temp_ids через v_ids)
-- на каждый удалённый сервер, выполняющий левую часть запроса.
SELECT count()
FROM cluster('test', system.numbers) AS n
GLOBAL ANY INNER JOIN v_ids USING (id)
WHERE n.number < 100;
```