Skip to main content
Запросы в ClickHouse можно разделить на несколько типов:
  1. Запросы на чтение данных: SELECT, SHOW, DESCRIBE, EXISTS.
  2. Запросы на запись данных: INSERT, OPTIMIZE, DELETE, UPDATE, ALTER TABLE ... DELETE, ALTER TABLE ... UPDATE.
  3. Запросы на изменение настроек: SET, USE.
  4. DDL DDL-запросы: CREATE, ALTER, RENAME, EXCHANGE, ATTACH, DETACH, DROP, TRUNCATE.
  5. Запросы управления доступом: GRANT, REVOKE, а также CREATE, ALTER и DROP пользователей, ролей, политик строк, политик маскирования, квот и профилей настроек. См. систему управления доступом и учётными записями.
  6. KILL QUERY.
ALTER TABLE ... DELETE и ALTER TABLE ... UPDATE изменяют данные, а не метаданные таблицы, поэтому выше они отнесены к запросам на запись данных. Для них требуются привилегии ALTER DELETE и ALTER UPDATE — те же самые привилегии, которые требуются для автономных операторов DELETE и UPDATE. Эти привилегии относятся к группе привилегий ALTER TABLE, поэтому при allow_ddl = 0 все четыре оператора для постоянной таблицы отклоняются. Следующие настройки определяют права пользователя в зависимости от типа запроса:

​
readonly

Ограничивает, какие запросы может выполнять сеанс. Значения этой настройки, значение по умолчанию и то, какие настройки позволяет изменять каждое значение, описаны в справочнике по настройкам; в этом разделе описано, какие классы запросов разрешает каждое значение. При значении 1 разрешены такие запросы, как:
  • Запросы на чтение (например, SELECT и эквивалентные ему запросы).
  • Запросы, изменяющие только контекст сеанса (например, USE).
При значении 2 дополнительно разрешены SET, CREATE TEMPORARY TABLE и RESTORE. RESTORE может создать таблицу и загрузить в неё данные, поэтому readonly = 2 сам по себе не препятствует записи из сеанса; при readonly = 1 такой запрос отклоняется. BACKUP не ограничивается настройкой readonly ни при каком её значении: сеанс, обладающий привилегиями на резервное копирование таблицы, может создать backup даже при readonly = 1. Не полагайтесь на readonly для запрета резервного копирования. Большинству табличных функций требуется привилегия CREATE TEMPORARY TABLE, поэтому SELECT, читающий из такой функции, отклоняется при readonly = 1, но не при readonly = 2. Некоторые из них, например numbers, разрешены в режиме только для чтения. При любом значении больше 0 для постоянной таблицы не допускаются ни запросы на запись данных (INSERT, OPTIMIZE, DELETE, UPDATE, ALTER TABLE ... DELETE, ALTER TABLE ... UPDATE), ни DDL-запросы (CREATE, ALTER TABLE, ALTER VIEW, RENAME, EXCHANGE, ATTACH, DETACH, DROP, TRUNCATE TABLE). Команды SYSTEM, требующие привилегии из группы SYSTEM, а также CREATE, ALTER и DROP пользователей, ролей, политик строк, политик маскирования, квот и профилей настроек также не допускаются. Исключением является управление именованными коллекциями: readonly не ограничивает CREATE NAMED COLLECTION, ALTER NAMED COLLECTION и DROP NAMED COLLECTION. Выдача привилегии с помощью GRANT также отклоняется, но не каждый оператор управления доступом: локальный REVOKE и GRANT CURRENT GRANTS не ограничиваются настройкой readonly, поэтому сеанс только для чтения по-прежнему может отозвать привилегию, которой он владеет с grant option, и передать собственные привилегии другому пользователю. Отзыв привилегии с предложением ON CLUSTER отклоняется. Обе настройки не распространяются на временные таблицы: сеанс, которому разрешено создать такую таблицу, может также выполнять для неё ALTER, вставлять в неё данные и удалять её.
При работе через HTTP interface запрос, метод которого отличается от POST, выполняется с readonly = 2, если иначе действующее значение было бы равно 0. Более строгое значение, уже заданное настройками пользователя или профилем настроек, сохраняется. Исключение составляют PUT и DELETE, когда они попадают в обработчик, определённый через SQL, который их принимает: такой запрос может изменять данные, если действующее значение readonly равно 0; в остальных случаях для изменения данных используйте метод POST.Для запроса, к которому применено такое повышение, параметр readonly в query string отклоняется с сообщением Cannot modify 'readonly' setting in readonly mode, если только он не задаёт то же значение, которое запрос уже имеет.Существует способ запретить пользователю изменять только определённые настройки, а также способ разрешить изменять только определённые настройки в условиях ограничений readonly = 1. Подробнее см. ограничения на настройки, где также не рекомендуется делать саму настройку readonly изменяемой в режиме только для чтения.

