# Установка переменных онлайн

## SET
```sql
SET [GLOBAL] server_variable_name = value
SET [INDEX table_name] GLOBAL @user_variable_name = (int_val1 [, int_val2, ...])
SET NAMES value [COLLATE value]
SET @@dummy_variable = ignored_value
```

Оператор `SET` в Manticore Search позволяет изменять значения переменных. Имена переменных не чувствительны к регистру, и никакие изменения значений переменных не сохранятся после перезапуска сервера.

Manticore Search поддерживает оператор `SET NAMES` и синтаксис `SET @@variable_name` для совместимости с внешними MySQL клиентскими библиотеками, коннекторами и фреймворками, которые могут требовать выполнения этих операторов при подключении. Однако эти операторы не влияют на сам Manticore Search.

В Manticore Search существуют четыре класса переменных:

1.  Переменная сервера на сессию: `set var_name = value`
2.  Глобальная переменная сервера: `set global var_name = value`
3.  Глобальная пользовательская переменная: `set global @var_name = (value)`
4.  Глобальная распределённая переменная: `set index dist_table_name global @var_name = (value)`

Глобальные пользовательские переменные разделяются между параллельными сессиями. Единственный поддерживаемый тип значения — список BIGINT, и эти переменные можно использовать с оператором IN() для фильтрации. Основное применение этой возможности — загрузка больших списков значений в `searchd` один раз с последующим многократным использованием, что снижает сетевые расходы. Глобальные пользовательские переменные можно передавать всем агентам распределённой таблицы или устанавливать локально в случае локальной таблицы, определённой в распределённой таблице. Пример:

```sql
// in session 1
mysql> SET GLOBAL @myfilter=(2,3,5,7,11,13);
Query OK, 0 rows affected (0.00 sec)

// later in session 2
mysql> SELECT * FROM test1 WHERE group_id IN @myfilter;
+------+--------+----------+------------+-----------------+------+
| id   | weight | group_id | date_added | title           | tag  |
+------+--------+----------+------------+-----------------+------+
|    3 |      1 |        2 | 1299338153 | another doc     | 15   |
|    4 |      1 |        2 | 1299338153 | doc number four | 7,40 |
+------+--------+----------+------------+-----------------+------+
2 rows in set (0.02 sec)
```

Manticore Search поддерживает переменные сервера на сессию и глобальные переменные сервера, которые влияют на определённые настройки сервера в соответствующих областях видимости. Ниже приведён список известных переменных сервера на сессию и глобальных переменных сервера:

Известные переменные сервера на сессию:

* `AUTOCOMMIT = {0 | 1}` определяет, должны ли операции изменения данных неявно заключаться в `BEGIN` и `COMMIT`.
* `COLLATION_CONNECTION = collation_name` выбирает колляцию для `ORDER BY` или `GROUP BY` по строковым значениям в последующих запросах. Список известных названий колляций см. в разделе [Collations](../Searching/Collations.md).
* `MAX_THREADS_PER_QUERY = <POSITIVE_INT_VALUE>` переопределяет [max_threads_per_query](../Server_settings/Searchd.md#max_threads_per_query) во время выполнения. Переменная на сессию влияет только на запросы, выполняемые в той же сессии (соединении), т.е. до отключения. Значение 0 означает "без ограничений". Если установлены обе переменные — и на сессию, и глобальная, приоритет выше у переменной на сессию.
* `NET_WRITE_TIMEOUT = <value>`
* `NET_READ_TIMEOUT = <value>`
* `INTERACTIVE_TIMEOUT = <value>`: Устанавливает таймаут подключения SQL (время простоя) для интерактивных SQL-сессий. Распространенный пример — подключение к серверу Manticore с использованием клиента командной строки (CLI), такого как `mysql`. Ранее существовали отдельные глобальные таймауты 'чтения' и 'записи', но это оказалось запутанным. Теперь `NET_WRITE_TIMEOUT` и `NET_READ_TIMEOUT` являются псевдонимами для `INTERACTIVE_TIMEOUT`. Все они управляют одной и той же переменной, относящейся только к конечным точкам SQL: максимальное допустимое время простоя соединения. Это похоже на `WAIT_TIMEOUT`, но специально для интерактивных сессий.
* `WAIT_TIMEOUT = <value>`: Устанавливает таймаут подключения SQL (время простоя) для неинтерактивных SQL-сессий. Распространённый пример — клиентская библиотека, подключающаяся к серверу Manticore и поддерживающая пул соединений для повторного использования. Это похоже на `INTERACTIVE_TIMEOUT`, но применяется специально к неинтерактивным сессиям.
* `OPTIMIZE_BY_ID = {0 | 1}`: Внутренний флаг, используемый в некоторых командах `debug`.
* `PROFILING = {0 | 1}` включает профилирование запросов в текущей сессии. По умолчанию 0. См. также [show profile](../Node_info_and_management/Profiling/Query_profile.md).
* `ro = {1 | 0}` переключает сессию в режим только для чтения или обратно. В выводе `show variables` переменная показывается под именем `session_read_only`.
* `throttling_period = <INT_VALUE>`: Интервал (в миллисекундах), в течение которого текущий выполняющийся запрос будет переназначен. Значение 0 отключает ограничение, что значит, запрос займет ядра CPU до завершения. Если параллельные запросы поступают в это же время из других соединений, они будут отправлены на свободные ядра или приостановлены до освобождения ядра. Установка отрицательного значения (-1) сбрасывает ограничение до стандартного скомпилированного значения (100 мс), что означает переназначение запроса каждые 100 мс, позволяющее выполнять параллельные запросы. Глобальное значение (устанавливаемое через `set global`) может задаваться только через VIP соединение.
* `thread_stack = <value>`: Меняет значение по умолчанию на лету, ограничивая размер стека, выделенного одной задаче. При этом 'thread' здесь означает не поток ОС, а поток пользователя, известный также как корутина. Это полезно, например, если вы загружаете percolate таблицу с неожиданно высокими требованиями. В таких случаях 'call pq' завершится ошибкой о недостаточном размере стека. Обычно нужно остановить демон, увеличить значение в конфиге, а затем перезапустить. Однако можно попробовать новое значение без перезапуска, установив его этой переменной. Глобальное значение также можно изменить онлайн с `set global thread_stack`, но это возможно только из VIP соединения.
* `threads_ex` (диагностическая): Заставляет Manticore вести себя так, как будто он запущен на CPU с указанным профилем. Краткий пример: `set threads_ex='4/2+6/3'` означает 'у вас есть 4 свободных CPU ядра, при планировании нескольких запросов их нужно группировать по 2. Кроме того, у вас есть 6 свободных CPU ядер для псевдо-шардинга, части нужно группировать по 3'. Эта опция диагностическая, так как очень полезна, например, чтобы увидеть, как ваш запрос выполнялся бы на конфигурации, которой у вас нет локально. Например, на 128-ядерном CPU. Или, наоборот, чтобы быстро ограничить демон до однопоточного режима, чтобы найти узкое место или исследовать сбой.

  <details>

	По умолчанию Manticore запускает пул потоков с рассчитанным количеством CPU ядер. Все типовые задачи распределяются в этот пул потоков для обеспечения максимального использования CPU. Например, когда в real-time таблице несколько дисковых чанков, поиск параллелится по ядрам CPU. Аналогично, для одного полнотекстового поиска в одном индексе демон пытается оптимизировать выполнение поиска параллельно, используя метод, называемый «псевдо-шардинг». Обе функции сильно зависят от общего количества ядер CPU и числа свободных ядер, доступных для немедленного использования.

	Этот подход улучшает производительность, но усложняет исследование инцидентов. Например, запрос с `COUNT(*)` может вернуть приблизительный результат (например, больше 100 совпадений), а последующий запуск того же запроса — точный результат (например, ровно 120 совпадений). Эта изменчивость зависит от доступных ядер, и поскольку этот фактор непредсказуем, это обычно ведёт к нерепродуцируемым результатам. Хотя это обычно допустимо, иногда может вызывать проблемы. Опция `threads_ex` задаёт желаемую конфигурацию CPU ядер, делая запросы с этой конфигурацией воспроизводимыми.

`threads_ex` устанавливает шаблон использования CPU для стандартных задач и для псевдо-шардирования, так как псевдо-шардирование может быть частью стандартного процесса параллелизации. Например, если существует несколько фрагментов диска, они будут запрошены параллельно, но каждый из них может быть далее параллелизован с использованием псевдо-шардирования. Таким образом, для эффективного управления этой ситуацией необходима пара шаблонов для каждого типа задач.

Шаблон — это строка вида `10/3`, где 10 обозначает уровень параллелизма (concurrency), а 3 — размер пакета (batch size). Если параллелизм равен 0, будет использоваться параллелизм по умолчанию. Если размер пакета равен 0, будет использоваться тривиальный шаблон по умолчанию. Любое нулевое значение может быть опущено или заменено на `*`. Шаблон по умолчанию (тривиальный) можно описать как `''`, а также как `*/*`, `0/0`, `0/`, `*/`, `/0`, `*` и т.д. Это означает, что демон использует все доступные ядра CPU без специальных ограничений на пакетирование.

Тривиальный шаблон с 20 потоками может быть выражен как `20/*`, `20/0`, `20/`, или просто `20`. Шаблон с циклическим распределением (round-robin) с размером пакета 2 — это `*/2`, `0/2`, или просто `/2`. Диспетчер с циклическим распределением, 20 потоками и размером пакета 3 — это `20/3`.

`threads_ex` — это шаблон для базовых задач и для псевдо-шардирования, разделённый знаком `+`, например:

* `30+3` — тривиальная база из 30 потоков + тривиальное псевдо-шардирование из 3 потоков
* `+/2` — тривиальная база + псевдо-шардирование с циклическим распределением с потоками по умолчанию и batch=2
* `10` — тривиальная база из 10 потоков + тривиальное псевдо-шардирование по умолчанию
* `/1+10` — база с циклическим распределением с потоками по умолчанию и batch=1 + тривиальное псевдо-шардирование с 10 потоками
* `4/2+2/1` — база с циклическим распределением с 4 потоками и batch=2 + псевдо-шардирование с циклическим распределением с 2 потоками и batch=1
* `1+1` — наиболее детерминированный случай. Ровно 1 поток + 1 псевдо-шард, т.е. параллелизации вообще нет. С этой настройкой вы можете воспроизводимо повторить один и тот же проблемный запрос и исследовать детали поведения. Более того, если вы установите `throttling_period=0`, ваш запрос «прилипнет» к текущему потоку и никогда не будет перепланирован во время выполнения, создавая идеальную среду для устранения неполадок.

Опция может быть установлена глобально извне как переменная окружения `MANTICORE_THREADS_EX`, например:

	```bash
	export MANTICORE_THREADS_EX=8
 	# or
	export MANTICORE_THREADS_EX='16+8/2'
  ```

  Или через MySQL CLI, как:
  ```sql
  SET threads_ex='16';
  -- или
  SET GLOBAL threads_ex='/2';
  ```

  Или как параметр запроса, например:
  ```sql
  SELECT ... OPTION threads_ex='1+1';
  ```

  Конфигурация `threads_ex` следует иерархии: сначала переменные окружения, затем глобальная переменная и, наконец, параметры запроса, что позволяет конкретным настройкам переопределять общие.

  </details>

Известные глобальные серверные переменные:

* `WAIT_TIMEOUT = <значение>` устанавливает таймаут SQL-соединения на максимально допустимое время простоя для неинтерактивного соединения. Вы можете настроить этот параметр либо для сессии (для текущего соединения), либо глобально, но глобальные настройки применяются только при использовании VIP-соединений.
* `INTERACTIVE_TIMEOUT = <значение>` устанавливает таймаут SQL-соединения на максимально допустимое время простоя для интерактивного соединения. Как и `WAIT_TIMEOUT`, этот параметр можно настроить для сессии или глобально, но глобальные настройки применяются только при использовании VIP-соединений.
* `ACCURATE_AGGREGATION`: Устанавливает значение по умолчанию для опции [accurate_aggregation](../Searching/Options.md#accurate_aggregation) будущих запросов.
* `AUTO_OPTIMIZE = <non-negative integer>` Настраивает [auto_optimize](../Server_settings/Searchd.md#auto_optimize): `0` отключает, `1` включает с порогом по умолчанию, а значения больше `1` умножают этот порог.
* `cluster_user = name` Устанавливает имя пользователя, используемое с `mysqldump` / `mariadb-dump` для [включения режима репликации](../Securing_and_compacting_a_table/Backup_and_restore.md#Backup-and-restore-with-mysqldump).
* `COREDUMP= {1|0}` Включает/выключает сохранение core-файла или минидампа сервера при сбое. Подробнее [здесь](../Starting_the_server/Manually.md#searchd-command-line-options).
* `CPUSTATS= {1|0}` Включает/выключает [отслеживание времени CPU](../Starting_the_server/Manually.md#searchd-command-line-options).
* `DISTINCT_PRECISION_THRESHOLD`: Устанавливает значение по умолчанию для опции [distinct_precision_threshold](../Searching/Options.md#distinct_precision_threshold) будущих запросов.
* `EMBEDDINGS_THREADS = <non-negative integer>` Меняет [embeddings_threads](../Server_settings/Searchd.md#embeddings_threads) во время работы. Значение ограничивает, сколько потоков библиотека embeddings может использовать при генерации векторов для вставок с автоэмбеддингом, перестроения KNN в `ALTER TABLE` и эмбеддинга текстовых запросов KNN. `0` отключает ограничение.
* `ES_COMPAT = {on/off/dashboards}` При установке в `on` (по умолчанию) поддерживаются запросы записи, аналогичные Elasticsearch; `off` отключает поддержку; `dashboards` включает поддержку и также разрешает запросы из Kibana (функциональность экспериментальная).
* `EXPANSION_MERGE_THRESHOLD_DOCS`: Изменяет значение настройки конфига [expansion_merge_threshold_docs](../Server_settings/Searchd.md#expansion_merge_threshold_docs) на лету.
* `EXPANSION_MERGE_THRESHOLD_HITS`: Изменяет значение настройки конфига [expansion_merge_threshold_hits](../Server_settings/Searchd.md#expansion_merge_threshold_hits) на лету.
* `GROUPING_IN_UTC = {0 | 1}` При установке в 1 вызывает расчет функций группировки по времени (day(), month(), year(), yearmonth(), yearmonthday()) в UTC. Подробнее о параметре [grouping_in_utc](../Server_settings/Searchd.md).
* `IOSTATS = {0 | 1}` Включает или выключает отчеты об операциях ввода-вывода (кроме атрибутов) в журнале запросов.
* `KNN_PARALLEL_BUILD = <положительное целое число>` Изменяет [knn_parallel_build](../Server_settings/Searchd.md#knn_parallel_build) во время выполнения. Значение контролирует, сколько рабочих потоков может использоваться для построения графов HNSW во время сохранения RT-чанков и слияний чанков при `OPTIMIZE` / автооптимизации.
* `LOG_DEBUG_FILTER = <string value>` Фильтрует избыточные сообщения журнала. Если установлено значение, тогда все логи с уровнем > INFO (например, `DEBUG`, `DEBUGV` и т.д.) будут сравниваться со строкой, и выводиться только в случае, если начинаются с данного значения.
* `LOG_LEVEL = {info | debug | replication | debugv | debugvv}` Изменяет текущий уровень подробности журнала.
* `MAINTENANCE = {0 | 1}` При установке в 1 переводит сервер в режим обслуживания. В этом режиме запросы могут выполнять только клиенты с VIP-соединениями. Все новые не-VIP соединения отклоняются. Существующие соединения сохраняются.
* `MAX_THREADS_PER_QUERY = <POSITIVE_INT_VALUE>` Переопределяет [max_threads_per_query](../Server_settings/Searchd.md#max_threads_per_query) во время выполнения. Если задано глобально, меняет поведение для всех сессий. Значение 0 означает "без ограничений". Если установлены обе переменные — на сессию и глобальная, приоритет у переменной на сессию.
* `NET_WAIT = {-1 | 0 | POSITIVE_INT_VALUE}` Изменяет значение настройки [net_wait_tm](../Server_settings/Searchd.md#net_wait_tm) searchd.
* `OPTIMIZE_CUTOFF = <value>`: Изменяет значение настройки конфига [optimize_cutoff](../Server_settings/Searchd.md#optimize_cutoff) на лету.
* `PSEUDO_SHARDING = {1|0}` Включает/выключает поиск с помощью [псевдо-шардинга](../Server_settings/Searchd.md#pseudo_sharding).
* `QCACHE_MAX_BYTES = <value>` Изменяет лимит использования ОЗУ для [query_cache](../Searching/Query_cache.md) на заданное значение.
* `QCACHE_THRESH_MSEC = <value>` Изменяет минимальный порог времени выполнения кэша запросов [query_cache](../Searching/Query_cache.md) на заданное значение.
* `QCACHE_TTL_SEC = <value>` Изменяет время жизни (TTL) для закэшированного результата в [query_cache](../Searching/Query_cache.md) на заданное значение.
* `QUERY_LOG_FORMAT = {plain | sphinxql}` Изменяет текущий формат журнала.
* `QUERY_LOG_MIN_MSEC = <value>` Изменяет значение настройки [query_log_min_msec](../Server_settings/Searchd.md#query_log_min_msec) searchd. В этом случае значение ожидается строго в миллисекундах без обработки суффиксов времени, как в конфиге.
  > Внимание: это очень специфичная и "жёсткая" переменная; отфильтрованные сообщения просто удаляются и не записываются в журнал. Лучше фильтруйте журнал с помощью чего-то вроде 'grep', тогда у вас всегда будет резервная копия полного оригинального журнала.
* `RESET_NETWORK_TIMEOUT_ON_PACKET = {1|0}` Изменяет параметр [reset_network_timeout_on_packet](../Server_settings/Searchd.md#reset_network_timeout_on_packet). Изменять этот параметр могут только клиенты с VIP-соединениями.
* `SECONDARY_INDEXES = {1|0}` Включает/выключает [вторичные индексы](../Server_settings/Searchd.md#secondary_indexes) для поисковых запросов.
* `TIMEZONE = <value>` Указывает временную зону, используемую функциями, связанными с датой/временем. Подробнее о параметре [timezone](../Server_settings/Searchd.md).

Примеры:

```sql
mysql> SET autocommit=0;
Query OK, 0 rows affected (0.00 sec)

mysql> SET GLOBAL query_log_format=sphinxql;
Query OK, 0 rows affected (0.00 sec)

mysql> SET GLOBAL @banned=(1,2,3);
Query OK, 0 rows affected (0.01 sec)

mysql> SET INDEX users GLOBAL @banned=(1,2,3);
Query OK, 0 rows affected (0.01 sec)
```

Чтобы сделать пользовательские переменные постоянными, убедитесь, что [sphinxql_state](../Server_settings/Searchd.md#sphinxql_state) включен.
<!-- proofread -->