​
allow_ddl

Разрешает или запрещает DDL-запросы к базам данных, таблицам, представлениям, словарям, пользовательским функциям, рабочим нагрузкам, ресурсам и обработчикам, определённым через SQL. Возможные значения:
  • 0 — выполнение запроса к постоянному объекту, требующего любой из следующих привилегий, блокируется: CREATE DATABASE, DROP DATABASE, CREATE TABLE, CREATE VIEW, ALTER TABLE, ALTER VIEW, DROP TABLE, DROP VIEW, TRUNCATE, CREATE DICTIONARY, DROP DICTIONARY, CREATE FUNCTION, DROP FUNCTION, CREATE WORKLOAD, DROP WORKLOAD, CREATE RESOURCE, DROP RESOURCE, CREATE HANDLER, ALTER HANDLER, DROP HANDLER. Запросам RENAME, EXCHANGE, ATTACH и DETACH эти привилегии тоже нужны, поэтому они также блокируются — за исключением ALTER TABLE ... ATTACH PARTITION и ATTACH PART, которым достаточно только INSERT, поэтому эта настройка их не блокирует (хотя readonly блокирует их для постоянной таблицы). Запросу ATTACH PARTITION ... FROM дополнительно требуется ALTER DELETE, поэтому он блокируется. Выдача и отзыв этих привилегий не блокируются.
  • 1 — эта настройка ничего не блокирует.
Значение по умолчанию: 1
Выполнить SET allow_ddl = 1 нельзя, если в текущем сеансе установлено allow_ddl = 0.allow_ddl не ограничивает запросы управления доступом: на GRANT, REVOKE, а также на CREATE, ALTER и DROP пользователей, ролей, политик строк, политик маскирования, квот и профилей настроек эта настройка не влияет. CREATE TEMPORARY TABLE и управление именованными коллекциями она также не затрагивает, равно как и ALTER DATABASE ... MODIFY SETTING, ALTER DATABASE ... MODIFY COMMENT и UNDROP TABLE, которые не ограничивает и readonly. Внутри CREATE или ALTER пользователя, роли или профиля настроек предложение SETTINGS allow_ddl = 1 отклоняется, пока в текущем сеансе действует allow_ddl = 0, а предложение SETTINGS allow_ddl = 0 принимается. Встроенная настройка проверяется на соответствие собственным ограничениям настроек сеанса — по этой же причине отклоняется и SET allow_ddl = 1.
KILL QUERYЗавершение собственных запросов не требует привилегии KILL QUERY, поэтому оно работает при любом сочетании readonly и allow_ddl. Однако требуется привилегия SELECT на system.processes — за исключением запроса KILL QUERY WHERE query_id = '<id>', который отменяет ваш собственный запрос с этим ID, не читая эту таблицу. Завершение запроса, принадлежащего другому пользователю, а также любой KILL QUERY ... ON CLUSTER требуют привилегии KILL QUERY, которую readonly = 1 и readonly = 2 не допускают.

​
Другие связанные настройки

  • allow_introspection_functions — третья настройка, которая наряду с readonly и allow_ddl участвует непосредственно в принятии решения о доступе. Если она отключена, выполнение функции интроспекции блокируется, а вот выдача привилегии INTROSPECTION — нет.
  • allow_non_metadata_alters не является настройкой разрешений, но дополнительно ограничивает ALTER TABLE: если она отключена, команда, изменяющая определение таблицы, отклоняется для таблиц семейства MergeTree в случае, когда её применение привело бы к перезаписи данных на диске (DROP COLUMN, RENAME COLUMN, изменение типа через MODIFY COLUMN, MODIFY TTL). CLEAR COLUMN, CLEAR INDEX и CLEAR PROJECTION также отклоняются, хотя они и оставляют определение без изменений. На команды, которые сами по себе являются мутациями, такие как ALTER TABLE ... DELETE, ALTER TABLE ... UPDATE и ALTER TABLE ... MATERIALIZE INDEX, это не распространяется.
Последнее изменение 26 сентября 2026 г.