Глава 6. Администрирование сервера MySQL
MySQL Server (mysqld
) является основной программой, которая делает большую часть
работы в MySQL. Эта глава обеспечивает краткий обзор сервера MySQL и касается
общего администрирования сервера:
Конфигурация сервера.
- Каталог данных, особенно системная база данных
mysql .
- Файлы системного журнала сервера.
- -Управление многими серверами на единственной машине.
Для дополнительной информации об административных темах см. также:
6.1. MySQL Server
mysqld
это сервер MySQL. Следующее обсуждение затрагивает эти темы
конфигурации сервера MySQL:
Для списков переменных сервера MySQL и опций, которые были добавлены,
устарели или удалены в MySQL 8.0 см.
раздел 1.5.
Не все механизмы хранения поддержаны всеми сборками сервера MySQL и
конфигурациями. Чтобы узнать, как определить, которые механизмы хранения Ваш
сервер MySQL поддерживает, см.
раздел 14.7.5.16.
6.1.1. Конфигурирование сервера
Сервер MySQL, mysqld
, имеет много опций, команд и системных переменных, которые могут
быть установлены при запуске, чтобы сконфигурировать его работу. Чтобы
определить опцию и системные значения переменной, используемые сервером,
выполните эту команду:
shell> mysqld --verbose --help
Команда производит список всех опций и конфигурируемых системных
переменных mysqld
. Его вывод включает значения опций и переменных по умолчанию и
выглядит примерно так:
abort-slave-event-count 0
allow-suspicious-udfs FALSE
archive ON
auto-increment-increment1
auto-increment-offset 1
autocommitTRUE
automatic-sp-privileges TRUE
avoid-temporal-upgradeFALSE
back-log 80
basedir /home/jon/bin/mysql-8.0/
...
tmpdir/tmp
transaction-alloc-block-size8192
transaction-isolation REPEATABLE-READ
transaction-prealloc-size 4096
transaction-read-only FALSE
transaction-write-set-extraction OFF
updatable-views-with-limitYES
validate-user-plugins TRUE
verbose TRUE
wait-timeout28800
Чтобы видеть значения переменной существующей системы, используемые
сервером при работе, соединитесь с ним и выполните этот запрос:
mysql> SHOW VARIABLES;
Чтобы видеть некоторую статистистику и индикаторы состояния для рабочего
сервера, выполните этот запрос:
mysql> SHOW STATUS;
Система переменная и информация о статусе также является доступной
через mysqladmin
:
shell> mysqladmin variables
shell> mysqladmin extended-status
Для полного описания всех опций, команд, системных переменных и переменных
состояния см. эти разделы:
Более подробная информация о контроле доступна из
Performance Schema, см. главу 23.
Если Вы определяете опцию в командной строке для
mysqld или
mysqld_safe
, это остается в силе только для этого вызова сервера. Чтобы использовать
опцию каждый раз выполнения сервера, поместите ее в файл опции. См.
раздел 5.2.6.
6.1.2.
Значения по умолчанию конфигурации сервера
Сервер MySQL имеет много операционных параметров, которые Вы можете
изменить при запуске сервера, используя параметры командной строки или
конфигурационные файлы (файлы опции). Также возможно изменить много
параметров во время выполнения. Для общих инструкций по устаноке параметров
при запуске или во время выполнения см. разделы
6.1.4 и
6.1.5.
В Windows MySQL Installer взаимодействует с пользователем и создает файл
my.ini в основном каталоге установки как файл опции по
умолчанию. Если Вы устанавливаете в Windows из архива Zip,
Вы можете скопировать файл шаблона my-default.ini
в основном каталоге установки в my.ini
и использовать его в качестве файла опций по умолчанию.
В Windows расширение файла опции .ini или
.cnf может не отображаться.
На любой платформе после завершения процесса установки Вы можете
отредактировать файл опции по умолчанию в любое время, чтобы изменить
параметры, используемые сервером. Например, чтобы использовать установку
параметра в файле, который прокомментирован с символом #
в начале строки, удалите # и измените значение параметра в
случае необходимости. Чтобы отключить установку, допишите
символ # к началу строки.
Для дополнительной информации о формате файла опции и синтаксисе см.
раздел 5.2.6.
6.1.3.
Параметры и переменные сервера
Следующая таблица обеспечивает список всех параметров командной строки
сервера и переменных состояния, применимых в пределах mysqld .
Таблица приводит параметры командной строки (Cmd-line),
опции, допустимые в конфигурационных файлах (файл опций), системные
переменные сервера и переменные состояния в одном объединенном списке с
уведомлением о том, где каждая опция/переменная допустима. Если набор
параметра сервера на командной строке или в файле опции отличается от
названия соответствующей системы сервера или переменной состояния, имя
переменной отмечено немедленно ниже соответствующей опции. Для переменных
состояния показывают контекст (область действия) переменной. Пожалуйста,
изучите соответствующие разделы для деталей об установке и использовании
опций и переменных. Где надо, есть прямая ссылка к дополнительной
информации об элементе.
Таблица 6.1. Опции и переменные
6.1.4. Опции команд сервера
Когда Вы запускаете mysqld
, Вы можете определить опции программы, используя любой
из методов, описанных в разделе 5.2.3
. Наиболее распространенные методы должны предоставить данные в файле
опций или в командной строке. Однако, в большинстве случаев желательно
удостовериться, что сервер использует те же самые опции каждый раз. Лучший
способ гарантировать это состоит в том, чтобы перечислить их в файле опций.
См. раздел 5.2.6.
Этот раздел также описывает формат файла опций и синтаксис.
mysqld
читает опции из групп [mysqld] и [server] .
mysqld_safe
читает опции из групп [mysqld] , [server] ,
[mysqld_safe] и [safe_mysqld] .
mysql.server
читает опции из групп
[mysqld] и [mysql.server] .
Встроенный сервер MySQL обычно читает опции из групп
[server] , [embedded] и
[xxxxx _SERVER] , где xxxxx
название приложения, в которое встроен сервер.
mysqld
принимает много опций. Для краткого резюме выполните эту команду:
mysqld --help
Чтобы видеть полный список, используйте эту команду:
mysqld --verbose --help
Следующий список показывает некоторые из наиболее распространенных
параметров сервера. Дополнительные опции описаны в других разделах:
Некоторые опции управляют размером буферов или кэшей. Для данного буфера
сервер, возможно, должен был бы выделить внутренние структуры данных. Эти
структуры, как правило, выделяются из полной памяти, выделенной буферу, и
количество требуемого пространства может зависеть от платформы. Это означает,
что, когда Вы назначаете значение опции, которая управляет размером буфера,
количество фактически доступного пространства могло бы отличаться от
назначенного значения. В некоторых случаях количество могло бы быть меньше,
чем назначенное значение. Также возможно, что сервер скорректирует значение
вверх. Например, если Вы назначите значение 0 опции, для которой минимальное
значение 1024, то сервер установит значение в 1024.
Значения для буферных размеров, длин и размеров стека даны в байтах,
если иначе не определено.
Некоторые опции берут значения имени файла. Если иначе не определено,
местоположение файла по умолчанию каталог данных, если значение является
относительным путем. Чтобы определить местоположение явно, используйте
абсолютный путь. Предположите, что каталог данных
/var/mysql/data . Если опция будет дана как относительный путь,
то она будет расположена под /var/mysql/data .
Если значение это абсолютный путь, его местоположение дано путем.
Вы можете также установить значения системных переменных сервера при
запуске сервера при использовании имен переменной как опции. Чтобы назначить
значение на системную переменную сервера, используйте опцию формы
--var_name =value .
Например,
--sort_buffer_size=384M установит переменную
sort_buffer_size
к значению 384 МБ.
Когда Вы назначаете значение переменной, MySQL может автоматически
исправить значение, чтобы остаться в пределах данного диапазона, или
скорректировать значение к самому близкому допустимому значению, если только
определенные значения разрешены.
Чтобы ограничить максимальное значение, в которое системная переменная
может быть установлена во время выполнения с
SET ,
определите этот максимум при использовании опции формы
--maximum-var_name =value
при запуске сервера.
Вы можете изменить значения большинства системных переменных во время
выполнения с SET ,
см. раздел 14.7.4.1.
раздел 6.1.5
обеспечивает полное описание для всех переменных и дополнительную информацию
для того, чтобы установить их при запуске сервера и во время выполнения. Для
информации о системных переменных см.
раздел 6.1.1.
--help ,
-?
Формат командной строки
| --help |
Выведет на экран короткое сообщение справки. Используйте опции
--verbose и
--help , чтобы
видеть полное сообщение.
-
--allow-suspicious-udfs
Формат командной строки
| --allow-suspicious-udfs |
Допустимые значения
| Тип |
boolean |
Значение по умолчанию |
FALSE |
Эта опция управляет тем, будут ли загружены
определяемые пользователем функции, которые имеют только символ
only an xxx для основной функции. По умолчанию опция выключена и
только UDF, у которых есть по крайней мере один вспомогательный символ, может
быть загружен, это предотвращает попытки загрузки функций из совместно
используемых файлов объекта, кроме тех, которые содержат законный UDF. См.
раздел 26.4.2.6.
-
--ansi
Формат командной строки
| --ansi |
Использовать стандартный (ANSI) синтаксис SQL вместо синтаксиса MySQL. Для
более точного управления режимом SQL сервера, используйте
--sql-mode , см.
разделы 1.8 и
6.1.8.
-
--basedir=
dir_name ,
-b
dir_name
Формат командной строки
| --basedir=dir_name |
Системная переменная
| Имя |
basedir
|
Область действия |
Глобальная |
Динамическая |
Нет |
Допустимые значения |
Тип |
directory name |
Путь к каталогу установки MySQL. Все пути обычно решаются
относительно этого каталога.
-
--big-tables
Формат командной строки
| --big-tables |
Системная переменная
| Имя |
big_tables
|
Область действия |
Глобальная, Сеансовая |
Динамическая |
Да |
Системная переменная
| Имя |
big_tables
|
Область действия |
Глобальная, Сеансовая |
Динамическая |
Да |
Допустимые значения
| Тип |
boolean |
Значение по умолчанию |
OFF |
Включить большие наборы результатов, сохраняя все временные наборы в
файлах. Эта опция предотвращает большинство ошибок table full
, но также и замедляет запросы, для которых были бы достаточны
таблицы в памяти. Сервер в состоянии обработать большие наборы результатов
автоматически при использовании памяти для маленьких временных таблиц и
переключаясь на дисковые таблицы, где необходимо.
-
--bind-address=addr
Формат командной строки
| --bind-address=addr |
Системная переменная
| Имя |
bind_address
|
Область действия |
Глобальная |
Динамическая |
Нет |
Допустимые значения
| Тип |
string |
Значение по умолчанию |
* |
Сервер MySQL слушает на единственном сетевом сокете для соединений
TCP/IP. Этот сокет связан с единственным адресом, но для адреса возможно
отобразиться на много сетевых интерфейсов. Чтобы определить адрес,
используйте опцию
--bind-address=addr при запуске сервера, где
addr адрес IPv4, IPv6 или имя хоста. Если
addr имя хоста, сервер решает имя к IP-адресу и
связывает с тем адресом.
Сервер обрабатывает различные типы адресов следующим образом:
Если адрес * , сервер принимает соединения TCP/IP на
всех интерфейсах IPv6 и IPv4, если узел сервера поддерживает IPv6, или
принимает соединения TCP/IP на всех адресах IPv4 иначе. Используйте этот
адрес, чтобы разрешить соединения IPv4 и IPv6 на всех интерфейсах сервера.
Это значение по умолчанию.
- Если адрес
0.0.0.0 , сервер принимает
соединения TCP/IP на всех интерфейсах IPv4.
- Если адрес
:: , сервер принимает
соединения TCP/IP на всех интерфейсах IPv4 и IPv6.
- Если это IPv4-отображенный адрес, сервер принимает соединения TCP/IP для
этого адреса в формате IPv4 или IPv6. Например, если сервер связан с
::ffff:127.0.0.1 , клиенты могут соединиться с использованием
--host=127.0.0.1 или --host=::ffff:127.0.0.1 .
- Если адрес обычный IPv4 или IPv6
(например,
127.0.0.1 или ::1 ), сервер принимает
соединения TCP/IP только для этого адреса IPv4 или IPv6.
Если Вы намереваетесь связать сервер с определенным адресом, убедитесь что
таблица mysql.user содержит учетную запись с административными
привилегиями, которые Вы можете использовать, чтобы соединиться с этим
адресом. Иначе Вы не будете в состоянии закрыть сервер. Например, если Вы
связываете сервер с * , Вы можете соединиться с этим, используя
все существующие учетные записи. Но если Вы связываете сервер с
::1 , он принимает соединения только на этом адресе. В этом
случае сначала удостоверьтесь, что учетная запись
'root'@'::1' присутствует в таблице mysql.user ,
таким образом, Вы можете все еще соединиться с сервером, чтобы закрыть его.
-
--binlog-format={ROW|STATEMENT|MIXED}
Формат командной строки
| --binlog-format=format |
Системная переменная
| Имя |
binlog_format |
Область действия |
Глобальная, Сеансовая |
Динамическая |
Да |
Допустимые значения
| Тип |
enumeration |
Значение по умолчанию |
ROW |
Допустимые значения |
ROW |
STATEMENT |
MIXED |
Использовать основанную на строке, основанную на запросе или смешанную
репликацию. Основанная на запросе является значением по умолчанию в MySQL
8.0. См. раздел 19.2.1.
При некоторых условиях изменение этого параметра во время выполнения
невозможно или заставляет репликацию терпеть неудачу. См.
раздел 6.4.4.2.
Установка двоичного формата журналирования, не включая двоичное
журналирование устанавливает
binlog_format глобальную системную
переменную и пишет предупреждение.
-
--character-sets-dir=dir_name
Формат командной строки
| --character-sets-dir=dir_name |
Системная переменная
| Имя |
character_sets_dir |
Область действия |
Глобальная |
Динамическая |
Нет |
Допустимые значения |
Тип |
directory name |
Каталог, где наборы символов установлены. См.
раздел 11.5.
-
--character-set-client-handshake
Формат командной строки
| --character-set-client-handshake
|
Допустимые значения
| Тип |
boolean |
Значение по умолчанию |
TRUE |
Не игнорировать информацию о наборе символов, посланную клиентом.
Чтобы проигнорировать информацию о клиенте и использовать набор символов по
умолчанию сервера, надо использовать
--skip-character-set-client-handshake ,
это заставляет MySQL вести себя как MySQL 4.0.
-
--character-set-filesystem=charset_name
Формат командной строки
| --character-set-filesystem=name |
Системная переменная
| Имя |
character_set_filesystem |
Область действия |
Глобальная, Сеансовая |
Динамическая |
Да |
Допустимые значения
| Тип |
string |
Значение по умолчанию |
binary |
Набор символов файловой системы. Эта опция устанавливает системную
переменную
character_set_filesystem .
-
--character-set-server=charset_name ,
-C charset_name
Формат командной строки
| --character-set-server |
Системная переменная
| Имя |
character_set_server |
Область действия |
Глобальная, Сеансовая |
Динамическая |
Да |
Допустимые значения
| Тип |
string |
Значение по умолчанию |
latin1 |
Используйте charset_name
как набор символов по умолчанию сервера. См.
раздел 11.5.
Если Вы используете эту опцию, чтобы определить набор символов не по
умолчанию, Вы должны также использовать
--collation-server , чтобы определить сопоставление.
-
--chroot=dir_name ,
-r dir_name
Формат командной строки
| --chroot=dir_name |
Допустимые значения |
Тип |
directory name |
Поместить сервер mysqld
в закрытую окружающую среду во время запуска при
использовании системного вызова chroot() .
Это рекомендуемая мера по безопасности. Использование этой опции несколько
ограничивает LOAD DATA INFILE и
SELECT ... INTO OUTFILE .
-
--collation-server=collation_name
Формат командной строки
| --collation-server |
Системная переменная
| Имя |
collation_server |
Область действия |
Глобальная, Сеансовая |
Динамическая |
Да |
Допустимые значения
| Тип |
string |
Значение по умолчанию |
latin1_swedish_ci |
Использовать collation_name как сопоставление
сервера по умолчанию. См. раздел
11.5.
-
--console
Формат командной строки
| --console |
Платформа |
Windows |
Только Windows. Сообщения журнала ошибки при записи к
stderr и stdout даже если
--log-error
определен. mysqld
не закрывает консоль, если эта опция используется.
Если --log-error
и --console
определены, --console
имеет приоритет. Сервер пишет на консоль, но не в
файл системного журнала.
-
--core-file
Формат командной строки
| --core-file |
Допустимые значения
| Тип |
boolean |
Значение по умолчанию |
OFF |
Писать файл дампа, если
mysqld падает. Название и местоположение основного файла
зависит от системы. На Linux это core.pid
в текущем рабочем каталоге процесса, который для
mysqld
каталог данных. pid ID процесса сервера. В OS X это
core.pid в каталоге /cores .
В Solaris используйте команду coreadm, чтобы
определить, где написать основной файл и как назвать его.
Для некоторых систем чтобы получить основной файл Вы должны также
определить
--core-file-size в
mysqld_safe. См.
раздел 5.3.2.
На некоторых системах, таких как Solaris,
Вы не получаете основной файл, если Вы также используете опцию
--user .
Могут быть дополнительные ограничения или ограничения. Например, может
быть необходимо выполнить ulimit -c unlimited
прежде, чем запустить сервер.
Консультируйтесь со своей системной документацией.
-
--daemonize
Формат командной строки
| --daemonize[={OFF|ON}] |
Допустимые значения
| Тип |
boolean |
Значение по умолчанию |
OFF |
Эта опция заставляет сервер работать как традиционный
разветвляющийся демон, разрешая это работать с операционными системами,
которые используют systemd для управления процессом.
Для получения дополнительной информации см.
раздел 2.5.9.
--daemonize
является взаимоисключающим с
--initialize и
--initialize-insecure .
-
--datadir=dir_name
, -h dir_name
Формат командной строки
| --datadir=dir_name |
Системная переменная
| Имя |
datadir
|
Область действия |
Глобальная |
Динамическая |
Нет |
Допустимые значения |
Тип |
directory name |
Путь к каталогу данных.
-
--debug[=
debug_options ] ,
-# [debug_options ]
Формат командной строки
| --debug[=debug_options] |
Системная переменная
| Имя |
debug |
Область действия |
Глобальная, Сеансовая |
Динамическая |
Да |
Допустимые значения
(Unix) | Тип |
string |
Значение по умолчанию |
d:t:i:o,/tmp/mysqld.trace |
Допустимые значения
(Windows) | Тип |
string |
Значение по умолчанию |
d:t:i:O,\mysqld.trace |
Если MySQL сконфигурирован с опцией CMake
-DWITH_DEBUG=1
, Вы можете использовать эту опцию, чтобы получить файл трассировки
того, что делает mysqld
. Типичная строка debug_options :
d:t:o,file_name . Значение по умолчанию
d:t:i:o,/tmp/mysqld.trace в Unix и
d:t:i:O,\mysqld.trace в Windows.
Использование
-DWITH_DEBUG=1 , чтобы сконфигурировать MySQL с поддержкой отладки,
позволяет Вам использовать опцию
--debug="d,parser_debug"
, когда Вы запускаете сервер. Это вызывает анализатор Bison,
который используется, чтобы обработать запросы SQL, чтобы вывести трассировку
анализатора к стандартному ошибочному выводу сервера. Как правило, этот вывод
написан в журнал ошибок.
Эта опция может быть дана многократно. Значения, которые начинаются с
with + или - , добавлены или вычтены из предыдущего
значения. Например, --debug=T
--debug=+P
устанавливает значение в P:T .
См. раздел 26.5.3.
-
--debug-sync-timeout[=N ]
Формат командной строки
| --debug-sync-timeout[=#] |
Допустимые значения |
Тип |
integer |
Управляет Debug Sync для тестирования и отладки. Использование Debug Sync
требует, чтобы MySQL был сконфигурирован с опцией
-DENABLE_DEBUG_SYNC=1 для CMake (см.
раздел 2.8.4). Если
Debug Sync не собран, эта опция недоступна. Значение опции: тайм-аут в
секундах. Значение по умолчанию 0, отключает Debug Sync. Чтобы включить,
определите значение больше, чем 0, это значение также становится тайм-аутом
по умолчанию для отдельных пунктов синхронизации. Если опция дана без
значения, тайм-аут установлен в 300 секунд.
Для описания средства Debug Sync и как использовать пункты синхронизации
см. MySQL Internals: Test Synchronization.
-
--default-storage-engine=type
Формат командной строки
| --default-storage-engine=name |
Системная переменная
| Имя |
default_storage_engine |
Область действия |
Глобальная, Сеансовая |
Динамическая |
Да |
Допустимые значения
| Тип |
enumeration |
Значение по умолчанию |
InnoDB |
Допустимые значения
| Тип |
enumeration |
Значение по умолчанию |
MyISAM |
Установить механизм хранения значения по умолчанию для таблиц. См.
главу 17. Эта опция устанавливает механизм хранения
только для постоянных таблиц. Установить механизм хранения для таблиц
TEMPORARY можно переменной
default_tmp_storage_engine .
Если Вы отключаете механизм хранения по умолчанию при запуске сервера, Вы
должны установить механизм по умолчанию для постоянных и для таблиц
TEMPORARY к иному механизму, или сервер не будет запускаться.
-
--default-time-zone=timezone
Формат командной строки
| --default-time-zone=name |
Допустимые значения |
Тип |
string |
Установить часовой пояс сервера по умолчанию. Эта опция устанавливает
глобальную переменную time_zone
. Если эта опция не дана, часовой пояс по умолчанию тот же самый,
как системный часовой пояс (данный значением
system_time_zone ).
-
--defaults-extra-file=file_name
Читать этот файл опции после глобального файла опции, но (в Unix) перед
пользовательским файлом опции. Если файл не существует или недоступен, ошибка
происходит. file_name интерпретируется относительно
текущего каталога, если дано как относительный, а не полный путь.
-
--defaults-file=
file_name
Используйте только данный файл опции. Если файл не существует или
недоступен, ошибка происходит. file_name
интерпретируется относительно текущего каталога, если дано как относительный
путь, а не полный.
Исключение: Даже с
--defaults-file
mysqld читает mysqld-auto.cnf .
-
--defaults-group-suffix=str
Читать не только обычные группы опции, но также и группы с именами и
суффиксом str . Например,
mysqld
обычно читает группу [mysqld] . Если
--defaults-group-suffix=_other задана,
mysqld
также читает группу [mysqld_other] .
-
--delay-key-write[={OFF|ON|ALL}]
Формат командной строки
| --delay-key-write[=name] |
Системная переменная
| Имя |
delay_key_write |
Область действия |
Глобальная |
Динамическая |
Да |
Допустимые значения
| Тип |
enumeration |
Значение по умолчанию |
ON |
Допустимые значения |
ON |
OFF |
ALL |
Определите, как использовать отсроченную запись ключа.
Это заставляет ключевые буферы не сбрасываться между записями для
MyISAM . OFF отключает отсроченную запись.
ON включает отсроченную запись для тех таблиц, которые были
составлены с опцией DELAY_KEY_WRITE .
ALL делает задержку записи для всех таблиц
MyISAM . См. разделы
6.1.1 и
17.2.1.
Если Вы устанавливаете эту переменную в ALL , Вы не должны
использовать таблицы MyISAM изнутри другой программы (другой
сервер MySQL или myisamchk
, например), когда таблицы используются.
--des-key-file=file_name
Формат командной строки
| --des-key-file=file_name
|
Читать ключи DES по умолчанию из этого файла. Эти ключи используются
DES_ENCRYPT() и
DES_DECRYPT() .
-
--early-plugin-load=plugin_list
Формат командной строки
| --early-plugin-load=plugin_list |
Допустимые значения
| Тип |
string |
Значение по умолчанию |
empty string |
Эта опция говорит серверу, который плагин загрузить прежде, чем загрузить
принудительные встроенные плагины и перед инициализацией механизма хранения.
Если дано несколько
--early-plugin-load , только последняя используется.
Значение опции отделенный точки с запятой список
name = plugin_library
и plugin_library . Каждый name
это название плагина, чтобы загрузить, а plugin_library
это название файла библиотеки, которая содержит код. Если библиотеку называют
без какого-либо предыдущего имени, сервер загружает все плагины в библиотеке.
Сервер ищет файлы библиотек в каталоге, названном в переменной
plugin_dir .
Например, если плагины называются
myplug1 и myplug2 и имеют файлы библиотеки
myplug1.so и myplug2.so ,
используйте эту опцию, чтобы выполнить раннюю загрузку:
shell> mysqld --early-plugin-load="myplug1=myplug1.so;myplug2=myplug2.so"
Кавычки используются вокруг значения параметра потому, что иначе точка с
запятой (; ) интерпретируется как специальный символ некоторыми
интерпретаторами команд. Оболочки Unix обрабатывают это как
разделитель команды, например.
Каждый названный плагин загружен рано для единственного вызова
mysqld.
После перезапуска плагин не загружен рано, если
--early-plugin-load использован снова.
Если сервер запущен, используя
--initialize
или
--initialize-insecure , плагины, определенные
--early-plugin-load , не загружены.
Если сервер выполнен с
--help ,
плагины, определенные
--early-plugin-load , загружены, но не инициализированы. Это
поведение гарантирует, что опции плагина выведены на
экран в сообщении справки.
По умолчанию
--early-plugin-load пусто. Чтобы загрузить плагин
keyring_file , Вы должны использовать явно опцию
--early-plugin-load с непустым значением.
Особенность шифрования табличного пространства InnoDB
полагается на плагин keyring_file для управления ключом
шифрования и плагин keyring_file должен быть загружен до
инициализации механизма хранения, чтобы облегчить InnoDB
восстановление для зашифрованных таблиц. Администраторы, которые хотят
загрузить keyring_file при запуске, должны использовать
соответствующее непустое значение опции, например, keyring_file.so
в Unix и keyring_file.dll в Windows.
Для информации о шифровании табличного пространства InnoDB
см. раздел 16.7.10.
Для общей информации о загрузке плагинов см.
раздел 6.6.2.
-
--enable-named-pipe
Формат командной строки
| --enable-named-pipe |
Платформа |
Windows |
Включить поддержку именованных каналов.
Эта опция применяется только в Windows.
-
--event-scheduler[=value ]
Формат командной строки
| --event-scheduler[=value] |
Системная переменная
| Имя |
event_scheduler |
Область действия |
Глобальная |
Динамическая |
Да |
Допустимые значения
| Тип |
enumeration |
Значение по умолчанию |
OFF |
Допустимые значения |
ON |
OFF |
DISABLED |
Включить или отключить планировщик событий.
Для получения дальнейшей информации см.
--event-scheduler .
-
--exit-info[=flags ] ,
-T [flags ]
Формат командной строки
| --exit-info[=flags] |
Допустимые значения |
Тип |
integer |
Это битовая маска различных флагов, которые Вы можете использовать для
того, чтобы отладить mysqld
. Не используйте эту опцию, если Вы не знаете
точно, что она делает!
-
--external-locking
Формат командной строки
| --external-locking |
Допустимые значения
| Тип |
boolean |
Значение по умолчанию |
FALSE |
Включить внешнюю блокировку (системную блокировку), которая отключена по
умолчанию. Если Вы используете эту опцию на системе, на которой
lockd толком не работает (к примеру, в Linux),
mysqld
легко зайти в тупик.
Чтобы отключить внешнюю блокировку явно, надо использовать
--skip-external-locking .
Внешняя блокировка затрагивает только доступ к таблицам
MyISAM .
Для получения дополнительной информации, включая условия, при которых это
может и не может использоваться, см.
раздел 9.11.5.
-
--flush
Формат командной строки
| --flush |
Системная переменная
| Имя |
flush |
Область действия |
Глобальная |
Динамическая |
Да |
Допустимые значения
| Тип |
boolean |
Значение по умолчанию |
OFF |
Синхронизирует все изменения диска после каждого запроса SQL. Обычно MySQL
делает запись всех изменений на диск только после каждого запроса SQL и
позволяет операционной системе обрабатывать синхронизацию с диском. См.
раздел B.5.3.3.
-
--gdb
Формат командной строки
| --gdb |
Допустимые значения
| Тип |
boolean |
Значение по умолчанию |
FALSE |
Установить обработчик прерывания для SIGINT
(должен остановить mysqld
по ^C , чтобы установить контрольные точки)
и отключить трассировку стека и основную обработку файла. См.
раздел 26.5.
-
--general-log[={0|1}]
Формат командной строки
| --general-log |
Системная переменная
| Имя |
general_log
|
Область действия |
Глобальная |
Динамическая |
Да |
Допустимые значения
| Тип |
boolean |
Значение по умолчанию |
OFF |
Определить начальное состояние журнала запроса. Без параметра или с
параметром 1 опция
--general-log включает журнал. Если опущено или дано с параметром
0, опция отключает журнал.
-
--initialize
Формат командной строки
| --initialize |
Допустимые значения
| Тип |
boolean |
Значение по умолчанию |
OFF |
Эта опция используется, чтобы инициализировать установку MySQL, создавая
каталог данных и заполняя таблицы в системной базе данных mysql ,
см. раздел 2.9.1.1
.
Когда сервер запущен с опцией
--initialize ,
некоторая функциональность недоступна, что ограничивает запросы, разрешенные
в любом файле, названном в --init-file . Кроме того,
disabled_storage_engines не имеет никакого эффекта.
--initialize
является взаимоисключающим с
--daemonize .
-
--initialize-insecure
Формат командной строки
| --initialize-insecure |
Допустимые значения
| Тип |
boolean |
Значение по умолчанию |
OFF |
Эта опция используется, чтобы инициализировать установку MySQL, создавая
каталог данных и заполняя таблицы в системной базе данных mysql .
Эта опция подразумевает
--initialize . См.
раздел 2.9.1.1
.
--initialize-insecure является взаимоисключающим с
--daemonize .
-
--init-file=file_name
Формат командной строки
| --init-file=file_name |
Системная переменная
| Имя |
init_file
|
Область действия |
Глобальная |
Динамическая |
Нет |
Допустимые значения |
Тип |
file name |
Читать запросы SQL из этого файла при запуске. Каждый запрос должен быть
на одной строке и не должен включать комментарии.
Если сервер запущен с
--initialize
или
--initialize-insecure , это работает в bootstap режиме, и некоторая
функциональность недоступна, что ограничивает запросы, разрешенные в файле.
Они включают запросы, которые касаются ведения учетных записей, репликацию
и глобальные операционные идентификаторы. См.
раздел 19.1.3.
--innodb-xxx
Установите опцию для механизма хранения InnoDB .
Опции InnoDB перечислены в
разделе 16.13.
-
--install
[service_name ]
Формат командной строки
| --install [service_name] |
Платформа |
Windows |
Только Windows. Установка сервера как службы Windows, которая запускается
автоматически во время запуска Windows. Имя службы по умолчанию
MySQL , если нет service_name . Для
получения дополнительной информации см.
раздел 2.3.5.8.
Если сервер запущен с
--defaults-file и
--install ,
--install
должна быть первой.
--install-manual
[service_name ]
Формат командной строки
| --install-manual [service_name]
|
Платформа |
Windows |
Только Windows. Установка сервера как службы Windows, которая должна быть
запущена вручную. Это не запускается автоматически во время запуска Windows.
Имя службы по умолчанию MySQL , если нет
service_name , см.
раздел 2.3.5.8.
Если сервер запущен с
--defaults-file
и
--install-manual ,
--install-manual должна быть первой.
--language=
lang_name , -L lang_name
Устарела |
5.6.1, by
lc-messages-dir |
Формат командной строки
| --language=name |
Системная переменная
| Имя |
language |
Область действия |
Глобальная |
Динамическая |
Нет |
Допустимые значения
| Тип |
directory name |
Значение по умолчанию |
/usr/local/mysql/share/mysql/english/
|
Язык, чтобы использовать для сообщений об ошибках.
lang_name может быть дан как языковое имя или как
полный путь к каталогу, где языковые файлы установлены. См.
раздел 11.2.
--lc-messages-dir
и
--lc-messages должны использоваться, а не
--language ,
которая устарела (и обработана как псевдоним для
--lc-messages-dir
). --language
будет удалена в будущем выпуске MySQL.
-
--large-pages
Формат командной строки
| --large-pages |
Системная переменная
| Имя |
large_pages
|
Область действия |
Глобальная |
Динамическая |
Нет |
Платформа |
Linux |
Допустимые значения
(Linux) | Тип |
boolean |
Значение по умолчанию |
FALSE |
Немногие архитектуры аппаратных средств/операционной системы поддерживают
страницы памяти больше, чем значение по умолчанию (обычно 4 КБ). Фактическое
выполнение этой поддержки зависит от используемого оборудования и
операционной системы. Приложения, которые выполняют много доступов к памяти,
могут получить рост скорости при использовании больших страниц из-за
уменьшенного буфера хранения перевода.
MySQL поддерживает выполнение Linux поддержки большой страницы (которую
называют HugeTLB в Linux). См.
раздел 9.12.3.2. Для Solaris
больших страниц см. описание опции
--super-large-pages .
--large-pages
отключена по умолчанию.
-
--lc-messages=
locale_name
Формат командной строки
| --lc-messages=name |
Системная переменная
| Имя |
lc_messages
|
Область действия |
Глобальная, Сеансовая |
Динамическая |
Да |
Допустимые значения
| Тип |
string |
Значение по умолчанию |
en_US |
Локаль для сообщений об ошибках. Значение по умолчанию
en_US . Сервер преобразовывает параметр к языковому имени и
комбинирует его со значением
--lc-messages-dir
, чтобы произвести местоположение для файла сообщения об ошибке.
См. раздел 11.2.
-
--lc-messages-dir=dir_name
Формат командной строки
| --lc-messages-dir=dir_name |
Системная переменная
| Имя |
lc_messages_dir |
Область действия |
Глобальная |
Динамическая |
Нет |
Допустимые значения |
Тип |
directory name |
Каталог, где сообщения об ошибках расположены. Сервер использует значение
вместе со значением
--lc-messages , чтобы произвести местоположение для файла сообщения
об ошибке. См. раздел 11.2.
-
--local-service
Формат командной строки
| --local-service |
Только Windows. Опция --local-service
после имени службы заставляет сервер выполнять использование учетной записи
Windows LocalService , которая ограничила системные привилегии.
Если оба параметра
--defaults-file и --local-service даны после
имени службы, они могут быть в любом порядке. См.
раздел 2.3.5.8.
-
--log-error[=file_name ]
Формат командной строки
| --log-error[=file_name] |
Системная переменная
| Имя |
log_error
|
Область действия |
Глобальная |
Динамическая |
Нет |
Допустимые значения |
Тип |
file name |
Ошибки и сообщения запуска писать в этот файл. См.
раздел 6.4.2.
Если у имени файла нет никакого расширения, сервер добавляет расширение
.err . Если Вы опускаете имя файла, файл системного журнала по
умолчанию в Unix host_name .err
в каталоге данных. Значение по умолчанию в Windows
host_name .err в каталоге данных, если
опция --pid-file
указана. В этом случае имя по умолчанию PID
с суффиксом .err в каталоге данных.
-
--log-isam[=
file_name ]
Формат командной строки
| --log-isam[=file_name] |
Допустимые значения |
Тип |
file name |
Зарегистрировать все изменения MyISAM в этом файле
(использовать только отлаживая MyISAM ).
-
--log-output=
value ,...
Формат командной строки
| --log-output=name |
Системная переменная
| Имя |
log_output
|
Область действия |
Глобальная |
Динамическая |
Да |
Допустимые значения
| Тип |
set |
Значение по умолчанию |
FILE |
Допустимые значения |
TABLE |
FILE |
NONE |
Эта опция определяет место назначения для общего журнала запроса и
медленного журнала запроса. Значение опции может быть дано как одно или
больше слов TABLE , FILE или NONE .
TABLE выбирает журналирование к таблицам
general_log и
slow_log в базе данных mysql как место назначения.
FILE выбирает журналирование к файлам системного журнала как
место назначения. NONE отключает журналирование. Если
NONE присутствует в значении опции, это имеет приоритет перед
любыми другими словами, которые присутствуют. TABLE и
FILE могут оба быть даны, чтобы выбрать оба выходных
места назначения журнала.
Эта опция выбирает выходные места назначения журнала, но не включает
вывод журнала. Чтобы сделать это, используйте
--general_log и
--slow_query_log .
Для FILE опции
--general_log_file
и -slow_query_log_file определяют местоположение файла
системного журнала. Для получения дополнительной информации см.
раздел 6.4.1.
-
--log-queries-not-using-indexes
Формат командной строки
| --log-queries-not-using-indexes |
Системная переменная
| Имя |
log_queries_not_using_indexes |
Область действия |
Глобальная |
Динамическая |
Да |
Допустимые значения
| Тип |
boolean |
Значение по умолчанию |
OFF |
Если Вы используете эту опцию с включенным медленным журналом запроса,
зарегистрированы запросы, которые, как ожидают, получат все строки. См.
раздел 6.4.5. Эта опция не
обязательно означает, что индекс не используется. Например, запрос, который
использует полный просмотр индекса, использует индекс, но будет
зарегистрирован, потому что индексирование не будет ограничивать число строк.
-
--log-raw
Формат командной строки
| --log-raw[=value] |
Допустимые значения
| Тип |
boolean |
Значение по умолчанию |
OFF |
Пароли в определенных запросах, написанных в
общий журнал запроса, медленный журнал запроса и двоичный журнал, переписаны
сервером, чтобы не появляться буквально в простом тексте.
Перезапись пароля может быть подавлена для общего журнала запроса, запуская
сервер с опцией --log-raw
. Эта опция может быть полезной в диагностических целях, чтобы
видеть точный текст запросов, как получено сервером, но из соображений
безопасности не рекомендуется для производственного использования.
Если плагин перезаписи запроса установлен, опция
--log-raw
затрагивает запрос следующим образом:
См. раздел 7.1.2.3.
-
--log-short-format
Формат командной строки
| --log-short-format |
Допустимые значения
| Тип |
boolean |
Значение по умолчанию |
FALSE |
Зарегистрирует меньше информации в медленном журнале запроса,
если это было активировано.
-
--log-tc=
file_name
Формат командной строки
| --log-tc=file_name |
Допустимые значения
| Тип |
file name |
Значение по умолчанию |
tc.log |
Название отображенного на память операционного файла системного журнала
координатора (для транзакций XA, которые затрагивают многие механизмы
хранения, когда двоичный журнал отключен). Имя по умолчанию
tc.log . Файл создается в каталоге данных, если не дан как полный
путь. Эта опция не использована.
-
--log-tc-size=
size
Формат командной строки
| --log-tc-size=# |
Допустимые значения
(32-bit platforms) | Тип |
integer |
Значение по умолчанию |
6 * page size |
Минимум |
6 * page size |
Максимум |
4294967295 |
Допустимые значения
(64-bit platforms) | Тип |
integer |
Значение по умолчанию |
6 * page size |
Минимум |
6 * page size |
Максимум |
18446744073709551615 |
Размер в байтах отображенного на память операционного журнала
координатора. Значение по умолчанию и минимальное значение 6*размер страницы,
значение должно быть кратным размеру страницы.
-
--log-warnings[=level ] ,
-W [level ]
Устарела |
5.7.2 |
Формат командной строки
| --log-warnings[=#] |
Системная переменная
| Имя |
log_warnings
|
Область действия |
Глобальная |
Динамическая |
Да |
Допустимые значения
(32-bit platforms) | Тип |
integer |
Значение по умолчанию |
2 |
Минимум |
0 |
Максимум |
4294967295 |
Допустимые значения
(64-bit platforms) | Тип |
integer |
Значение по умолчанию |
2 |
Минимум |
0 |
Максимум |
18446744073709551615 |
log_error_verbosity
предпочтена, и должна использоваться вместо
--log-warnings
или log_warnings
. См.
log_error_verbosity и
log_warnings . Опция командной строки
--log-warnings
и системная переменная
log_warnings устарели и будут удалены в будущем выпуске MySQL.
Произвести ли дополнительные предупреждающие сообщения для журнала ошибок.
Эта опция включена по умолчанию со значением 2. Чтобы отключить это, надо
использовать
--log-warnings=0 . Определение опции без level
увеличивает текущее значение на 1. Сервер регистрирует сообщения о
запросах, которые опасны для основанного на запросе журналирования, если
значение больше 0. Прерванные соединения и ошибки доступа для новых попыток
соединения зарегистрированы, если значение больше 1. См.
раздел B.5.2.10.
-
--low-priority-updates
Формат командной строки
| --low-priority-updates |
Системная переменная
| Имя |
low_priority_updates |
Область действия |
Глобальная, Сеансовая |
Динамическая |
Да |
Допустимые значения
| Тип |
boolean |
Значение по умолчанию |
FALSE |
Дать изменяющим таблицу операциям
(INSERT ,
REPLACE ,
DELETE и
UPDATE )
более низкий приоритет, чем select. Это может также быть сделано, используя
{INSERT | REPLACE | DELETE | UPDATE} LOW_PRIORITY ... , чтобы
понизить приоритет только одного запроса, или SET
LOW_PRIORITY_UPDATES=1 , чтобы изменить приоритет в одном потоке. Это
затрагивает только механизмы хранения, которые используют только блокировку
на уровне таблицы (MyISAM , MEMORY ,
MERGE ). См. раздел 9.11.2
.
-
--min-examined-row-limit=number
Формат командной строки
| --min-examined-row-limit=# |
Системная переменная
| Имя |
min_examined_row_limit
|
Область действия |
Глобальная, Сеансовая |
Динамическая |
Да |
Допустимые значения
(32-bit platforms) | Тип |
integer |
Значение по умолчанию |
0 |
Минимум |
0 |
Максимум |
4294967295 |
Допустимые значения
(64-bit platforms) | Тип |
integer |
Значение по умолчанию |
0 |
Минимум |
0 |
Максимум |
18446744073709551615 |
Когда эта опция установлена, запросы, которые исследуют меньше
number строк не записаны в медленный журнал запроса.
Значение по умолчанию 0.
-
--memlock
Формат командной строки
| --memlock |
Допустимые значения
| Тип |
boolean |
Значение по умолчанию |
FALSE |
Заблокирует процесс mysqld
в памяти. Эта опция могла бы помочь, если у Вас есть
проблема, что операционная система заставляет
mysqld свопиться на диск.
--memlock
работает в системах, которые поддерживают системный вызов
mlockall() : Solaris, Linux с ядром 2.4 и выше и некоторые Unix.
В Linux Вы можете сказать, действительно ли
mlockall() (и таким образом эта опция), поддержан, проверяя,
определен ли он в системном файле mman.h :
shell> grep mlockall /usr/include/sys/mman.h
Если mlockall() поддержан, Вы должны видеть в выводе
предыдущей команды что-то вроде:
extern int mlockall (int __flags) __THROW;
Использование этой опции может потребовать, чтобы Вы выполнили сервер как
root , по причинам безопасности, это обычно не хорошая идея. См.
раздел 7.1.5.
В Linux и возможно в других системах Вы можете избежать потребности
выполнить сервер как root изменяя файл limits.conf .
См. раздел 9.12.3.2.
Вы не должны попытаться использовать эту опцию в системе, которая не
поддерживает системный вызов mlockall() , если Вы сделаете это,
mysqld
очень вероятно откажет, как только Вы попытаетесь запустить его.
--myisam-block-size=N
Формат командной строки
| --myisam-block-size=# |
Допустимые значения
| Тип |
integer |
Значение по умолчанию |
1024 |
Минимум |
1024 |
Максимум |
16384 |
Размер блока, который будет использоваться для
индексных страниц MyISAM .
-
--myisam-recover-options[=option [,
option ]...]]
Формат командной строки
| --myisam-recover-options[=name] |
Допустимые значения
| Тип |
enumeration |
Значение по умолчанию |
OFF |
Допустимые значения |
OFF |
DEFAULT |
BACKUP |
FORCE |
QUICK |
Установить режим восстановления механизма хранения MyISAM .
Значение опции: любая комбинация значений
OFF , DEFAULT , BACKUP ,
FORCE или QUICK . Если Вы определяете много
значений, отделите их запятыми. Определение опции без параметра является тем
же самым, как определение DEFAULT , определение с явным значением
"" отключает восстановление (то же самое как значение
OFF ). Если восстановление включено, каждый раз
mysqld
открывая таблицу MyISAM , проверяет, отмечена ли таблица как
разрушенная или не была закрыта должным образом. Последняя опция работает,
только если Вы работаете с отключенной внешней блокировкой. Если это верно,
mysqld
осуществляет проверку таблицы. Если таблица была повреждена,
mysqld
пытается восстановить ее.
Следующие опции затрагивают ремонтные работы.
Опция | Описание |
OFF | Ничего не делать. |
DEFAULT |
Восстановление без резервного копирования, принуждения или быстрой проверки.
|
BACKUP | Если файл с данными был
изменен во время восстановления, сохранить резервную копию файла
tbl_name .MYD как
tbl_name-datetime .BAK . |
FORCE | Выполнить восстановление, даже
если мы потеряли бы больше, чем одну строку из файла .MYD .
|
QUICK | Не проверять строки в таблице,
если нет удаленных блоков. |
Прежде, чем сервер автоматически восстанавливает таблицу, он пишет
о ремонте в журнал ошибок. Если Вы хотите быть в состоянии исправить
большинство проблем без пользовательского вмешательства, Вы должны
использовать опции BACKUP, FORCE . Это вызывает ремонт таблицы,
даже если некоторые строки были бы удалены, но это сохраняет старый файл с
данными как резервную копию, чтобы Вы могли позже исследовать, что произошло.
См. раздел 17.2.1.
-
--no-defaults
Не читать файлы опции. Если запуск программы терпит неудачу из-за чтения
неизвестных опций из файла опции,
--no-defaults
может использоваться, чтобы препятствовать тому, чтобы они были считаны.
Исключение: файл .mylogin.cnf , если существует, считан во
всех случаях. Это разрешает паролям быть определенными более безопасным
способом, чем в командной строке, даже когда
--no-defaults
использована. .mylogin.cnf создается
mysql_config_editor
, см.
раздел 5.6.7.
-
--old-alter-table
Формат командной строки
| --old-alter-table |
Системная переменная
| Имя |
old_alter_table |
Область действия |
Глобальная, Сеансовая |
Динамическая |
Да |
Допустимые значения
| Тип |
boolean |
Значение по умолчанию |
OFF |
Когда эта опция дана, сервер не использует оптимизированный метод
обработки ALTER TABLE .
Это возвращается к использованию временной таблицы, копированию данных и
затем переименованию временной таблицы к оригиналу, как используется в MySQL
5.0 и ранее. Для получения дополнительной информации о работе
ALTER TABLE см.
раздел 14.1.7.
-
--old-style-user-limits
Формат командной строки
|
--old-style-user-limits |
Допустимые значения
| Тип |
boolean |
Значение по умолчанию |
FALSE |
Включить пользовательские пределы в старом стиле. До MySQL 5.0.3 пределы
ресурса учетной записи были посчитаны отдельно для каждого узла, от которого
пользователь соединялся, а не для строки учетной записи в таблице
user . См. раздел 7.3.5
.
-
--open-files-limit=count
Формат командной строки
| --open-files-limit=# |
Системная переменная
| Имя |
open_files_limit |
Область действия |
Глобальная |
Динамическая |
Нет |
Допустимые значения
| Тип |
integer |
Значение по умолчанию |
5000, with possible adjustment |
Минимум |
0 |
Максимум |
platform dependent |
Изменяет число описателей файла, доступных
mysqld.
Вы должны попытаться увеличить значение этой опции, если
mysqld
дает Вам ошибку Too many open files .
mysqld
использует значение опции, чтобы зарезервировать описатели с
setrlimit() . Внутренне максимальное значение
для этой опции unsigned integer, но фактический максимум зависит от
платформы. Если требуемое число описателей файла не может быть выделено,
mysqld
пишет предупреждение в журнал ошибок.
mysqld
может попытаться выделить больше требуемого числа описателей (если они
доступны), используя значения
max_connections и
table_open_cache
, чтобы оценить, будет ли необходимо больше описателей.
В Unix значение не может быть установлено меньше ulimit
-n.
--performance-schema-xxx
Сконфигурирует опцию Performance Schema. Для деталей см.
раздел 23.11.
-
--pid-file=file_name
Формат командной строки
| --pid-file=file_name |
Системная переменная
| Имя |
pid_file
|
Область действия |
Глобальная |
Динамическая |
Нет |
Допустимые значения |
Тип |
file name |
Путь файла ID процесса. Сервер создает файл в каталоге данных, если
абсолютный путь не дан, чтобы определить иной каталог. Этот файл используется
другими программами, такими как
mysqld_safe, чтобы определить
ID процесса сервера.
-
--plugin-xxx
Определяет опцию, которая принадлежит плагину сервера. Например, много
механизмов хранения могут быть созданы как плагины, и для таких механизмов,
опции для них могут быть определены с префиксом
--plugin .
Таким образом,
--innodb_file_per_table для InnoDB может быть
определен как
--plugin-innodb_file_per_table .
Для булевых опций, которые могут быть включены или отключены, префикс
--skip и другие альтернативные форматы поддержаны также (см.
раздел 5.2.5). Например,
--skip-plugin-innodb_file_per_table выключает
innodb_file_per_table .
Объяснение для префикса --plugin то, что это
позволяет опциям плагинов быть определенными однозначно, если есть конфликт
имени со встроенным параметром сервера. Например, если автор назвал плагин
sql и осуществил опцию mode
, имя опции могло бы быть
--sql-mode , что
в противоречии со встроенной опцией с тем же самым именем. В таких случаях
ссылки на противоречивое имя решены в пользу встроенной опции. Чтобы избежать
двусмысленности, пользователи могут определить опцию плагина как
--plugin-sql-mode . Использование префикса
--plugin для опций плагина рекомендуют, чтобы избежать
любого вопроса двусмысленности.
-
--plugin-load=
plugin_list
Формат командной строки
| --plugin-load=plugin_list |
Допустимые значения |
Тип |
string |
Эта опция говорит серверу загружать названные плагины при запуске. Если
дано несколько опций
--plugin-load , только последняя используется. Дополнительные
плагины, чтобы загрузить могут быть определены, используя
--plugin-load-add .
Значение опции разделенный точкой с запятой список значений
name = plugin_library
и plugin_library . Каждое name это
название плагина, чтобы загрузить, а plugin_library
название файла библиотеки, которая содержит код. Если библиотеку называют без
какого-либо предыдущего имени плагина, сервер загружает все плагины в
библиотеке. Сервер ищет файлы библиотеки в каталоге, названном в переменной
plugin_dir .
Например, если плагины называют myplug1 и
myplug2 и они имеют библиотеки
myplug1.so и myplug2.so ,
используйте эту опцию, чтобы выполнить раннюю загрузку:
shell> mysqld --plugin-load="myplug1=myplug1.so;myplug2=myplug2.so"
Кавычки используются вокруг значения параметра здесь потому, что иначе
точка с запятой (; ) интерпретируется как специальный символ
некоторыми интерпретаторами команд. Оболочки Unix обрабатывают это как
разделитель команды, например.
Каждый названный плагин загружен для единственного вызова
mysqld.
После перезапуска плагин не загружен, если
--plugin-load
используется снова. Это в отличие от
INSTALL PLUGIN ,
который добавляет запись в таблицу mysql.plugins , чтобы
заставить плагин загружаться для каждого нормального запуска сервера.
При нормальном запуске сервер определяет, которые плагины загрузятся,
читая системную таблицу mysql.plugins . Если сервер запущен с
--skip-grant-tables , это не консультируется с таблицей
mysql.plugins и не загружает плагины, перечисленные там.
--plugin-load
позволяет плагинам быть загруженными даже когда задана
--skip-grant-tables .
--plugin-load
также позволяет быть загруженными при запуске плагинам, которые не могут быть
загружены во время выполнения.
См. раздел 6.6.2.
-
--plugin-load-add=plugin_list
Формат командной строки
| --plugin-load-add=plugin_list |
Допустимые значения
| Тип |
string |
Эта опция дополняет
--plugin-load .
--plugin-load-add добавляет плагин или плагины к набору
плагинов, которые будут загружены при запуске. Формат параметра как для
--plugin-load
.
--plugin-load-add может использоваться, чтобы избежать определять
большой набор плагинов как длинный
--plugin-load
.
--plugin-load-add
можно дать в отсутствие
--plugin-load
, но любой
--plugin-load-add прежде
--plugin-load
не имеет никакого эффекта потому, что
--plugin-load
сбрасывает набор плагинов, чтобы загрузить. Другими словами, эти опции:
--plugin-load=x --plugin-load-add=y
эквивалентны этой опции:
--plugin-load="x;y"
Но эти опции:
--plugin-load-add=y --plugin-load=x
эквивалентны этой опции:
--plugin-load=x
См. раздел 6.6.2.
-
--port=port_num
, -P port_num
Формат командной строки
| --port=# |
Системная переменная
| Имя |
port |
Область действия |
Глобальная |
Динамическая |
Нет |
Допустимые значения
| Тип |
integer |
Значение по умолчанию |
3306 |
Минимум |
0 |
Максимум |
65535 |
Номер порта, чтобы использовать, слушая соединения TCP/IP.
На Unix номер порта должен быть 1024 или выше, если сервер
не запущен как root .
-
--port-open-timeout=num
Формат командной строки
| --port-open-timeout=# |
Допустимые значения
| Тип |
integer |
Значение по умолчанию |
0 |
На некоторых системах, когда сервер остановлен, порт TCP/IP не
может стать доступным немедленно. Если сервер перезапущен быстро, его попытка
вновь открыть порт может потерпеть неудачу. Эта опция указывает, сколько
секунд сервер должен ждать порт TCP/IP, если это не может быть открыто.
Значение по умолчанию не должно ждать.
-
--print-defaults
Напечатать название программы и все опции, которые это получает
от файлов опции.
-
--remove
[service_name ]
Формат командной строки
| --remove [service_name] |
Платформа |
Windows |
Только Windows. Удаляет службу Windows MySQL. Имя службы по умолчанию
MySQL , если service_name не указан.
См. раздел 2.3.5.8.
-
--safe-user-create
Формат командной строки
| --safe-user-create |
Допустимые значения
| Тип |
boolean |
Значение по умолчанию |
FALSE |
Если эта опция включена, пользователь не может создать новых пользователей
MySQL при использовании GRANT , если
пользователь не имеет привилегии
INSERT для таблицы mysql.user или любого
столбца в таблице. Если Вы хотите, чтобы у пользователя была способность
создать новых пользователей, у которых есть те привилегии, которые
пользователь имеет право предоставить, Вы должны предоставить
пользователю следующую привилегию:
GRANT INSERT(user) ON mysql.user TO 'user_name '@'host_name ';
Это гарантирует, что пользователь не может изменить столбцы привилегии
непосредственно, но должен использовать
GRANT , чтобы дать
привилегии другим пользователям.
-
--secure-auth
Устарела |
5.7.5 |
Формат командной строки
| --secure-auth |
Системная переменная
| Имя |
secure_auth
|
Область действия |
Глобальная |
Динамическая |
Да |
Допустимые значения
| Тип |
boolean |
Значение по умолчанию |
ON |
Допустимые значения
| ON |
Эта опция заставляет сервер блокировать соединения клиентам, которые
пытаются использовать учетные записи, которые сохранили пароли в старом
(до 4.1) формате. Используйте это, чтобы предотвратить использование паролей,
использующих старый формат (и следовательно опасную коммуникацию по сети).
Эта опция устарела и будет удалена в будущем выпуске MySQL. Это всегда
включается и попытка отключить это
(--skip-secure-auth
,
--secure-auth=0 ) производит ошибку.
Запуск сервера терпит неудачу с ошибкой, если эта опция включена, и
таблицы привилегии находятся в формате pre-4.1.
mysql
также имеет опцию
--secure-auth , которая предотвращает соединения с сервером, если
сервер требует пароля в старом формате для учетной записи клиента.
Пароли, которые используют pre-4.1, менее безопасны, чем пароли, которые
используют родной метод хеширования пароля. Пароли Pre-4.1 устарели
и поддержка их была удалена.
--secure-file-priv=
dir_name
Формат командной строки
| --secure-file-priv=dir_name |
Системная переменная
| Имя |
secure_file_priv |
Область действия |
Глобальная |
Динамическая |
Нет |
Допустимые значения
| Тип |
string |
Значение по умолчанию |
platform specific |
Допустимые значения |
empty |
dirname |
NULL |
Эта опция устанавливает
secure_file_priv
, которая используется, чтобы ограничить эффект импорта и экспортных
операций, таких как выполнение
LOAD DATA и
SELECT ... INTO OUTFILE и
функция LOAD_FILE() .
-
--shared-memory
Формат командной строки
| --shared_memory[={0,1}] |
Системная переменная
| Имя |
shared_memory
|
Область действия |
Глобальная |
Динамическая |
Нет |
Платформа |
Windows |
Допустимые значения
| Тип |
boolean |
Значение по умолчанию |
FALSE |
Включить соединения совместно используемой памяти местными клиентами.
Эта опция доступна только в Windows.
-
--shared-memory-base-name=name
Формат командной строки
| --shared_memory_base_name=name |
Системная переменная
| Имя |
shared_memory_base_name |
Область действия |
Глобальная |
Динамическая |
Нет |
Платформа |
Windows |
Допустимые значения
| Тип |
string |
Значение по умолчанию |
MYSQL |
Название совместно используемой памяти, чтобы использовать для соединений
совместно используемой памяти. Эта опция доступна только в Windows. Имя по
умолчанию MYSQL . Имя является чувствительным к регистру.
-
--skip-concurrent-insert
Выключить способность выбрать и вставить в то же самое время на
MyISAM . Это должно использоваться, только если Вы думаете, что
нашли ошибку в этой особенности. См.
раздел 9.11.3.
-
--skip-event-scheduler
Формат командной строки
| --skip-event-scheduler |
| --disable-event-scheduler
|
Переводит Event Scheduler в OFF .
Это не то же самое как отключение Event Scheduler, которое требует установки
--event-scheduler=DISABLED , см.
опцию
--event-scheduler .
-
--skip-grant-tables
Эта опция заставляет сервер запускаться, не используя систему привилегий
вообще, что дает любому неограниченный доступ ко всем базам данных.
Вы можете заставить рабочий сервер начинать использовать таблицы с помощью
mysqladmin
flush-privileges или
mysqladmin reload
из системной оболочки или командой MySQL
FLUSH PRIVILEGES после соединения с сервером.
Эта опция также заставляет сервер подавлять во время запуска загрузку
определяемых пользователем функций (UDF), намеченных событий и плагинов,
которые были установлены с
INSTALL PLUGIN .
Чтобы заставить плагины быть загруженными так или иначе, используйте опцию
--plugin-load
.
--skip-grant-tables также блокирует
disabled_storage_engines .
Эта опция не заставляет загрузку серверных компонентов быть подавленной
во время запуска сервера.
FLUSH PRIVILEGES
может быть выполнен неявно другими действиями, выполненными после запуска.
Например, mysql_upgrade
сбрасывает привилегии во время процедуры обновления.
-
--skip-host-cache
Отключить использование внутреннего кэша узла для более быстрого
разрешения имени к IP. В этом случае сервер выполняет поиск DNS каждый раз,
когда клиент соединяется. См. раздел
9.12.4.2.
Использование
--skip-host-cache подобно установке
host_cache_size
к 0, но host_cache_size
более гибко, потому что это может также использоваться, чтобы
изменить размеры, включить или отключить кэш узла во время выполнения, не
только при запуске сервера.
Если Вы запускаете сервер с
--skip-host-cache
, это не предотвращает изменения значения
host_cache_size ,
но такие изменения не имеют никакого эффекта, и кэш не включен повторно,
даже если host_cache_size
больше 0.
--skip-innodb
Отключить механизм хранения InnoDB .
В этом случае, потому что механизм хранения по умолчанию
InnoDB ,
сервер не будет запускаться, если Вы также не будете использовать
--default-storage-engine и
--default-tmp-storage-engine , чтобы установить значение по
умолчанию в некоторый другой механизм для постоянных и
для TEMPORARY таблиц.
Механизм хранения InnoDB не может быть отключен, и
--skip-innodb
устарела и не имеет никакого эффекта. Ее использование приводит к
предупреждению. Эта опция будет удалена в будущем выпуске MySQL.
-
--skip-name-resolve
Не решать имена хоста, проверяя соединения клиента.
Использовать только IP-адреса. Если Вы используете эту опцию, все столбцы
Host в таблицах привилегий должны быть IP-адресами. См.
раздел 9.12.4.2.
В зависимости от сетевой конфигурации Вашей системы и значения
Host для Ваших учетных записей, клиенты, возможно, должны
соединиться с использованием явной опции --host , например,
--host=127.0.0.1 или --host=::1 .
Попытка соединиться с узлом 127.0.0.1
обычно приводит к учетной записи localhost .
Однако, это терпит неудачу, если сервер выполнен с
--skip-name-resolve , так что удостоверьтесь, что учетная запись
существует, которая может принять соединение.
Например, чтобы быть в состоянии соединиться как root , используя
--host=127.0.0.1 или --host=::1 ,
создайте эти учетные записи:
CREATE USER 'root'@'127.0.0.1' IDENTIFIED BY 'root-password ';
CREATE USER 'root'@'::1' IDENTIFIED BY 'root-password ';
-
--skip-networking
Не слушать соединения TCP/IP вообще. Все взаимодействие с
mysqld
должно быть сделано, используя именованные каналы или совместно используемую
память (в Windows) или файлы сокетов Unix (в Unix). Эта опция настоятельно
рекомендована для систем, где только местным клиентам разрешают работать. См.
раздел 9.12.4.2.
--ssl*
Опции, которые начинаются с
--ssl , определяют, разрешить ли клиентам соединяться с
использованием SSL и указывают, где найти ключи SSL и сертификаты. См.
раздел 7.4.5.
-
--standalone
Формат командной строки
| --standalone |
Платформа |
Windows |
Только в Windows. Инструктирует сервер MySQL не работать как служба.
-
--super-large-pages
Формат командной строки
| --super-large-pages |
Платформа |
Solaris |
Допустимые значения
(Solaris) | Тип |
boolean |
Значение по умолчанию |
FALSE |
Стандартное использование больших страниц в MySQL пытается использовать
самый большой поддержанный размер до 4 МБ. В Solaris особенность
super large pages включает использование страниц до
256 МБ. Эта особенность доступна для недавних платформ SPARC. Это может быть
включено или отключено при использовании опций
--super-large-pages или
--skip-super-large-pages .
-
--symbolic-links
,
--skip-symbolic-links
Формат командной строки
| --symbolic-links |
Включить или отключить поддержку символьной ссылки. В Unix
включение символических ссылок означает, что Вы можете соединить опции
INDEX DIRECTORY или DATA DIRECTORY в
CREATE TABLE .
Если Вы удаляете или переименовываете таблицу, файлы, на которые указывают ее
символические ссылки, также удалены или переименованы. См.
раздел 9.12.2.2.
У этой опции нет никакого значения в Windows.
-
--skip-show-database
Формат командной строки
| --skip-show-database |
Системная переменная
| Имя |
skip_show_database |
Область действия |
Глобальная |
Динамическая |
Нет |
Эта опция устанавливает
skip_show_database , которая управляет, кому разрешают использовать
SHOW DATABASES . См.
раздел 6.1.5.
-
--skip-stack-trace
Формат командной строки
| --skip-stack-trace |
Не пишите трассировку стека. Эта опция полезна, когда Вы выполняете
mysqld
под отладчиком. На некоторых системах Вы также должны использовать эту опцию,
чтобы получить файл дампа. См. раздел 26.5.
-
--slow-query-log[={0|1}]
Формат командной строки
| --slow-query-log |
Системная переменная
| Имя |
slow_query_log |
Область действия |
Глобальная |
Динамическая |
Да |
Допустимые значения
| Тип |
boolean |
Значение по умолчанию |
OFF |
Определите начальное состояние медленного журнала запроса. Без параметра
или с параметром 1
--slow-query-log включает журнал. Если опущена или дана с
параметром 0 опция отключает журнал.
-
--slow-start-timeout=timeout
Формат командной строки
| --slow-start-timeout=# |
Допустимые значения
(Windows) | Тип |
integer |
Значение по умолчанию |
15000 |
Эта опция управляет тайм-аутом запуска службы Windows.
Значение: максимальное количество миллисекунд, которое менеджер
по управлению службой ждет прежде, чем попытаться уничтожить службу во
время запуска. Значение по умолчанию 15000 (15 секунд). Если служба MySQL
слишком долго запускается, Вы, возможно, должны увеличить это значение.
Значение 0 отменяет тайм-аут.
-
--socket=path
Формат командной строки
| --socket={file_name|pipe_name}
|
Системная переменная
| Имя |
socket
|
Область действия |
Глобальная |
Динамическая |
Нет |
Допустимые значения
| Тип |
string |
Значение по умолчанию |
/tmp/mysql.sock |
В Unix эта опция определяет файл сокета Unix для местных соединений.
Значение по умолчанию /tmp/mysql.sock .
Если эта опция дана, сервер создает файл в каталоге данных, если абсолютный
путь не дан, чтобы определить иной каталог. В Windows опция определяет имя
канала, чтобы использовать, слушая местные соединения, которые используют
названный канал. Значение по умолчанию MySQL
(не чувствительно к регистру).
-
--sql-mode=value
[,value [,value ...]]
Формат командной строки
| --sql-mode=name |
Системная переменная
| Имя |
sql_mode
|
Область действия |
Глобальная, Сеансовая |
Динамическая |
Да |
Допустимые значения
| Тип |
set |
Значение по умолчанию |
ONLY_FULL_GROUP_BY STRICT_TRANS_TABLES NO_ZERO_IN_DATE
NO_ZERO_DATE ERROR_FOR_DIVISION_BY_ZERO NO_AUTO_CREATE_USER
NO_ENGINE_SUBSTITUTION |
Допустимые значения |
ALLOW_INVALID_DATES |
ANSI_QUOTES |
ERROR_FOR_DIVISION_BY_ZERO |
HIGH_NOT_PRECEDENCE |
IGNORE_SPACE |
NO_AUTO_CREATE_USER |
NO_AUTO_VALUE_ON_ZERO |
NO_BACKSLASH_ESCAPES |
NO_DIR_IN_CREATE |
NO_ENGINE_SUBSTITUTION |
NO_FIELD_OPTIONS |
NO_KEY_OPTIONS |
NO_TABLE_OPTIONS |
NO_UNSIGNED_SUBTRACTION |
NO_ZERO_DATE |
NO_ZERO_IN_DATE |
ONLY_FULL_GROUP_BY |
PAD_CHAR_TO_FULL_LENGTH |
PIPES_AS_CONCAT |
REAL_AS_FLOAT |
STRICT_ALL_TABLES |
STRICT_TRANS_TABLES |
Установить режим SQL. См. раздел 6.1.8.
Программы установки MySQL могут сконфигурировать режим SQL во
время процесса установки.
Если режим SQL отличается от значения по умолчанию или от того, что Вы
ожидаете, проверьте установку в файле опции, который сервер
читает при запуске.
--sysdate-is-now
Формат командной строки
| --sysdate-is-now |
Допустимые значения
| Тип |
boolean |
Значение по умолчанию |
FALSE |
SYSDATE()
возвращает по умолчанию время, в которое это выполняется, а не время, в
которое запрос, в котором это происходит, начинает выполняться. Это
отличается от поведения NOW()
. Эта опция предписывает
SYSDATE() стать псевдонимом
NOW() . Для информации о значениях для двоичного
журналирования см. описание для
SYSDATE() в
разделе 13.7 и для
SET TIMESTAMP в
разделе 6.1.5.
-
--tc-heuristic-recover={COMMIT|ROLLBACK}
Формат командной строки
| --tc-heuristic-recover=name |
Допустимые значения
| Тип |
enumeration |
Значение по умолчанию |
COMMIT |
Допустимые значения |
COMMIT |
ROLLBACK |
Тип решения, которое использовать в эвристическом процессе восстановления.
Чтобы использовать эту опцию, два или больше механизма хранения, которые
поддерживают транзакции XA,
должны быть установлены.
-
--temp-pool
Формат командной строки
| --temp-pool |
Допустимые значения
| Тип |
boolean |
Значение по умолчанию |
TRUE |
Эта опция заставляет большинство временных файлов, создаваемых сервером
использовать маленький набор имен, а не уникальное имя для каждого нового
файла. Это обходит проблему в ядре Linux, имеющую дело с созданием многих
новых файлов с различными именами. Со старым поведением Linux допускала
утечку памяти, потому что выделяла ее кэшу записи в каталоге, а не дисковому
кэшу. Эта опция проигнорирована везде, за исключением Linux.
-
--transaction-isolation=level
Формат командной строки
| --transaction-isolation=name |
Допустимые значения
| Тип |
enumeration |
Значение по умолчанию |
REPEATABLE-READ |
Допустимые значения |
READ-UNCOMMITTED |
READ-COMMITTED |
REPEATABLE-READ |
SERIALIZABLE |
Устанавливает операционный уровень изоляции по умолчанию.
level может быть
READ-UNCOMMITTED
, READ-COMMITTED
,
REPEATABLE-READ или
SERIALIZABLE . См.
раздел 14.3.6.
Операционный уровень изоляции по умолчанию может также быть установлен во
время выполнения, используя SET
TRANSACTION или переменную
tx_isolation .
-
--transaction-read-only
Формат командной строки
| --transaction-read-only |
Допустимые значения
| Тип |
boolean |
Значение по умолчанию |
OFF |
Устанавливает операционный режим доступа по умолчанию. По умолчанию режим
только для чтения отключен, таким образом, режим чтение-запись.
Чтобы установить операционный режим доступа по умолчанию во время
выполнения, используйте SET
TRANSACTION или переменную
tx_read_only , см.
раздел 14.3.6.
-
--tmpdir=dir_name ,
-t dir_name
Формат командной строки
| --tmpdir=dir_name |
Системная переменная
| Имя |
tmpdir
|
Область действия |
Глобальная |
Динамическая |
Нет |
Допустимые значения |
Тип |
directory name |
Путь к каталогу, чтобы создать временные файлы.
Это могло бы быть полезно, если Ваше значение по умолчанию
/tmp находится на разделе, который слишком маленький, чтобы
держать временные таблицы. Эта опция принимает несколько путей, которые
используются круговым способом. Пути должны быть отделены символами двоеточия
(: ) в Unix и символом точки с запятой (; ) в
Windows. Если сервер MySQL действует как ведомое устройство, Вы не должны
установить --tmpdir
в каталог на основанной на памяти файловой системе или в каталог,
который очищен, когда сервер перезапускается. Для получения дополнительной
информации о местоположении хранения временных файлов см.
раздел B.5.3.5. Ведомое устройство
нуждается в некоторых из своих временных файлов, чтобы пережить машинный
перезапуск так, чтобы оно могло копировать временные таблицы или
LOAD DATA INFILE . Если файлы во
временном каталоге файла потеряны, когда сервер перезапускается,
репликация терпит неудачу.
-
--user={user_name
|user_id } ,
-u {user_name |user_id }
Формат командной строки
| --user=name |
Допустимые значения |
Тип |
string |
Выполнить mysqld
как пользователя, имеющего имя user_name
или числовой user ID user_id . User
в этом контексте обращается к системной учетной записи, а не к
пользователю MySQL, перечисленному в таблицах привилегий.
Эта опция принудительна, запуская
mysqld как
root . Сервер изменяет свой пользовательской ID во время запуска,
заставляя это работать как особый пользователь, а не как root .
См. раздел 7.1.1.
Чтобы избежать возможной дыры в системе безопасности, где пользователь
добавляет опцию --user=root
в файл my.cnf (таким образом заставляя сервер
работать как root ),
mysqld использует только первую опцию
--user
и производит предупреждение, если там много опций
--user .
Опции в /etc/my.cnf и $MYSQL_HOME/my.cnf
обработаны перед параметрами командной строки, таким образом, рекомендуется,
чтобы Вы поместили опцию --user
в /etc/my.cnf и определили значение кроме
root . Опция в /etc/my.cnf найдена перед любой
другой опцией --user
, что гарантирует, что сервер работает
не как пользователь root .
-
--verbose ,
-v
Используйте эту опцию с
--help для подробной справки.
-
--version ,
-V
Информация о версии и выход.
6.1.5. Системные переменные сервера
Сервер MySQL поддерживает много системных переменных, которые указывают,
как он сконфигурирован. У каждой системной переменной есть значение по
умолчанию. Системные переменные могут быть установлены в опциях запуска
сервера в командной строке или в файле опции. Большинство из них может быть
изменено динамически во времени выполнения, используя
SET ,
который позволяет Вам изменить работу сервера, не имея необходимости
останавливать и перезапускать это. Установка глобального значения системной
переменной требует привилегии
SUPER .
Для некоторых системных переменных, устанавка значения сеанса также требует
привилегии SUPER ,
если так, это обозначено в описании переменной. Вы можете также использовать
системные значения переменной в выражениях.
Есть несколько способов видеть имена и значения системных переменных:
Чтобы видеть значения, которые сервер будет использовать
в значениях по умолчанию и любых файлах опции, которые он читает,
используйте эту команду:
mysqld --verbose --help
- Чтобы видеть значения, которые сервер будет использовать
в значениях по умолчанию, игнорируя настройки в любых файлах опции,
используйте эту команду:
mysqld --no-defaults --verbose --help
- Чтобы видеть текущее значение, используемое рабочим сервером, используйте
SHOW VARIABLES или
системные таблицы переменной в Performance Schema. См.
раздел 23.9.13
.
Этот раздел включает таблицу, которая перечисляет все системные
переменные и обеспечивает описание каждой. Переменные без обозначенной версии
присутствуют во всех выпусках MySQL 8.0. Для получения дополнительной
информации о манипуляции системными переменными см.
раздел 6.1.6.
Таблица 6.2. Системные переменные
Для дополнительной системной информации о переменной см. эти разделы:
Некоторые из следующих переменных описаний относятся к
включению или выключению
переменной. Эти переменные могут быть включены с
SET , устанавливая их в
ON или 1 , или отключены, устанавливая их в
OFF или 0 . Логические переменные могут быть
установлены при запуске в значения ON , TRUE ,
OFF и FALSE (не чувствительны к регистру), так же
как 1 и 0 . См.
раздел 5.2.5.
Некоторые системные переменные управляют размером буферов или кэшей.
Для данного буфера сервер, возможно, должен был бы выделить внутренние
структуры данных. Эти структуры, как правило, выделяются от полной памяти,
выделенной буферу, количество требуемого пространства может зависеть от
платформы. Это означает, что, когда Вы назначаете значение системной
переменной, которая управляет размером буфера, количество фактически
доступного пространства может отличаться от назначенного значения. В
некоторых случаях количество могло бы быть меньше, чем назначенное значение.
Также возможно, что сервер скорректирует значение вверх. Например, если Вы
назначите значение 0 переменной, для которой минимальное значение 1024, то
сервер установит значение в 1024.
Значения для буферных размеров, длин и размеров стека даны в байтах,
если иначе не определено.
Некоторые системные переменные берут значения имени файла. Если иначе не
определено, местоположение файла значения по умолчанию каталог данных, если
значение относительный путь. Чтобы определить местоположение явно,
используйте абсолютный путь. Предположите, что каталог данных
/var/mysql/data . Если оцененная к имени файла переменная будет
дана как относительный путь, то он будет расположен под
/var/mysql/data . Если значение абсолютный путь, его
местоположение дано путем.
autocommit
Формат командной строки
| --autocommit[=#] |
Системная переменная
| Имя |
autocommit
|
Область действия |
Глобальная, Сеансовая |
Динамическая |
Да |
Системная переменная
| Имя |
autocommit
|
Область действия |
Глобальная, Сеансовая |
Динамическая |
Да |
Допустимые значения
| Тип |
boolean |
Значение по умолчанию |
ON |
Режим autocommit. Если установлено в 1, все изменения таблицы немедленно
вступают в силу. Если установлено в 0, Вы должны использовать
COMMIT , чтобы принять транзакцию,
или ROLLBACK , чтобы отменить ее.
Если autocommit = 0
и Вы изменяете это на 1, MySQL выполняет автоматический
COMMIT любой открытой транзакции.
Другой способ начать транзакцию состоит в том, чтобы использовать
START TRANSACTION или
BEGIN , см.
раздел 14.3.1.
По умолчанию соединения клиента начинаются с
autocommit = 1.
Чтобы заставить клиентов начинать со значением по умолчанию 0, установите
глобальное значение autocommit
, запуская сервер с опцией
--autocommit=0 .
Чтобы установить переменную, используя файл опции, включите эти строки:
[mysqld]
autocommit=0
-
automatic_sp_privileges
Системная переменная
| Имя |
automatic_sp_privileges |
Область действия |
Глобальная |
Динамическая |
Да |
Допустимые значения
| Тип |
boolean |
Значение по умолчанию |
TRUE |
Когда у этой переменной есть значение 1 (значение по умолчанию), сервер
автоматически предоставляет привилегии
EXECUTE и
ALTER ROUTINE
создателю сохраненной подпрограммы, если пользователь не может уже выполнить
и изменить или удалить ее. Привилегия
ALTER ROUTINE
нужна, чтобы ужадить подпрограмму. Сервер также автоматически удаляет эти
привилегии у создателя, когда подпрограмма удалена. Если
automatic_sp_privileges = 0,
сервер автоматически не добавляет или удаляет эти привилегии.
Создатель подпрограммы это учетная запись, используемая, чтобы выполнить
CREATE . Это может быть учетной записью, названной как
DEFINER в обычном определении. См.
раздел 21.2.2.
-
auto_generate_certs
Формат командной строки
| --auto_generate_certs[={OFF|ON}]
|
Системная переменная
| Имя |
auto_generate_certs |
Область действия |
Глобальная |
Динамическая |
Нет |
Допустимые значения
| Тип |
boolean |
Значение по умолчанию |
ON |
Эта переменная доступна, если сервер был собран, используя OpenSSL (см.
раздел 7.4.1).
Это управляет, генерирует ли сервер ключ SSL и файлы сертификата в каталоге
данных, если они еще не существуют.
При запуске сервер автоматически производит сертификаты
SSL кдиента и сервера и ключевые файлы в каталоге данных, если
auto_generate_certs
включена, никакие опции SSL, кроме
--ssl не
определены, и файлы SSL сервера отсутствуют в каталоге данных.
Эти файлы включают безопасные соединения клиента, используя SSL, см.
раздел 7.4.4.
Для получения дополнительной информации о генерации
файла SSL, включая имена файла и характеристики, см.
раздел 7.4.6.1
sha256_password_auto_generate_rsa_keys связана, но управляет
генерацией файлов ключевой пары RSA, необходимых для безопасного обмена
паролями, использующего RSA по незащищенным соединениям.
-
avoid_temporal_upgrade
Устарела |
5.7.6 |
Формат командной строки
| --avoid_temporal_upgrade={OFF|ON} |
Системная переменная
| Имя |
avoid_temporal_upgrade |
Область действия |
Глобальная |
Динамическая |
Да |
Допустимые значения
| Тип |
boolean |
Значение по умолчанию |
OFF |
Эта переменная управляет тем, обновляет ли
ALTER TABLE
неявно временные столбцы, которые были в формате pre-5.6.4
(TIME ,
DATETIME и
TIMESTAMP
без поддержки дробной точности секунд). Обновление таких столбцов требует,
чтобы таблица была пересоздана, что предотвращает любое использование быстрых
изменений, которые могли бы иначе относиться к работе,
которая будет выполнена.
Эта переменная отключена по умолчанию. Включение предписывает
ALTER TABLE не пересоздавать
временные столбцы и таким образом быть в состоянии использовать в своих
интересах возможные быстрые изменения.
Эта переменная устарела и будет удалена в будущем выпуске MySQL.
-
back_log
Системная переменная
| Имя |
back_log
|
Область действия |
Глобальная |
Динамическая |
Нет |
Допустимые значения
| Тип |
integer |
Значение по умолчанию |
-1 (autosized) |
Минимум |
1 |
Максимум |
65535 |
Это играет роль, когда основной поток MySQL получает очень много запросов
соединения за очень короткое время. Это тогда занимает время
(хотя очень немного) для основного потока, чтобы проверить соединение и
начать обмен данными. back_log
указывает, сколько запросов может быть сложено в течение этого
короткого времени прежде, чем MySQL на мгновение прекратит отвечать на новые
запросы. Вы должны увеличить это, только если Вы ожидаете большое количество
соединений за короткий период времени.
Другими словами, это значение размер очереди для поступающих соединений
TCP/IP. У Вашей операционной системы есть свой собственный предел
этой очереди. Страница руководства для системного вызова Unix
listen() дает больше деталей. Проверьте свою документацию OS на
максимальное значение для этой переменной.
back_log
не может быть установлен выше чем Ваш предел операционной системы.
Значение по умолчанию основано на следующей формуле при максимуме в 900:
50 + (max_connections / 5)
-
basedir
Формат командной строки
| --basedir=dir_name |
Системная переменная
| Имя |
basedir
|
Область действия |
Глобальная |
Динамическая |
Нет |
Допустимые значения |
Тип |
directory name |
Основной каталог MySQL. Эта переменная может быть установлена с
--basedir .
Относительные пути для других переменных обычно решаются
относительно основного каталога.
-
big_tables
Формат командной строки
| --big-tables |
Системная переменная
| Имя |
big_tables
|
Область действия |
Глобальная, Сеансовая |
Динамическая |
Да |
Системная переменная
| Имя |
big_tables
|
Область действия |
Глобальная, Сеансовая |
Динамическая |
Да |
Допустимые значения
| Тип |
boolean |
Значение по умолчанию |
OFF |
Если установлено в 1, все временные таблицы сохранены на диске, а не в
памяти. Это немного медленнее, но ошибка
The table tbl_name is full
не происходит для SELECT , которые
требуют большой временной таблицы. Значение по умолчанию для нового
соединения 0 (использовать временные таблицы в памяти). Обычно Вы никогда не
должны устанавливать эту переменную, потому что таблицы в памяти
автоматически преобразованы в таблицы на диске, когда требуется.
-
bind_address
Формат командной строки
| --bind-address=addr |
Системная переменная
| Имя |
bind_address
|
Область действия |
Глобальная |
Динамическая |
Нет |
Допустимые значения
| Тип |
string |
Значение по умолчанию |
* |
Значение опции
--bind-address .
Эта переменная не имеет никакого эффекта для встроенного сервера
(libmysqld ) и не видна в пределах встроенного сервера.
-
block_encryption_mode
Формат командной строки
| --block_encryption_mode=# |
Системная переменная
| Имя |
block_encryption_mode |
Область действия |
Глобальная, Сеансовая |
Динамическая |
Да |
Допустимые значения
| Тип |
string |
Значение по умолчанию |
aes-128-ecb |
Эта переменная управляет режимом блочного шифрования для основанных на
блоке алгоритмов, таких как AES. Это затрагивает шифрование для
AES_ENCRYPT() и
AES_DECRYPT() .
block_encryption_mode принимает значение в формате
aes-keylen -mode , где
keylen длина ключа в битах и mode
режим шифрования. Значение не является чувствительным к регистру. Разрешенные
значения для keylen 128, 192 и 256.
Разрешенные режимы шифрования зависят от того, был ли MySQL собран, используя
OpenSSL или yaSSL:
Для OpenSSL mode :
ECB , CBC , CFB1 ,
CFB8 , CFB128 , OFB .
- Для yaSSL
mode : ECB , CBC .
Например, это запрос заставляет функции шифрования AES использовать длину
ключа в 256 бит и режим CBC:
SET block_encryption_mode = 'aes-256-cbc';
Ошибка происходит для попыток установить
block_encryption_mode
к значению, содержащему неподдержанную длину ключа или режим,
который не поддерживает библиотека SSL.
-
bulk_insert_buffer_size
Формат командной строки
| --bulk_insert_buffer_size=# |
Системная переменная
| Имя |
bulk_insert_buffer_size |
Область действия |
Глобальная, Сеансовая |
Динамическая |
Да |
Допустимые значения
(32-bit platforms) | Тип |
integer |
Значение по умолчанию |
8388608 |
Минимум |
0 |
Максимум |
4294967295 |
Допустимые значения
(64-bit platforms) | Тип |
integer |
Значение по умолчанию |
8388608 |
Минимум |
0 |
Максимум |
18446744073709551615 |
MyISAM использует специальный подобный дереву кэш,
чтобы сделать большую вставку быстрее для
INSERT ... SELECT ,
INSERT ... VALUES (...), (...), ... и
LOAD DATA INFILE ,
добавляя данные к непустым таблицам. Эта переменная ограничивает размер
дерева кэша в байтах на поток. Установка этого к 0 отключает эту оптимизацию.
Значение по умолчанию составляет 8 МБ.
-
character_set_client
Системная переменная
| Имя |
character_set_client |
Область действия |
Глобальная, Сеансовая |
Динамическая |
Да |
Допустимые значения |
Тип |
string |
Набор символов для запросов, которые прибывают от клиента. Значение сеанса
этой переменной установлено, используя набор символов, который требует
клиент, когда клиент соединяется с сервером. Много клиентов поддерживают
опцию --default-character-set , чтобы позволить этому набору
символов, который будет определен явно. См. также
раздел 11.1.4.
Глобальное значение переменной используется, чтобы установить значение сеанса
в случаях, когда требуемое клиентом значение неизвестно или не доступно, или
сервер сконфигурирован, чтобы проигнорировать запросы клиента:
ucs2 , utf16 , utf16le и
utf32 не может использоваться в качестве набора символов
клиента, что означает, что они также не работают для
SET NAMES или
SET CHARACTER SET .
-
character_set_connection
Системная переменная
| Имя |
character_set_connection |
Область действия |
Глобальная, Сеансовая |
Динамическая |
Да |
Допустимые значения |
Тип |
string |
Набор символов для литералов, у которых нет набора символов
и для преобразования числа к строке. Для информации см.
раздел 11.1.3.8.
-
character_set_database
Системная переменная
| Имя |
character_set_database |
Область действия |
Глобальная, Сеансовая |
Динамическая |
Да |
Footnote |
Да |
Допустимые значения |
Тип |
string |
Набор символов используется базой данных значения по умолчанию.
Сервер устанавливает эту переменную всякий раз, когда база данных по
умолчанию изменяется. Если нет никакой базы данных по умолчанию, у переменной
есть то же самое значение, как у
character_set_server
.
Глобальные перменные
character_set_database и
collation_database
устарели и будут удалены в будущей версии MySQL.
Назначение значения к сеансовым перменным
character_set_database и
collation_database устарело, и назначения производят
предупреждение. Переменные сеанса станут только для чтения в будущей версии
MySQL, и назначения произведут ошибку. Останется возможным получить доступ к
переменным сеанса, чтобы определить набор символов базы данных и
сопоставление для базы данных по умолчанию.
-
character_set_filesystem
Формат командной строки
| --character-set-filesystem=name
|
Системная переменная
| Имя |
character_set_filesystem |
Область действия |
Глобальная, Сеансовая |
Динамическая |
Да |
Допустимые значения
| Тип |
string |
Значение по умолчанию |
binary |
Набор символов файловой системы. Эта переменная используется, чтобы
интерпретировать строковые литералы, которые обращаются к именам файла, как
в LOAD DATA INFILE и
SELECT ... INTO OUTFILE и
функции LOAD_FILE() .
Такие имена файла преобразованы из
character_set_client в
character_set_filesystem
прежде, чем попытка открытия файла происходит. Значение по умолчанию
binary , что означает, что никакое преобразование не происходит.
Для систем, на которых разрешены имена файла в мультибайтном наборе символов,
иное значение может быть более соответствующим. Например, если система
представляет имена файла, используя UTF-8, установите
character_set_filesystem в 'utf8' .
-
character_set_results
Системная переменная
| Имя |
character_set_results |
Область действия |
Глобальная, Сеансовая |
Динамическая |
Да |
Допустимые значения |
Тип |
string |
Набор символов, используемый для того, чтобы возвратить результат запроса
или сообщения об ошибках клиенту.
-
character_set_server
Формат командной строки
| --character-set-server |
Системная переменная
| Имя |
character_set_server |
Область действия |
Глобальная, Сеансовая |
Динамическая |
Да |
Допустимые значения
| Тип |
string |
Значение по умолчанию |
latin1 |
Набор символов по умолчанию сервера.
-
character_set_system
Системная переменная
| Имя |
character_set_system |
Область действия |
Глобальная |
Динамическая |
Нет |
Допустимые значения
| Тип |
string |
Значение по умолчанию |
utf8 |
Набор символов используется сервером для того, чтобы сохранить
идентификаторы. Значение всегда utf8 .
-
character_sets_dir
Формат командной строки
| --character-sets-dir=dir_name
|
Системная переменная
| Имя |
character_sets_dir |
Область действия |
Глобальная |
Динамическая |
Нет |
Допустимые значения |
Тип |
directory name |
Каталог, где наборы символов установлены.
-
check_proxy_users
Формат командной строки
| --check_proxy_users=[={OFF|ON}]
|
Системная переменная
| Имя |
check_proxy_users |
Область действия |
Глобальная |
Динамическая |
Да |
Допустимые значения
| Тип |
boolean |
Значение по умолчанию |
OFF |
Эта переменная управляет, выполняет ли сервер пользователя по
доверенности, отображающегося для плагинов аутентификации, которые просят
это. С check_proxy_users
может также быть необходимо позволить определенным для плагина
системным переменным использовать пользователя полномочия
сервера, отображающего поддержку:
См. раздел 7.3.10.
-
collation_connection
Системная переменная
| Имя |
collation_connection |
Область действия |
Глобальная, Сеансовая |
Динамическая |
Да |
Допустимые значения |
Тип |
string |
Сопоставление набора символов соединения.
-
collation_database
Системная переменная
| Имя |
collation_database |
Область действия |
Глобальная, Сеансовая |
Динамическая |
Да |
Footnote |
Да |
Допустимые значения |
Тип |
string |
Сопоставление используется базой данных по умолчанию. Сервер устанавливает
эту переменную всякий раз, когда база данных по умолчанию изменяется. Если
нет никакой базы данных по умолчанию, у переменной есть то же самое значение,
как у collation_server
.
Глобальные переменные
character_set_database и
collation_database
устарели и будут удалены в будущей версии MySQL.
Назначение значения к сеансовым перменным
character_set_database и
collation_database
устарело, и назначения производят предупреждение. Переменные
сеанса станут только для чтения в будущей версии MySQL, и назначения
произведут ошибку. Останется возможным получить доступ к переменным сеанса,
чтобы определить набор символов базы данных и сопоставление для базы
данных по умолчанию.
-
collation_server
Формат командной строки
| --collation-server |
Системная переменная
| Имя |
collation_server |
Область действия |
Глобальная, Сеансовая |
Динамическая |
Да |
Допустимые значения
| Тип |
string |
Значение по умолчанию |
latin1_swedish_ci |
Сопоставление по умолчанию сервера.
-
completion_type
Формат командной строки
| --completion_type=# |
Системная переменная
| Имя |
completion_type |
Область действия |
Глобальная, Сеансовая |
Динамическая |
Да |
Допустимые значения
| Тип |
enumeration |
Значение по умолчанию |
NO_CHAIN |
Допустимые значения |
NO_CHAIN |
CHAIN |
RELEASE |
0 |
1 |
2 |
Допустимые значения
| Тип |
enumeration |
Значение по умолчанию |
NO_CHAIN |
Допустимые значения |
NO_CHAIN |
CHAIN |
RELEASE |
0 |
1 |
2 |
Операционный тип завершения. Эта переменная может взять значения,
показанные в следующей таблице. Переменная может быть назначена, используя
значения имени или соответствующие целочисленные значения.
Значение | Описание |
NO_CHAIN (0) |
COMMIT и
ROLLBACK не работают.
Это значение по умолчанию. |
CHAIN (1) |
COMMIT и
ROLLBACK эквивалентны
COMMIT AND CHAIN и ROLLBACK AND CHAIN ,
соответственно. Новая транзакция немедленно запускается с того же самого
уровня изоляции, как только что законченная транзакция. |
RELEASE (2) |
COMMIT и
ROLLBACK эквивалентны
COMMIT RELEASE и ROLLBACK RELEASE , соответственно.
Сервер разъединяет соединение после завершения транзакции.
|
completion_type
затрагивает транзакции, которые начинаются с
START TRANSACTION или
BEGIN и заканчиваются
COMMIT или
ROLLBACK .
Это не относится к неявным завершениям, которые могут следовать из выполнения
запросов, перечисленных в разделе 14.3.3
. Это также не применяется к
XA COMMIT ,
XA ROLLBACK или при
autocommit=1 .
-
concurrent_insert
Формат командной строки
| --concurrent_insert[=#] |
Системная переменная
| Имя |
concurrent_insert |
Область действия |
Глобальная |
Динамическая |
Да |
Допустимые значения
| Тип |
enumeration |
Значение по умолчанию |
AUTO |
Допустимые значения |
NEVER |
AUTO |
ALWAYS |
0 |
1 |
2 |
Допустимые значения
| Тип |
enumeration |
Значение по умолчанию |
AUTO |
Допустимые значения |
NEVER |
AUTO |
ALWAYS |
0 |
1 |
2 |
Если AUTO (значение по умолчанию), MySQL разрешает
INSERT и
SELECT работать одновременно на
MyISAM , у которых нет никаких свободных блоков в середине файла
с данными. Если Вы запускаете
mysqld с
--skip-new ,
эта переменная установлена в NEVER .
Эта переменная может взять значения, показанные в следующей таблице.
Переменная может быть назначена, используя значения имени или
соответствующие целочисленные значения.
Значение |
Описание |
NEVER (0) |
Отключает параллельные вставки. |
AUTO (1) | Значение по умолчанию.
Включает параллельные вставки для MyISAM , у
которых нет промежутков. |
ALWAYS (2) |
Включает параллельные вставки для всех таблиц MyISAM .
Для таблицы с промежутком новые строки вставлены в конце таблицы, если она
используется другим потоком. Иначе MySQL приобретает нормальную блокировку
записи и вставляет строку в промежуток. |
См. раздел 9.11.3.
-
connect_timeout
Формат командной строки
| --connect_timeout=# |
Системная переменная
| Имя |
connect_timeout |
Область действия |
Глобальная |
Динамическая |
Да |
Допустимые значения
| Тип |
integer |
Значение по умолчанию |
10 |
Минимум |
2 |
Максимум |
31536000 |
Число секунд, которое mysqld
ждет пакет перед ответом Bad handshake .
Значение по умолчанию составляет 10 секунд.
Увеличение
connect_timeout могло бы помочь, если клиенты часто сталкиваются с
ошибками формы Lost connection to MySQL server at 'XXX
', system error: errno .
-
core_file
Системная переменная
| Имя |
core_file
|
Область действия |
Глобальная |
Динамическая |
Нет |
Допустимые значения
| Тип |
boolean |
Значение по умолчанию |
OFF |
Написать ли файл дампа, если сервер отказывает. Эта переменная установлена
опцией --core-file
.
-
datadir
Формат командной строки
| --datadir=dir_name |
Системная переменная
| Имя |
datadir
|
Область действия |
Глобальная |
Динамическая |
Нет |
Допустимые значения |
Тип |
directory name |
Каталог данных MySQL. Эта переменная может быть установлена с опцией
--datadir .
-
date_format
Эта переменная не использована. Это устарело и будет удалено в
будущем выпуске MySQL.
-
datetime_format
Эта переменная не использована. Это устарело и будет удалено в
будущем выпуске MySQL.
-
debug
Формат командной строки
| --debug[=debug_options] |
Системная переменная
| Имя |
debug
|
Область действия |
Глобальная, Сеансовая |
Динамическая |
Да |
Допустимые значения
(Unix) | Тип |
string |
Значение по умолчанию |
d:t:i:o,/tmp/mysqld.trace |
Допустимые значения
(Windows) | Тип |
string |
Значение по умолчанию |
d:t:i:O,\mysqld.trace |
Эта переменная указывает на текущие настройки отладки.
Это доступно только для серверов, созданных с поддержкой отладки.
Начальное значение прибывает из значения экзепляров опции
--debug , данных при
запуске сервера. Глобальные значения и значения сеанса могут быть установлены
во время выполнения, для этого нужна привилегия
SUPER .
Назначение значения, которое начинается с + или
- добавляет или вычитает из текущего значения:
mysql> SET debug = 'T';
mysql> SELECT @@debug;
+---------+
| @@debug |
+---------+
| T |
+---------+
mysql> SET debug = '+P';
mysql> SELECT @@debug;
+---------+
| @@debug |
+---------+
| P:T |
+---------+
mysql> SET debug = '-P';
mysql> SELECT @@debug;
+---------+
| @@debug |
+---------+
| T |
+---------+
См. раздел 26.5.3.
-
debug_sync
Системная переменная
| Имя |
debug_sync
|
Область действия |
Сеансовая |
Динамическая |
Да |
Системная переменная
| Имя |
debug_sync
|
Область действия |
Сеансовая |
Динамическая |
Да |
Допустимые значения |
Тип |
string |
Эта переменная пользовательский интерфейс к средству Debug Sync.
Использование Debug Sync требует, чтобы MySQL был сконфигурирован с опцией
-DENABLE_DEBUG_SYNC=1 в CMake (см.
раздел 2.8.4). Если
Debug Sync не собран, эта системная переменная недоступна.
Глобальное переменное значение только для чтения и указывает, включено ли
средство. По умолчанию Debug Sync отключена и значение
debug_sync
OFF . Если сервер запущен с
--debug-sync-timeout=N , где
N значение тайм-аута больше 0, Debug Sync
включено, и значение
debug_sync ON - current signal ,
сопровождаемое именем сигнала. Кроме того, N
становится тайм-аутом по умолчанию для отдельных пунктов синхронизации.
Значение сеанса может быть считано любым пользователем и будет иметь то же
самое значение как глобальная переменная. Значение сеанса может быть
установлено пользователями, которые имеют привилегию
SUPER , чтобы
управлять пунктами синхронизации.
Для описания средства Debug Sync и как использовать пункты синхронизации
см. MySQL Internals: Test Synchronization.
-
default_authentication_plugin
Формат командной строки
| --default-authentication-plugin=plugin_name
|
Системная переменная
| Имя |
default_authentication_plugin |
Область действия |
Глобальная |
Динамическая |
Нет |
Допустимые значения
| Тип |
enumeration |
Значение по умолчанию |
mysql_native_password |
Допустимые значения |
mysql_native_password |
sha256_password |
Плагин аутентификации по умолчанию. Разрешенные значения
mysql_native_password (использует пароли MySQL, это значение по
умолчанию) и sha256_password (использует пароли SHA-256). См.
разделы 7.5.1.1 и
7.5.1.2.
Если Вы используете эту переменную, чтобы изменить плагин аутентификации
по умолчанию на значение кроме mysql_native_password ,
клиенты старше MySQL 5.5.6 больше не будут в состоянии соединиться, потому
что они не будут понимать получающегося изменения протокола аутентификации.
Значение
default_authentication_plugin влияет на эти
аспекты работы сервера:
Это определяет, какой плагин аутентификации сервер назначает на
новые учетные записи, создаваемые CREATE
USER и GRANT , которые не
называют плагин явно с IDENTIFIED WITH .
- Это устанавливает
old_passwords при запуске к значению, которое совместимо с методом
хеширования пароля, требуемым плагином по умолчанию.
old_passwords
влияет на значения хеширования паролей, определенных в IDENTIFIED BY
CREATE USER и
GRANT , а также пароли, определенные
как параметр функции PASSWORD()
.
- Для учетной записи, создаваемой с любым из следующих запросов, сервер
связывает учетную запись с плагином аутентификации по умолчанию и назначает
учетной записи данный пароль, хешированный согласно значению
old_passwords .
CREATE USER ... IDENTIFIED BY 'cleartext password ';
GRANT ... IDENTIFIED BY 'cleartext password ';
- Для учетной записи, создаваемой с любым из следующих запросов, запрос
терпит неудачу, если хеш пароля не зашифрован, используя формат хеша,
требуемый плагином аутентификации по умолчанию. Иначе сервер связывает
учетную запись с плагином аутентификации по умолчанию и назначает учетной
записи данный хеш пароля.
CREATE USER ... IDENTIFIED BY PASSWORD 'encrypted password ';
GRANT ... IDENTIFIED BY PASSWORD 'encrypted password ';
default_password_lifetime
Формат командной строки
| --default_password_lifetime=#
|
Системная переменная
| Имя |
default_password_lifetime |
Область действия |
Глобальная |
Динамическая |
Да |
Допустимые значения
| Тип |
integer |
Значение по умолчанию |
0 |
Минимум |
0 |
Максимум |
65535 |
Эта переменная определяет глобальную автоматическую политику истечения
пароля. Это относится к учетным записям, которые используют встроенные
методы аутентификации MySQL (учетные записи, которые используют плагин
аутентификации mysql_native_password
или sha256_password ).
По умолчанию
default_password_lifetime = 0, что
отключает автоматическое истечение пароля. Если значение
default_password_lifetime положительное целое число
N , это указывает на разрешенное время жизни пароля,
пароли должны быть изменены каждые N дней.
Глобальная политика истечения пароля может быть переопределена как надо
для отдельных учетных записей, используя ALTER USER , см.
раздел 7.3.7.
-
default_storage_engine
Формат командной строки
| --default-storage-engine=name
|
Системная переменная
| Имя |
default_storage_engine |
Область действия |
Глобальная, Сеансовая |
Динамическая |
Да |
Допустимые значения
| Тип |
enumeration |
Значение по умолчанию |
InnoDB |
Допустимые значения
| Тип |
enumeration |
Значение по умолчанию |
MyISAM |
Механизм хранения по умолчанию. Эта переменная устанавливает механизм
хранения только для постоянных таблиц. Установить механизм хранения для
таблиц TEMPORARY можно через переменную
default_tmp_storage_engine .
Чтобы видеть, какие механизмы хранения доступны и включены, используйте
the SHOW ENGINES или
запросите таблицу ENGINES
в базе данных INFORMATION_SCHEMA .
Если Вы отключаете механизм хранения по умолчанию при запуске сервера, Вы
должны установить механизм по умолчанию для постоянных и для
TEMPORARY таблиц к иному механизму, или сервер
не будет запускаться.
-
default_tmp_storage_engine
Формат командной строки
| --default_tmp_storage_engine=name
|
Системная переменная
| Имя |
default_tmp_storage_engine |
Область действия |
Глобальная, Сеансовая |
Динамическая |
Да |
Допустимые значения
| Тип |
enumeration |
Значение по умолчанию |
InnoDB |
Механизм хранения по умолчанию для таблиц TEMPORARY
(создаваемых с CREATE TEMPORARY
TABLE ). Чтобы установить механизм хранения для постоянных таблиц,
установите
default_storage_engine . Также см. обсуждение той переменной
относительно возможных значений.
-
default_week_format
Формат командной строки
| --default_week_format=# |
Системная переменная
| Имя |
default_week_format |
Область действия |
Глобальная, Сеансовая |
Динамическая |
Да |
Допустимые значения
| Тип |
integer |
Значение по умолчанию |
0 |
Минимум |
0 |
Максимум |
7 |
Значение режима по умолчанию, чтобы использовать для функции
WEEK() , см.
раздел 13.7.
-
delay_key_write
Формат командной строки
| --delay-key-write[=name] |
Системная переменная
| Имя |
delay_key_write |
Область действия |
Глобальная |
Динамическая |
Да |
Допустимые значения
| Тип |
enumeration |
Значение по умолчанию |
ON |
Допустимые значения |
ON |
OFF |
ALL |
Эта опция применяется только к MyISAM .
У этого может быть одно из следующих значений, чтобы затронуть обработку
опции DELAY_KEY_WRITE таблицы, которая может использоваться в
CREATE TABLE .
Опция | Описание |
OFF |
DELAY_KEY_WRITE игнорируется. |
ON |
MySQL использует любую опцию DELAY_KEY_WRITE , определенную в
CREATE TABLE .
Это значение по умолчанию. |
ALL |
Все новые открытые таблицы обработаны, как будто они создавались с
включенной опцией DELAY_KEY_WRITE . |
Если DELAY_KEY_WRITE включен для таблицы, ключевой буфер не
сбрасывается для таблицы на каждом обновлении индекса, а только когда таблица
закрыта. Это убыстряет запись большого числа ключей, но если Вы используете
эту функцию, Вы должны добавить автоматическую проверку всех таблиц
MyISAM , запуская сервер с
--myisam-recover-options (например,
--myisam-recover-options=BACKUP,FORCE ).
См. разделы 6.1.4 и
17.2.1.
Если Вы включаете внешнюю блокировку с
--external-locking , нет никакой защиты от повреждения индекса для
таблиц, которые используют отсроченную запись ключа.
delayed_insert_limit
Устарела |
5.6.7 |
Формат командной строки
| --delayed_insert_limit=# |
Системная переменная
| Имя |
delayed_insert_limit |
Область действия |
Глобальная |
Динамическая |
Да |
Допустимые значения
(32-bit platforms) | Тип |
integer |
Значение по умолчанию |
100 |
Минимум |
1 |
Максимум |
4294967295 |
Допустимые значения
(64-bit platforms) | Тип |
integer |
Значение по умолчанию |
100 |
Минимум |
1 |
Максимум |
18446744073709551615 |
Эта системная переменная устарела (потому что DELAYED вставки
уже не поддержаны) и будет удалена в будущем выпуске.
-
delayed_insert_timeout
Устарела |
5.6.7 |
Формат командной строки
| --delayed_insert_timeout=# |
Системная переменная
| Имя |
delayed_insert_timeout |
Область действия |
Глобальная |
Динамическая |
Да |
Допустимые значения
| Тип |
integer |
Значение по умолчанию |
300 |
Эта системная переменная устарела (потому что DELAYED вставки
уже не поддержаны) и будет удалена в будущем выпуске.
-
delayed_queue_size
Устарела |
5.6.7 |
Формат командной строки
| --delayed_queue_size=# |
Системная переменная
| Имя |
delayed_queue_size |
Область действия |
Глобальная |
Динамическая |
Да |
Допустимые значения
(32-bit platforms) | Тип |
integer |
Значение по умолчанию |
1000 |
Минимум |
1 |
Максимум |
4294967295 |
Допустимые значения
(64-bit platforms) | Тип |
integer |
Значение по умолчанию |
1000 |
Минимум |
1 |
Максимум |
18446744073709551615 |
Эта системная переменная устарела (потому что DELAYED вставки
уже не поддержаны) и будет удалена в будущем выпуске.
-
disabled_storage_engines
Формат командной строки
| --disabled_storage_engines=engine[,
engine]... |
Системная переменная
| Имя |
disabled_storage_engines |
Область действия |
Глобальная |
Динамическая |
Нет |
Допустимые значения
| Тип |
string |
Значение по умолчанию |
empty string |
Эта переменная указывает, какие механизмы хранения не могут
использоваться, чтобы составить таблицы или табличные пространства. Например,
чтобы предотвратить создание новых таблиц
MyISAM или FEDERATED ,
запустите сервер с этими строками в файле параметра сервера:
[mysqld]
disabled_storage_engines="MyISAM,FEDERATED"
По умолчанию
disabled_storage_engines пуста (никакие механизмы не отключены),
но это может быть установлено в список разделенных запятой значений из одного
или более механизмов (не чувствительный к регистру). Любой механизм,
названный в значении, не может использоваться, чтобы составить таблицы или
табличные пространства с CREATE
TABLE или CREATE
TABLESPACE и не может использоваться с
ALTER TABLE ... ENGINE или
ALTER TABLESPACE ... ENGINE , чтобы
изменить механизм хранения существующих таблиц или табличных пространств.
Попытки сделать это приведут к ошибке
ER_DISABLED_STORAGE_ENGINE .
disabled_storage_engines не ограничивает другие запросы DDL для
существующих таблиц, например,
CREATE INDEX ,
TRUNCATE TABLE ,
ANALYZE TABLE ,
DROP TABLE или
DROP TABLESPACE .
Это разрешает гладкий переход так, чтобы существующие таблицы или табличные
пространства, которые используют отключенный механизм, могли мигрировать к
разрешенному механизму средствами ALTER
TABLE ... ENGINE permitted_engine .
Разрешено установить
default_storage_engine или
default_tmp_storage_engine к механизму хранения, который отключен.
Это может заставить приложения вести себя беспорядочно или терпеть неудачу,
хотя это могло бы быть полезным методом в среде проектирования для того,
чтобы идентифицировать приложения, которые используют отключенные механизмы,
так, чтобы они могли быть изменены.
disabled_storage_engines отключен и не имеет никакого эффекта,
если сервер запущен с какой-либо из этих опций: --initialize ,
--initialize-insecure , --skip-grant-tables .
-
disconnect_on_expired_password
Формат командной строки
| --disconnect_on_expired_password[=#]
|
Системная переменная
| Имя |
disconnect_on_expired_password |
Область действия |
Сеансовая |
Динамическая |
Нет |
Допустимые значения
| Тип |
boolean |
Значение по умолчанию |
ON |
Эта переменная управляет, как сервер обрабатывает клиентов с
паролями с истекшим сроком:
Если клиент указывает, что он может обработать истекший пароль,
значение
disconnect_on_expired_password не важно. Сервер разрешает клиенту
соединяться, но помещает его в режим песочницы.
- Если клиент не указывает, что это может обработать истекший пароль,
сервер обрабатывает клиента согласно значению
disconnect_on_expired_password :
См. раздел 7.3.8
.
-
div_precision_increment
Формат командной строки
| --div_precision_increment=# |
Системная переменная
| Имя |
div_precision_increment |
Область действия |
Глобальная, Сеансовая |
Динамическая |
Да |
Допустимые значения
| Тип |
integer |
Значение по умолчанию |
4 |
Минимум |
0 |
Максимум |
30 |
Эта переменная указывает на число цифр, которыми можно увеличить масштаб
результата операций разделения, выполненных с оператором
/ .
Значение по умолчанию 4. Минимальные и максимальные значения 0 и 30,
соответственно. Следующий пример иллюстрирует эффект увеличения
значения по умолчанию.
mysql> SELECT 1/7;
+--------+
| 1/7 |
+--------+
| 0.1429 |
+--------+
mysql> SET div_precision_increment = 12;
mysql> SELECT 1/7;
+----------------+
| 1/7 |
+----------------+
| 0.142857142857 |
+----------------+
-
end_markers_in_json
Системная переменная
| Имя |
end_markers_in_json |
Область действия |
Глобальная, Сеансовая |
Динамическая |
Да |
Допустимые значения
| Тип |
boolean |
Значение по умолчанию |
OFF |
Должен ли оптимизатор JSON добавить маркеры конца.
-
eq_range_index_dive_limit
Системная переменная
| Имя |
eq_range_index_dive_limit |
Область действия |
Глобальная, Сеансовая |
Динамическая |
Да |
Допустимые значения
| Тип |
integer |
Значение по умолчанию |
200 |
Минимум |
0 |
Максимум |
4294967295 |
Эта переменная указывает на число диапазонов равенства в условии сравнения
равенства, когда оптимизатор должен переключиться с использования индексного
погружения на индексную статистику в оценке числа готовящихся строк. Это
относится к оценке выражений, у которых есть любая из этих эквивалентных
форм, где оптимизатор использует групповой индекс, чтобы искать
значения col_name :
col_name IN(val1 , ..., valN )
col_name = val1 OR ... OR
col_name = valN
В обоих случаях выражение содержит N
диапазонов равенства. Оптимизатор может заставить оценку строки
использовать индексные погружения или индексную статистику. Если
eq_range_index_dive_limit больше 0, оптимизатор
использует существующую индексную статистику вместо индексного погружения,
если есть
eq_range_index_dive_limit или больше диапазонов равенства. Таким
образом, чтобы разрешить использование индексное погружение для до
N диапазонов равенства, установите
eq_range_index_dive_limit в N +1.
Чтобы отключить использование индексной статистики и всегда использовать
индексное погружение независимо от N , установите
eq_range_index_dive_limit в 0.
См. раздел 9.2.1.3.3
.
Чтобы обновить индексную статистику таблицы
для наилучших оценок, используют
ANALYZE TABLE .
-
error_count
Число ошибок, которые следовали из последнего запроса, который произвел
сообщения. Эта переменная только для чтения. См.
раздел 14.7.5.17.
-
event_scheduler
Формат командной строки
| --event-scheduler[=value] |
Системная переменная
| Имя |
event_scheduler |
Область действия |
Глобальная |
Динамическая |
Да |
Допустимые значения
| Тип |
enumeration |
Значение по умолчанию |
OFF |
Допустимые значения |
ON |
OFF |
DISABLED |
Эта переменная указывает на состояние Event Scheduler:
возможные значения ON , OFF и DISABLED ,
по умолчанию OFF . Эта переменная и ее эффекты на работу Event
Scheduler обсуждены более подробно
здесь.
-
expire_logs_days
Формат командной строки
| --expire_logs_days=# |
Системная переменная
| Имя |
expire_logs_days |
Область действия |
Глобальная |
Динамическая |
Да |
Допустимые значения
| Тип |
integer |
Значение по умолчанию |
0 |
Минимум |
0 |
Максимум |
99 |
Число дней для автоматического удаления двоичного файла системного
журнала. Значение по умолчанию 0, что означает, что
никакого автоматического удаления нет.
Возможные удаления происходят при запуске и когда двоичный журнал
сбрасывается. Сброс журнала происходит как обозначено в
разделе 6.4.
Чтобы удалить двоичные файлы системного журнала вручную, используйте
PURGE BINARY LOGS , см.
раздел 14.4.1.1.
-
explicit_defaults_for_timestamp
Устарела |
5.6.6 |
Формат командной строки
| --explicit_defaults_for_timestamp=#
|
Системная переменная
| Имя |
explicit_defaults_for_timestamp |
Область действия |
Глобальная, Сеансовая |
Динамическая |
Нет |
Допустимые значения
| Тип |
boolean |
Значение по умолчанию |
FALSE |
В MySQL тип данных TIMESTAMP
отличается нестандартными способами от других типов данных:
Столбцам TIMESTAMP ,
не объявленным явно с NULL , назначен признак NOT NULL
. Столбцы других типов данных, если не объявлены явно как
NOT NULL , допускают значения NULL . Установка такого
столбца к NULL установит это к текущему timestamp.
- Первый столбец
TIMESTAMP
в таблице, если не объявлен с NULL или явным параметром
DEFAULT или ON UPDATE , автоматически назначен
как DEFAULT CURRENT_TIMESTAMP и
ON UPDATE CURRENT_TIMESTAMP .
- Cтолбцы
TIMESTAMP
после первого, если не объявлены с NULL или явным
DEFAULT , автоматически назначены
DEFAULT '0000-00-00 00:00:00'
(нулевой timestamp).
Для вставленных строк, которые не определяют явного значения для такого
столбца, назначено '0000-00-00 00:00:00' , но
никакого предупреждения не происходит.
Эти нестандартные поведения остаются значением по умолчанию для
TIMESTAMP , но с MySQL 5.6.6
устарели, и это предупреждение появляется при запуске:
[Warning] TIMESTAMP with implicit DEFAULT value is deprecated.
Please use --explicit_defaults_for_timestamp server option (see
documentation for more details).
Как обозначено предупреждением, чтобы выключить нестандартные поведения,
включают
explicit_defaults_for_timestamp при запуске сервера. С этой
включенной переменной, сервер обрабатывает
TIMESTAMP следующим образом вместо этого:
Столбцы TIMESTAMP ,
не объявленные явно как NOT NULL могут быть NULL .
Установка такого столбца к NULL , установит его именно к
NULL , а не к текущему timestamp.
- Нет столбцов
TIMESTAMP ,
которым назначено DEFAULT CURRENT_TIMESTAMP или
ON UPDATE CURRENT_TIMESTAMP автоматически. Эти признаки должны
быть явно определены.
- Столбцы
TIMESTAMP ,
объявленные как NOT NULL и без явного DEFAULT
обработаны как не имеющие значения по умолчанию. Для вставленных строк,
которые не определяют явного значения для такого столбца, результат зависит
от режима SQL. Если строгий режим SQL включен, ошибка происходит. Если
строгий режим SQL не включен, столбцу назначают неявное значение по умолчанию
'0000-00-00 00:00:00' и предупреждение происходит. Это подобно
тому, как MySQL обрабатывает другие временные типы, например,
DATETIME .
explicit_defaults_for_timestamp
самостоятельно устарела, потому что ее единственная цель состоит в том, чтобы
разрешить управление устаревшей логикой
TIMESTAMP , которая будет
удалена в будущем выпуске MySQL. Когда это удаление произойдет,
explicit_defaults_for_timestamp не будет иметь никакой цели и
будет удалена также.
external_user
Системная переменная
| Имя |
external_user
|
Область действия |
Сеансовая |
Динамическая |
Нет |
Допустимые значения |
Тип |
string |
Внешнее имя пользователя, используемое во время процесса аутентификации,
как установлено плагином, чтобы подтверждать подлинность клиента.
С родной (встроенной) аутентификацией MySQL, или если плагин не устанавливает
значение, эта переменная NULL . См.
раздел 7.3.10.
-
flush
Формат командной строки
| --flush |
Системная переменная
| Имя |
flush |
Область действия |
Глобальная |
Динамическая |
Да |
Допустимые значения
| Тип |
boolean |
Значение по умолчанию |
OFF |
Если ON , сервер сбрасывает все изменения на диск после
каждого запроса SQL. Обычно MySQL делает запись всех изменений диска только
после каждого запроса SQL и позволяет операционной системе обрабатывать
синхронизацию с диском. См. раздел B.5.3.3.
Эта переменная установлена в ON если Вы запускаете
mysqld с
опцией --flush .
-
flush_time
Формат командной строки
| --flush_time=# |
Системная переменная
| Имя |
flush_time
|
Область действия |
Глобальная |
Динамическая |
Да |
Допустимые значения
| Тип |
integer |
Значение по умолчанию |
0 |
Минимум |
0 |
Допустимые значения
(Windows) | Тип |
integer |
Значение по умолчанию |
0 |
Минимум |
0 |
Если это установлено в ненулевое значение, все таблицы закрыты каждые
flush_time секунд,
чтобы освободить ресурсы и синхронизировать данные с диском. Эта опция лучше
всего используется только на системах с минимальными ресурсами.
-
foreign_key_checks
Если установлено в 1 (значение по умолчанию), ограничения внешнего ключа
для InnoDB проверены. Если установлено в 0, ограничения внешнего
ключа проигнорированы, с несколькими исключениями. Обновляя таблицу, которая
была удалена, ошибка возвращена, если табличное определение не соответствует
ограничениям внешнего ключа, ссылающимся на таблицу. Аналогично,
ALTER TABLE
возвращает ошибку, если определение внешнего ключа неправильно сформировано.
Для получения дополнительной информации см.
раздел 14.1.15.3.
Как правило, эта установка включена во время нормального функционирования,
чтобы провести в жизнь
ссылочную целостность.
Отключение проверки внешнего ключа может быть полезным для перезагрузки
таблиц InnoDB в порядке, отличающемся от требуемого их
родительскими/дочерними отношениями. См.
раздел 16.8.6.
Установка foreign_key_checks в 0 также влияет на запросы
определения данных: DROP SCHEMA
удаляет схему, даже если это содержит таблицы, у которых есть внешние
ключи, которые упомянуты таблицами вне схемы, и
DROP TABLE удаляет таблицы, у которых есть внешние ключи,
которые упомянуты другими таблицами.
Установка foreign_key_checks в 1 не вызывает просмотр
существующих табличных данных. Поэтому, строки, добавленные к таблице в то
время, как
foreign_key_checks = 0 не будут проверены для последовательности.
Удаление индексирования необходимого ограничением внешнего ключа не
разрешено, даже с
foreign_key_checks=0 . Ограничение внешнего ключа должно быть
удалено прежде, чем удалить индексирование.
ft_boolean_syntax
Формат командной строки
| --ft_boolean_syntax=name |
Системная переменная
| Имя |
ft_boolean_syntax |
Область действия |
Глобальная |
Динамическая |
Да |
Допустимые значения
| Тип |
string |
Значение по умолчанию |
+ -><()~*:""&| |
Список операторов, поддержанных булевыми полнотекстовыми поисками,
выполненными, используя IN BOOLEAN MODE . См.
раздел 13.9.2.
Значение переменной по умолчанию
'+ -><()~*:""&|' .
Правила для того, чтобы изменить значение следующие:
ft_max_word_len
Формат командной строки
| --ft_max_word_len=# |
Системная переменная
| Имя |
ft_max_word_len |
Область действия |
Глобальная |
Динамическая |
Нет |
Допустимые значения
| Тип |
integer |
Минимум |
10 |
Максимальная длина слова, которое будет включено в
индекс MyISAM FULLTEXT .
Индексы FULLTEXT на MyISAM
должны быть пересозданы после изменения этой переменной. Используйте
REPAIR TABLE tbl_name QUICK .
ft_min_word_len
Формат командной строки
| --ft_min_word_len=# |
Системная переменная
| Имя |
ft_min_word_len |
Область действия |
Глобальная |
Динамическая |
Нет |
Допустимые значения
| Тип |
integer |
Значение по умолчанию |
4 |
Минимум |
1 |
Минимальная длина слова, которое будет включено в
индекс MyISAM FULLTEXT .
Индексы FULLTEXT на MyISAM должны быть
пересозданы после изменения этой переменной. Используйте
REPAIR TABLE tbl_name QUICK .
ft_query_expansion_limit
Формат командной строки
| --ft_query_expansion_limit=# |
Системная переменная
| Имя |
ft_query_expansion_limit |
Область действия |
Глобальная |
Динамическая |
Нет |
Допустимые значения
| Тип |
integer |
Значение по умолчанию |
20 |
Минимум |
0 |
Максимум |
1000 |
Число главных соответствий, чтобы использовать для полнотекстовых поисков,
выполненных, используя WITH QUERY EXPANSION .
-
ft_stopword_file
Формат командной строки
| --ft_stopword_file=file_name
|
Системная переменная
| Имя |
ft_stopword_file |
Область действия |
Глобальная |
Динамическая |
Нет |
Допустимые значения |
Тип |
file name |
Файл, из которого можно считать список стоп-слов
для полнотекстовых поисков на MyISAM .
Сервер ищет файл в каталоге данных, если абсолютный путь не дан, чтобы
определить иной каталог. Все слова из файла используются, комментарии
не позволены. По умолчанию, встроенный список
стоп-слов используется (как определено в файле
storage/myisam/ft_static.c ).
Установка этой переменной к пустой строке ('' )
отключает фильтрацию стоп-слов. См.
раздел 13.9.4.
Индексы FULLTEXT на MyISAM должны быть
пересозданы после изменения этой переменной или содержимого файла стоп-слов.
Используйте REPAIR TABLE tbl_name QUICK .
general_log
Формат командной строки
| --general-log |
Системная переменная
| Имя |
general_log
|
Область действия |
Глобальная |
Динамическая |
Да |
Допустимые значения
| Тип |
boolean |
Значение по умолчанию |
OFF |
Включен ли общий журнал запроса. Значение может быть 0 (или
OFF ), чтобы отключить журнал, или 1 (или ON ), чтобы
включить журнал. Значение по умолчанию зависит от опции
--general_log .
Местом назначения для вывода журнала управляет
log_output :
если это значение NONE , никакие записи журнала не написаны, даже
если журнал включен.
-
general_log_file
Формат командной строки
| --general-log-file=file_name
|
Системная переменная
| Имя |
general_log_file |
Область действия |
Глобальная |
Динамическая |
Да |
Допустимые значения
| Тип |
file name |
Значение по умолчанию |
host_name.log |
Название общего файла системного журнала запроса. Значение по умолчанию
host_name .log , но начальное значение может
быть изменено с
--general_log_file .
-
group_concat_max_len
Формат командной строки
| --group_concat_max_len=# |
Системная переменная
| Имя |
group_concat_max_len |
Область действия |
Глобальная, Сеансовая |
Динамическая |
Да |
Допустимые значения
(32-bit platforms) | Тип |
integer |
Значение по умолчанию |
1024 |
Минимум |
4 |
Максимум |
4294967295 |
Допустимые значения
(64-bit platforms) | Тип |
integer |
Значение по умолчанию |
1024 |
Минимум |
4 |
Максимум |
18446744073709551615 |
Максимальная разрешенная длина результата в байтах для функции
GROUP_CONCAT() .
Значение по умолчанию 1024.
-
have_compress
YES , если библиотека сжатия zlib
доступна серверу, NO если нет. Если нет, функции
COMPRESS() и
UNCOMPRESS()
не могут использоваться.
-
have_crypt
YES , если системный вызов crypt()
доступен серверу, NO если нет. Если нет, функция
ENCRYPT()
не может использоваться.
-
have_dynamic_loading
YES , если mysqld
поддерживает динамическую загрузку плагинов,
NO если нет. Если значение NO , Вы не можете
использовать такие опции, как --plugin-load , чтобы
загрузить плагины при запуске сервера, или
INSTALL PLUGIN , чтобы
загрузить плагины во время выполнения.
-
have_geometry
YES , если сервер поддерживает пространственные типы данных,
NO , если нет.
-
have_openssl
Псевдоним для have_ssl
.
-
have_profiling
YES , если профилирование запросов доступно. NO ,
если нет. Если есть, переменная profiling управляет, включена ли
эта способность или отключена. См.
раздел 14.7.5.31.
Эта переменная устарела и будет удалена в будущем выпуске MySQL.
-
have_query_cache
YES , если mysqld
поддерживает кэш запроса, NO , если нет.
-
have_rtree_keys
YES , если доступны индексы RTREE ,
NO , если нет. Они используются для
пространственных индексов в MyISAM .
-
have_ssl
YES , если
mysqld поддерживает соединения SSL, NO ,
если нет. DISABLED указывает, что сервер был собран с поддержкой
SSL, но не был запущен с соответствующими опциями
--ssl-xxx . См.
раздел 7.4.2
.
-
have_statement_timeout
Системная переменная
| Имя |
have_statement_timeout |
Область действия |
Глобальная |
Динамическая |
Нет |
Допустимые значения |
Тип |
boolean |
Доступна ли особенность тайм-аута выполнения запроса (см.
здесь).
Значение может быть NO , если фоновый поток, используемый этой
особенностью, не мог быть инициализирован.
-
have_symlink
YES , если поддержка символической ссылки включена,
NO , если нет. Это требуется в Unix для поддержки
табличных опций DATA DIRECTORY и INDEX DIRECTORY .
Если сервер запущен с
--skip-symbolic-links , значение DISABLED .
У этой переменной нет никакого значения в Windows.
-
host_cache_size
Системная переменная
| Имя |
host_cache_size |
Область действия |
Глобальная |
Динамическая |
Да |
Допустимые значения
| Тип |
integer |
Значение по умолчанию |
-1 (autosized) |
Минимум |
0 |
Максимум |
65536 |
Размер внутреннего кэша узла (см.
раздел 9.12.4.2).
Установка размера в 0 отключает кэш узла. Изменение размера кэша во время
выполнения неявно вызывает FLUSH HOSTS
, чтобы очистить кэш узла и усечь таблицу
host_cache .
Значение по умолчанию 128, плюс 1 для значения
max_connections
до 500, плюс 1 для каждого увеличения на 20 больше 500 в
max_connections
до верхнего предела в 2000.
Используйте
--skip-host-cache подобно установке
host_cache_size
в 0, но host_cache_size
более гибко, потому что это может также использоваться, чтобы
изменить размеры, включить или отключить кэш узла во время выполнения, не
только при запуске сервера.
Если Вы запускаете сервер с
--skip-host-cache
, это не предотвращает изменения значения
host_cache_size ,
но такие изменения не имеют никакого эффекта, и кэш не включен повторно, даже
если
host_cache_size больше 0.
-
hostname
Системная переменная
| Имя |
hostname
|
Область действия |
Глобальная |
Динамическая |
Нет |
Допустимые значения |
Тип |
string |
Сервер устанавливает эту переменную в имя хоста сервера при запуске.
-
identity
Эта переменная синоним для
last_insert_id .
Это существует для совместимости с другими системами базы данных. Вы можете
считать значение с SELECT @@identity и установить
как SET identity .
-
init_connect
Формат командной строки
| --init-connect=name |
Системная переменная
| Имя |
init_connect
|
Область действия |
Глобальная |
Динамическая |
Да |
Допустимые значения |
Тип |
string |
Строка, которая будет выполнена сервером для каждого клиента, который
соединяется. Строка состоит из одного или более запросов SQL, отделенных
символами точки с запятой. Например, каждый сеанс клиента начинается по
умолчанию с включенным режимом autocommit. Для более старых серверов (до
MySQL 5.5.8) нет глобальной переменной
autocommit , чтобы
определить, что autocommit должен быть отключен по умолчанию, но как обходное
решение init_connect
может использоваться, чтобы достигнуть того же самого эффекта:
SET GLOBAL init_connect='SET autocommit=0';
init_connect
может также быть установлена в командной строке или в файле опции. Чтобы
установить переменную как только что показано с использованием файла опции,
включайте эти строки:
[mysqld]
init_connect='SET autocommit=0'
Содержимое init_connect
не выполнено для пользователей, которые имеют привилегию
SUPER .
Это сделано, чтобы ошибочное значение для
init_connect
не препятствовало тому, чтобы клиенты соединились. Например, значение могло
бы содержать запрос, у которого есть синтаксическая ошибка, таким образом
заставляя соединения клиента потерпеть неудачу. Невыполнение
init_connect
для пользователей, которые имеют привилегию
SUPER
позволяет им открыть соединение и установить значение
init_connect .
Сервер отказывается от любых наборов результатов, произведенных запросами
в значении init_connect
.
-
information_schema_stats
Формат командной строки
| --information_schema_stats=value |
Системная переменная
| Имя |
information_schema_stats |
Область действия |
Глобальная, Сеансовая |
Динамическая |
Да |
Допустимые значения
| Тип |
enumeration |
Значение по умолчанию |
CACHED |
Допустимые значения |
CACHED |
LATEST |
Некоторые таблицы в INFORMATION_SCHEMA содержат столбцы,
которые обеспечивают табличную статистику:
STATISTICS.CARDINALITY
TABLES.AUTO_INCREMENT
TABLES.AVG_ROW_LENGTH
TABLES.CHECKSUM
TABLES.CHECK_TIME
TABLES.CREATE_TIME
TABLES.DATA_FREE
TABLES.DATA_LENGTH
TABLES.INDEX_LENGTH
TABLES.MAX_DATA_LENGTH
TABLES.TABLE_ROWS
TABLES.UPDATE_TIME
Эти столбцы представляют динамические табличные метаданные, то есть,
информация, которая изменяется как табличное содержание.
information_schema_stats определяет источник, из которого сервер
получает табличную статистику:
CACHED (значение по умолчанию), сервер получает
статистику из таблиц INFORMATION_SCHEMA , которые содержат
кэшируемые значения (STATISTICS и TABLES ).
Когда сервер запускается, кэшируемые статистические данные NULL .
Чтобы обновить кэшируемые значения для данной таблицы, надо использовать
ANALYZE TABLE .
LATEST сервер читает статистику непосредственно из
механизмов хранения. В этом случае сервер заменяет ссылки в запросах к
таблицам STATISTICS и TABLES
именами, у которых есть суффикс _DYNAMIC
(STATISTICS_DYNAMIC и TABLES_DYNAMIC ).
Сервер выполняет эту замену внутренне: Вы должны написать запросы,
используя имя таблицы без _DYNAMIC . Например, когда
information_schema_stats = LATEST ,
сервер обрабатывает этот запрос:
SELECT * FROM INFORMATION_SCHEMA.TABLES;
как если бы Вы написали этот запрос:
SELECT * FROM INFORMATION_SCHEMA.TABLES_DYNAMIC;
information_schema_stats также влияет на запросы
SHOW , которые осуществлены как
запросы к таблицам INFORMATION_SCHEMA .
Для предыдущего примера соответствующий запрос это
SHOW
SHOW TABLES ,
и сервер читает таблицы TABLES
или TABLES_DYNAMIC ,
в зависимости от
information_schema_stats .
См. раздел 9.2.4
.
-
init_file
Формат командной строки
| --init-file=file_name |
Системная переменная
| Имя |
init_file
|
Область действия |
Глобальная |
Динамическая |
Нет |
Допустимые значения |
Тип |
file name |
Название файла, определенного
--init-file , когда Вы запускаете сервер. Это должно быть
файлом, содержащим запросы SQL, которые Вы хотите, чтобы сервер выполнил,
когда он запускается. Каждый запрос должен быть на одной строке и не должен
включать комментарии. Для получения дополнительной информации см. описание
--init-file .
innodb_xxx
Системные переменные InnoDB
перечислены в раздел 16.13.
Эти переменные управляют многими аспектами хранения, использования памяти и
образцов ввода/вывода для таблиц InnoDB и особенно важны теперь,
когда InnoDB механизм хранения по умолчанию.
-
insert_id
Значение, которое будет использоваться следующим
INSERT или
ALTER TABLE , вставляя
значение AUTO_INCREMENT . Это, главным образом,
используется с двоичным журналом.
-
interactive_timeout
Формат командной строки
| --interactive_timeout=# |
Системная переменная
| Имя |
interactive_timeout |
Область действия |
Глобальная, Сеансовая |
Динамическая |
Да |
Допустимые значения
| Тип |
integer |
Значение по умолчанию |
28800 |
Минимум |
1 |
Число секунд, которое сервер ждет деятельности по интерактивному
соединению прежде, чем закрыть это. Интерактивный клиент определен как
клиент, который использует опцию CLIENT_INTERACTIVE в
mysql_real_connect()
. См. wait_timeout
.
-
internal_tmp_disk_storage_engine
Формат командной строки
| --internal_tmp_disk_storage_engine=#
|
Системная переменная
| Имя |
internal_tmp_disk_storage_engine
|
Область действия |
Глобальная |
Динамическая |
Да |
Допустимые значения
| Тип |
enumeration |
Значение по умолчанию |
INNODB |
Допустимые значения |
MYISAM |
INNODB |
Механизм хранения для внутренних временных таблиц на диске (см.
раздел 9.4.4).
Разрешенные значения MYISAM и INNODB
(значение по умолчанию).
Если
internal_tmp_disk_storage_engine=INNODB ,
запросы, которые производят временные таблицы, которые превышают
пределы столбца или строки
InnoDB вернут ошибку Row size too large или
Too many columns. Обходное решение должно установить
internal_tmp_disk_storage_engine в MYISAM .
-
join_buffer_size
Формат командной строки
| --join_buffer_size=# |
Системная переменная
| Имя |
join_buffer_size |
Область действия |
Глобальная, Сеансовая |
Динамическая |
Да |
Допустимые значения
(32-bit platforms) | Тип |
integer |
Значение по умолчанию |
131072 |
Минимум |
128 |
Максимум |
4294967295 |
Допустимые значения
(64-bit platforms) | Тип |
integer |
Значение по умолчанию |
131072 |
Минимум |
128 |
Максимум |
18446744073709547520 |
Допустимые значения
(Windows) | Тип |
integer |
Значение по умолчанию |
262144 |
Минимум |
128 |
Максимум |
4294967295 |
Допустимые значения
(Other, 32-bit platforms) | Тип
| integer |
Значение по умолчанию |
262144 |
Минимум |
128 |
Максимум |
4294967295 |
Допустимые значения
(Other, 64-bit platforms) | Тип
| integer |
Значение по умолчанию |
262144 |
Минимум |
128 |
Максимум |
18446744073709547520 |
Минимальный размер буфера, который используется для
индексных просмотров, диапазона индексных просмотров и соединений, которые не
используют индексы, и таким образом выполняют полное сканирование таблицы.
Обычно лучший способ получить быстрые соединения состоит в том, чтобы
добавить индекс. Увеличьте значение
join_buffer_size
, чтобы получить более быстрое полное соединение, когда добавление
индекса невозможно. Один буфер соединения выделен для каждого полного
соединения между двумя таблицами. Для сложного соединения между несколькими
таблицами, для которых индекс не используются, многие буферы соединения могли
бы быть необходимы.
Если не используется Batched Key Access (BKA),
нет никакой выгоды от установки более крупного буфера, чем необходимый, чтобы
держать каждую строку соответствия, и все соединения выделяют, по крайней
мере, минимальный размер, так что проявите осмотрительность в установке этой
переменной к большому значению глобально. Лучше сохранить глобальную
установку маленькой и изменить на большую установку только в сеансах, которые
делают большие соединения. Время распределения памяти может вызвать
существенные исполнительные задержки, если глобальный размер больше, чем
необходимый большинству запросов, которые используют это.
Когда используется BKA, значение
join_buffer_size
определяет, насколько большой пакет ключей находится в каждом запросе к
механизму хранения. Чем больше буфер, тем более последовательный доступ будет
к правой таблице соединения, что может значительно улучшить работу.
Значение по умолчанию составляет 256 КБ. Максимальная допустимая установка
для join_buffer_size
4GB-1. Большие значения разрешены для 64-битовых платформ (кроме
64-битной Windows, для которой большие значения
являются усеченными к 4GB-1 с предупреждением).
См. разделы 9.2.1.10 и
9.2.1.14.
-
keep_files_on_create
Формат командной строки
| --keep_files_on_create=# |
Системная переменная
| Имя |
keep_files_on_create |
Область действия |
Глобальная, Сеансовая |
Динамическая |
Да |
Допустимые значения
| Тип |
boolean |
Значение по умолчанию |
OFF |
Если таблица MyISAM составлена без опции
DATA DIRECTORY , файл .MYD
создается в каталоге базы данных. По умолчанию если MyISAM
находит существующий файл .MYD , он его перезаписывает.
То же самое относится к файлам .MYI
для таблиц, составленных без опции INDEX DIRECTORY .
Чтобы подавить это поведение, установите
keep_files_on_create
в ON (1), тогда MyISAM не будет
перезаписывать существующие файлы и возвращает ошибку вместо этого. Значение
по умолчанию OFF (0).
Если таблица MyISAM создана с опцией
DATA DIRECTORY или INDEX DIRECTORY и существующий
файл .MYD или .MYI найден, MyISAM всегда возвращает
ошибку. Это не будет перезаписывать файл в указанном каталоге.
-
key_buffer_size
Формат командной строки
| --key_buffer_size=# |
Системная переменная
| Имя |
key_buffer_size |
Область действия |
Глобальная |
Динамическая |
Да |
Допустимые значения
(32-bit platforms) | Тип |
integer |
Значение по умолчанию |
8388608 |
Минимум |
8 |
Максимум |
4294967295 |
Допустимые значения
(64-bit platforms) | Тип |
integer |
Значение по умолчанию |
8388608 |
Минимум |
8 |
Максимум |
OS_PER_PROCESS_LIMIT |
Индексные блоки для таблицы MyISAM буферизованы и совместно
использованы всеми потоками.
key_buffer_size это размер буфера, используемого для
индексных блоков. Ключевой буфер также известен как ключевой кэш.
Максимальная допустимая установка для
key_buffer_size
4GB-1 на 32-битовых платформах. Большие значения разрешены для 64-битовых
платформ. Эффективный максимальный размер мог бы быть меньше, в зависимости
от Вашей доступной физической RAM и пределов RAM на процесс, наложенных Вашей
операционной системой или платформой аппаратных средств. Значение этой
переменной указывает на объем памяти, который требуют. Внутренне сервер
выделяет такую большую память насколько возможно до этого количества, но
фактическое распределение могло бы быть меньше.
Вы можете увеличить значение, чтобы поправить индексную
обработку для всех чтений и многократных записей,
на системе, первичная функция которой должна выполнить MySQL, используя
MyISAM ,
25% полной памяти машины это приемлемое значение для этой переменной. Однако,
Вы должны знать, что, если Вы делаете значение слишком большим (например,
больше 50% полной памяти машины), Ваша система могла бы начать своп страниц
и становиться чрезвычайно медленной. Это потому, что MySQL полагается на
операционную систему, чтобы выполнить кэширование для чтений данных,
таким образом, Вы должны оставить некоторое место для кэша файловой системы.
Вы должны также рассмотреть требования к памяти любых других механизмов
хранения, которые Вы можете использовать в дополнение к
MyISAM .
Для большей скорости при записи многих строк в то же самое время, надо
использовать LOCK TABLES . См.
раздел 9.2.2.1.
Вы можете проверить исполнение ключевого буфера через
SHOW STATUS с просмотром
переменных
Key_read_requests ,
Key_reads ,
Key_write_requests
и Key_writes
. См. раздел 14.7.5. Отношение
Key_reads/Key_read_requests должно обычно быть меньше 0.01.
Отношение Key_writes/Key_write_requests
близко к 1, если Вы используете главным образом обновления и удаления, но
может быть намного меньшим, если Вы склонны делать обновления, которые
затрагивают много строк в то же самое время, или если Вы используете
табличную опцию DELAY_KEY_WRITE .
Фракция ключевого буфера в использовании может быть определена, используя
key_buffer_size
в соединении с
Key_blocks_unused и буферным размером блока, который доступен из
key_cache_block_size :
1 - ((Key_blocks_unused * key_cache_block_size) / key_buffer_size)
Это значение приблизительно, потому что некоторое место в ключевом буфере
выделено внутренне для административных структур. Факторы, которые влияют на
количество издержек для этих структур, включают размер указателя и размер
блока. Поскольку размер блока увеличивается, процент ключевого буфера,
имеет тенденцию уменьшаться. Большие блоки приводят к меньшему числу операций
чтения (потому что больше ключей получено за чтение), но наоборот увеличению
чтений ключей, которые не исследованы (если не все ключи в
блоке относятся к запросу).
Возможно создать многократные ключевые кэши MyISAM .
Предел размера 4GB относится к каждому кэшу индивидуально, не к группе. См.
раздел 9.10.2.
-
key_cache_age_threshold
Формат командной строки
| --key_cache_age_threshold=# |
Системная переменная
| Имя |
key_cache_age_threshold |
Область действия |
Глобальная |
Динамическая |
Да |
Допустимые значения
(32-bit platforms) | Тип |
integer |
Значение по умолчанию |
300 |
Минимум |
100 |
Максимум |
4294967295 |
Допустимые значения
(64-bit platforms) | Тип |
integer |
Значение по умолчанию |
300 |
Минимум |
100 |
Максимум |
18446744073709551615 |
Это значение управляет понижением буферов от горячего подсписка ключевого
кэша к теплому подсписку. Нижние значения заставляют понижение происходить
более быстро. Минимальное значение 100. Значение по умолчанию 300. См.
раздел 9.10.2.
-
key_cache_block_size
Формат командной строки
| --key_cache_block_size=# |
Системная переменная
| Имя |
key_cache_block_size |
Область действия |
Глобальная |
Динамическая |
Да |
Допустимые значения
| Тип |
integer |
Значение по умолчанию |
1024 |
Минимум |
512 |
Максимум |
16384 |
Размер в байтах блоков в ключевом кэше. Значение по умолчанию 1024. См.
value is 1024. See раздел 9.10.2.
-
key_cache_division_limit
Формат командной строки
| --key_cache_division_limit=#
|
Системная переменная
| Имя |
key_cache_division_limit |
Область действия |
Глобальная |
Динамическая |
Да |
Допустимые значения
| Тип |
integer |
Значение по умолчанию |
100 |
Минимум |
1 |
Максимум |
100 |
Пункт подразделения между горячими и теплыми подсписками ключевого кэша.
Значение задает процент буферного списка, чтобы использовать для теплого
подсписка. Допустимые значения колеблются от 1 до 100. Значение по умолчанию
100. См. раздел 9.10.2.
-
keyring_file_data
Формат командной строки
| --keyring_file_data=file_name
|
Системная переменная
| Имя |
keyring_file_data |
Область действия |
Глобальная |
Динамическая |
Да |
Допустимые значения
| Тип |
file name |
Значение по умолчанию |
platform specific |
Путь файла с данными, используемого для безопасного хранения данных
плагина keyring_file (см.
раздел 7.5.3).
Местоположение файла должно быть в каталоге, который рассматривает для
использования только плагин keyring_file .
Например, не определяйте местонахождение файла в каталоге данных.
Операции брелока являются транзакционными: плагин
keyring_file использует резервный файл во время записи, чтобы
гарантировать, что он может откатиться назад к оригинальному файлу, если
работа терпит неудачу. У резервного файла есть то же самое имя, как задано
keyring_file_data
с расширением .backup .
Не используйте тот же самый файл данных keyring_file
для многократных серверов MySQL. У каждого сервера должен быть свой
собственный уникальный файл с данными.
Имя файла по умолчанию keyring , расположенный в каталоге,
который определен платформой и зависит от значения опции
INSTALL_LAYOUT
в CMake, как показано в следующей таблице.
Чтобы определить каталог по умолчанию для файла явно, если Вы создаете пакет
из исходных текстов, используйте опцию
INSTALL_MYSQLKEYRINGDIR для CMake.
Значение INSTALL_LAYOUT |
Значение по умолчанию keyring_file_data |
DEB , RPM ,
SLES , SVR4 |
/var/lib/mysql-keyring/keyring |
Иначе | keyring/keyring в
CMAKE_INSTALL_PREFIX |
Если значение, назначенное
keyring_file_data
определяет файл, который не существует, плагин keyring_file
пытается создать это во время инициализации. В случае необходимости плагин
также создает каталог, в котором расположен файл.
Если Вы создаете каталог вручную, он должен иметь рестриктивный режим и
доступен только для учетной записи, используемой, чтобы выполнить сервер.
Например, на Unix, чтобы использовать
/usr/local/mysql/mysql-keyring/keyring ,
следующие команды (выполненные как root )
создают каталог и установят его режим и собственность:
shell> cd /usr/local/mysql
shell> mkdir mysql-keyring
shell> chmod 750 mysql-keyring
shell> chown mysql mysql-keyring
shell> chgrp mysql mysql-keyring
Если плагин keyring_file не может создать или получить доступ
к файлу, он пишет сообщение об ошибке в журнал ошибок. Если предпринятое
назначение во время выполнения
keyring_file_data приводит к ошибке, значение
переменной остается неизменным.
Когда плагин keyring_file создал файл с данными
keyring_file и начал использовать это, важно не удалить файл.
Например, InnoDB использует файл, чтобы сохранить главный ключ,
используемый, чтобы дешифровать данные в таблицах с шифрованием табличного
пространства, см. раздел
16.7.10. Потеря файла заставит данные в таких таблицах становиться
недоступными. Допустимо переименовать или переместить файл, пока Вы изменяете
значение
keyring_file_data соответственно.
Рекомендуется, чтобы Вы создали отдельную резервную копию файла
keyring немедленно после того, как Вы составляете первую
зашифрованную таблицу, а также после ротации главного ключа.
large_files_support
Был ли mysqld
собран с опциями для поддержки больших файлов.
-
large_pages
Формат командной строки
| --large-pages |
Системная переменная
| Имя |
large_pages
|
Область действия |
Глобальная |
Динамическая |
Нет |
Платформа |
Linux |
Допустимые значения
(Linux) | Тип |
boolean |
Значение по умолчанию |
FALSE |
Включена ли поддержка большой страницы (через опцию
--large-pages
). См. раздел 9.12.3.2.
-
large_page_size
Системная переменная
| Имя |
large_page_size |
Область действия |
Глобальная |
Динамическая |
Нет |
Допустимые значения
(Linux) | Тип |
integer |
Значение по умолчанию |
0 |
Если поддержка большой страницы включена, это показывает размер страниц
памяти. Большие страницы памяти поддержаны только в Linux, на других
платформах значение этой переменной всегда 0. См.
раздел 9.12.3.2.
-
last_insert_id
Значение, которое будет возвращено из
LAST_INSERT_ID()
. Это сохранено в двоичном журнале, когда Вы используете
LAST_INSERT_ID()
в запросе, который обновляет таблицу. Установка этой переменной не обновляет
значение, возвращенное C API
mysql_insert_id() .
-
lc_messages
Формат командной строки
| --lc-messages=name |
Системная переменная
| Имя |
lc_messages
|
Область действия |
Глобальная, Сеансовая |
Динамическая |
Да |
Допустимые значения
| Тип |
string |
Значение по умолчанию |
en_US |
Локаль, чтобы использовать для сообщений об ошибках. Значение по умолчанию
en_US . Сервер преобразует параметр к языковому имени и
комбинирует его со значением
lc_messages_dir , чтобы произвести местоположение для файла
сообщения об ошибке. См. раздел
11.2.
-
lc_messages_dir
Формат командной строки
| --lc-messages-dir=dir_name |
Системная переменная
| Имя |
lc_messages_dir |
Область действия |
Глобальная |
Динамическая |
Нет |
Допустимые значения |
Тип |
directory name |
Каталог, где сообщения об ошибках расположены. Сервер использует значение
вместе со значением lc_messages
, чтобы произвести местоположение для файла сообщения об ошибке.
См. раздел 11.2.
-
lc_time_names
Системная переменная
| Имя |
lc_time_names
|
Область действия |
Глобальная, Сеансовая |
Динамическая |
Да |
Допустимые значения |
Тип |
string |
Эта переменная определяет локаль, которая управляет языком, используемым,
чтобы вывести на экран имена дня, месяца и сокращения. Эта переменная
затрагивает вывод из функций
DATE_FORMAT() ,
DAYNAME() и
MONTHNAME() .
Имена значения POSIX-стиля, например, 'ja_JP' или 'pt_BR'
. Значение по умолчанию 'en_US' независимо от установки
локали Вашей системы. Для дополнительной информации см.
раздел 11.7.
-
license
Системная переменная
| Имя |
license
|
Область действия |
Глобальная |
Динамическая |
Нет |
Допустимые значения
| Тип |
string |
Значение по умолчанию |
GPL |
Тип лицензии сервера.
-
local_infile
Системная переменная
| Имя |
local_infile
|
Область действия |
Глобальная |
Динамическая |
Да |
Допустимые значения
| Тип |
boolean |
Значение по умолчанию |
true |
Поддержан ли LOCAL для
LOAD DATA INFILE .
Если эта переменная отключена, клиенты не могут использовать
LOCAL в LOAD DATA .
В то время как значение по умолчанию для этой переменной true ,
разрешен ли LOAD DATA INFILE LOCAL зависит от того, как MySQL
был собран, так же как от многих настроек на сервере и на клиенте, см.
раздел 7.1.6.
-
lock_wait_timeout
Формат командной строки
| --lock_wait_timeout=# |
Системная переменная
| Имя |
lock_wait_timeout |
Область действия |
Глобальная, Сеансовая |
Динамическая |
Да |
Допустимые значения
| Тип |
integer |
Значение по умолчанию |
31536000 |
Минимум |
1 |
Максимум |
31536000 |
Эта переменная определяет тайм-аут в секундах для попыток приобрести
блокировки метаданных. Допустимые значения колеблются от 1 до 31536000 (1
год). Значение по умолчанию 31536000.
Этот тайм-аут относится ко всем запросам, которые используют метаданные о
блокировке. Они включают операции DML и DDL на таблицах, представлениях,
хранимых процедурах и сохраненных функциях, так же как
LOCK TABLES ,
FLUSH TABLES WITH READ LOCK и
HANDLER .
Этот тайм-аут не относится к неявным доступам к системным таблицам в
базе данных mysql , таких как таблицы привилегий, измененные
GRANT или
REVOKE или табличные запросы
журналирования. Тайм-аут действительно относится к системным таблицам, к
которым получают доступ непосредственно, как с
SELECT или
UPDATE .
Значение тайм-аута применяется отдельно для каждой попытки блокировки
метаданных. Данный запрос может потребовать больше, чем одной блокировки,
таким образом, для запроса возможно заблокировать дольше, чем на
lock_wait_timeout
прежде, чем сообщить об ошибке тайм-аута. Когда тайм-аут блокировки
происходит, будет ошибка
ER_LOCK_WAIT_TIMEOUT .
lock_wait_timeout
не относится к отсроченным вставкам, которые всегда выполняются с
тайм-аутом 1 год. Это сделано, чтобы избежать ненужных тайм-аутов, потому что
сеанс, который выпускает отсроченную вставку, не получает уведомления о
тайм-аутах отсроченных вставок.
-
locked_in_memory
Системная переменная
| Имя |
locked_in_memory |
Область действия |
Глобальная |
Динамическая |
Нет |
Был ли mysqld
заблокирован в памяти с
--memlock .
-
log_bin_trust_function_creators
Формат командной строки
| --log-bin-trust-function-creators
|
Системная переменная
| Имя |
log_bin_trust_function_creators |
Область действия |
Глобальная |
Динамическая |
Да |
Допустимые значения
| Тип |
boolean |
Значение по умолчанию |
FALSE |
Эта переменная применяется, когда двоичное журналирование включено.
Это управляет, можно ли доверять создателям сохраненных функций, чтобы не
создать сохраненные функции, которые заставят опасные события быть
написанными в двоичный журнал. Если установлено в 0 (значение по умолчанию),
пользователям не разрешают создать или изменить сохраненные функции, если они
не имеют привилегии SUPER
в дополнение к CREATE
ROUTINE или ALTER
ROUTINE . Установка 0 также проводит в жизнь ограничение, которым
функция должна быть объявлена с DETERMINISTIC ,
READS SQL DATA или NO SQL . Если переменная
установлена в 1, MySQL не проводит в жизнь эти ограничения на создание
сохраненных функций. Эта переменная также применяется к созданию триггеров.
См. раздел 21.7.
-
log_builtin_as_identified_by_password
Формат командной строки
|
--log_builtin_as_identified_by_password[={OFF|ON}] |
Системная переменная
| Имя |
log_builtin_as_identified_by_password |
Область действия |
Глобальная |
Динамическая |
Да |
Допустимые значения
| Тип |
boolean |
Значение по умолчанию |
OFF |
Эта переменная затрагивает двоичное журналирование запросов
пользовательского управления. Если включено, двоичное журналирование для
CREATE USER ,
вовлекающих встроенные плагины аутентификации, переписывает, чтобы включать
IDENTIFIED BY PASSWORD , а
SET PASSWORD зарегистрированы как
SET PASSWORD , а не
ALTER USER .
-
log_error
Формат командной строки
| --log-error[=file_name] |
Системная переменная
| Имя |
log_error
|
Область действия |
Глобальная |
Динамическая |
Нет |
Допустимые значения |
Тип |
file name |
Местоположение журнала ошибок или stderr , если сервер пишет
сообщение об ошибке в стандартный ошибочный вывод. См.
раздел 6.4.2.
-
log_error_verbosity
Формат командной строки
| --log_error_verbosity=# |
Системная переменная
| Имя |
log_error_verbosity |
Область действия |
Глобальная |
Динамическая |
Да |
Допустимые значения
| Тип |
integer |
Значение по умолчанию |
3 |
Минимум |
1 |
Максимум |
3 |
Эта переменная управляет уровнем подробностей в записи ошибок,
предупреждений и сообщений примечания к журналу ошибок. Следующая таблица
показывает разрешенные значения. Значение по умолчанию 3.
Значение |
Зарегистрированные типы сообщения |
1 | Ошибки только |
2 | Ошибки и предупреждения |
3 | Все сообщения |
log_error_verbosity
предпочтен и должен использоваться вместо более старого
log_warnings .
В частности, назначение значения
log_warnings
назначает значение
log_error_verbosity и наоборот.
-
log_output
Формат командной строки
| --log-output=name |
Системная переменная
| Имя |
log_output
|
Область действия |
Глобальная |
Динамическая |
Да |
Допустимые значения
| Тип |
set |
Значение по умолчанию |
FILE |
Допустимые значения |
TABLE |
FILE |
NONE |
Место назначения для регистрации общего запроса и медленного журнала
запроса. Значение может быть списком разделенных запятой значений из одного
или больше слов TABLE (зарегистрировать в таблице),
FILE (в файле) или NONE (не регистрировать).
Значение по умолчанию FILE . NONE
имеет приоритет перед каким-либо другим спецификатором. Если значение
NONE , записи журнала не записаны, даже если журналы включены.
Если журналы не включены, никакое журналирование не происходит, даже если
значение log_output
не NONE . См. раздел 6.4.1
.
-
log_queries_not_using_indexes
Формат командной строки
| --log-queries-not-using-indexes
|
Системная переменная
| Имя |
log_queries_not_using_indexes |
Область действия |
Глобальная |
Динамическая |
Да |
Допустимые значения
| Тип |
boolean |
Значение по умолчанию |
OFF |
Зарегистрированы ли запросы, которые не используют индекс, в медленном
журнале запроса. См. раздел 6.4.5.
-
log_syslog
Формат командной строки
| --log_syslog[={0|1}] |
Системная переменная
| Имя |
log_syslog
|
Область действия |
Глобальная |
Динамическая |
Да |
Допустимые значения
(Unix) | Тип |
boolean |
Значение по умолчанию |
OFF |
Допустимые значения
(Windows) | Тип |
boolean |
Значение по умолчанию |
ON |
Регистрируют ли при ошибке записи вывод в syslog
(для Unix) или в Event Log (в Windows).
Значение по умолчанию определено платформой:
Независимо от значения по умолчанию
log_syslog может быть
установлен явно, чтобы управлять выводом на любой поддержанной платформе.
Вывод syslog является ортогональным к посылке ошибочного
вывода к файлу или (в Windows) на консоль. Ошибочный вывод может быть
направлен к последнему месту назначения в дополнение к (или вместо)
syslog . См. раздел 6.4.2.
-
log_syslog_facility
Формат командной строки
| --log_syslog_facility=value
|
Системная переменная
| Имя |
log_syslog_facility |
Область действия |
Глобальная |
Динамическая |
Да |
Допустимые значения
| Тип |
string |
Значение по умолчанию |
daemon |
Средство для записи журнала ошибок в syslog
(какая программа посылает сообщению). Эта переменная не имеет никакого
эффекта, если log_syslog
включена. См. раздел 6.4.2.
Разрешенные значения могут измениться от операционной системы, см.
документацию на syslog .
Эта переменная не существует в Windows.
-
log_syslog_include_pid
Формат командной строки
| --log_syslog_include_pid[={0|1}]
|
Системная переменная
| Имя |
log_syslog_include_pid |
Область действия |
Глобальная |
Динамическая |
Да |
Допустимые значения
| Тип |
boolean |
Значение по умолчанию |
ON |
Включать ли ID процесса сервера в каждую строку вывода журнала ошибок,
написанного в syslog . Эта переменная не имеет никакого эффекта,
если log_syslog
включена. См. раздел 6.4.2.
Эта переменная не существует в Windows.
-
log_syslog_tag
Формат командной строки
| --log_syslog_tag=value |
Системная переменная
| Имя |
log_syslog_tag |
Область действия |
Глобальная |
Динамическая |
Да |
Допустимые значения
| Тип |
string |
Значение по умолчанию |
empty string |
Тег, который будет добавлен к идентификатору сервера в журнале ошибок,
syslog . Эта переменная не имеет никакого эффекта, если включена
log_syslog , см.
раздел 6.4.2.
По умолчанию идентификатор сервера mysqld
без тега. Если тег tag_val определен, это приложено к
идентификатору сервера с ведущим дефисом, приводящим к идентификатору
mysqld-tag_val .
В Windows, чтобы использовать тег, который еще не существует, сервер
должен быть выполнен из учетной записи с привилегиями Администратора, чтобы
разрешить создание записи регистрации для тега. Такие привилегии не
требуются, если тег уже существует.
-
log_timestamps
Формат командной строки
| --log_timestamps=# |
Системная переменная
| Имя |
log_timestamps |
Область действия |
Глобальная |
Динамическая |
Да |
Допустимые значения
| Тип |
enumeration |
Значение по умолчанию |
UTC |
Допустимые значения |
UTC |
SYSTEM |
Эта переменная управляет часовым поясом сообщений журнала ошибок,
общего журнала запроса и журнала медленных запросов, написанных в файлы.
Это не затрагивает часовой пояс общего журнала запроса и медленного журнала
запросов, написанных в таблицы (mysql.general_log ,
mysql.slow_log ). Строки, полученные из тех таблиц, могут быть
преобразованы от местного системного часового пояса до любого желаемого
часового пояса с помощью
CONVERT_TZ() или устанавливая сеансовое значение
time_zone .
Разрешенные значения
log_timestamps : UTC (значение по умолчанию) и
SYSTEM (местный системный часовой пояс).
Timestamp написаны, используя формат ISO 8601/RFC 3339:
YYYY-MM-DDThh:mm:ss.uuuuuu плюс конечное значение
Z (UTC) или hh:mm (смещение относительно UTC).
-
log_throttle_queries_not_using_indexes
Если вклчюена
log_queries_not_using_indexes ,
log_throttle_queries_not_using_indexes ограничивает число запросов
в минуту, которые могут быть написана в медленный журнал запроса. Значение 0
(значение по умолчанию) не означает "без ораничений"
. См. раздел 6.4.5.
-
log_slow_admin_statements
Системная переменная
| Имя |
log_slow_admin_statements |
Область действия |
Глобальная |
Динамическая |
Да |
Допустимые значения
| Тип |
boolean |
Значение по умолчанию |
OFF |
Включать медленные административные запросы в запросы, написанные в
медленный журнал запросов. Административные запросы включают
include ALTER TABLE ,
ANALYZE TABLE ,
CHECK TABLE ,
CREATE INDEX ,
DROP INDEX ,
OPTIMIZE TABLE и
REPAIR TABLE .
-
log_warnings
Устарела |
5.7.2 |
Формат командной строки
| --log-warnings[=#] |
Системная переменная
| Имя |
log_warnings
|
Область действия |
Глобальная |
Динамическая |
Да |
Допустимые значения
(32-bit platforms) | Тип |
integer |
Значение по умолчанию |
2 |
Минимум |
0 |
Максимум |
4294967295 |
Допустимые значения
(64-bit platforms) | Тип |
integer |
Значение по умолчанию |
2 |
Минимум |
0 |
Максимум |
18446744073709551615 |
Произвести ли дополнительные предупреждающие сообщения для журнала ошибок.
Эта переменная включена по умолчанию со значением 2. Чтобы отключить,
установите это в 0. Сервер регистрирует сообщения о запросах, которые опасны
для основанного на запросе журналирования, если значение больше 0. Прерванные
соединения и ошибки доступа для новых попыток соединения зарегистрированы,
если значение больше 1. См. раздел
B.5.2.10.
Включение этой опции, устанавливая это больше 0, рекомендуется, если Вы
используете репликацию, чтобы получить больше информации о том, что
происходит, например, сообщения о сетевых отказах и пересоединениях. Если
значение больше 1, прерванные соединения и ошибки доступа для новых попыток
соединения написаны в журнал ошибок.
Если ведомый сервер запущен с включенной
log_warnings ,
ведомое устройство печатает сообщения в журнал ошибок, чтобы предоставить
информацию о состоянии, таком как двоичный журнал и координаты журнала реле,
где это запускает свое задание, когда это переключается на другой журнал
реле, когда это повторно соединяется после разъединения и т.д.
С MySQL 5.7.2 единицы информации, которыми ранее управляла
log_warnings ,
управляют
log_error_verbosity , которая предпочтена и должна использоваться
вместо более старой
log_warnings .
log_warnings и опция командной строки
--log-warnings
устарели и будут удалены в будущем выпуске MySQL.
Назначение значения к
log_warnings назначает значение на
log_error_verbosity
и наоборот. Переменные связаны следующим образом:
С MySQL 5.7.2 уровнем журнала значения по умолчанию управляет
log_error_verbosity
, у которой есть значение по умолчанию 3. Кроме того, значение по
умолчанию для log_warnings
изменено от 1 до 2, которое соответствует
log_error_verbosity=3
. Чтобы достигнуть уровня журналирования, подобного предыдущему
значению по умолчанию, надо установить
log_error_verbosity=2
.
В MySQL 5.7.2 и выше использование
log_warnings
все еще разрешено, но отображается на использование
log_error_verbosity
:
long_query_time
Формат командной строки
| --long_query_time=# |
Системная переменная
| Имя |
long_query_time |
Область действия |
Глобальная, Сеансовая |
Динамическая |
Да |
Допустимые значения
| Тип |
numeric |
Значение по умолчанию |
10 |
Минимум |
0 |
Допустимые значения
| Тип |
numeric |
Значение по умолчанию |
10 |
Минимум |
0 |
Если запрос занимает больше времени чем это значение в секундах, сервер
увеличивает Slow_queries
. Если медленный журнал запроса включен, запрос зарегистрирован в
медленном системном журнале запросов. Это значение измерено в режиме
реального времени, а не времени центрального процессора, таким образом,
запрос, который находится под порогом на слегка загруженной системе, мог бы
быть выше порога на более загруженной. Минимальные и значения по умолчанию
long_query_time
0 и 10, соответственно. Значение может быть определено с точностью до
разрешению микросекунд. Для того, чтобы зарегистрировать в файл, время
написано, включая часть микросекунд. Для того, чтобы зарегистрировать в
таблицу, написаны только целые значения времени, часть микросекунд
проигнорирована. См. раздел 6.4.5.
-
low_priority_updates
Формат командной строки
| --low-priority-updates |
Системная переменная
| Имя |
low_priority_updates |
Область действия |
Глобальная, Сеансовая |
Динамическая |
Да |
Допустимые значения
| Тип |
boolean |
Значение по умолчанию |
FALSE |
Если установлено в 1 , все
INSERT ,
UPDATE ,
DELETE и
LOCK TABLE WRITE ждут, пока нет никакого ожидающего
SELECT или
LOCK TABLE READ на затронутой таблице. Это затрагивает только
механизмы хранения, которые используют только блокировку на уровне таблицы
(такие, как MyISAM , MEMORY и MERGE ).
-
lower_case_file_system
Системная переменная
| Имя |
lower_case_file_system |
Область действия |
Глобальная |
Динамическая |
Нет |
Допустимые значения |
Тип |
boolean |
Эта переменная описывает чувствительность к регистру имен файла в файловой
системе, где каталог данных расположен. OFF указывает, что имена
являются чувствительными к регистру, ON указывает, что они не
являются чувствительными к регистру. Эта переменная только для чтения, потому
что она отражает признак файловой системы, и установка ее не имела бы
никакого эффекта на файловую систему.
-
lower_case_table_names
Формат командной строки
| --lower_case_table_names[=#]
|
Системная переменная
| Имя |
lower_case_table_names |
Область действия |
Глобальная |
Динамическая |
Нет |
Допустимые значения
| Тип |
integer |
Значение по умолчанию |
0 |
Минимум |
0 |
Максимум |
2 |
Если установлено в 0, имена таблиц сохранены как определено, и сравнения
являются чувствительными к регистру. Если установлено в 1, имена таблиц
сохранены в нижнем регистре на диске, и сравнения не являются чувствительными
к регистру. Если установлено в 2, имена таблиц сохранены как дано, но
сравнены в нижнем регистре. Эта опция также относится к именам базы данных и
табличным псевдонимам. Для дополнительной информации см.
раздел 10.2.2.
В Windows значение по умолчанию 1. В OS X значение по умолчанию 2.
Вы не должны установить
lower_case_table_names в 0, если Вы выполняете MySQL на системе,
где каталог данных находится на нечувствительной к регистру файловой системе
(такой как Windows или OS X). Это неподдержанная комбинация, которая может
привести к сбою в INSERT INTO ... SELECT ... FROM tbl_name
при неправильном регистре tbl_name .
С MyISAM доступ к именам таблиц, используя различные регистры,
может вызвать повреждение индекса.
С MySQL 5.7.9 сообщение об ошибке напечатано, и сервер завершается,
если Вы пытаетесь запустить сервер с
--lower_case_table_names=0 на нечувствительной к
регистру файловой системе.
Если Вы используете таблицы InnoDB ,
Вы должны установить эту переменную в 1 на всех платформах, чтобы вынудить
имена быть преобразованными в нижний регистр.
Установка этой переменной в MySQL 8.0 меняет поведение опций фильтрации
репликации относительно чувствительности к регистру (Bug #51639), см.
раздел 19.2.5.
-
max_allowed_packet
Формат командной строки
| --max_allowed_packet=# |
Системная переменная
| Имя |
max_allowed_packet |
Область действия |
Глобальная, Сеансовая |
Динамическая |
Да |
Допустимые значения
| Тип |
integer |
Значение по умолчанию |
4194304 |
Минимум |
1024 |
Максимум |
1073741824 |
Максимальный размер одного пакета, любой строки или любого параметра,
посланного фукцией C API
mysql_stmt_send_long_data() .
Значение по умолчанию составляет 4 МБ.
Пакетный буфер сообщения инициализирован
net_buffer_length
байт, но может вырасти до
max_allowed_packet
байт, если надо. Это значение по умолчанию является маленьким,
чтобы поймать большой (возможно, неправильный) пакет.
Вы должны увеличить это значение, если Вы используете большие столбцы
BLOB или длинные строки. Это должно
быть столь же большим как самое большое значение
BLOB . Предел протокола для
max_allowed_packet
1GB. Значение должно быть кратным 1024, не кратные значения
округлены в меньшую сторону к самому близкому кратному числу.
Когда Вы изменяете размер буфера сообщения, изменяя значение
max_allowed_packet
, Вы должны также изменить размер буфера на стороне клиента, если
Ваша программа клиента разрешает это. Значением по умолчанию
max_allowed_packet
, встроенным в библиотеку клиента, является 1GB,
но отдельные программы клиента могли бы переопределить это. Например,
mysql и
mysqldump
имеют значения по умолчанию 16 МБ и 24 МБ, соответственно. Они также
позволяют Вам изменить клиентское значение, устанавливая
max_allowed_packet
в командной строке или в файле опций.
Значение сеанса этой переменной только для чтения. Клиент может получить
так много байтов, как значение сеанса. Однако, сервер не будет посылать
клиенту больше байтов, чем глобальное текущее значение
max_allowed_packet
. Глобальное значение могло быть меньше, чем значение сеанса, если
глобальное значение изменено после того, как клиент соединяется.
-
max_connect_errors
Формат командной строки
| --max_connect_errors=# |
Системная переменная
| Имя |
max_connect_errors |
Область действия |
Глобальная |
Динамическая |
Да |
Допустимые значения
(32-bit platforms) | Тип |
integer |
Значение по умолчанию |
100 |
Минимум |
1 |
Максимум |
4294967295 |
Допустимые значения
(64-bit platforms) | Тип |
integer |
Значение по умолчанию |
100 |
Минимум |
1 |
Максимум |
18446744073709551615 |
Если больше последовательных запросов соединения, чем это значение, от
узла прерваны без успешного соединения, сервер блокирует хост, переставая
принимать с него соединения. Вы можете открыть заблокированные узлы,
сбрасывая кэш узла. Сделать это можно с помощью
FLUSH HOSTS или
mysqladmin flush-hosts.
Если соединение установлено успешно в пределах меньше
max_connect_errors
после предыдущего прерванного соединения, счетчик ошибок для узла
очищен к нолю. Однако, как только узел заблокирован, сброс кэша узла это
единственный способ открыть это. Значение по умолчанию 100.
-
max_connections
Формат командной строки
| --max_connections=# |
Системная переменная
| Имя |
max_connections |
Область действия |
Глобальная |
Динамическая |
Да |
Допустимые значения
| Тип |
integer |
Значение по умолчанию |
151 |
Минимум |
1 |
Максимум |
100000 |
Максимальное разрешенное число одновременных соединений клиента.
По умолчанию это 151. См.
раздел B.5.2.6.
Увеличение этого значения увеличивает число описателей файла, которых
требует mysqld
. Если необходимое число описателей недоступно, сервер уменьшает значение
max_connections .
См. раздел 9.4.3.1.
Соединения, отвергнутые потому, что лимит
max_connections
достигнут, увеличивают значение
Connection_errors_max_connections .
-
max_delayed_threads
Устарела |
5.6.7 |
Формат командной строки
| --max_delayed_threads=# |
Системная переменная
| Имя |
max_delayed_threads |
Область действия |
Глобальная, Сеансовая |
Динамическая |
Да |
Допустимые значения
| Тип |
integer |
Значение по умолчанию |
20 |
Минимум |
0 |
Максимум |
16384 |
Эта системная переменная устарела (потому что DELAYED вставки
не поддержаны) и будет удалена в будущем выпуске.
-
max_digest_length
Формат командной строки
| --max_digest_length=# |
Системная переменная
| Имя |
max_digest_length |
Область действия |
Глобальная |
Динамическая |
Нет |
Допустимые значения
| Тип |
integer |
Значение по умолчанию |
1024 |
Минимум |
0 |
Максимум |
1048576 |
Максимальное количество байтов, доступных для вычислительных обзоров
запроса (см.
раздел 23.7). Когда это количество используется для того, чтобы вычислить
обзор для запроса, никакие дальнейшие маркеры из разобранного запроса не
собраны. Запросы, отличающиеся только после этих байтов разобранных маркеров,
производят тот же самый обзор и соединены для статистики обзора.
Уменьшение
max_digest_length уменьшает использование памяти, но заставляет
значение обзора большего количества запросов становится неразличимым, если
они отличаются только в конце. Увеличение значения разрешает более длинным
запросым быть отличенными, но использование памяти увеличено, особенно для
рабочих нагрузок, которые вовлекают большие количества одновременных сеансов
(max_digest_length
байт выделены на сеанс).
Эта переменная не относится к обзорам Performance Schema,
но применяется к другим функциям сервера, которые используют обзоры, таким
как плагины перезаписи запроса. Чтобы управлять обзорами Performance Schema,
надо использовать
performance_schema_max_digest_length .
-
max_error_count
Формат командной строки
| --max_error_count=# |
Системная переменная
| Имя |
max_error_count |
Область действия |
Глобальная, Сеансовая |
Динамическая |
Да |
Допустимые значения
| Тип |
integer |
Значение по умолчанию |
64 |
Минимум |
0 |
Максимум |
65535 |
Максимальное количество ошибок, предупреждений и сообщений примечания,
которые будут сохранены для SHOW
ERRORS и SHOW
WARNINGS . Это то же самое, как число областей условия в области
диагностики, и таким образом число условий, которые могут быть просмотрены
GET DIAGNOSTICS .
-
max_execution_time
Формат командной строки
| --max_execution_time=# |
Системная переменная
| Имя |
max_execution_time |
Область действия |
Глобальная, Сеансовая |
Динамическая |
Да |
Допустимые значения
| Тип |
integer |
Значение по умолчанию |
0 |
Тайм-аут выполнения для
SELECT
в миллисекундах. Если значение 0, тайм-ауты не включены.
max_execution_time
применяется следующим образом:
max_heap_table_size
Формат командной строки
| --max_heap_table_size=# |
Системная переменная
| Имя |
max_heap_table_size |
Область действия |
Глобальная, Сеансовая |
Динамическая |
Да |
Допустимые значения
(32-bit platforms) | Тип |
integer |
Значение по умолчанию |
16777216 |
Минимум |
16384 |
Максимум |
4294967295 |
Допустимые значения
(64-bit platforms) | Тип |
integer |
Значение по умолчанию |
16777216 |
Минимум |
16384 |
Максимум |
1844674407370954752 |
Эта переменная устанавливает максимальный размер создаваемой пользователем
таблицы MEMORY . Значение переменной используется, чтобы
вычислить значение MAX_ROWS для таблицы MEMORY .
Установка этой переменной не имеет никакого эффекта на любой существующей
таблице MEMORY , если таблица не обновлена с таким запросом, как
CREATE TABLE ,
ALTER TABLE или
TRUNCATE TABLE .
Перезапуск сервера также устанавливает максимальный размер существующих
таблиц MEMORY к глобальному значению
max_heap_table_size
.
Эта переменная также используется в соединении с
tmp_table_size ,
чтобы ограничить размер внутренних таблиц в памяти. См.
раздел 9.4.4.
max_heap_table_size не реплицируется, см. разделы
19.4.1.23 и
19.4.1.38.
-
max_insert_delayed_threads
Устарела |
5.6.7 |
Системная переменная
| Имя |
max_insert_delayed_threads |
Область действия |
Глобальная, Сеансовая |
Динамическая |
Да |
Допустимые значения |
Тип |
integer |
Синоним для
max_delayed_threads .
Эта системная переменная устарела (потому что DELAYED вставки
не поддержаны) и будет удалена в будущем выпуске.
-
max_join_size
Формат командной строки
| --max_join_size=# |
Системная переменная
| Имя |
max_join_size
|
Область действия |
Глобальная, Сеансовая |
Динамическая |
Да |
Допустимые значения
| Тип |
integer |
Значение по умолчанию |
18446744073709551615 |
Минимум |
1 |
Максимум |
18446744073709551615 |
Не разрешать запросы, которые, вероятно, должны исследовать больше, чем
max_join_size
строк (для однотабличных запросов) или комбинаций строки (для многотабличных
запросов) или которые, вероятно, сделают больше, чем
max_join_size
дисковых поисков. Устанавливая это значение, Вы можете поймать запросы, где
ключи не используются должным образом, и это, вероятно, заняло бы много
времени. Установите это, если Ваши пользователи склонны выполнять соединения
без WHERE , которые занимают много времени или
возвращают миллионы строк.
Установка этой переменной к значению кроме DEFAULT
сбрасывает значение
sql_big_selects в 0 . Если Вы устанавливаете
sql_big_selects
снова, max_join_size
проигнорирована.
Если результат запроса находится в кэше запроса, никакая проверка размера
результата не выполнена, потому что результат был ранее вычислен, и это не
обременяет сервер, чтобы послать его клиенту.
-
max_length_for_sort_data
Формат командной строки
| --max_length_for_sort_data=#
|
Системная переменная
| Имя |
max_length_for_sort_data |
Область действия |
Глобальная, Сеансовая |
Динамическая |
Да |
Допустимые значения
| Тип |
integer |
Значение по умолчанию |
1024 |
Минимум |
4 |
Максимум |
8388608 |
Размер индексируемого значения, который определяет используемый
алгоритм filesort , см.
раздел 9.2.1.15.
-
max_points_in_geometry
Формат командной строки
| --max_points_in_geometry=integer
|
Системная переменная
| Имя |
max_points_in_geometry |
Область действия |
Глобальная |
Динамическая |
Да |
Допустимые значения
| Тип |
integer |
Значение по умолчанию |
65536 |
Минимум |
3 |
Максимум |
1048576 |
Максимальное значение параметра
points_per_circle функции
ST_Buffer_Strategy()
.
-
max_prepared_stmt_count
Формат командной строки
| --max_prepared_stmt_count=# |
Системная переменная
| Имя |
max_prepared_stmt_count |
Область действия |
Глобальная |
Динамическая |
Да |
Допустимые значения
| Тип |
integer |
Значение по умолчанию |
16382 |
Минимум |
0 |
Максимум |
1048576 |
Эта переменная ограничивает общее количество готовых запросов в сервере.
Это может использоваться в окружающей среде, где есть потенциал для атак
denial-of-service, основанных на выполнении сервера из памяти, готовя
огромные числа запросов. Если значение установлено ниже, чем текущее число
готовых запросов, существующие запросы не затронуты и могут использоваться,
но никакие новые запросы не могут быть подготовлены, пока текущее число не
удаляется ниже предела. Значение по умолчанию 16382. Допустимый диапазон
значений от 0 до 1 миллиона. Установка значения в 0
отключает подготовленные запросы.
-
max_relay_log_size
Формат командной строки
| --max_relay_log_size=# |
Системная переменная
| Имя |
max_relay_log_size |
Область действия |
Глобальная |
Динамическая |
Да |
Допустимые значения
| Тип |
integer |
Значение по умолчанию |
0 |
Минимум |
0 |
Максимум |
1073741824 |
Если запись ведомым устройством его журнала реле заставляет текущий размер
файла системного журнала превышать значение этой переменной, ведомое
устройство ротирует журналы реле (закрывает текущий файл и открывает
следующий). Если
max_relay_log_size = 0, сервер смотрит
max_binlog_size
для двоичного журнала и для журнала реле. Если
max_relay_log_size
больше 0, это ограничивает размер журнала реле, который позволяет
Вам иметь различные размеры для двух журналов. Вы должны установить
max_relay_log_size
между 4096 байтами и 1GB (включительно) или к 0. Значение по
умолчанию 0. См.
раздел 19.2.2.
-
max_seeks_for_key
Формат командной строки
| --max_seeks_for_key=# |
Системная переменная
| Имя |
max_seeks_for_key |
Область действия |
Глобальная, Сеансовая |
Динамическая |
Да |
Допустимые значения
(32-bit platforms) | Тип |
integer |
Значение по умолчанию |
4294967295 |
Минимум |
1 |
Максимум |
4294967295 |
Допустимые значения
(64-bit platforms) | Тип |
integer |
Значение по умолчанию |
18446744073709551615 |
Минимум |
1 |
Максимум |
18446744073709551615 |
Ограничить принятое максимальное количество просмотров строк при поиске,
основанном на ключе. MySQL предполагает, что не больше, чем это число ключей
требуется, ища соответствие строк в таблице, просматривая индексирование,
независимо от фактического количества элементов индексирования (см.
раздел 14.7.5.22). Устанавливая это в низкое
значение (например, 100), Вы можете вынудить MySQL предпочесть индекс
вместо сканирования таблицы.
-
max_sort_length
Формат командной строки
| --max_sort_length=# |
Системная переменная
| Имя |
max_sort_length |
Область действия |
Глобальная, Сеансовая |
Динамическая |
Да |
Допустимые значения
| Тип |
integer |
Значение по умолчанию |
1024 |
Минимум |
4 |
Максимум |
8388608 |
Число байтов, чтобы использовать, сортируя значения данных.
Сервер использует только первые
max_sort_length
байт каждого значения и игнорирует остальные. Следовательно, значения,
которые отличаются только после первых
max_sort_length
байт сравниваются как равные для GROUP BY ,
ORDER BY и DISTINCT .
Увеличение значения
max_sort_length может потребовать увеличения значения
sort_buffer_size
. Для деталей см. раздел
9.2.1.15.
-
max_sp_recursion_depth
Формат командной строки
| --max_sp_recursion_depth[=#]
|
Системная переменная
| Имя |
max_sp_recursion_depth |
Область действия |
Глобальная, Сеансовая |
Динамическая |
Да |
Допустимые значения
| Тип |
integer |
Значение по умолчанию |
0 |
Максимум |
255 |
Число раз, которое любую хранимую процедуру можно вызвать рекурсивно.
Значение по умолчанию для этой опции 0, что полностью отключает рекурсию в
хранимых процедурах. Максимальное значение 255.
Рекурсия хранимой процедуры увеличивает требование к пространству стека
потока. Если Вы увеличиваете значение
max_sp_recursion_depth , может быть необходимо увеличить размер
стека потока, увеличивая значение
thread_stack при запуске сервера.
-
max_tmp_tables
Эта переменная не использована. Это устарело и будет удалено в
будущем выпуске MySQL.
-
max_user_connections
Формат командной строки
| --max_user_connections=# |
Системная переменная
| Имя |
max_user_connections |
Область действия |
Глобальная, Сеансовая |
Динамическая |
Да |
Допустимые значения
| Тип |
integer |
Значение по умолчанию |
0 |
Минимум |
0 |
Максимум |
4294967295 |
Максимальное количество одновременных соединений, разрешенных любой данной
учетной записи пользователя MySQL. Значение 0 (значение по умолчанию) не
означает "без ограничений".
У этой переменной есть глобальное значение, которое может быть установлено
при запуске сервера или во время выполнения. Также есть значение сеанса
только для чтения, которое указывает на эффективный предел одновременных
соединений, который относится к учетной записи, связанной с текущим сеансом.
Значение сеанса инициализировано следующим образом:
Пределы ресурса учетной записи определены, используя
CREATE USER или
ALTER USER , см.
раздел 7.3.5.
-
max_write_lock_count
Формат командной строки
| --max_write_lock_count=# |
Системная переменная
| Имя |
max_write_lock_count |
Область действия |
Глобальная |
Динамическая |
Да |
Допустимые значения
(32-bit platforms) | Тип |
integer |
Значение по умолчанию |
4294967295 |
Минимум |
1 |
Максимум |
4294967295 |
Допустимые значения
(64-bit platforms) | Тип |
integer |
Значение по умолчанию |
18446744073709551615 |
Минимум |
1 |
Максимум |
18446744073709551615 |
После обработки нескольких блокировок записи разрешают, чтобы некоторая
блокировка чтения была обработана промежуточно.
mecab_rc_file
Формат командной строки
| --mecab_rc_file |
Системная переменная
| Имя |
mecab_rc_file
|
Область действия |
Глобальная |
Динамическая |
Нет |
Допустимые значения |
Тип |
directory name |
Опция mecab_rc_file используется, настраивая
полнотекстовый анализатор MeCab.
Опция mecab_rc_file определяет путь к конфигурационному файлу
mecabrc , который является конфигурационным файлом для MeCab.
Опция только для чтения и может быть установлена только при запуске. Файл
mecabrc обязан инициализировать MeCab.
См. раздел 13.9.9.
Для информации об опциях, которые могут быть определены в
конфигурационном файле MeCab mecabrc , см.
MeCab Documentation на сайте
Google Developers.
-
metadata_locks_cache_size
Устарела |
5.7.4 |
Системная переменная
| Имя |
metadata_locks_cache_size |
Область действия |
Глобальная |
Динамическая |
Нет |
Допустимые значения
| Тип |
integer |
Значение по умолчанию |
1024 |
Минимум |
1 |
Максимум |
1048576 |
Размер метаданных блока кэша. Сервер использует этот кэш, чтобы избежать
создания и разрушения объектов синхронизации. Это особенно полезно на
системах, где такие операции дороги.
Метаданные, блокирующие изменения выполнения, сделали эту переменную
ненужной, таким образом, она устарела и будет удалена в
будущем выпуске MySQL.
-
metadata_locks_hash_instances
Устарела |
5.7.4 |
Системная переменная
| Имя |
metadata_locks_hash_instances |
Область действия |
Глобальная |
Динамическая |
Нет |
Допустимые значения
| Тип |
integer |
Значение по умолчанию |
8 |
Минимум |
1 |
Максимум |
1024 |
Набор блокировок метаданных может быть разделен в отдельные хеши, чтобы
разрешить соединениям, получающим доступ к различным объектам, использовать
различные хеши блокировки и уменьшить издержки
metadata_locks_hash_instances
определяет число хешей (значение по умолчанию 8).
Метаданные, блокирующие изменения выполнения, сделали эту переменную
ненужной, таким образом, она устарела и будет удалена в
будущем выпуске MySQL.
-
min_examined_row_limit
Формат командной строки
| --min-examined-row-limit=# |
Системная переменная
| Имя |
min_examined_row_limit |
Область действия |
Глобальная, Сеансовая |
Динамическая |
Да |
Допустимые значения
(32-bit platforms) | Тип |
integer |
Значение по умолчанию |
0 |
Минимум |
0 |
Максимум |
4294967295 |
Допустимые значения
(64-bit platforms) | Тип |
integer |
Значение по умолчанию |
0 |
Минимум |
0 |
Максимум |
18446744073709551615 |
Запросы, которые исследуют меньше, чем это число строк, не
зарегистрированы в медленном журнале запроса.
-
multi_range_count
Устарела |
5.6.7 |
Формат командной строки
| --multi_range_count=# |
Системная переменная
| Имя |
multi_range_count |
Область действия |
Глобальная, Сеансовая |
Динамическая |
Да |
Допустимые значения
| Тип |
integer |
Значение по умолчанию |
256 |
Минимум |
1 |
Максимум |
4294967295 |
Эта переменная не имеет никакого эффекта. Она устарела и будет удалена
в будущем выпуске MySQL.
-
myisam_data_pointer_size
Формат командной строки
| --myisam_data_pointer_size=#
|
Системная переменная
| Имя |
myisam_data_pointer_size |
Область действия |
Глобальная |
Динамическая |
Да |
Допустимые значения
| Тип |
integer |
Значение по умолчанию |
6 |
Минимум |
2 |
Максимум |
7 |
Размер указателя по умолчанию в байтах, чтобы использовать
CREATE TABLE для
MyISAM без опции MAX_ROWS .
Эта переменная не может быть меньше 2 или больше 7. Значение по умолчанию 6.
См. раздел B.5.2.11.
-
myisam_max_sort_file_size
Формат командной строки
| --myisam_max_sort_file_size=#
|
Системная переменная
| Имя |
myisam_max_sort_file_size |
Область действия |
Глобальная |
Динамическая |
Да |
Допустимые значения
(32-bit platforms) | Тип |
integer |
Значение по умолчанию |
2147483648 |
Допустимые значения
(64-bit platforms) | Тип |
integer |
Значение по умолчанию |
9223372036854775807 |
Максимальный размер временного файла, который MySQL разрешают
использовать, обновляя индекс MyISAM
(при работе REPAIR TABLE ,
ALTER TABLE или
LOAD DATA INFILE ).
Если размер файла больше, чем это значение, индекс создается, используя
ключевой кэш вместо этого, что медленнее. Значение дано в байтах.
Если индексные файлы MyISAM превышают этот размер, и дисковое
пространство доступно, увеличивая значение может помочь работе. Пространство
должно быть доступным в файловой системе, содержащей каталог, где
оригинальный индексный файл расположен.
-
myisam_mmap_size
Формат командной строки
| --myisam_mmap_size=# |
Системная переменная
| Имя |
myisam_mmap_size |
Область действия |
Глобальная |
Динамическая |
Нет |
Допустимые значения
(32-bit platforms) | Тип |
integer |
Значение по умолчанию |
4294967295 |
Минимум |
7 |
Максимум |
4294967295 |
Допустимые значения
(64-bit platforms) | Тип |
integer |
Значение по умолчанию |
18446744073709551615 |
Минимум |
7 |
Максимум |
18446744073709551615 |
Максимальный объем памяти, чтобы использовать для сжатого отображения
файлов MyISAM .
Если многие сжатые MyISAM таблицы используются, значение может
быть уменьшено, чтобы уменьшить вероятность свопа.
-
myisam_recover_options
Значение опции
--myisam-recover-options . См.
раздел 6.1.4.
-
myisam_repair_threads
Формат командной строки
| --myisam_repair_threads=# |
Системная переменная
| Имя |
myisam_repair_threads
|
Область действия |
Глобальная, Сеансовая |
Динамическая |
Да |
Допустимые значения
(32-bit platforms) | Тип |
integer |
Значение по умолчанию |
1 |
Минимум |
1 |
Максимум |
4294967295 |
Допустимые значения
(64-bit platforms) | Тип |
integer |
Значение по умолчанию |
1 |
Минимум |
1 |
Максимум |
18446744073709551615 |
Если это значение больше 1, табличные индексы MyISAM
создаются параллельно (каждый индекс в собственном потоке) во время
процесса Repair by sorting . Значение по умолчанию 1.
Мультипоточное восстановление все еще в стадии бета-тестирования.
myisam_sort_buffer_size
Формат командной строки
|
--myisam_sort_buffer_size=# |
Системная переменная
| Имя |
myisam_sort_buffer_size
|
Область действия |
Глобальная, Сеансовая |
Динамическая |
Да |
Допустимые значения
(Windows, 32-bit platforms) | Тип
| integer |
Значение по умолчанию |
8388608 |
Минимум |
4096 |
Максимум |
4294967295 |
Допустимые значения
(Windows, 64-bit platforms) | Тип
|
integer |
Значение по умолчанию |
8388608 |
Минимум |
4096 |
Максимум |
18446744073709551615 |
Допустимые значения
(Other, 32-bit platforms) | Тип
|
integer |
Значение по умолчанию |
8388608 |
Минимум |
4096 |
Максимум |
4294967295 |
Допустимые значения
(Other, 64-bit platforms) | Тип
|
integer |
Значение по умолчанию |
8388608 |
Минимум |
4096 |
Максимум |
18446744073709551615 |
Размер буфера, который выделен, сортируя индексы MyISAM
при REPAIR TABLE
или когда индекс создается с CREATE
INDEX или ALTER TABLE
.
Максимальная допустимая установка для
myisam_sort_buffer_size 4GB-1.
Большие значения разрешены для 64-битовых платформ.
-
myisam_stats_method
Формат командной строки
| --myisam_stats_method=name |
Системная переменная
| Имя |
myisam_stats_method
|
Область действия |
Глобальная, Сеансовая |
Динамическая |
Да |
Допустимые значения
| Тип |
enumeration |
Значение по умолчанию |
nulls_unequal |
Допустимые значения |
nulls_equal |
nulls_unequal |
nulls_ignored |
Как сервер обрабатывает значения NULL ,
собирая статистические данные о распределении индексных значений для
таблиц MyISAM . У этой переменной есть три возможных значения:
nulls_equal , nulls_unequal и
nulls_ignored . Для nulls_equal все индексные
значения NULL считаются равными и формируют единственную группу
значения, у которой есть размер, равный числу значений
NULL . Для nulls_unequal значения NULL
считают неравными, и каждое значение NULL
формирует отличную группу значения размера 1. Для nulls_ignored
значения NULL проигнорированы.
Метод, который используется для того, чтобы произвести табличные
расчеты статистики, как оптимизатор выбирает индекс для выполнения запроса,
описан в разделе 9.3.7/a>.
-
myisam_use_mmap
Формат командной строки
| --myisam_use_mmap |
Системная переменная
| Имя |
myisam_use_mmap |
Область действия |
Глобальная |
Динамическая |
Да |
Допустимые значения
| Тип |
boolean |
Значение по умолчанию |
OFF |
Использовать отображаемую память для чтения и
записи таблиц MyISAM .
-
mysql_native_password_proxy_users
Формат командной строки
| --mysql_native_password_proxy_users=
[={OFF|ON}] |
Системная переменная
| Имя |
mysql_native_password_proxy_users |
Область действия |
Глобальная |
Динамическая |
Да |
Допустимые значения
| Тип |
boolean |
Значение по умолчанию |
OFF |
Эта переменная управляет включен ли встроенный плагин аутентификации
mysql_native_password для пользователей по доверенности. Это не
имеет никакого эффекта, если включена перменная
check_proxy_users
. См. раздел 7.3.10.
-
named_pipe
Системная переменная
| Имя |
named_pipe
|
Область действия |
Глобальная |
Динамическая |
Нет |
Платформа |
Windows |
Допустимые значения
(Windows) | Тип |
boolean |
Значение по умолчанию |
OFF |
Только Windows. Указывает, поддерживает ли сервер соединения
по названным каналам.
-
net_buffer_length
Формат командной строки
| --net_buffer_length=# |
Системная переменная
| Имя |
net_buffer_length |
Область действия |
Глобальная, Сеансовая |
Динамическая |
Да |
Допустимые значения
| Тип |
integer |
Значение по умолчанию |
16384 |
Минимум |
1024 |
Максимум |
1048576 |
Каждый поток клиента связан с буфером соединения и буфером результата.
Оба начинают с размера, данного
net_buffer_length
, но динамически увеличены до
max_allowed_packet
байт. Буфер результата сжимается до
net_buffer_length
после каждого запроса SQL.
Эта переменная не должна обычно изменяться, но если у Вас есть очень
небольшая память, Вы можете установить это в ожидаемую длину запросов,
посланных клиентами. Если запросы превышают эту длину, буфер соединения
автоматически увеличен. Максимальное значение
net_buffer_length
может быть установлено в 1 МБ.
Значение сеанса этой переменной только для чтения.
-
net_read_timeout
Формат командной строки
| --net_read_timeout=# |
Системная переменная
| Имя |
net_read_timeout |
Область действия |
Глобальная, Сеансовая |
Динамическая |
Да |
Допустимые значения
| Тип |
integer |
Значение по умолчанию |
30 |
Минимум |
1 |
Число секунд, чтобы ждать большего количества данных от соединения прежде,
чем прервать чтение. Когда сервер читает от клиента,
net_read_timeout
управляет значением тайм-аута, когда прерваться. Когда сервер пишет
клиенту,
net_write_timeout управляет значением тайм-аута, когда прерваться.
См. также
slave_net_timeout .
-
net_retry_count
Формат командной строки
| --net_retry_count=# |
Системная переменная
| Имя |
net_retry_count |
Область действия |
Глобальная, Сеансовая |
Динамическая |
Да |
Допустимые значения
(32-bit platforms) | Тип |
integer |
Значение по умолчанию |
10 |
Минимум |
1 |
Максимум |
4294967295 |
Допустимые значения
(64-bit platforms) | Тип |
integer |
Значение по умолчанию |
10 |
Минимум |
1 |
Максимум |
18446744073709551615 |
Если чтение или запись на коммуникационном порту прервано, повторить много
раз перед отказом. Это значение указывает, сколько именно раз и должно быть
установлено довольно высоко на FreeBSD, потому что внутренние прерывания
посылают во все потоки.
-
net_write_timeout
Формат командной строки
| --net_write_timeout=# |
Системная переменная
| Имя |
net_write_timeout |
Область действия |
Глобальная, Сеансовая |
Динамическая |
Да |
Допустимые значения
| Тип |
integer |
Значение по умолчанию |
60 |
Минимум |
1 |
Число секунд, чтобы ждать блока, который будет написан соединению прежде,
чем прервать запись. См. также
net_read_timeout
.
-
new
Формат командной строки
| --new |
Системная переменная
| Имя |
new |
Область действия |
Глобальная, Сеансовая |
Динамическая |
Да |
Disabled by |
skip-new |
Допустимые значения
| Тип |
boolean |
Значение по умолчанию |
FALSE |
Эта переменная использовалась в MySQL 4.0, чтобы включить логику 4.1 и
сохранена для обратной совместимости. Значение всегда OFF .
ngram_token_size
Формат командной строки
| --ngram_token_size |
Системная переменная
| Имя |
ngram_token_size |
Область действия |
Глобальная |
Динамическая |
Нет |
Допустимые значения
| Тип |
integer |
Значение по умолчанию |
2 |
Минимум |
1 |
Максимум |
10 |
Определяет маркерный размер для n-gram полнотекстового анализатора.
Опция ngram_token_size только для чтения и может быть изменена
только при запуске. Значение по умолчанию 2 (bigram). Максимальное значение
10. См. раздел 13.9.8.
-
offline_mode
Формат командной строки
| --offline_mode=val |
Системная переменная
| Имя |
offline_mode
|
Область действия |
Глобальная |
Динамическая |
Да |
Допустимые значения
| Тип |
boolean |
Значение по умолчанию |
OFF |
Находится ли сервер в offline mode, у которого
есть эти характеристики:
Соединенные пользователи клиента, которые не имеют привилегии
SUPER , отсоединены
по следующему запросу с соответствующей ошибкой. Разъединение включает
завершение рабочих запросов и выпуск блокировок.
Такие клиенты также не могут начать новые соединения и получить
соответствующую ошибку.
- Соединенные пользователи клиента, которые имеют привилегию
SUPER , не разъединены и
могут начать новые соединения, чтобы управлять сервером.
- Ведомым потокам репликации
разрешают продолжить применять данные к серверу.
Только пользователи, которые имеют привилегию
SUPER , могут
управлять офлайновым режимом. Чтобы поместить сервер в офлайновый режим,
измените значение
offline_mode с OFF на ON .
Чтобы возобновить нормальное функционирование, измените
offline_mode с
ON на OFF . В офлайновом режиме клиенты, которым
отказывают в доступе, получают ошибку
ER_SERVER_OFFLINE_MODE
.
-
old
Формат командной строки
| --old |
Системная переменная
| Имя |
old |
Область действия |
Глобальная |
Динамическая |
Нет |
old
переменная совместимости. Это отключено по умолчанию, но может быть позволено
при запуске, чтобы вернуть сервер к поведениям, существующим в
более старых версиях.
Когда old включена,
это изменяет контекст по умолчанию индексной подсказки к используемому до
MySQL 5.1.17. Таким образом, индексные подсказки без FOR
применяются только к тому, как индексирование используется для извлечения
строки, а не к разрешению ORDER BY или GROUP BY
(см. раздел 9.9.4.
С основанным на запросе двоичным журналированием различные режимы для
ведущего и ведомых устройств могут привести к ошибкам.
-
old_alter_table
Формат командной строки
| --old-alter-table |
Системная переменная
| Имя |
old_alter_table |
Область действия |
Глобальная, Сеансовая |
Динамическая |
Да |
Допустимые значения
| Тип |
boolean |
Значение по умолчанию |
OFF |
Когда эта переменная включена, сервер не использует оптимизированный метод
обработки ALTER TABLE .
Это возвращается к использованию временной таблицы, копированию данных, а
затем переименованию временной таблицы к оригиналу, как используется MySQL
5.0 и ранее. Для получения дополнительной информации о работе
ALTER TABLE см.
раздел 14.1.7.
-
old_passwords
Устарела |
5.7.6 |
Системная переменная
| Имя |
old_passwords
|
Область действия |
Глобальная, Сеансовая |
Динамическая |
Да |
Допустимые значения
| Тип |
enumeration |
Значение по умолчанию |
0 |
Допустимые значения |
0 |
2 |
Эта системная переменная устарела
и будет удалена в будущем выпуске MySQL.
Эта переменная управляет методом хеширования пароля, используемым функцией
PASSWORD() .
Это также влияет на пароль в
CREATE USER и
GRANT , которые определяют пароль,
используя IDENTIFIED BY .
Следующая таблица показывает разрешенные значения
old_passwords ,
метод хеширования пароля для каждого значения и какие плагины аутентификации
используют пароли, хешированные с каждым методом.
Значение |
Метод хеширования пароля |
Связанный плагин аутентификации |
0 | MySQL 4.1 native |
mysql_native_password |
2 | SHA-256 | sha256_password
|
Если old_passwords=2
, следуйте инструкциям для того, чтобы использовать плагин
sha256_password в
разделе 7.5.1.2.
Сервер устанавливает глобальное значение
old_passwords
во время запуска, чтобы быть совместимым с методом хеширования пароля,
требуемым плагином аутентификации по умолчанию. Плагин по умолчанию
mysql_native_password , если
default_authentication_plugin не установлена иначе.
Когда клиент успешно соединяется с сервером, сервер устанавливает
сеансовое значение
old_passwords соответственно методу аутентификации учетной записи.
Например, если учетная запись использует плагин sha256_password ,
сервер установит old_passwords=2 .
См. раздел 7.3.9.
-
open_files_limit
Формат командной строки
| --open-files-limit=# |
Системная переменная
| Имя |
open_files_limit |
Область действия |
Глобальная |
Динамическая |
Нет |
Допустимые значения
| Тип |
integer |
Значение по умолчанию |
5000, with possible adjustment |
Минимум |
0 |
Максимум |
platform dependent |
Число файлов, которые операционная система разрешает
mysqld
открывать. Значение этой переменной во время выполнения это реальное
значение, разрешенное системой, может отличаться от значения, которое Вы
определяете при запуске сервера. Значение 0 на системах, где MySQL не может
изменить число открытых файлов.
Эффективное значение
open_files_limit основано на значении, определенном при системном
запуске (если есть) и значениях
max_connections и
table_open_cache
с использованием этих формул:
1) 10 + max_connections + (table_open_cache * 2).
2) max_connections * 5.
3) open_files_limit при запуске, 5000, если не указано.
Сервер пытается получить число описателей файла, используя максимум из
этих трех значений. Если так много описателей не могут быть получены, сервер
пытается получить столько, сколько система разрешит.
-
optimizer_prune_level
Формат командной строки
| --optimizer_prune_level[=#] |
Системная переменная
| Имя |
optimizer_prune_level |
Область действия |
Глобальная, Сеансовая |
Динамическая |
Да |
Допустимые значения
| Тип |
boolean |
Значение по умолчанию |
1 |
Управляет эвристикой, примененной во время оптимизации запроса, чтобы
сократить менее многообещающие частичные планы из области поиска оптимизации.
Значение 0 отключает эвристику так, чтобы оптимизатор выполнил исчерпывающий
поиск. Значение 1 предписывает оптимизатору сократить планы, основанные на
числе строк, полученных промежуточными планами.
-
optimizer_search_depth
Формат командной строки
| --optimizer_search_depth[=#]
|
Системная переменная
| Имя |
optimizer_search_depth |
Область действия |
Глобальная, Сеансовая |
Динамическая |
Да |
Допустимые значения
| Тип |
integer |
Значение по умолчанию |
62 |
Минимум |
0 |
Максимум |
62 |
Допустимые значения
| Тип |
integer |
Значение по умолчанию |
62 |
Минимум |
0 |
Максимум |
62 |
Максимальная глубина поиска, выполненного запросом.
Значения, больше чем число отношений в запросе, приводят к лучшим планам
запроса, но занимают больше времени, чтобы произвести план выполнения.
Значения, меньшие чем число отношений в запросе, возвращают более быстрый
план выполнения, но получающийся план может быть далеким от того, чтобы быть
оптимальным. Если установлено в 0, система автоматически
выбирает разумное значение.
-
optimizer_switch
Формат командной строки
| --optimizer_switch=value |
| --optimizer_switch=value
|
Системная переменная
| Имя |
optimizer_switch |
Область действия |
Глобальная, Сеансовая |
Динамическая |
Да |
Допустимые значения
| Тип |
set |
Допустимые значения |
batched_key_access={on|off} |
block_nested_loop={on|off} |
condition_fanout_filter={on|off}
|
derived_merge={on|off} |
duplicateweedout={on|off} |
engine_condition_pushdown={on|off}
|
firstmatch={on|off} |
index_condition_pushdown={on|off}
|
index_merge={on|off} |
index_merge_interраздел={on|off}
|
index_merge_sort_union={on|off}
|
index_merge_union={on|off} |
loosescan={on|off} |
materialization={on|off} |
mrr={on|off} |
mrr_cost_based={on|off} |
semijoin={on|off} |
subquery_materialization_cost_based=
{on|off} |
use_index_extensions={on|off}
|
Допустимые значения
| Тип |
set |
Допустимые значения |
engine_condition_pushdown={on|off} |
firstmatch={on|off} |
index_condition_pushdown={on|off}
|
index_merge={on|off} |
index_merge_interраздел={on|off}
|
index_merge_sort_union={on|off}
|
index_merge_union={on|off} |
loosescan={on|off} |
materialization={on|off} |
mrr={on|off} |
mrr_cost_based={on|off} |
semijoin={on|off} |
optimizer_switch
включает управление оптимизатором. Значение этой переменной ряд флагов,
у каждого из которых есть значение on или off ,
чтобы указать, включено ли соответствующее поведение оптимизатора.
Эта переменная имеет глобальное и сеансовое значения и может быть изменена во
время выполнения. Глобальное значение по умолчанию может быть установлено
при запуске сервера.
Чтобы видеть текущий набор флагов, выберите значение:
mysql> SELECT @@optimizer_switch\G
*************************** 1. row ***************************
@@optimizer_switch: index_merge=on,index_merge_union=on,
index_merge_sort_union=on,
engine_condition_pushdown=on,
index_condition_pushdown=on,
mrr=on,mrr_cost_based=on,
block_nested_loop=on,batched_key_access=off,
materialization=on,semijoin=on,loosescan=on,
firstmatch=on,duplicateweedout=on,
subquery_materialization_cost_based=on,
use_index_extensions=on,
condition_fanout_filter=on,derived_merge=on
См. раздел 9.9.2.
-
optimizer_trace
Системная переменная
| Имя |
optimizer_trace |
Область действия |
Глобальная, Сеансовая |
Динамическая |
Да |
Допустимые значения |
Тип |
string |
Эта переменная управляет трассировкой оптимизатора, см.
MySQL Internals: Tracing the Optimizer.
-
optimizer_trace_features
Системная переменная
| Имя |
optimizer_trace_features |
Область действия |
Глобальная, Сеансовая |
Динамическая |
Да |
Допустимые значения |
Тип |
string |
Эта переменная включает или отключает выбранную трассировку оптимизатора,
см. MySQL Internals: Tracing the Optimizer.
-
optimizer_trace_limit
Системная переменная
| Имя |
optimizer_trace_limit |
Область действия |
Глобальная, Сеансовая |
Динамическая |
Да |
Допустимые значения
| Тип |
integer |
Значение по умолчанию |
1 |
Максимальное количество трассировок оптимизатора, чтобы вывести на экран.
Для деталей см. MySQL Internals: Tracing the Optimizer.
-
optimizer_trace_max_mem_size
Системная переменная
| Имя |
optimizer_trace_max_mem_size |
Область действия |
Глобальная, Сеансовая |
Динамическая |
Да |
Допустимые значения
| Тип |
integer |
Значение по умолчанию |
16384 |
Максимальный совокупный размер сохраненных трассировок оптимизтора, см.
MySQL Internals: Tracing the Optimizer.
-
optimizer_trace_offset
Системная переменная
| Имя |
optimizer_trace_offset |
Область действия |
Глобальная, Сеансовая |
Динамическая |
Да |
Допустимые значения
| Тип |
integer |
Значение по умолчанию |
-1 |
Смещение трассировок оптимизатора, чтобы вывести на экран. Для деталей см.
MySQL Internals: Tracing the Optimizer.
performance_schema_xxx
Системные переменные Performance Schema перечислены в
разделе 23.12.
Эти переменные могут использоваться, чтобы сконфигурировать
работу Performance Schema.
-
parser_max_mem_size
Формат командной строки
| --parser_max_mem_size=N |
Системная переменная
| Имя |
parser_max_mem_size |
Область действия |
Глобальная, Сеансовая |
Динамическая |
Да |
Допустимые значения
(32-bit platforms) | Тип |
integer |
Значение по умолчанию |
4294967295 |
Минимум |
400000 |
Максимум |
4294967295 |
Допустимые значения
(64-bit platforms) | Тип |
integer |
Значение по умолчанию |
18446744073709551615 |
Минимум |
400000 |
Максимум |
18446744073709551615 |
Максимальный объем памяти, доступный анализатору. Значение по умолчанию не
устанавливает границы доступной памяти. Значение может быть уменьшено, чтобы
защититься от ситуаций нехватки памяти, вызванных, анализом
сложных запросов SQL.
-
persisted_globals_load
Формат командной строки
| --persisted_globals_load[=ON|OFF]
|
Системная переменная
| Имя |
persisted_globals_load |
Область действия |
Глобальная |
Динамическая |
Нет |
Допустимые значения
| Тип |
boolean |
Значение по умолчанию |
ON |
Загрузить ли настройки конфигурации из файла mysqld-auto.cnf
в каталоге данных. Сервер обычно обрабатывает этот файл при запуске после
всех других файлов опции (см.
раздел 5.2.6). Отключение
persisted_globals_load заставляет последовательность запуска
сервера пропускать файл mysqld-auto.cnf .
Чтобы изменить содержание mysqld-auto.cnf , используйте
SET PERSIST , см.
раздел 14.7.4.1.
-
pid_file
Формат командной строки
| --pid-file=file_name |
Системная переменная
| Имя |
pid_file
|
Область действия |
Глобальная |
Динамическая |
Нет |
Допустимые значения |
Тип |
file name |
Путь к файлу process ID (PID). Эта переменная может быть установлена с
опцией --pid-file
.
-
plugin_dir
Формат командной строки
| --plugin_dir=dir_name |
Системная переменная
| Имя |
plugin_dir
|
Область действия |
Глобальная |
Динамическая |
Нет |
Допустимые значения
| Тип |
directory name |
Значение по умолчанию |
BASEDIR/lib/plugin |
Путь к каталогу плагинов.
Если каталог перезаписываем сервером, для пользователя может быть возможно
написать выполнимый код в файл в каталоге с помощью
SELECT ... INTO DUMPFILE . Это может быть предотвращено,
делая plugin_dir
только для чтения серверу или устанавливая
--secure-file-priv
к каталогу, где SELECT
может быть сделан безопасно.
-
port
Формат командной строки
| --port=# |
Системная переменная
| Имя |
port |
Область действия |
Глобальная |
Динамическая |
Нет |
Допустимые значения
| Тип |
integer |
Значение по умолчанию |
3306 |
Минимум |
0 |
Максимум |
65535 |
Номер порта для соединений TCP/IP.
Эта переменная может быть установлена
--port .
-
preload_buffer_size
Формат командной строки
| --preload_buffer_size=# |
Системная переменная
| Имя |
preload_buffer_size |
Область действия |
Глобальная, Сеансовая |
Динамическая |
Да |
Допустимые значения
| Тип |
integer |
Значение по умолчанию |
32768 |
Минимум |
1024 |
Максимум |
1073741824 |
Размер буфера, который выделен, когда предварительно загружается индекс.
-
profiling
Если установлено в 0 или OFF (значение по умолчанию),
профилирование запроса отключено. Если установлено в 1 или ON ,
профилирование запроса включено и запросы
SHOW PROFILE и
SHOW PROFILES
обеспечивают доступ к профилированию информации. См.
раздел 14.7.5.31.
Эта переменная устарела и будет удалена в будущем выпуске MySQL.
-
profiling_history_size
Число запросов, для которых можно поддержать информацию о профилировании,
если включена опция profiling
. Значение по умолчанию 15. Максимальное значение 100.
Установка значения к 0 отключает профилирование. См.
раздел 14.7.5.31.
Эта переменная устарела и будет удалена в будущем выпуске MySQL.
-
protocol_version
Системная переменная
| Имя |
protocol_version |
Область действия |
Глобальная |
Динамическая |
Нет |
Допустимые значения |
Тип |
integer |
Версия протокола клиент-сервер используется сервером MySQL.
-
proxy_user
Системная переменная
| Имя |
proxy_user
|
Область действия |
Сеансовая |
Динамическая |
Нет |
Допустимые значения |
Тип |
string |
Если текущий клиент это полномочие для другого пользователя, эта
переменная - имя пользователя по доверенности. Иначе эта переменная
NULL . См. раздел 7.3.10.
-
pseudo_slave_mode
Системная переменная
| Имя |
pseudo_slave_mode |
Область действия |
Сеансовая |
Динамическая |
Да |
Допустимые значения |
Тип |
integer |
Эта переменная для внутреннего использования сервера.
-
pseudo_thread_id
Системная переменная
| Имя |
pseudo_thread_id |
Область действия |
Сеансовая |
Динамическая |
Да |
Допустимые значения |
Тип |
integer |
Эта переменная для внутреннего использования сервера.
-
query_alloc_block_size
Формат командной строки
| --query_alloc_block_size=# |
Системная переменная
| Имя |
query_alloc_block_size |
Область действия |
Глобальная, Сеансовая |
Динамическая |
Да |
Допустимые значения
| Тип |
integer |
Значение по умолчанию |
8192 |
Минимум |
1024 |
Максимум |
4294967295 |
Block Size |
1024 |
Размер блоков памяти, которые выделены для объектов, создаваемых во время
парсинга и выполнения запроса. Если у Вас есть проблемы с фрагментацией
памяти, может помочь увеличить этот параметр.
-
query_cache_limit
Формат командной строки
| --query_cache_limit=# |
Системная переменная
| Имя |
query_cache_limit |
Область действия |
Глобальная |
Динамическая |
Да |
Допустимые значения
(32-bit platforms) | Тип |
integer |
Значение по умолчанию |
1048576 |
Минимум |
0 |
Максимум |
4294967295 |
Допустимые значения
(64-bit platforms) | Тип |
integer |
Значение по умолчанию |
1048576 |
Минимум |
0 |
Максимум |
18446744073709551615 |
Не кэшировать результаты, которые больше, чем это число байтов.
Значение по умолчанию составляет 1 МБ.
-
query_cache_min_res_unit
Формат командной строки
| --query_cache_min_res_unit=#
|
Системная переменная
| Имя |
query_cache_min_res_unit |
Область действия |
Глобальная |
Динамическая |
Да |
Допустимые значения
(32-bit platforms) | Тип |
integer |
Значение по умолчанию |
4096 |
Минимум |
512 |
Максимум |
4294967295 |
Допустимые значения
(64-bit platforms) | Тип |
integer |
Значение по умолчанию |
4096 |
Минимум |
512 |
Максимум |
18446744073709551615 |
Минимальный размер (в байтах) для блоков кэша запроса.
Значение по умолчанию 4096 (4KB). Настройка для этой переменной дана в
разделе 9.10.3.3.
-
query_cache_size
Формат командной строки
| --query_cache_size=# |
Системная переменная
| Имя |
query_cache_size |
Область действия |
Глобальная |
Динамическая |
Да |
Допустимые значения
(32-bit platforms) | Тип |
integer |
Значение по умолчанию |
1048576 |
Минимум |
0 |
Максимум |
4294967295 |
Допустимые значения
(64-bit platforms) | Тип |
integer |
Значение по умолчанию |
1048576 |
Минимум |
0 |
Максимум |
18446744073709551615 |
Объем памяти для того, чтобы кэшировать результаты запроса. По умолчанию
кэш запроса отключен. Это достигнуто, используя значение по умолчанию 1M, со
значением по умолчанию для query_cache_type 0.
Чтобы значительно уменьшить издержки, если Вы устанавливаете размер в 0, Вы
должны также запустить сервер с
query_cache_type=0
.
Допустимые значения кратны 1024, другие значения округлены в меньшую
сторону к самому близкому кратному числу.
query_cache_size
байт памяти выделены, даже если
query_cache_type
= 0. См. раздел 9.10.3.3
.
Кэш запроса нуждается в минимальном размере приблизительно 40 КБ, чтобы
выделить его структуры. Точный размер зависит от системной архитектуры.
Если Вы устанавливаете слишком маленькое значение
query_cache_size
, предупреждение произойдет, как описано в
разделе 9.10.3.3.
-
query_cache_type
Формат командной строки
| --query_cache_type=# |
Системная переменная
| Имя |
query_cache_type |
Область действия |
Глобальная, Сеансовая |
Динамическая |
Да |
Допустимые значения
| Тип |
enumeration |
Значение по умолчанию |
0 |
Допустимые значения |
0 |
1 |
2 |
Установите тип кэша запроса. Установка GLOBAL задает
тип для всех клиентов, которые соединяются после того. Отдельные клиенты
могут установить SESSION , чтобы затронуть их собственное
использование кэша запроса. Возможные значения
показывают в следующей таблице.
Опция | Описание |
0 или OFF |
Не кэшировать результаты запроса. Отметьте, что это не освобождает буфер кэша
запроса. Чтобы сделать это, Вы должны установить
query_cache_size
= 0. |
1 или ON |
Кэшировать все результаты за исключением тех, которые начинаются с
SELECT SQL_NO_CACHE . |
2 или DEMAND |
Кэш только для запросов, которые начинаются с SELECT SQL_CACHE .
|
По умолчанию OFF .
Если сервер запущен с query_cache_type = 0,
это не приобретает кэш запроса mutex вообще, что означает, что кэш запроса
не может быть включен во время выполнения и уменьшены
издержки в выполнении запроса.
-
query_cache_wlock_invalidate
Формат командной строки
| --query_cache_wlock_invalidate
|
Системная переменная
| Имя |
query_cache_wlock_invalidate |
Область действия |
Глобальная, Сеансовая |
Динамическая |
Да |
Допустимые значения
| Тип |
boolean |
Значение по умолчанию |
FALSE |
Обычно, когда один клиент приобретает блокировку WRITE на
таблице MyISAM , другие клиенты не заблокированы для запросов,
которые читают из таблицы, если результаты запроса присутствуют в кэше
запроса. Установка этой переменной к 1 при блокировке WRITE
лишает законной силы любые запросы в кэше запроса, которые обращаются к
таблице. Это вынуждает других клиентов, которые пытаются получить доступ к
таблице, ждать в то время, как блокировка взята.
-
query_prealloc_size
Формат командной строки
| --query_prealloc_size=# |
Системная переменная
| Имя |
query_prealloc_size |
Область действия |
Глобальная, Сеансовая |
Динамическая |
Да |
Допустимые значения
(32-bit platforms) | Тип |
integer |
Значение по умолчанию |
8192 |
Минимум |
8192 |
Максимум |
4294967295 |
Block Size |
1024 |
Допустимые значения
(64-bit platforms) | Тип |
integer |
Значение по умолчанию |
8192 |
Минимум |
8192 |
Максимум |
18446744073709551615 |
Block Size |
1024 |
Размер постоянного буфера, используемого для парсинга и выполнения
запроса. Этот буфер не освобожден между запросами. Если Вы выполняете сложные
запросы, большее значение
query_prealloc_size могло бы быть полезным в работе, потому
что это может уменьшить потребность в распределении памяти во время
операций выполнения запроса.
-
rand_seed1
rand_seed1 и
rand_seed2
существуют только как переменные сеанса и могут быть установлены, но не
считаны. Эти переменные показаны в
выводе SHOW VARIABLES .
Цель этих переменных состоит в том, чтобы поддержать репликацию функции
RAND() .
Для запросов, которые вызывают
RAND() , ведущее устройство передает два значения к ведомому
устройству, где они используются, чтобы отобрать генератор случайных чисел.
Ведомое устройство использует эти значения, чтобы установить переменные
сеанса rand_seed1 и
rand_seed2
так, чтобы RAND()
на ведомом устройстве производила то же самое значение, как на ведущем.
-
rand_seed2
См. описание для
rand_seed1 .
-
range_alloc_block_size
Формат командной строки
| --range_alloc_block_size=# |
Системная переменная
| Имя |
range_alloc_block_size |
Область действия |
Глобальная, Сеансовая |
Динамическая |
Да |
Допустимые значения
| Тип |
integer |
Значение по умолчанию |
4096 |
Минимум |
4096 |
Максимум |
4294967295 |
Block Size |
1024 |
Допустимые значения
(64-bit platforms) | Тип |
integer |
Значение по умолчанию |
4096 |
Минимум |
4096 |
Максимум |
18446744073709547520 |
Block Size |
1024 |
Размер блоков, которые выделены, делая оптимизацию диапазона.
-
range_optimizer_max_mem_size
Формат командной строки
| --range_optimizer_max_mem_size=N
|
Системная переменная
| Имя |
range_optimizer_max_mem_size |
Область действия |
Глобальная, Сеансовая |
Динамическая |
Да |
Допустимые значения
| Тип |
integer |
Значение по умолчанию |
8388608 |
Предел на потребление памяти для оптимизации диапазона.
Значение 0 означает отсутствие ограничения. Если план выполнения, который
рассматривает оптимизатор, использует метод доступа диапазона, но
оптимизатор оценивает, что объем памяти, необходимый для этого метода,
превысил бы предел, он оставляет этот план и рассматривает другие планы.
Для получения дополнительной информации см.
раздел 9.2.1.3.4.
-
rbr_exec_mode
Системная переменная
| Имя |
rbr_exec_mode
|
Область действия |
Сеансовая |
Динамическая |
Да |
Допустимые значения
| Тип |
enumeration |
Значение по умолчанию |
STRICT |
Допустимые значения |
IDEMPOTENT |
STRICT |
Эта переменная переключает сервер между режимами
IDEMPOTENT и STRICT . IDEMPOTENT
вызывает подавление ошибок duplicate-key и no-key-found. Этот режим полезен,
когда переигрывание основанного на строке двоичного журнала
вызывает конфликты с существующими данными.
mysqlbinlog
использует этот режим, когда Вы устанавливаете опцию
--idempotent :
SET SESSION RBR_EXEC_MODE=IDEMPOTENT;
-
read_buffer_size
Формат командной строки
| --read_buffer_size=# |
Системная переменная
| Имя |
read_buffer_size |
Область действия |
Глобальная, Сеансовая |
Динамическая |
Да |
Допустимые значения
| Тип |
integer |
Значение по умолчанию |
131072 |
Минимум |
8200 |
Максимум |
2147479552 |
Каждый поток, который делает последовательный просмотр для таблиц
MyISAM , выделяет буфер этого размера (в байтах) для каждой
таблицы, которую просматривает. Если Вы делаете много последовательных
просмотров, Вы могли бы хотеть увеличить это значение, которое по умолчанию
131072. Значение этой переменной должно быть кратным 4KB. Если это будет
установлено в значение, которое не является кратным 4KB, то его значение
будет округлено в меньшую сторону к самому близкому кратному числу.
Эта опция также используется в следующем контексте для
всех механизмов хранения:
и в одном другом особенном методе механизма хранения: чтобы определить
размер блока памяти для таблиц
MEMORY .
Максимальная допустимая установка для
read_buffer_size
2GB.
См. раздел 9.12.3.1.
-
read_only
Формат командной строки |
--read_only |
Системная переменная
| Имя |
read_only |
Область действия |
Глобальная |
Динамическая |
Да |
Допустимые значения
| Тип |
boolean |
Значение по умолчанию |
OFF |
Когда read_only
включена, сервер не разрешает обновлений клиента кроме пользователей, которые
имеют привилегию SUPER .
Эта переменная отключена по умолчанию.
Сервер также поддерживает переменную
super_read_only
(отключена по умолчанию), которая имеет эти эффекты:
Даже с включенной read_only
сервер разрешает эти операции:
Обновления, выполненные ведомыми потоками, если сервер ведомое
устройство. В установках может быть полезно включить
read_only на
ведомых серверах, чтобы гарантировать, что ведомые устройства принимают
обновления только от главного сервера, а не от клиентов.
ANALYZE TABLE или
OPTIMIZE TABLE .
Цель режима только для чтения состоит в том, чтобы предотвратить изменения
структуры таблицы или содержания. Анализ и оптимизация их не меняют.
Это означает, например, что проверки непротиворечивости на ведомых
устройствах только для чтения могут быть выполнены с помощью
mysqlcheck --all-databases
--analyze.
- Операции на таблицах
TEMPORARY .
- Вставки в таблицы журнала (
mysql.general_log и
mysql.slow_log ), см.
раздел 6.4.1.
- Обновления Performance Schema, например, таблиц
UPDATE или
TRUNCATE TABLE .
Изменения read_only
на главном сервере не копируются к ведомым серверам. Значение может быть
установлено на ведомом сервере, независимом от установки
на ведущем устройстве.
Следующие условия относятся к попыткам включить
read_only
(включая неявные попытки, следующие из включения
super_read_only
):
read_rnd_buffer_size
Формат командной строки
| --read_rnd_buffer_size=# |
Системная переменная
| Имя |
read_rnd_buffer_size
|
Область действия |
Глобальная, Сеансовая |
Динамическая |
Да |
Допустимые значения
| Тип |
integer |
Значение по умолчанию |
262144 |
Минимум |
1 |
Максимум |
2147483647 |
Эта переменная используется для чтений из MyISAM
и, для любого механизма хранения, для оптимизации Multi-Range Read.
Читая строки из MyISAM в сортированном порядке после
сортировки ключей, строки считаны через этот буфер, чтобы избежать
дисковых поисков. См.
раздел 9.2.1.15.
Установка переменной к большому значению может улучшить
ORDER BY . Однако, это буфер, выделенный для каждого клиента,
таким образом, Вы не должны установить глобальную переменную в большое
значение. Вместо этого замените переменную сеанса только для тех клиентов,
которые должны выполнить большие запросы.
Максимальная допустимая установка для
read_rnd_buffer_size
2GB.
Для получения дополнительной информации об использовании памяти во время
различных операций см. раздел 9.12.3.1.
Для информации об оптимизации Multi-Range Read см.
раздел 9.2.1.13.
-
relay_log_purge
Формат командной строки
| --relay_log_purge |
Системная переменная
| Имя |
relay_log_purge |
Область действия |
Глобальная |
Динамическая |
Да |
Допустимые значения
| Тип |
boolean |
Значение по умолчанию |
TRUE |
Отключает или включает автоматическую чистку файлов системного журнала
реле, как только они больше не необходимы. Значение по умолчанию 1
(ON ).
-
relay_log_space_limit
Формат командной строки
| --relay_log_space_limit=# |
Системная переменная
| Имя |
relay_log_space_limit |
Область действия |
Глобальная |
Динамическая |
Нет |
Допустимые значения
(32-bit platforms) | Тип |
integer |
Значение по умолчанию |
0 |
Минимум |
0 |
Максимум |
4294967295 |
Допустимые значения
(64-bit platforms) | Тип |
integer |
Значение по умолчанию |
0 |
Минимум |
0 |
Максимум |
18446744073709551615 |
Максимальное количество пространства, чтобы использовать для
всех журналов реле.
-
report_host
Формат командной строки
| --report-host=host_name |
Системная переменная
| Имя |
report_host
|
Область действия |
Глобальная |
Динамическая |
Нет |
Допустимые значения |
Тип |
string |
Значение опции
--report-host .
-
report_password
Формат командной строки
| --report-password=name |
Системная переменная
| Имя |
report_password |
Область действия |
Глобальная |
Динамическая |
Нет |
Допустимые значения |
Тип |
string |
Значение опции
--report-password . Не то же самое, как пароль, который
используется для учетной записи пользователя репликации MySQL.
-
report_port
Формат командной строки
| --report-port=# |
Системная переменная
| Имя |
report_port
|
Область действия |
Глобальная |
Динамическая |
Нет |
Допустимые значения
| Тип |
integer |
Значение по умолчанию |
[slave_port] |
Минимум |
0 |
Максимум |
65535 |
Значение опции
--report-port .
-
report_user
Формат командной строки
| --report-user=name |
Системная переменная
| Имя |
report_user
|
Область действия |
Глобальная |
Динамическая |
Нет |
Допустимые значения |
Тип |
string |
Значение опции
--report-user . Не то же самое, как название учетной записи
пользователя репликации MySQL.
-
require_secure_transport
Формат командной строки
| --require_secure_transport[={OFF|ON}]
|
Системная переменная
| Имя |
require_secure_transport |
Область действия |
Глобальная |
Динамическая |
Да |
Допустимые значения
| Тип |
boolean |
Значение по умолчанию |
OFF |
Обязаны ли соединения клиента с сервером использовать некоторую форму
безопасного транспорта. Когда эта переменная включена, сервер разрешает
только соединения TCP/IP, которые используют SSL, или соединения, которые
используют файл сокета (Unix) или совместно используемую память (Windows).
Сервер отклоняет нережимные попытки соединения, которые терпят неудачу с
ошибкой
ER_SECURE_TRANSPORT_REQUIRED .
Эта способность добавляет учетной записи требования SSL, которые имеют
приоритет. Если учетная запись определена с REQUIRE SSL ,
включение
require_secure_transport не позволяет использовать учетную запись,
чтобы соединиться с использованием файла сокета Unix.
Для сервера возможно не иметь безопасные транспортные средства в наличии.
Например, сервер в Windows не поддерживает безопасных транспортных средств,
если запущен, не определяя сертификаты SSL или ключевые файлы и с выключенной
опцией shared_memory
. При этих условиях попытки включить
require_secure_transport при запуске заставляют сервер писать
сообщение в журнал ошибок и завершиться. Попытки включить переменную во время
выполнения терпят неудачу с ошибкой
ER_NO_SECURE_TRANSPORTS_CONFIGURED .
-
rpl_semi_sync_master_enabled
Системная переменная
| Имя |
rpl_semi_sync_master_enabled |
Область действия |
Глобальная |
Динамическая |
Да |
Допустимые значения
| Тип |
boolean |
Значение по умолчанию |
OFF |
Включена ли полусинхронная репликация на ведущем устройстве. Чтобы
включить или отключить плагин, установите эту переменную в
ON или OFF (1 или 0), соответственно.
Значение по умолчанию OFF .
Эта переменная доступна, только если основная сторона
полусинхронного плагина установлена.
-
rpl_semi_sync_master_timeout
Системная переменная
| Имя |
rpl_semi_sync_master_timeout |
Область действия |
Глобальная |
Динамическая |
Да |
Допустимые значения
| Тип |
integer |
Значение по умолчанию |
10000 |
Допустимые значения
| Тип |
integer |
Значение по умолчанию |
10000 |
Значение в миллисекундах, которое управляет, сколько времени ведущее
устройство ждет подтверждения от ведомого устройства перед синхронизацией и
возвратом к асинхронной репликации. Значение по умолчанию 10000 (10 секунд).
Эта переменная доступна, только если основная сторона
полусинхронного плагина установлена.
-
rpl_semi_sync_master_trace_level
Уровень трассировки полусинхронной репликации
на ведущем устройстве. Определены четыре уровня:
Эта переменная доступна, только если основная сторона
полусинхронного плагина установлена.
-
rpl_semi_sync_master_wait_for_slave_count
Число подтверждений, которое ведущее устройство должно получить за
транзакцию перед обработкой. По умолчанию
rpl_semi_sync_master_wait_for_slave_count
1 , что означает обработку после получения единственного ведомого
подтверждения. Работает лучше для маленьких значений этой переменной.
Например, если rpl_semi_sync_master_wait_for_slave_count
2 , то 2 ведомых устройства должны подтвердить получение
транзакции перед периодом тайм-аута, сконфигурированным
rpl_semi_sync_master_timeout для продолжения полусинхронной
репликации. Если меньше ведомых устройств подтверждает получение транзакции
во время периода тайм-аута, ведущее устройство
возвращается к нормальной репликации.
Это поведение также зависит от
rpl_semi_sync_master_wait_no_slave .
Эта переменная доступна, только если основная сторона
полусинхронного плагина установлена.
-
rpl_semi_sync_master_wait_no_slave
Ждет ли ведущее устройство периода тайм-аута, сконфигурированного
rpl_semi_sync_master_timeout , даже если количество ведомых
меньше числа ведомых устройств, сконфигурированных
rpl_semi_sync_master_wait_for_slave_count
во время периода тайм-аута.
Когда значение rpl_semi_sync_master_wait_no_slave =
ON (значение по умолчанию), допустимо число ведомых меньше
rpl_semi_sync_master_wait_for_slave_count
во время периода тайм-аута. Пока достаточно многие ведомые устройства
признают транзакцию прежде, чем период тайм-аута истечет,
полусинхронная репликация продолжается.
Когда значение rpl_semi_sync_master_wait_no_slave =
OFF , если количество ведомых меньше, чем число,
сконфигурированное в
rpl_semi_sync_master_wait_for_slave_count
в любое время во время периода тайм-аута, сконфигурированного
rpl_semi_sync_master_timeout , ведущее устройство
возвращается к нормальной репликации.
-
rpl_semi_sync_master_wait_point
Системная переменная
| Имя |
rpl_semi_sync_master_wait_point |
Область действия |
Глобальная |
Динамическая |
Да |
Допустимые значения
| Тип |
enumeration |
Значение по умолчанию |
AFTER_SYNC |
Допустимые значения |
AFTER_SYNC |
AFTER_COMMIT |
Эта переменная управляет пунктом, в котором полусинхронное ведущее
устройство ждет подтверждения от ведомого прежде, чем возвратить состояние
клиенту, который передал транзакцию. Эти значения разрешены:
AFTER_SYNC (значение по умолчанию): ведущее
устройство пишет каждую транзакцию в двоичный журнал и ведомому устройству,
и синхронизирует двоичный журнал с диском. Ведущее устройство ждет
подтверждение от ведомого после синхронизации. После получения подтверждения
ведущее устройство передает транзакцию механизму хранения и возвращает
результат клиенту, который тогда может продолжить работу.
AFTER_COMMIT : Ведущее устройство пишет каждую транзакцию
в двоичный журнал и ведомому устройству, синхронизирует двоичный журнал, и
передает транзакцию механизму хранения. Ведущее устройство ждет
подтверждение от ведомого. После получения ведущее устройство возвращает
результат клиенту, который тогда может продолжить работу.
Характеристики репликации этих настроек отличаются следующим образом:
С AFTER_SYNC все клиенты видят преданную транзакцию в
то же самое время: после того, как это было признано ведомым устройством и
передано механизму хранения на ведущем устройстве. Таким образом, все клиенты
видят те же самые данные по ведущему устройству.
В случае отказа все транзакции на ведущем устройстве, скопированы
ведомому устройству (сохранены в его журнале реле). Катастрофический отказ
ведущего устройства проходит без потерь на ведомом, потому
что ведомое современно.
- С
AFTER_COMMIT клиент, выпускающий транзакцию, получает
статус возврата только после того, как сервер передает данные механизму
хранения и получает подтверждение.
Если что-то идет не так, как надо, таким образом, что ведомое устройство
не обрабатывает транзакцию, то в случае катастрофического отказа, возможно,
что клиенты будут видеть потерю данных относительно того, что они видели
на ведущем устройстве.
С добавлением
rpl_semi_sync_master_wait_point в MySQL 5.7
создавалось ограничение совместимости версий, потому что это увеличивает
версию полусинхронного интерфейса: черверы для MySQL 5.7 и выше не работают с
полусинхронными плагинами ответа от более старых версий.
-
rpl_semi_sync_slave_enabled
Системная переменная
| Имя |
rpl_semi_sync_slave_enabled |
Область действия |
Глобальная |
Динамическая |
Да |
Допустимые значения
| Тип |
boolean |
Значение по умолчанию |
OFF |
Включена ли полусинхронная репликация на ведомом устройстве. Чтобы
включить или отключить плагин, установите эту переменную в
ON или OFF (1 или 0),
соответственно. Значение по умолчанию OFF .
-
rpl_semi_sync_slave_trace_level
Системная переменная
| Имя |
rpl_semi_sync_slave_trace_level |
Область действия |
Глобальная |
Динамическая |
Да |
Допустимые значения
| Тип |
integer |
Значение по умолчанию |
32 |
Уровень отладки полусинхронной репликации на ведомом устройстве. См.
rpl_semi_sync_master_trace_level для допустимых значений.
-
schema_definition_cache
Формат командной строки
| --schema_definition_cache=N |
Системная переменная
| Имя |
schema_definition_cache |
Область действия |
Глобальная |
Динамическая |
Да |
Допустимые значения
| Тип |
integer |
Значение по умолчанию |
256 |
Минимум |
256 |
Максимум |
524288 |
Определяет предел для числа объектов определения схемы, используемых и
неиспользуемых, которое может быть сохранено в кэше объекта словаря.
Неиспользованные объекты определения схемы сохранены в кэше объекта
словаря только когда число используемых меньше емкость, определенная
schema_definition_cache .
Установка 0 определяет, что объекты определения схемы
сохранены в кэше объекта словаря только в то время, когда они используются.
См. раздел 15.4.
-
secure_auth
Устарела |
5.7.5 |
Формат командной строки
| --secure-auth |
Системная переменная
| Имя |
secure_auth
|
Область действия |
Глобальная |
Динамическая |
Да |
Допустимые значения
| Тип |
boolean |
Значение по умолчанию |
ON |
Допустимые значения
| ON |
Если эта переменная включена, сервер блокирует соединения клиентам,
которые пытаются использовать учетные записи, которым сохранили пароли в
старом формате (pre-4.1).
Позвольте этой переменной предотвратить все использование паролей,
использующих старый формат (и следовательно опасную коммуникацию по сети).
Эта переменная устарела и будет удалена в будущем выпуске MySQL. Это
всегда включено и попытка отключить это производит ошибку.
Запуск сервера терпит неудачу с ошибкой, если эта переменная включена,
и таблицы привилегии находятся в формате pre-4.1.
Пароли, которые используют хеширующие методы pre-4.1,
менее безопасны, чем пароли, которые используют родной метод хеширования
пароля и должны быть обновлены.
secure_file_priv
Формат командной строки
| --secure-file-priv=dir_name
|
Системная переменная
| Имя |
secure_file_priv |
Область действия |
Глобальная |
Динамическая |
Нет |
Допустимые значения
| Тип |
string |
Значение по умолчанию |
platform specific |
Допустимые значения |
empty |
dirname |
NULL |
Эта переменная используется, чтобы ограничить эффект импорта данных и
экспортных операций, таких как
LOAD DATA ,
SELECT ... INTO OUTFILE и
LOAD_FILE() .
Эти операции разрешены только пользователям, которые имеют привилегию
FILE .
secure_file_priv
может быть установлена следующим образом:
Значение по умолчанию зависит от значения
INSTALL_LAYOUT
в CMake, как показано в следующей таблице.
Чтобы определить значение по умолчанию
secure_file_priv
явно, если Вы собираете пакет из исходных текстов, используйте
опцию
INSTALL_SECURE_FILE_PRIVDIR в CMake.
Значение INSTALL_LAYOUT |
Значение по цмолчанию secure_file_priv
|
STANDALONE , WIN |
Пусто |
DEB , RPM , SLES ,
SVR4 | /var/lib/mysql-files |
Иначе | mysql-files под
CMAKE_INSTALL_PREFIX value |
Чтобы установить значение по умолчанию
secure_file_priv
для встроенного сервера libmysqld , используйте опцию
INSTALL_SECURE_FILE_PRIV_EMBEDDEDDIR в
CMake. Значение по умолчанию для
этой опции NULL .
Сервер проверяет значение
secure_file_priv
при запуске и пишет предупреждение в журнал ошибок, если значение
небезопасно. Не-NULL считают небезопасным, если это пусто,
значение является каталогом данных или его подкаталогом, или это каталог,
который доступен всем пользователям. Если
secure_file_priv
установлен в несуществующий путь, сервер пишет сообщение об ошибке в
журнал ошибок и завершается.
-
server_id
Формат командной строки
| --server-id=# |
Системная переменная
| Имя |
server_id
|
Область действия |
Глобальная |
Динамическая |
Да |
Допустимые значения
| Тип |
integer |
Значение по умолчанию |
0 |
Минимум |
0 |
Максимум |
4294967295 |
ID сервера, используемое в репликации, чтобы дать каждому ведущему и
ведомому устройствам уникальную идентичность. Эта переменная установлена
опцией --server-id
. Для каждого сервера, участвующего в репликации, Вы должны выбрать
положительное целое число в диапазоне от 1 до 232-1, чтобы
действовать как ID этого сервера.
-
session_track_gtids
Формат командной строки
| --session_track_gtids=[value]
|
Системная переменная
| Имя |
session_track_gtids |
Область действия |
Глобальная, Сеансовая |
Динамическая |
Да |
Допустимые значения
| Тип |
enumeration |
Значение по умолчанию |
OFF |
Допустимые значения |
OFF |
OWN_GTID |
ALL_GTIDS |
Управляет трекингом, чтобы получить GTID и возвратить их в пакете OK.
В зависимости от значения этой опции, в конце выполнения транзакции,
определенные GTID получены и добавлены к пакету OK.
Возможные наборы GTID, чтобы отследить:
См. раздел 25.8.7.65
.
-
session_track_schema
Формат командной строки
| --session_track_schema=# |
Системная переменная
| Имя |
session_track_schema |
Область действия |
Глобальная, Сеансовая |
Динамическая |
Да |
Допустимые значения
| Тип |
boolean |
Значение по умолчанию |
ON |
Отслеживает ли сервер изменение названия схемы по умолчанию (базы данных)
в пределах текущего сеанса и делает эту информацию доступной для клиента,
когда изменения происходят.
Если уведомление включено, о любой установке схемы по умолчанию сообщают,
даже если новое имя схемы то же самое, как старое.
См. раздел 25.8.7.65
.
-
session_track_state_change
Формат командной строки
| --session_track_state_change=#
|
Системная переменная
| Имя |
session_track_state_change |
Область действия |
Глобальная, Сеансовая |
Динамическая |
Да |
Допустимые значения
| Тип |
boolean |
Значение по умолчанию |
OFF |
Отслеживает ли сервер изменение статуса текущего сеанса и уведомляет
клиента, когда изменения происходят. Статус сеанса состоит из этих значений:
Если включено, о любых изменениях состояния сеанса сообщают, даже если
новые значения те же самые, как старые.
session_track_state_change управляет только уведомлением о том,
когда изменения происходят, а не каковы эти изменения. Чтобы получить
уведомление для изменения имени схемы по умолчанию и системных значений
переменной сеанса, используйте
session_track_schema
и
session_track_system_variables .
См. раздел 25.8.7.65
.
-
session_track_system_variables
Формат командной строки
| --session_track_system_variables=#
|
Системная переменная
| Имя |
session_track_system_variables |
Область действия |
Глобальная, Сеансовая |
Динамическая |
Да |
Допустимые значения
| Тип |
string |
Значение по умолчанию |
time_zone, autocommit, character_set_client,
character_set_results, character_set_connection |
Отслеживает ли сервер системные переменные сеанса и делает ли эту
информацию доступной для клиента, когда изменения происходят. Значение:
список разделенных запятой переменных, для которых можно отследить изменения.
По умолчанию для уведомления включают
time_zone ,
autocommit ,
character_set_client
,
character_set_results и
character_set_connection . Последние три переменные затронуты
SET NAMES .
Специальное значение * заставляет сервер отслеживать
изменения всех переменных сеанса. Если дано, это значение должно быть
определено отдельно без определенных системных имен переменной.
Уведомление происходит для всех назначений на прослеженные системные
переменные сеанса, даже если новые значения те же самые, как старые.
См. раздел 25.8.7.65
.
-
sha256_password_auto_generate_rsa_keys
Формат командной строки
| --sha256_password_auto_generate_rsa_keys[
={OFF|ON}] |
Системная переменная
| Имя |
sha256_password_auto_generate_rsa_keys |
Область действия |
Глобальная |
Динамическая |
Нет |
Допустимые значения
| Тип |
boolean |
Значение по умолчанию |
ON |
Эта переменная доступна, если сервер был собран, используя OpenSSL (см.
OpenSSL (see раздел 7.4.1).
Это управляет, генерирует ли сервер частные/общественные файлы ключевой пары
RSA в каталоге данных, если они не существуют.
При запуске сервер автоматически производит
файлы ключевой пары RSA в каталоге данных, если
sha256_password_auto_generate_rsa_keys включена, никакие опции RSA
не определены и файлы RSA отсутствуют в каталоге данных. Эти файлы включают
безопасный обмен паролями, использующий RSA по незашифрованным соединениям
для учетных записей, заверенных плагином sha256_password , см.
раздел 7.5.1.2.
См. раздел
7.4.6.1.
auto_generate_certs
связана, но не управляет генерацией сертификатов SSL и ключевых
файлов, необходимых для безопасных соединений, используя SSL.
-
sha256_password_private_key_path
Системная переменная
| Имя |
sha256_password_private_key_path |
Область действия |
Глобальная |
Динамическая |
Нет |
Допустимые значения
| Тип |
file name |
Значение по умолчанию |
private_key.pem |
Эта переменная доступна, если MySQL был собран, используя OpenSSL (см.
раздел 7.4.1).
Значение: путь частного ключевого файла RSA для плагина аутентификации
sha256_password . Если файл называют как относительный путь, он
интерпретируется относительно каталога серверных данных. Файл должен быть в
формате PEM. Поскольку это хранит частный ключ, его режим доступа должен быть
ограничен так, чтобы только сервер MySQL мог читать это.
См. раздел 7.5.1.2
.
-
sha256_password_proxy_users
Формат командной строки
| --sha256_password_proxy_users=[={OFF|ON}]
|
Системная переменная
| Имя |
sha256_password_proxy_users |
Область действия |
Глобальная |
Динамическая |
Да |
Допустимые значения
| Тип |
boolean |
Значение по умолчанию |
OFF |
Эта переменная управляет поддерживает ли
встроенный плагин аутентификации sha256_password пользователей
по доверенности. Это не имеет никакого эффекта, если
check_proxy_users
включена. См. раздел 7.3.10.
-
sha256_password_public_key_path
Системная переменная
| Имя |
sha256_password_public_key_path |
Область действия |
Глобальная |
Динамическая |
Нет |
Допустимые значения
| Тип |
file name |
Значение по умолчанию |
public_key.pem |
Эта переменная доступна, если MySQL был собран, используя OpenSSL (см.
раздел 7.4.1).
Значение это путь к файлу открытого ключа RSA для плагина аутентификации
sha256_password . Если файл называют как относительный путь, он
интерпретируется относительно каталога данных сервера. Файл должен быть в
формате PEM. Поскольку это хранит открытый ключ, копии могут быть свободно
распределены пользователям клиента. Клиенты, которые явно определяют открытый
ключ, соединяясь с сервером, используя шифрование пароля RSA, должны
использовать тот же самый открытый ключ в качестве используемого сервером.
См. раздел 7.5.1.2
.
-
shared_memory
Формат командной строки
| --shared_memory[={0,1}] |
Системная переменная
| Имя |
shared_memory |
Область действия |
Глобальная |
Динамическая |
Нет |
Платформа |
Windows |
Допустимые значения
| Тип |
boolean |
Значение по умолчанию |
FALSE |
Только Windows. Разрешает ли сервер соединения
совместно используемой памяти.
-
shared_memory_base_name
Формат командной строки
| --shared_memory_base_name=name
|
Системная переменная
| Имя |
shared_memory_base_name |
Область действия |
Глобальная |
Динамическая |
Нет |
Платформа |
Windows |
Допустимые значения
| Тип |
string |
Значение по умолчанию |
MYSQL |
Только Windows. Название совместно используемой памяти, чтобы использовать
для соединений совместно используемой памяти. Это полезно, выполняя много
копий MySQL на единственной физической машине. Имя по умолчанию
MYSQL . Имя является чувствительным к регистру.
-
show_compatibility_56
Устарела |
5.7.6 |
Формат командной строки
| --show_compatibility_56[={OFF|ON}] |
Системная переменная
| Имя |
show_compatibility_56 |
Область действия |
Глобальная |
Динамическая |
Да |
Допустимые значения
| Тип |
boolean |
Значение по умолчанию |
OFF |
INFORMATION_SCHEMA имеет таблицы, которые содержат систему и
информацию о переменной состояния (см. разделы
22.10 и
22.9). Performance Schema
также содержит систему и таблицы переменных состояния (см. разделы
23.9.13 и
23.9.14).
Таблицы Performance Schema предназначены, чтобы заменить таблицы
INFORMATION_SCHEMA , которые устарели с MySQL 5.7.6
и будут удалены в будущем выпуске MySQL.
Для совета относительно перемещения с
INFORMATION_SCHEMA на Performance Schema см.
раздел
23.17. Чтобы помочь в перемещении, Вы можете использовать переменную
show_compatibility_56
, которая затрагивает, включает ли совместимость MySQL 5.6
относительно того, как информация о переменной системы и состояния обеспечена
таблицами INFORMATION_SCHEMA и Performance Schema, а также
запросами SHOW VARIABLES и
SHOW STATUS .
show_compatibility_56 устарела, потому что ее единственная цель
состоит в том, чтобы разрешить управление устаревшей системой и источниками
информации о состоянии, которые будут удалены в будущем выпуске MySQL. Когда
те источники будут удалены,
show_compatibility_56 не будет иметь никакой цели и
будет удалена тоже.
Следующее обсуждение описывает эффекты
show_compatibility_56 :
Для лучшего понимания сильно рекомендуется, чтобы Вы также
прочитали эти разделы:
Обзор
show_compatibility_56
show_compatibility_56 затрагивает эти аспекты работы сервера
относительно переменных состояния и системы:
Этот список суммирует эффекты
show_compatibility_56
с дополнительными деталями, данными позже:
Если
show_compatibility_56 = ON ,
совместимость с MySQL 5.6 включена. Более старые источники информации
(SHOW , таблицы INFORMATION_SCHEMA )
производят тот же самый вывод как в MySQL 5.6.
- Если
show_compatibility_56 = OFF ,
совместимость с MySQL 5.6 отключена. Выбор из таблиц
INFORMATION_SCHEMA производит ошибку, потому что таблицы
Performance Schema предназначены, чтобы заменить их.
INFORMATION_SCHEMA устарела в MySQL 5.7.6
и будет удалена в будущем выпуске MySQL.
Получить информацию о переменной состояния, когда
show_compatibility_56=OFF , можно с помощью
Performance Schema или запроса SHOW .
Когда
show_compatibility_56=OFF ,
SHOW VARIABLES и
SHOW STATUS
выводят на экран строки из таблиц Performance Schema
global_variables ,
session_variables ,
global_status и
session_status .
Эти таблицы читаемы всеми даже без привилегии
SELECT , то есть
привилегия SELECT
не требуется, чтобы использовать SHOW .
Несколько переменных состояния Slave_xxx
доступны из SHOW STATUS
, когда
show_compatibility_56 = ON . Если
show_compatibility_56
= OFF , некоторые из тех переменных не выставлены
SHOW STATUS . Информация,
которую они предоставляют, доступна в связанных с
Performance Schema таблицах.
show_compatibility_56 не имеет никакого эффекта на использование
доступа к переменным с нотацией @@ :
@@GLOBAL.var_name ,
@@SESSION.var_name ,
@@var_name .
show_compatibility_56 не имеет никакого эффекта на использование
встроенного сервера, который производит совместимый с 5.6 вывод
во всех случаях.
Следующие описания детализируют эффект установки
show_compatibility_56
в ON или OFF
в контекстах, в которых применяется эта переменная.
Влияние show_compatibility_56 на запрос SHOW
SHOW GLOBAL VARIABLES :
ON : Вывод MySQL 5.6.
OFF : Вывод выводит на экран строки из таблицы Performance
Schema
global_variables .
SHOW [SESSION | LOCAL] VARIABLES
:
ON : Вывод MySQL 5.6.
OFF : Вывод выводит на экран строки из таблицы Performance
Schema
session_variables .
SHOW GLOBAL STATUS :
SHOW [SESSION | LOCAL] STATUS
:
ON : Вывод MySQL 5.6.
OFF : Вывод выводит на экран строки из таблицы Performance
Schema
session_status и счетчики выполнения запроса
Com_xxx .
Действие show_compatibility_56 на INFORMATION_SCHEMA
Таблицы INFORMATION_SCHEMA
(GLOBAL_VARIABLES ,
SESSION_VARIABLES ,
GLOBAL_STATUS и
SESSION_STATUS ):
Действие
show_compatibility_56 на Performance Schema
Таблицы Performance Schema:
Таблицы переменных состояния Performance Schema:
Действие show_compatibility_56 на ведомые переменные состояния
Ведомые переменные состояния:
Действие show_compatibility_56 на FLUSH STATUS
FLUSH STATUS :
ON : Этот запрос производит поведение MySQL 5.6.
Это добавляет, что переменные состояния сеанса текущего потока оцениваются к
глобальным значениям и сбрасывает значения сеанса к нолю. Некоторые
глобальные переменные могут быть сброшены к нолю также. Это также сбрасывает
счетчики для ключевых кэшей (по умолчанию и названный) к нолю и устанавливает
Max_used_connections
к текущему числу открытых соединений.
OFF : Этот запрос добавляет состояние сеанса всех активных
сеансов в глобальные переменные состояния, сбрасывает состояние всех активных
сеансов и сбрасывает учетную запись, узел и пользовательские значения
состояния разъединенных сеансов.
show_old_temporals
Устарела |
5.7.6 |
Формат командной строки
| --show_old_temporals={OFF|ON} |
Системная переменная
| Имя |
show_old_temporals |
Область действия |
Глобальная, Сеансовая |
Динамическая |
Да |
Допустимые значения
| Тип |
boolean |
Значение по умолчанию |
OFF |
Включает ли вывод SHOW CREATE
TABLE комментарии, чтобы отметить временные столбцы, которые были
в формате pre-5.6.4 (TIME ,
DATETIME и
TIMESTAMP без поддержки
дробных частей секунд). Эта переменная отключена по умолчанию. Если включена,
вывод SHOW CREATE TABLE
похож на это:
CREATE TABLE `mytbl` (
`ts` timestamp /* 5.5 binary format */ NOT NULL DEFAULT CURRENT_TIMESTAMP,
`dt` datetime /* 5.5 binary format */ DEFAULT NULL,
`t` time /* 5.5 binary format */ DEFAULT NULL
) DEFAULT CHARSET=latin1
Вывод для столбца COLUMN_TYPE таблицы
INFORMATION_SCHEMA.COLUMNS
затронут так же.
Эта переменная устарела и будет удалена в будущем выпуске MySQL.
-
skip_external_locking
Формат командной строки
| --skip-external-locking |
Системная переменная
| Имя |
skip_external_locking |
Область действия |
Глобальная |
Динамическая |
Нет |
Допустимые значения
| Тип |
boolean |
Значение по умолчанию |
ON |
OFF , если
mysqld использует внешнюю блокировку (системную
блокировку), ON , если внешняя блокировка отключена. Это
затрагивает только табличный доступ к
MyISAM .
Эта переменная установлена опцией
--external-locking
или
--skip-external-locking .
Внешняя блокировка отключена по умолчанию.
Внешняя блокировка затрагивает только доступ к
MyISAM .
См. раздел 9.11.5.
-
skip_name_resolve
Формат командной строки
| --skip-name-resolve |
Системная переменная
| Имя |
skip_name_resolve |
Область действия |
Глобальная |
Динамическая |
Нет |
Допустимые значения
| Тип |
boolean |
Значение по умолчанию |
OFF |
Эта переменная установлена от значения опции
--skip-name-resolve . Если она OFF , то
mysqld
решает имена хоста, проверяя соединения клиента. Если это ON ,
mysqld
использует только номера IP, в этом случае все значения столбцов
Host таблиц привилегий должны быть IP-адресами или
localhost . См. раздел 9.12.4.2
.
-
skip_networking
Формат командной строки
| --skip-networking |
Системная переменная
| Имя |
skip_networking |
Область действия |
Глобальная |
Динамическая |
Нет |
ON , если сервер разрешает только местные (не TCP/IP)
соединения. В Unix местные соединения используют файл сокета. В Windows
местные соединения используют названный канал или совместно используемую
память. Эта переменная может быть установлена в ON опцией
--skip-networking
.
-
skip_show_database
Формат командной строки
| --skip-show-database |
Системная переменная
| Имя |
skip_show_database |
Область действия |
Глобальная |
Динамическая |
Нет |
Это препятствует тому, чтобы пользователи могли использовать запрос
SHOW DATABASES , если они не
имеют привилегии SHOW
DATABASES . Это может улучшить безопасность, если у Вас есть
беспокойство по поводу пользовательской возможности видеть, что базы данных
принадлежат другим пользователям. Эффект зависит от привилегии
SHOW DATABASES :
если значение переменной ON ,
SHOW DATABASES разрешен только пользователям, которые имеют
привилегию SHOW DATABASES
, и запрос выводят на экран все имена базы данных. Если значение
OFF , SHOW DATABASES
разрешен всем пользователям, но выводит на экран названия только
тех баз данных, для которых пользователь имеет привилегию
SHOW DATABASES
или другие привилегии. Отметьте, что любую
глобальную привилегию считают привилегией для базы данных.
-
slow_launch_time
Формат командной строки
| --slow_launch_time=# |
Системная переменная
| Имя |
slow_launch_time |
Область действия |
Глобальная |
Динамическая |
Да |
Допустимые значения
| Тип |
integer |
Значение по умолчанию |
2 |
Если создание потока занимает больше времени, чем это значение
секунд, сервер увеличивает переменную
Slow_launch_threads .
-
slow_query_log
Формат командной строки
| --slow-query-log |
Системная переменная
| Имя |
slow_query_log |
Область действия |
Глобальная |
Динамическая |
Да |
Допустимые значения
| Тип |
boolean |
Значение по умолчанию |
OFF |
Включен ли медленный журнал запроса. Значение может быть 0 (или
OFF ), чтобы отключить журнал, или 1 (или ON ), чтобы
включить журнал. Значение по умолчанию зависит от опции
--slow_query_log .
Местом назначения для вывода журнала управляет системная переменная
log_output ,
если это значение NONE , никакие записи журнала не написаны, даже
если журнал включен.
Понятие "медленный" определено значением
переменной long_query_time
, см. раздел 6.4.5.
-
slow_query_log_file
Формат командной строки
| --slow-query-log-file=file_name
|
Системная переменная
| Имя |
slow_query_log_file |
Область действия |
Глобальная |
Динамическая |
Да |
Допустимые значения
| Тип |
file name |
Значение по умолчанию |
host_name-slow.log |
Название медленного файла системного журнала запроса. Значение по
умолчанию host_name -slow.log ,
но начальное значение может быть изменено опцией
--slow_query_log_file .
-
socket
Формат командной строки
| --socket={file_name|pipe_name}
|
Системная переменная
| Имя |
socket
|
Область действия |
Глобальная |
Динамическая |
Нет |
Допустимые значения
| Тип |
string |
Значение по умолчанию |
/tmp/mysql.sock |
В Unix эта переменная задает название файла сокета, который используется
для местных соединений клиента. Значение по умолчанию
/tmp/mysql.sock .
Для некоторых форматов дистрибутивов каталог мог бы отличаться,
например, /var/lib/mysql для RPM.
В Windows эта переменная задает название названного канала, который
используется для местных соединений клиента. Значение по умолчанию
MySQL (не чувствительно к регистру).
-
sort_buffer_size
Формат командной строки
| --sort_buffer_size=# |
Системная переменная
| Имя |
sort_buffer_size |
Область действия |
Глобальная, Сеансовая |
Динамическая |
Да |
Допустимые значения
(Windows) | Тип |
integer |
Значение по умолчанию |
262144 |
Минимум |
32768 |
Максимум |
4294967295 |
Допустимые значения
(Other, 32-bit platforms) | Тип
|
integer |
Значение по умолчанию |
262144 |
Минимум |
32768 |
Максимум |
4294967295 |
Допустимые значения
(Other, 64-bit platforms) | Тип
|
integer |
Значение по умолчанию |
262144 |
Минимум |
32768 |
Максимум |
18446744073709551615 |
Каждый сеанс, который должен выполнить сортировку, выделяет буфер этого
размера. sort_buffer_size
не является определенным для любого механизма хранения и
применяется в общей манере для оптимизации. В минимуме
sort_buffer_size
должно быть достаточно большим, чтобы разместить пятнадцать кортежей в
буфере сортировки. Кроме того, увеличение значения
max_sort_length
может потребовать увеличения значения
sort_buffer_size
. См. раздел 9.2.1.15.
Если Вы видите много сообщений
Sort_merge_passes
в секунду в выводе SHOW GLOBAL
STATUS , Вы можете рассмотреть увеличение
sort_buffer_size
, чтобы ускорить ORDER BY или GROUP BY , которые
не могут быть улучшены с оптимизацией запроса или улучшением индекса.
Оптимизатор пытается рассчитать, сколько места необходимо, но может
выделить больше, до предела. Установка этого больше, чем необходимо глобально
замедлит большинство запросов. Лучше увеличивать это как установку сеанса и
только для сеансов, которые нуждаются в большем размере. В Linux есть пороги
256 КБ и 2 МБ, где большие значения могут значительно замедлить распределение
памяти, таким образом, Вы должны рассмотреть значения ниже одного из этих
значений. Экспериментируйте, чтобы найти лучшее значение для Вашей рабочей
нагрузки. См. раздел B.5.3.5.
Максимальная допустимая установка для
sort_buffer_size
4GB-1. Большие значения разрешены для 64-битовых платформ (кроме 64-битной
Windows, для которой большие значения являются
усеченными к 4GB-1 с предупреждением).
-
sql_auto_is_null
Системная переменная
| Имя |
sql_auto_is_null |
Область действия |
Глобальная, Сеансовая |
Динамическая |
Да |
Системная переменная
| Имя |
sql_auto_is_null |
Область действия |
Глобальная, Сеансовая |
Динамическая |
Да |
Допустимые значения
| Тип |
boolean |
Значение по умолчанию |
0 |
Допустимые значения
| Тип |
boolean |
Значение по умолчанию |
0 |
Если эта переменная установлена в 1, то после запроса, который успешно
вставляет автоматически произведенное значение
AUTO_INCREMENT , Вы можете найти значение, делая
запрос следующей формы:
SELECT * FROM tbl_name WHERE auto_col IS NULL
Если запрос возвращает строку, значение то же самое, как будто Вы вызвали
LAST_INSERT_ID() ,
см. раздел 13.14. Если нет
успешно вставленного AUTO_INCREMENT ,
SELECT не возвращает строки.
Поведение получения AUTO_INCREMENT при использовании
IS NULL
используется некоторыми программами ODBC, такими как Access. См.
Obtaining Auto-Increment Values.
Это поведение может быть отключено, устанавливая
sql_auto_is_null
в 0.
Значение по умолчанию
sql_auto_is_null
0.
-
sql_big_selects
Системная переменная
| Имя |
sql_big_selects |
Область действия |
Глобальная, Сеансовая |
Динамическая |
Да |
Системная переменная
| Имя |
sql_big_selects |
Область действия |
Глобальная, Сеансовая |
Динамическая |
Да |
Допустимые значения
| Тип |
boolean |
Значение по умолчанию |
1 |
Если установлено в 0, MySQL аварийно прекращает
SELECT , которые, вероятно, займут
очень долгое время (то есть, запросы, для которых оптимизатор оценивает, что
число исследованных строк превышает значение
max_join_size ).
Это полезно когда нецелесообразное WHERE было сделано. Значение
по умолчанию для нового соединения 1, которое разрешает все
SELECT .
Если Вы устанавливаете
max_join_size к значению кроме DEFAULT ,
sql_big_selects
установлена в 0.
-
sql_buffer_result
Системная переменная
| Имя |
sql_buffer_result |
Область действия |
Глобальная, Сеансовая |
Динамическая |
Да |
Допустимые значения
| Тип |
boolean |
Значение по умолчанию |
0 |
Если установлена в 1,
sql_buffer_result результаты
SELECT будут помещены во временные
таблицы. Это помогает MySQL освободить табличные блокировки раньше и может
быть выгодно в случаях, где требуется много времени, чтобы послать результаты
клиенту. Значение по умолчанию 0.
-
sql_log_bin
Системная переменная
| Имя |
sql_log_bin
|
Область действия |
Сеансовая |
Динамическая |
Да |
Системная переменная
| Имя |
sql_log_bin
|
Область действия |
Глобальная, Сеансовая |
Динамическая |
Да |
Допустимые значения |
Тип |
boolean |
Сделано ли журналирование к двоичному журналу. Значение по умолчанию 1
(журналирование включено). Чтобы изменить журналирование для текущего сеанса,
измените значение сеанса для этой переменной. Пользователь сеанса должен
иметь привилегию SUPER ,
чтобы установить эту переменную.
Установка этой переменной в 0 препятствует тому, чтобы GTID был
назначен на транзакции в двоичном журнале. Если Вы используете
GTID для репликации, это означает, что, даже когда двоичное журналирование
позже включено еще раз, GTID, написанные в журнал с этого пункта, не
составляют транзакций, которые произошли во время отключения журналирования,
и те транзакции потеряны.
В MySQL 8.0 невозможно установить @@session.sql_log_bin в
пределах транзакции или подзапроса (Bug #53437).
-
sql_log_off
Системная переменная
| Имя |
sql_log_off
|
Область действия |
Глобальная, Сеансовая |
Динамическая |
Да |
Системная переменная
| Имя |
sql_log_off
|
Область действия |
Глобальная, Сеансовая |
Динамическая |
Да |
Допустимые значения
| Тип |
boolean |
Значение по умолчанию |
0 |
Сделано ли журналирование к общему журналу запроса. Значение по умолчанию
0 (сделано журналирование). Чтобы изменить журналирование для текущего
сеанса, измените значение сеанса этой переменной. Пользователь сеанса должен
иметь привилегию SUPER ,
чтобы установить эту опцию. Значение по умолчанию 0.
-
sql_mode
Формат командной строки
| --sql-mode=name |
Системная переменная
| Имя |
sql_mode
|
Область действия |
Глобальная, Сеансовая |
Динамическая |
Да |
Допустимые значения
| Тип |
set |
Значение по умолчанию |
ONLY_FULL_GROUP_BY STRICT_TRANS_TABLES NO_ZERO_IN_DATE
NO_ZERO_DATE ERROR_FOR_DIVISION_BY_ZERO NO_AUTO_CREATE_USER
NO_ENGINE_SUBSTITUTION |
Допустимые значения |
ALLOW_INVALID_DATES |
ANSI_QUOTES |
ERROR_FOR_DIVISION_BY_ZERO |
HIGH_NOT_PRECEDENCE |
IGNORE_SPACE |
NO_AUTO_CREATE_USER |
NO_AUTO_VALUE_ON_ZERO |
NO_BACKSLASH_ESCAPES |
NO_DIR_IN_CREATE |
NO_ENGINE_SUBSTITUTION |
NO_FIELD_OPTIONS |
NO_KEY_OPTIONS |
NO_TABLE_OPTIONS |
NO_UNSIGNED_SUBTRACTION |
NO_ZERO_DATE |
NO_ZERO_IN_DATE |
ONLY_FULL_GROUP_BY |
PAD_CHAR_TO_FULL_LENGTH |
PIPES_AS_CONCAT |
REAL_AS_FLOAT |
STRICT_ALL_TABLES |
STRICT_TRANS_TABLES |
Текущий режим SQL сервера, который может быть установлен динамически. См.
раздел 6.1.8.
Программы установки MySQL могут сконфигурировать режим SQL во
время процесса установки.
Если режим SQL отличается от значения по умолчанию или от того, что Вы
ожидаете, проверьте на установку в файле опции, который сервер
читает при запуске.
sql_notes
Если установлено в 1 (значение по умолчанию), предупреждения уровня
Note увеличивают warning_count , а сервер
делает их запись. Если установлено в 0, предупреждения Note
не увеличивают warning_count
, а сервер не делает их запись.
mysqldump
включает вывод, чтобы установить эту переменную в 0 так, чтобы перезагрузка
файла дампа не произвела предупреждения для событий, которые не затрагивают
целостность работы перезагрузки.
-
sql_quote_show_create
Если установлено в 1 (значение по умолчанию), сервер заключает
идентификаторы в кавычки для
SHOW CREATE TABLE и
SHOW CREATE DATABASE .
Если установлено в 0, заключение в кавычки отключено. Эта опция включена по
умолчанию так, чтобы репликация работала на идентификаторы, которые требуют
заключения в кавычки. См. разделы
14.7.5.10 и 14.7.5.6.
-
sql_safe_updates
Если установлено в 1, MySQL аварийно завершает
UPDATE или
DELETE , которые не используют ключ
в WHERE или LIMIT . Определенно, у запросов
UPDATE должен быть
WHERE , который использует ключ или LIMIT или то и
другое. DELETE должны иметь то и
другое. Это позволяет поймать
UPDATE или
DELETE , где ключи не используются
должным образом и это, вероятно, изменило бы или удалило бы большое
количество строк. Значение по умолчанию 0.
-
sql_select_limit
Системная переменная
| Имя |
sql_select_limit |
Область действия |
Глобальная, Сеансовая |
Динамическая |
Да |
Допустимые значения |
Тип |
integer |
Максимальное количество строк, чтобы возвратить из
SELECT .
Значение по умолчанию для нового соединения это максимальное количество
строк, которые сервер разрешает для таблицы. Типичные значения по умолчанию:
(232)-1 или (264)-1. Если Вы изменили предел, значение
по умолчанию может быть восстановлено, назначая значение DEFAULT
.
Если SELECT имеет
LIMIT , то LIMIT имеет приоритет перед значением
sql_select_limit
.
-
sql_warnings
Эта переменная управляет производят ли однострочные
INSERT
информационную строку, если предупреждения происходят.
Значение по умолчанию 0. Установите значение в 1, чтобы
произвести информационную строку.
-
ssl_ca
Формат командной строки
| --ssl-ca=file_name |
Системная переменная
| Имя |
ssl_ca
|
Область действия |
Глобальная |
Динамическая |
Нет |
Допустимые значения |
Тип |
file name |
Путь к файлу со списком доверенных SSL CA.
-
ssl_capath
Формат командной строки
| --ssl-capath=dir_name |
Системная переменная
| Имя |
ssl_capath
|
Область действия |
Глобальная |
Динамическая |
Нет |
Допустимые значения |
Тип |
directory name |
Путь к каталогу, который содержит сертификаты доверенных
SSL CA в формате PEM.
-
ssl_cert
Формат командной строки
| --ssl-cert=file_name |
Системная переменная
| Имя |
ssl_cert
|
Область действия |
Глобальная |
Динамическая |
Нет |
Допустимые значения |
Тип |
file name |
Название файла сертификата SSL, чтобы использовать для того, чтобы
основать безопасное соединение.
-
ssl_cipher
Формат командной строки
| --ssl-cipher=name |
Системная переменная
| Имя |
ssl_cipher
|
Область действия |
Глобальная |
Динамическая |
Нет |
Допустимые значения |
Тип |
string |
Список допустимых шифров, чтобы использовать для шифрования SSL.
-
ssl_crl
Формат командной строки
| --ssl-crl=file_name |
Системная переменная
| Имя |
ssl_crl
|
Область действия |
Глобальная |
Динамическая |
Нет |
Допустимые значения |
Тип |
file name |
Путь к файлу, содержащему список аннулированных сертификатов
в формате PEM. Аннулирование работает для дистрибутивов MySQL, собранных,
используя OpenSSL (но не yaSSL). См.
раздел 7.4.1.
-
ssl_crlpath
Формат командной строки
| --ssl-crlpath=dir_name |
Системная переменная
| Имя |
ssl_crlpath
|
Область действия |
Глобальная |
Динамическая |
Нет |
Допустимые значения |
Тип |
directory name |
Путь к каталогу, который содержит файлы, содержащие списки аннулирования
сертификатов в формате PEM. Аннулирование работает для дистрибутивов MySQL,
собранных, используя OpenSSL (но не yaSSL). См.
раздел 7.4.1.
-
ssl_key
Формат командной строки
| --ssl-key=file_name |
Системная переменная
| Имя |
ssl_key
|
Область действия |
Глобальная |
Динамическая |
Нет |
Допустимые значения |
Тип |
file name |
Название файла ключа SSL, чтобы использовать для того, чтобы
основать безопасное соединение.
-
stored_program_cache
Формат командной строки
| --stored-program-cache=# |
Системная переменная
| Имя |
stored_program_cache |
Область действия |
Глобальная |
Динамическая |
Да |
Допустимые значения
| Тип |
integer |
Значение по умолчанию |
256 |
Минимум |
16 |
Максимум |
524288 |
Устанавливает мягкий верхний предел для числа кэшируемых сохраненных
подпрограмм на соединение. Значение этой переменной определено с точки зрения
числа сохраненных подпрограмм, проводимых в каждом из этих двух кэшей,
поддержанных MySQL Server для, соответственно, хранимых процедур и функций.
Всякий раз, когда сохраненная подпрограмма выполнена, этот размер кэша
проверен прежде, чем запрос первого или верхнего уровня в подпрограмме
разобран, если число подпрограмм того же самого типа (хранимые процедуры или
функции) превышает предел, определенный этой переменной, соответствующий кэш
сбрасывается, и память, ранее выделенная для кэшируемых объектов,
освобождена. Это позволяет сбросить кэш безопасно, даже когда есть
зависимости между сохраненными подпрограммами.
Кэши хранимых процедур и функций существуют параллельно с сохраненным
разделением кэша определения программы
dictionary
object cache. Кэши хранимых процедур и функций работают для
соединения в то время, как кэш определения программы использован совместно.
У существования объектов в кэшах хранимых процедур и функций
нет никакой зависимости от существования объектов в сохраненном кэше
определения программы, и наоборот. Для получения дополнительной информации
см. раздел 15.4.
-
stored_program_definition_cache
Формат командной строки
| --stored_program_definition_cache=N
|
Системная переменная
| Имя |
stored_program_definition_cache |
Область действия |
Глобальная |
Динамическая |
Да |
Допустимые значения
| Тип |
integer |
Значение по умолчанию |
256 |
Минимум |
256 |
Максимум |
524288 |
Определяет предел для числа хранивмых объектов определения программы,
которые могут быть сохранены в кэше объекта словаря.
Неиспользованные объекты определения программы сохранены в кэше объекта
словаря только когда используемое число меньше емкости, определенной
stored_program_definition_cache .
Установка 0 означает хранить объекты определения программы,
в кэше объекта словаря только в то время, как они используются.
Сохраненное разделение кэша определения программы существует параллельно с
кэшами процедур и функций, которые сконфигурированы, используя опцию
stored_program_cache .
Опция
stored_program_cache устанавливает мягкий верхний предел для числа
кэшируемых хранимых процедур или функций на соединение, и предел проверен
каждый раз, когда соединение выполняет хранимую процедуру или функцию.
Сохраненное разделение кэша определения программы, с другой стороны, является
совместно используемым кэшем, который хранит сохраненные объекты определения
программы в других целях. У существования объектов в сохраненном разделении
кэша определения программы нет никакой зависимости от существования объектов
в кэшах хранимых процедур или функций, и наоборот.
См. раздел 15.4.
-
super_read_only
Формат командной строки
| --super_read_only[={OFF|ON}]
|
Системная переменная
| Имя |
super_read_only |
Область действия |
Глобальная |
Динамическая |
Да |
Допустимые значения
| Тип |
boolean |
Значение по умолчанию |
OFF |
Если read_only
включена, сервер разрешает, чтобы клиент обновил данные только от имени
пользователей, которые имеют привилегию
SUPER , если
super_read_only
тоже включена, сервер запрещает обновления даже от пользователей, которые
имеют привилегию SUPER .
Изменения
super_read_only на главном сервере не копируются к ведомым
серверам. Значение может быть установлено на ведомом сервере, независимо от
установки на ведущем устройстве.
-
system_time_zone
Системная переменная
| Имя |
system_time_zone |
Область действия |
Глобальная |
Динамическая |
Нет |
Допустимые значения |
Тип |
string |
Системный часовой пояс сервера. Когда сервер начинает выполняться, он
наследует установку часового пояса от машинных значений по умолчанию,
возможно, измененных окружающей средой учетной записи, используемой для того,
чтобы выполнить сервер или скрипт запуска. Значение используется, чтобы
установить
system_time_zone . Как правило, часовой пояс определен переменной
окружения TZ . Это также может быть определено, используя опцию
--timezone
в скрипте mysqld_safe
.
system_time_zone
отличается от time_zone
. Хотя у них могло бы быть то же самое значение, последняя
переменная используется, чтобы инициализировать часовой пояс для каждого
клиента, который соединяется. См.
раздел 11.6.
-
tablespace_definition_cache
Формат командной строки
| --tablespace_definition_cache=N
|
Системная переменная
| Имя |
tablespace_definition_cache |
Область действия |
Глобальная |
Динамическая |
Да |
Допустимые значения
| Тип |
integer |
Значение по умолчанию |
256 |
Минимум |
256 |
Максимум |
524288 |
Определяет предел для числа объектов определения табличного пространства,
которые могут быть сохранены в кэше объекта словаря.
Неиспользованные объекты определения табличного пространства
сохранены в кэше объекта словаря только, когда число меньше емкости,
определенной tablespace_definition_cache .
Установка 0 предписывает, что
объекты определения табличного пространства сохранены в кэше объекта словаря
только в то время, когда они используются.
См. раздел 15.4.
-
table_definition_cache
Системная переменная
| Имя |
table_definition_cache |
Область действия |
Глобальная |
Динамическая |
Да |
Допустимые значения
| Тип |
integer |
Значение по умолчанию |
-1 (autosized) |
Минимум |
400 |
Максимум |
524288 |
Допустимые значения
| Тип |
integer |
Значение по умолчанию |
256 |
Минимум |
256 |
Максимум |
524288 |
Число табличных определений, которые могут быть сохранены в кэше
определения. Если Вы используете большое количество таблиц, Вы можете создать
большой табличный кэш определения, чтобы ускорить открытие таблиц. Табличный
кэш определения занимает меньше места и не использует описатели файла, в
отличие от нормального табличного кэша.
Минимальное значение 400. Значение по умолчанию основано на
следующей формуле с пределом в 2000:
400 + (table_open_cache / 2)
Для InnoDB
table_definition_cache действует как мягкий предел для числа
открытых таблиц в кэше словаря данных InnoDB . Если число
открытых таблиц превышает
table_definition_cache , LRU начинает отмечать таблицы для
вычеркивания из кэша и в конечном счете удаляет их из кэша словаря данных.
Предел помогает обратиться к ситуациям, в которых существенное количество
памяти использовалось бы, чтобы кэшировать редко используемые таблицы до
следующего перезапуска сервера. Число табличных случаев с кэшируемыми
метаданными могло быть выше чем предел, определенный
table_definition_cache , поскольку системные таблицы
InnoDB , а также родительские и дочерние таблицы с отношениями
внешнего ключа не помещены в список LRU и не подвергаются
вычеркиванию из памяти.
Дополнительно
table_definition_cache определяет мягкий предел для числа
табличных пространств InnoDB
file-per-table, которые могут быть открыты, что также управляется
innodb_open_files
. Если установлены
table_definition_cache и
innodb_open_files
, самая высокая установка используется. Если никакая переменная не
установлена, используется
table_definition_cache , у которой есть более высокое
значение по умолчанию. Если число открытых дескрипторов табличного
пространства превышает предел, определенный
table_definition_cache или
innodb_open_files
, LRU ищет в списке файл табличного пространства LRU файлы, которые
полностью сброшены и в настоящее время не расширяются. Этот процесс выполнен
каждый раз, когда новое табличное пространство открыто. Если нет никаких
неактивных табличных пространств, никакие файлы
табличного пространства не закрыты.
Табличный кэш определения существует параллельно с табличным разделением
кэша определения
dictionary object cache. Оба кэша хранят табличные определения, но служат
различным частям сервера MySQL. У объектов в одном кэше нет никакой
зависимости от объектов в другом. Для получения дополнительной информации см.
раздел 15.4.
-
table_open_cache
Системная переменная
| Имя |
table_open_cache |
Область действия |
Глобальная |
Динамическая |
Да |
Допустимые значения
| Тип |
integer |
Значение по умолчанию |
2000 |
Минимум |
1 |
Максимум |
524288 |
Допустимые значения
| Тип |
integer |
Значение по умолчанию |
64 |
Минимум |
1 |
Максимум |
524288 |
Число открытых таблиц для всех потоков. Увеличение этого значения
увеличивает число описателей файла, которых требует
mysqld.
Вы можете проверить, должны ли Вы увеличить табличный кэш, проверяя
переменную Opened_tables
, см. раздел 6.1.7
. Если значение
Opened_tables является большим, и Вы не используете
FLUSH TABLES
часто (который вынуждает все таблицы быть закрытыми и вновь открытыми), тогда
Вы должны увеличить значение
table_open_cache
. См. раздел 9.4.3.1.
-
table_open_cache_instances
Системная переменная
| Имя |
table_open_cache_instances |
Область действия |
Глобальная |
Динамическая |
Нет |
Допустимые значения
| Тип |
integer |
Значение по умолчанию |
16 |
Минимум |
1 |
Максимум |
64 |
Число открытых табличных кэшей. Чтобы улучшить масштабируемость, уменьшая
издержки среди сеансов, открытый табличный кэш может быть разделен на
несколько меньших кэшей
table_open_cache
/
table_open_cache_instances .
Сеанс должен заблокировать только один экземпляр, чтобы получить доступ к
этому для запросов DML. Этот доступ разрешает более высокую
производительность для операций, которые используют кэш, когда есть много
сеансов, получающих доступ к таблицам. Ззапросы DDL все еще требуют
блокировки всего кэша, но такие запросы являются намного менее частыми,
чем запросы DML.
Значение 8 или 16 рекомендуется на системах, которые обычно используют 16
или больше ядер.
-
thread_cache_size
Формат командной строки
| --thread_cache_size=# |
Системная переменная
| Имя |
thread_cache_size |
Область действия |
Глобальная |
Динамическая |
Да |
Допустимые значения
| Тип |
integer |
Значение по умолчанию |
-1 (autosized) |
Минимум |
0 |
Максимум |
16384 |
Сколько потоков сервер должен кэшировать для повторного использования.
Когда клиент отсоединяется, потоки клиента помещены в кэш, если есть меньше,
чем thread_cache_size
потоков. Запросы о потоках удовлетворены, снова используя потоки,
взятые от кэша, если возможно, и только когда кэш пуст, новый поток
создается. Эта переменная может быть увеличена, чтобы улучшить работу, если у
Вас есть много новых соединений. Обычно, это не обеспечивает значительное
усовершенствование, если у Вас есть хорошее выполнение потока. Однако, если
Ваш сервер видит сотни соединений в секунду, Вы должны обычно устанавливать
thread_cache_size
достаточно высоко так, чтобы самое новые соединения работали с
кэшированными потоками. Исследуя различие между
Connections и
Threads_created
, Вы можете видеть, насколько эффективен кэш потоков. Для деталей см.
раздел 6.1.7.
Значение по умолчанию основано на следующей формуле с максимумом в 100:
8 + (max_connections / 100)
Эта переменная не имеет никакого эффекта для встроенного сервера
(libmysqld ) и не видна в пределах встроенного сервера.
-
thread_handling
Формат командной строки
| --thread_handling=name |
Системная переменная
| Имя |
thread_handling |
Область действия |
Глобальная |
Динамическая |
Нет |
Допустимые значения
| Тип |
enumeration |
Значение по умолчанию |
one-thread-per-connection |
Допустимые значения |
no-threads |
one-thread-per-connection
|
dynamically-loaded |
Допустимые значения
| Тип |
enumeration |
Значение по умолчанию |
one-thread-per-connection |
Допустимые значения |
no-threads |
one-thread-per-connection
|
pool-of-threads |
Обрабатывающая поток модель используется сервером для потоков соединения.
Допустимые значения: no-threads (сервер использует единственный
поток, чтобы обработать одно соединение) и
one-thread-per-connection (сервер использует один поток, чтобы
обработать каждое соединение клиента).
no-threads полезно для отладки под Linux, см.
раздел 26.5.
Эта переменная не имеет никакого эффекта для встроенного сервера
(libmysqld ) и не видна в пределах встроенного сервера.
-
thread_stack
Формат командной строки
| --thread_stack=# |
Системная переменная
| Имя |
thread_stack
|
Область действия |
Глобальная |
Динамическая |
Нет |
Допустимые значения
(32-bit platforms) | Тип |
integer |
Значение по умолчанию |
196608 |
Минимум |
131072 |
Максимум |
4294967295 |
Block Size |
1024 |
Допустимые значения
(64-bit platforms) | Тип |
integer |
Значение по умолчанию |
262144 |
Минимум |
131072 |
Максимум |
18446744073709551615 |
Block Size |
1024 |
Размер стека для каждого потока. Значение по умолчанию 192 КБ (256 КБ для
64-битовых систем) является достаточно большим для нормального
функционирования. Если размер стека потока является слишком маленьким, он
ограничивает сложность запросов SQL, которые сервер может обработать, глубину
рекурсии хранимых процедур и другие потребляющие память действия.
-
time_format
Эта переменная не использована. Это устарело и будет удалено в
будущем выпуске MySQL.
-
time_zone
Системная переменная
| Имя |
time_zone
|
Область действия |
Глобальная, Сеансовая |
Динамическая |
Да |
Допустимые значения |
Тип |
string |
Зона текущего времени. Эта переменная используется, чтобы инициализировать
часовой пояс для каждого клиента, который соединяется. По умолчанию начальное
значение этого 'SYSTEM' (что означает, использовать
значение system_time_zone
). Значение может быть определено явно при запуске
сервера с опцией
--default-time-zone . См.
раздел 11.6.
-
timestamp
Системная переменная
| Имя |
timestamp
|
Область действия |
Сеансовая |
Динамическая |
Да |
Допустимые значения |
Тип |
numeric |
Установите время для этого клиента. Это используется, чтобы получить
оригинальный timestamp, если Вы используете двоичный журнал, чтобы
восстановить строки. timestamp_value должна быть Unix
timestamp (значение как возвращено
UNIX_TIMESTAMP()
, а не в формате 'YYYY-MM-DD hh:mm:ss' ) или
DEFAULT .
Установите timestamp
к постоянной величине, чтобы сохранить то значение, пока оно не изменено
снова. Установка timestamp
в DEFAULT заставляет значение быть
текущей датой и временем.
В MySQL 8.0 timestamp
DOUBLE вместо BIGINT , потому что его значение
включает часть микросекунд.
SET timestamp затрагивает значение, возвращенное
NOW() , но не
SYSDATE() .
Это означает, что настройки timestamp в двоичном журнале не имеют никакого
эффекта на SYSDATE() .
Сервер может быть запущен с опцией
--sysdate-is-now
, чтобы SYSDATE()
стала псевдонимом для
NOW() , в этой ситуации SET timestamp влияет
на обе функции.
-
tls_version
Формат командной строки
| --tls_version=protocol_list
|
Системная переменная
| Имя |
tls_version
|
Область действия |
Глобальная |
Динамическая |
Нет |
Допустимые значения
(OpenSSL) | Тип |
string |
Значение по умолчанию |
TLSv1,TLSv1.1,TLSv1.2 |
Допустимые значения
(yaSSL) | Тип |
string |
Значение по умолчанию |
TLSv1,TLSv1.1 |
Протоколы, разрешенные сервером для зашифрованных соединений. Значение:
список разделенных запятой значений, содержащий одно или более имен
протокола. Протоколы, которые могут быть названы в этой переменной, зависят
от библиотеки SSL, использовавшейся, чтобы собрать MySQL. Для деталей см.
раздел 7.4.3.
-
tmp_table_size
Формат командной строки
| --tmp_table_size=# |
Системная переменная
| Имя |
tmp_table_size |
Область действия |
Глобальная, Сеансовая |
Динамическая |
Да |
Допустимые значения
| Тип |
integer |
Значение по умолчанию |
16777216 |
Минимум |
1024 |
Максимум |
18446744073709551615 |
Максимальный размер внутренних временных таблиц в памяти. Эта переменная
не относится к создаваемым пользователем таблицам MEMORY .
Фактический предел определен от меньшего из значений
tmp_table_size и
max_heap_table_size
. Если временная таблица в памяти превышает предел, MySQL
автоматически преобразовывает это во временную таблицу на диске. Опция
internal_tmp_disk_storage_engine определяет механизм хранения,
используемый для временных таблиц на диске.
Увеличьте значение
tmp_table_size (и
max_heap_table_size в случае необходимости), если Вы
применяете много сложных запросов GROUP BY ,
и Вас есть большая память.
Вы можете сравнить число внутренних временных таблиц на диске с общим
количеством внутренних временных таблиц, сравнивая значения
Created_tmp_disk_tables и
Created_tmp_tables
.
См. раздел 9.4.4.
-
tmpdir
Формат командной строки
| --tmpdir=dir_name |
Системная переменная
| Имя |
tmpdir
|
Область действия |
Глобальная |
Динамическая |
Нет |
Допустимые значения |
Тип |
directory name |
Каталог, используемый для временных файлов и временных таблиц. Эта
переменная может быть установлена в список из нескольких путей, которые
используются круговым способом. Пути должны быть отделены символами двоеточия
(: ) в Unix и точкой с запятой (; ) в Windows.
Функция многократного каталога может быть использована, чтобы
распространить загрузку между несколькими физическими дисками. Если сервер
MySQL действует как ведомое устройство, Вы не должны установить
tmpdir , чтобы
указать каталог на основанной на памяти файловой системе или к каталогу,
который очищен, когда сервер перезапускается. Ведомое устройство
нуждается в некоторых из своих временных файлов, чтобы пережить машинный
перезапуск так, чтобы оно могло копировать временные таблицы или
LOAD DATA INFILE .
Если файлы во временном каталоге файла потеряны, когда сервер
перезапускается, репликация терпит неудачу. Вы можете установить временный
каталог ведомого устройства, используя
slave_load_tmpdir
. В этом случае ведомое устройство не будет использовать
tmpdir и Вы можете
установить tmpdir
к любому непостоянному местоположению.
-
transaction_alloc_block_size
Формат командной строки
| --transaction_alloc_block_size=#
|
Системная переменная
| Имя |
transaction_alloc_block_size |
Область действия |
Глобальная, Сеансовая |
Динамическая |
Да |
Допустимые значения
| Тип |
integer |
Значение по умолчанию |
8192 |
Минимум |
1024 |
Максимум |
131072 |
Block Size |
1024 |
Количество в байтах, на которое можно увеличить память для
транзакции, которая нуждается в памяти. См. описание
transaction_prealloc_size .
-
transaction_prealloc_size
Формат командной строки
| --transaction_prealloc_size=#
|
Системная переменная
| Имя |
transaction_prealloc_size |
Область действия |
Глобальная, Сеансовая |
Динамическая |
Да |
Допустимые значения
| Тип |
integer |
Значение по умолчанию |
4096 |
Минимум |
1024 |
Максимум |
131072 |
Block Size |
1024 |
Есть блок памяти на транзакцию, из которого различные связанные с
транзакцией распределения берут память. Начальный размер в байтах
transaction_prealloc_size .
Для каждого распределения, которое не может быть удовлетворено из блока,
потому что это имеет недостаточную память в наличии, блок увеличен на
transaction_alloc_block_size байт. Когда транзакция заканчивается,
блок усечен до
transaction_prealloc_size байт.
Делая
transaction_prealloc_size достаточно большим, чтобы содержать все
запросы в пределах единственной транзакции, Вы можете избежать
многих вызовов malloc() .
-
transaction_write_set_extraction
Формат командной строки
| --transaction_write_set_extraction=[value]
|
Системная переменная
| Имя |
transaction_write_set_extraction |
Область действия |
Глобальная, Сеансовая |
Динамическая |
Да |
Допустимые значения
| Тип |
enumeration |
Значение по умолчанию |
OFF |
Допустимые значения |
OFF |
MURMUR32 |
XXHASH64 |
Сохранено для будущего использования.
-
tx_isolation
Системная переменная
| Имя |
tx_isolation
|
Область действия |
Глобальная, Сеансовая |
Динамическая |
Да |
Допустимые значения
| Тип |
enumeration |
Значение по умолчанию |
REPEATABLE-READ |
Допустимые значения |
READ-UNCOMMITTED |
READ-COMMITTED |
REPEATABLE-READ |
SERIALIZABLE |
Операционный уровень изоляции по умолчанию. Значение по умолчанию
REPEATABLE-READ
.
Эта переменная может быть установлена непосредственно или косвенно через
SET TRANSACTION . См.
раздел 14.3.6. Если Вы устанавливаете
tx_isolation
непосредственно к имени уровня изоляции, которое содержит пробел, имя должно
быть в пределах кавычек с пробелом, замененным на тире. Например:
SET tx_isolation = 'READ-COMMITTED';
Любая уникальная приставка допустимого значения может использоваться,
чтобы установить значение этой переменной.
Операционный уровень изоляции по умолчанию может также быть установлен при
запуске, используя опцию
--transaction-isolation .
-
tx_read_only
Системная переменная
| Имя |
tx_read_only
|
Область действия |
Глобальная, Сеансовая |
Динамическая |
Да |
Допустимые значения
| Тип |
boolean |
Значение по умолчанию |
OFF |
Операционный режим доступа по умолчанию. Значение может быть
OFF (read/write, по умолчанию) или
ON (read only).
Эта переменная может быть установлена непосредственно или косвенно через
SET TRANSACTION . См.
раздел 14.3.6.
Чтобы установить операционный режим доступа
по умолчанию при запуске, используйте опцию
--transaction-read-only .
-
unique_checks
Системная переменная
| Имя |
unique_checks
|
Область действия |
Глобальная, Сеансовая |
Динамическая |
Да |
Системная переменная
| Имя |
unique_checks
|
Область действия |
Глобальная, Сеансовая |
Динамическая |
Да |
Допустимые значения
| Тип |
boolean |
Значение по умолчанию |
1 |
Если установлено в 1 (значение по умолчанию), проверки уникальности на
вторичный индекс в InnoDB выполнены. Если установлено в 0,
механизмам хранения разрешают предположить, что дубликаты ключа не
присутствуют во входных данных. Если Вы знаете наверняка, что Ваши данные не
содержат нарушения уникальности, Вы можете установить это в 0, чтобы ускорить
большой табличный импорт в InnoDB .
Установка этой переменной к 0 не требует, чтобы
проигнорировать дубликаты ключа. Механизму все еще разрешают проверить на них
и выпустить ошибки, если он обнаруживает их.
-
updatable_views_with_limit
Формат командной строки
| --updatable_views_with_limit=#
|
Системная переменная
| Имя |
updatable_views_with_limit |
Область действия |
Глобальная, Сеансовая |
Динамическая |
Да |
Допустимые значения
| Тип |
boolean |
Значение по умолчанию |
1 |
Эта переменная управляет, могут ли обновления представления быть сделаны,
когда представление не содержит все столбцы первичного ключа, определенного в
основной таблице, если запрос обновления содержит LIMIT .
Такие обновления часто производятся инструментами GUI. Обновление
UPDATE или
DELETE . Первичный ключ здесь
означает PRIMARY KEY или UNIQUE индекс, в котором
никакой столбец не может содержать NULL .
У переменной может быть два значения:
validate_password_xxx
Плагин validate_password
осуществляет ряд системных переменных, имеющих названия формы
validate_password_xxx .
Эти переменные затрагивают тестирование пароля плагином, см.
раздел 7.5.2.2
.
-
validate_user_plugins
Системная переменная
| Имя |
validate_user_plugins |
Область действия |
Глобальная |
Динамическая |
Нет |
Допустимые значения
| Тип |
boolean |
Значение по умолчанию |
ON |
Если эта переменная включена (значение по умолчанию), сервер проверяет
каждую учетную запись пользователя и производит предупреждение, если условия
найдены, которые сделали бы учетную запись непригодной:
Включение validate_user_plugins
замедляет инициализацию сервера и FLUSH PRIVILEGES .
Если Вы не требуете дополнительной проверки, можете отключить эту переменную
при запуске, чтобы избежать снижения работоспособности.
-
version
Номер версии для сервера. Значение могло бы также включать
указания суффикса или информацию о конфигурации.
-log указывает, что один или больше общий журнал, медленный
журнал запроса или двоичный журнал включен. -debug
указывает, что сервер был создан с включенной поддержкой отладки.
-
version_comment
Системная переменная
| Имя |
version_comment |
Область действия |
Глобальная |
Динамическая |
Нет |
Допустимые значения |
Тип |
string |
У программы конфигурации CMake есть опция
COMPILATION_COMMENT , которая разрешает комментарию быть
определенным, создавая MySQL. Эта переменная содержит значение того
комментария. См. раздел
2.8.4.
-
version_compile_machine
Системная переменная
| Имя |
version_compile_machine |
Область действия |
Глобальная |
Динамическая |
Нет |
Допустимые значения |
Тип |
string |
Тип двоичного кода сервера.
-
version_compile_os
Системная переменная
|
Имя |
version_compile_os |
Область действия |
Глобальная |
Динамическая |
Нет |
Допустимые значения |
Тип |
string |
Тип операционной системы, на которой был создан MySQL.
-
wait_timeout
Формат командной строки
| --wait_timeout=# |
Системная переменная
| Имя |
wait_timeout
|
Область действия |
Глобальная, Сеансовая |
Динамическая |
Да |
Допустимые значения
(Windows) | Тип |
integer |
Значение по умолчанию |
28800 |
Минимум |
1 |
Максимум |
2147483 |
Допустимые значения
(Other) | Тип |
integer |
Значение по умолчанию |
28800 |
Минимум |
1 |
Максимум |
31536000 |
Число секунд, которое сервер ждет деятельности по неинтерактивному
соединению прежде, чем закрыть его.
На запуске потока, сеансовое значение
wait_timeout
инициализировано от глобального
wait_timeout или от глобального
interactive_timeout
, в зависимости от типа клиента (как определено опцией
соединения CLIENT_INTERACTIVE в
mysql_real_connect()
). См. также
interactive_timeout .
-
warning_count
Число ошибок, предупреждений и примечаний из последнего запроса, который
произвело сообщения. Эта переменная только для чтения. См.
раздел 14.7.5.40.
6.1.6.
Использование системных переменных
MySQL поддерживает много системных переменных, которые указывают, как он
сконфигурирован. Раздел 6.1.5
описывает значение этих переменных. У каждой системной переменной есть
значение по умолчанию. Системные переменные могут быть установлены в опциях
запуска сервера в командной строке или в файле опций. Большинство из них
может быть изменено динамически в то время, как сервер работает, посредством
SET , что
позволяет Вам изменить работу сервера, не имея необходимости останавливать и
перезапускать его. Вы можете также использовать системные
значения переменной в выражениях.
Есть два контекста, в которых существуют системные переменные.
Глобальные переменные затрагивают всю работу сервера. Переменные сеанса
затрагивают его работу для отдельных соединений клиента. У данной системной
переменной могут быть глобальное и значение сеанса.
Глобальные и системные переменные сеанса связаны следующим образом:
Когда сервер запускается, он инициализирует каждую глобальную
переменную к ее значению по умолчанию. Эти значения по умолчанию могут быть
изменены опциями, определенными в командной строке или в файле опций. См.
раздел 5.2.3.
- Сервер также поддерживает ряд переменных сеанса для каждого клиента,
который соединяется. Переменные сеанса клиента инициализированы во
время соединения, используя текущее значение соответствующих глобальных
переменных. Например, режимом клиента SQL управляет сеансовая переменная
sql_mode , которая
инициализирована, когда клиент соединяется со значением глобальной переменной
sql_mode .
Для некоторых системных переменных значение сеанса не инициализировано
от соответствующего глобального значения, если это так,
это обозначено в описании.
Системные значения переменной могут быть установлены глобально при запуске
сервера при использовании опций в командной строке или в файле опций. Когда
Вы используете опцию запуска, чтобы установить переменную, которая берет
числовое значение, то это значение может быть дано с суффиксом
K , M или G (в любом регистре), чтобы
указать на множитель 1024, 10242 или 10243,
то есть, килобайт, мегабайт или гигабайт, соответственно. Таким образом,
следующая команда запускает сервер с размером кэша запроса 16 мегабайт и
максимальным пакетным размером в гигабайт:
mysqld --query_cache_size=16M --max_allowed_packet=1G
В пределах файла опций те переменные установлены так:
[mysqld]
query_cache_size=16M
max_allowed_packet=1G
Регистр букв суффикса не имеет значения:
16M и 16m эквивалентны
Чтобы ограничить максимальное значение, в которое системная переменная
может быть установлена во время выполнения с помощью
SET ,
определите этот максимум при использовании опции формы
--maximum-var_name =value
при запуске сервера. Например, чтобы предотвратить значение
query_cache_size
от увеличения больше, чем до 32 МБ во время выполнения, используйте
опцию --maximum-query_cache_size=32M .
Много системных переменных являются динамическими и могут быть изменены во
время выполнения при использовании
SET . См.
раздел 6.1.6.2.
Чтобы изменить системную переменную с
SET ,
обратитесь к ней по имени, произвольно предваренному модификатором:
Чтобы указать, что переменная глобальная, предварите ее имя
ключевым словом GLOBAL
или спецификатором @@global. :
SET GLOBAL max_connections = 1000;
SET @@global.max_connections = 1000;
Привилегия SUPER
нужна, чтобы устанавливать глобальные переменные.
- Другой способ установить глобальную переменную состоит в том, чтобы
предшествовать ее имени ключевым словом
PERSIST или @@persist. :
SET PERSIST max_connections = 1000;
SET @@persist.max_connections = 1000;
Этот синтаксис SET позволяет Вам произвести изменения
конфигурации во время выполнения, которые также сохраняются через перезапуски
сервера. Как SET GLOBAL ,
SET PERSIST
изменяет значение во время выполнения, но также пишет установку переменной в
файл опций mysqld-auto.cnf в каталоге данных (заменяя любую
существующую установку переменной, если есть). При запуске сервер
обрабатывает этот файл после всех других файлов опций. Привилегия
SUPER нужна, чтобы
сохранять глобальные переменные.
Управление mysqld-auto.cnf нужно оставить серверу:
Переменная для плагина может быть сохранена, если плагин установлен, когда
SET PERSIST выполнена.
Назначение сохраненной переменной вступает в силу для последующих
перезапусков сервера, если плагин все еще установлен. Если плагин больше не
будет установлен, то переменная не будет существовать, когда сервер будет
читать mysqld-auto.cnf . В этом случае, сервер пишет
предупреждение в журнал ошибок и продолжает работу
currently unknown variable 'var_name '
was read from the persisted config file
- Чтобы указать, что это переменная сеанса, предварите ее имя ключевым
словом
SESSION , @@session. или @@ :
SET SESSION sql_mode = 'TRADITIONAL';
SET @@session.sql_mode = 'TRADITIONAL';
SET @@sql_mode = 'TRADITIONAL';
Установка переменной сеанса обычно не требует никакой специальной
привилегии, хотя есть исключения, которые требуют привилегию
SUPER (например,
sql_log_bin ).
Клиент может изменить его собственные переменные сеанса, но не таковые из
любого другого клиента.
Системные переменные только для сеанса не могут быть сохранены.
Они не могут быть установлены при запуске сервера, таким образом нет
никакой причины перечислять их в mysqld-auto.cnf .
LOCAL и @@local. синонимы
для SESSION и @@session. .
- Если никакой модификатор не присутствует,
SET
меняет переменную сеанса. Если у переменной нет никакого значения
сеанса, ошибка происходит.
mysql> SET max_connections = 1000;
ERROR 1229 (HY000): Variable 'max_connections' is a
GLOBAL variable and should be set with SET GLOBAL
- Ошибка происходит при этих обстоятельствах:
Предыдущие модификаторы применяются только к системным переменным.
Ошибка происходит для попыток применить их к определяемым пользователем
переменным, параметрам хранимой процедуры или функции или местным
переменным сохраненной программы.
SET
может содержать многократные переменные назначения, отделенные запятыми. Это
запрос назначает значения на определяемую пользователем
переменную и системную переменную:
SET @x = 1, SESSION sql_mode = '';
Если Вы устанавливаете многократные системные переменные, новый
модификатор GLOBAL или SESSION
используется для следующих назначений, у которых нет
никакого определенного модификатора.
Примеры многократного назначения переменных:
SET GLOBAL sort_buffer_size = 1000000, SESSION sort_buffer_size = 1000000;
SET @@global.sort_buffer_size = 1000000, @@local.sort_buffer_size = 1000000;
SET GLOBAL max_connections = 1000, sort_buffer_size = 1000000;
Если любое переменное назначение в
SET
терпит неудачу, весь запрос терпит неудачу, никакие переменные не изменены,
файл mysqld-auto.cnf не изменен.
Если Вы заменяете системную переменную сеанса, значение остается в силе в
пределах Вашего сеанса, пока Вы не меняете переменную к иному значению или
сеанс не закончится. Изменение не имеет никакого эффекта на другие сеансы.
Если Вы меняете глобальную системную переменную, значение
используется для новых сеансов, пока Вы не меняете переменную к иному
значению или не завершите сервер. Изменение видимо любому клиенту, который
получает доступ к глобальной переменной. Однако, изменение затрагивает
соответствующую переменную сеанса только для клиентов, которые соединяются
после изменения. Глобальное изменение не затрагивает переменную сеанса для
любых текущих сеансов клиента (даже сеанс, в пределах которого выполнена
команда SET GLOBAL ).
Чтобы сделать глобальную системную переменную постоянной установкой,
чтобы это применилось после перезапуска сервера, измените это с
SET PERSIST , чтобы
сделать запись этого в файл mysqld-auto.cnf . Также возможно
использовать SET GLOBAL
и вручную изменить my.cnf , но это более тяжело, и ошибка во
вручную вводимой установке не могла бы быть обнаружена сразу.
SET PERSIST
более удобен и избегает возможности накосячить.
Чтобы установить значение GLOBAL к вкомпилированному в
MySQL или SESSION к текущему значению соответствующей
GLOBAL , установите переменную в DEFAULT .
Например, следующие два запроса идентичны в установке значения сеансовой
переменной max_join_size
к текущему глобальному значению:
SET @@session.max_join_size=DEFAULT;
SET @@session.max_join_size=@@global.max_join_size;
Не все системные переменные могут быть установлены в DEFAULT .
В таких случаях назначение DEFAULT приводит к ошибке.
С SET PERSIST (или
@@persist. ) эффект установки глобальной переменной к ее значению
по умолчанию является определенным версией:
С MySQL 8.0.1, устанавливая глобальную переменную в
DEFAULT назначаете значение по умолчанию и удаляете это из
mysqld-auto.cnf . Установка переменной к ее буквальному значению
по умолчанию назначает значение по умолчанию и добавляет установку для
переменной к mysqld-auto.cnf .
С MySQL 8.0.1, устанавливая глобальную переменную в
DEFAULT или к буквальному значению переменной назначаете
переменной ее значение по умолчанию. Установка переменной к
DEFAULT удаляет это из файла mysqld-auto.cnf .
Установка переменной к ее буквальному значению по умолчанию добавляет
установку для переменной к mysqld-auto.cnf .
- В MySQL 8.0.0 устанавливая глобальную переменную в
DEFAULT
или к буквальному значению переменной назначает переменной ее значение по
умолчанию. Это также добавляет установку для переменной к
mysqld-auto.cnf , если ее там нет, и удаляет, если есть.
Ошибка происходит для попыток назначить DEFAULT
определяемым пользователем переменным, параметрам хранимой процедуры или
функции или местным переменным сохраненной программы.
Чтобы обратиться к значению системной переменной в выражениях, используйте
один из модификаторов @@ . Например, Вы можете получить значения
в SELECT :
SELECT @@global.sql_mode, @@session.sql_mode, @@sql_mode;
Для ссылки на системную переменную в выражении как
@@var_name (вместо
@@global. или @@session. ), MySQL
возвращает значение сеанса, если это существует и глобальное значение иначе.
Это отличается от SET @@var_name =
expr , который всегда
обращается к значению сеанса.
@@persist. не разрешен в выражениях.
Суффиксы для того, чтобы определить множитель значения могут
использоваться, устанавливая переменную при запуске сервера, но не чтобы
установить значение с SET
во время выполнения. С другой стороны, с
SET Вы можете назначить
значение переменной, используя выражение, которое не является истиной, когда
Вы устанавливаете переменную при запуске сервера. Например, первая из
следующих строк является законной при запуске сервера, но вторая нет:
shell> mysql --max_allowed_packet=16M
shell> mysql --max_allowed_packet=16*1024*1024
Наоборот, вторая из следующих строк является законной во время выполнения,
но первая нет:
mysql> SET GLOBAL max_allowed_packet=16M;
mysql> SET GLOBAL max_allowed_packet=16*1024*1024;
Некоторые системные переменные могут быть включены с
SET , устанавливая их в
ON или 1 , или отключены, устанавливая их в
OFF или 0 . Однако, чтобы установить такую
переменную в командной строке или в файле опций, Вы должны установить это в
1 или 0 , ON или OFF не
сработают. Например, в командной строке
--delay_key_write=1
работает, но
--delay_key_write=ON нет.
Чтобы вывести на экран системные имена переменной и значения, используйте
SHOW VARIABLES :
mysql> SHOW VARIABLES;
+-----------------------------+-----------------------------------+
| Variable_name | Value |
+-----------------------------+-----------------------------------+
| auto_increment_increment | 1 |
| auto_increment_offset | 1 |
| automatic_sp_privileges | ON |
| back_log | 50 |
| basedir | /home/mysql/ |
| binlog_cache_size | 32768 |
| bulk_insert_buffer_size | 8388608 |
| character_set_client | latin1 |
| character_set_connection | latin1 |
| character_set_database | latin1 |
| character_set_results | latin1 |
| character_set_server | latin1 |
| character_set_system | utf8 |
| character_sets_dir | /home/mysql/share/mysql/charsets/ |
| collation_connection | latin1_swedish_ci |
| collation_database | latin1_swedish_ci |
| collation_server | latin1_swedish_ci |
...
| innodb_autoextend_increment | 8 |
| innodb_buffer_pool_size | 8388608 |
| innodb_commit_concurrency | 0 |
| innodb_concurrency_tickets | 500 |
| innodb_data_file_path | ibdata1:10M:autoextend |
| innodb_data_home_dir | |
...
| version | 5.1.6-alpha-log |
| version_comment | Source distribution |
| version_compile_machine | i686 |
| version_compile_os | suse-linux |
| wait_timeout | 28800 |
+-----------------------------+-----------------------------------+
С LIKE запрос
выводит на экран только те переменные, которые соответствуют образцу. Чтобы
получить определенное имя переменной, используйте
LIKE :
SHOW VARIABLES LIKE 'max_join_size';
SHOW SESSION VARIABLES LIKE 'max_join_size';
Чтобы получить список переменных чье имя соответствует образцу,
используйте символ % в
LIKE :
SHOW VARIABLES LIKE '%size%';
SHOW GLOBAL VARIABLES LIKE '%size%';
Подстановочные символы могут использоваться в любой позиции в пределах
образца, который будет соответствующим. Строго говоря, потому что
_ подстановочный знак, который соответствует любому
единственному символу, Вы должны экранировать его как \_ ,
чтобы соответствовать этому буквально. Практически это редко необходимо.
Для SHOW VARIABLES ,
если Вы не определяете ни одного спецификатора GLOBAL или
SESSION , MySQL вернет SESSION .
Причина требования ключевого слова GLOBAL , устанавливая
только глобальные переменные: предотвратить проблемы в будущем. Если мы
должны были удалить переменную SESSION , у которой есть то же
самое имя как у GLOBAL , клиент с привилегией
SUPER
мог бы случайно изменить GLOBAL вместо SESSION .
Если мы добавляем SESSION с тем же самым именем, как
GLOBAL , клиент, который намеревается изменить
GLOBAL , мог бы сменить только переменную SESSION .
6.1.6.1.
Структурированные системные переменные
Структурированная переменная отличается от регулярной системной
переменной в двух отношениях:
MySQL поддерживает структурированный переменный тип, который определяет
параметры, управляющие работой ключевых кэшей. У структурированной переменной
ключевого кэша есть эти компоненты:
Этот раздел описывает синтаксис для того, чтобы обратиться к
структурированным переменным. Ключевые переменные кэша используются для
примеров синтаксиса, но определенные детали о том, как ключевые кэши
работают, могут быть найдены в другом месте, в
разделе 9.10.2.
Чтобы обратиться к компоненту структурированной переменной, Вы можете
использовать составное имя в формате
instance_name.component_name :
hot_cache.key_buffer_size
hot_cache.key_cache_block_size
cold_cache.key_cache_block_size
Для каждой структурированной системной переменной экземпляр с именем
default всегда предопределяется. Если Вы обращаетесь к
компоненту структурированной переменной без какого-либо имени экземпляра,
используется default . То есть, default.key_buffer_size
и key_buffer_size
обращаются к той же самой системной переменной.
Структурированные переменные и компоненты следуют
этим правилам обозначения:
Для данного типа структурированной переменной у каждого
экземпляра должно быть имя, которое уникально в пределах
переменных этого типа. Однако, имена не должны быть уникальными
между разными типами.
Например, у каждой структурированной переменной есть экземпляр
default , то есть, default не уникально для
разных типов переменных.
- Названия компонентов каждого структурированного переменного типа должны
быть уникальными через все системные имена переменной. Если бы это не было
так (то есть, если бы два различных типа структурированных переменных могли
бы совместно использовать составляющие членские имена), то не было бы ясно,
которое значение по умолчанию переменной использовать для ссылок на членские
имена, которые не квалифицированы именем экземпляра.
- Если структурированное переменное имя экземпляра не является законным как
неупомянутый идентификатор, именуйте его как заключенный в кавычки
идентификатор, используя обратные кавычки. Например,
hot-cache
не является законным, но `hot-cache` допустимо.
global , session и local
недопустимы. Это избегает конфликта с такой нотацией как
@@global.var_name , чтобы обратиться к
неструктурированным системным переменным.
В настоящее время, у первых двух правил нет никакой возможности быть
нарушенными, потому что единственный структурированный переменный тип это
для ключевых кэшей. Эти правила примут большее значение, если некоторый
другой тип структурированной переменной будет создаваться в будущем.
С одним исключением Вы можете обратиться к структурированным переменным
, используя составные имена в любом контексте, где простые имена переменной
могут произойти. Например, Вы можете назначить значение на структурированную
переменную, используя параметр командной строки:
shell> mysqld --hot_cache.key_buffer_size=64K
В файле опций используйте этот синтаксис:
[mysqld]
hot_cache.key_buffer_size=64K
Если Вы запускаете сервер с этой опцией, он создает ключевой кэш
hot_cache размером в 64KB в дополнение к ключевому кэшу значения
по умолчанию, у которого есть размер по умолчанию 8 МБ.
Предположите, что Вы запускаете сервер следующим образом:
shell> mysqld --key_buffer_size=256K \
--extra_cache.key_buffer_size=128K \
--extra_cache.key_cache_block_size=2048
В этом случае сервер устанавливает размер ключевого кэша
по умолчанию в 256 КБ (Вы, возможно, также написали
--default.key_buffer_size=256K ).
Кроме того, сервер создает второй ключевой кэш extra_cache ,
размером в 128 КБ с размером буферов блоков для того, чтобы кэшировать
блоки табличного индекса, в 2048 байт.
Следующий пример запускает сервер с тремя различными ключевыми кэшами,
имеющими размеры в соотношении 3:1:1:
shell> mysqld --key_buffer_size=6M \
--hot_cache.key_buffer_size=2M \
--cold_cache.key_buffer_size=2M
Структурированные переменные значения могут быть установлены и получены
также во время выполнения. Например, чтобы установить ключевой кэш
hot_cache к размеру 10 МБ, используйте любой из этих запросов:
mysql> SET GLOBAL hot_cache.key_buffer_size = 10*1024*1024;
mysql> SET @@global.hot_cache.key_buffer_size = 10*1024*1024;
Чтобы получить размер кэша, сделайте это:
mysql> SELECT @@global.hot_cache.key_buffer_size;
Однако, следующий запрос не работает. Переменная интерпретируется не как
составное имя, а как простая строка для
LIKE :
mysql> SHOW GLOBAL VARIABLES LIKE 'hot_cache.key_buffer_size';
Это исключение к возможности использовать структурированные имена
переменной где угодно.
6.1.6.2.
Динамические системные переменные
Много системных переменных сервера являются динамическими и могут быть
установлены во время выполнения при использовании
SET GLOBAL или
SET SESSION .
Вы можете также получить их значения с использование
SELECT . См.
раздел 6.1.6.
Следующая таблица показывает полный список всех динамических
системных переменных. Последний столбец указывает для каждой переменной
область действия GLOBAL , SESSION или обе сразу.
Таблица также приводит опции сеанса, которые могут быть установлены с
помощью SET . См.
раздел 6.1.5.
Переменные, у которых есть тип string,
берут строковое значение. Переменные, у которых есть тип
numeric, берут числовое значение. Переменные, у
которых есть тип boolean, могут быть 0, 1,
ON или OFF . Переменные, которые отмечены как
enumeration, обычно должны устанавливаться в одно
из доступных значений для переменной, но могут также быть установлены в
число, которое соответствует желаемому значению перечисления. Для
перечисленных системных переменных первое значение перечисления соответствует
0. Это отличается от столбцов ENUM ,
для которых первое значение перечисления соответствует 1.
Таблица 6.3. Динамические переменные
6.1.7. Переменные состояния сервера
Сервер MySQL поддерживает много переменных состояния, которые
предоставляют информацию о его работе. Вы можете рассмотреть эти переменные и
их значения при использовании SHOW [GLOBAL | SESSION] STATUS
(см. раздел 14.7.5.35).
Дополнительное ключевое слово GLOBAL
соединяет значения по всем соединениям, а SESSION
показывает значения для текущего соединения.
mysql> SHOW GLOBAL STATUS;
+-------------------------+------------+
| Variable_name | Value |
+-------------------------+------------+
| Aborted_clients | 0 |
| Aborted_connects | 0 |
| Bytes_received | 155372598 |
| Bytes_sent | 1176560426 |
...
| Connections | 30023 |
| Created_tmp_disk_tables | 0 |
| Created_tmp_files | 3 |
| Created_tmp_tables | 2 |
...
| Threads_created | 217 |
| Threads_running | 88 |
| Uptime | 1389872 |
+-------------------------+------------+
Несколько переменных состояния предоставляют количество запросов.
Чтобы определить число выполненных запросов, используйте эти отношения:
SUM(Com_xxx) + Qcache_hits
= Questions + запросы в пределах сохраненных подпрограмм
= Запросы
Много переменных состояния сброшены к 0
FLUSH STATUS .
Следующая таблица приводит все доступные переменные состояния сервера:
Таблица 6.4. Переменные статуса
У переменных состояния есть следующие значения.
Aborted_clients
Число соединений, которые были прерваны, потому что клиент отвалился, не
закрывая соединение должным образом. См.
раздел B.5.2.10.
-
Aborted_connects
Число неудачных попыток соединиться с сервером MySQL. См.
раздел B.5.2.10.
Для дополнительной связанной с соединением информации, проверьте
перменную
Connection_errors_xxx и таблицу
host_cache .
Aborted_connects
невидима во встроенном сервере, потому что для того сервера она
ничего не делает.
-
Binlog_cache_disk_use
Число транзакций, которые использовали временный двоичной кэш журнала, но
это превысило значение
binlog_cache_size и использован временный файл, чтобы сохранить
запросы от транзакции.
Число нетранзакционных запросов, которые заставили двоичной операционный
кэш журнала быть написанным на диск, прослежено отдельно в
Binlog_stmt_cache_disk_use .
-
Acl_cache_items_count
Число кэшируемых объектов привилегии. Каждый объект это комбинация
привилегии пользователя и ее активных ролей.
-
Binlog_cache_use
Число транзакций, которые использовали двоичной кэш журнала.
-
Binlog_stmt_cache_disk_use
Число неоперационных запросов, которые использовали двоичной кэш запроса
журнала, но это превысило значение
binlog_stmt_cache_size и использован временный файл, чтобы
сохранить те запросы.
-
Binlog_stmt_cache_use
Число нетранзакционных запросов, которые использовали
кэш двоичного журнала.
-
Bytes_received
Число байтов получено от всех клиентов.
-
Bytes_sent
Число байтов, посланных всем клиентам.
-
Com_xxx
Com_xxx
еременные счетчика запросов указывают на число раз выполнения каждого
запроса xxx . Есть одна переменная состояния для каждого
типа запроса. Например, Com_delete и
Com_update считают запросы
DELETE и
UPDATE , соответственно.
Com_delete_multi и Com_update_multi
подобны, но относятся к DELETE и
UPDATE , которые используют
многотабличную версию синтаксиса.
Если результат запроса возвращен из кэша запроса, сервер увеличивает
Qcache_hits , а не
Com_select . См.
раздел 9.10.3.4.
Обсуждение в начале этого раздела указывает, как связать эти
считающие запросы переменные состояния с другими такими переменными.
Все переменные Com_stmt_xxx
увеличены, даже если готовый параметр запроса неизвестен,
или ошибка произошла во время выполнения. Другими словами, их значения
соответствуют числу выпущенных запросов, а не числу успешно завершенных.
Com_stmt_xxx
переменные состояния следующие:
Com_stmt_prepare
Com_stmt_execute
Com_stmt_fetch
Com_stmt_send_long_data
Com_stmt_reset
Com_stmt_close
Эти переменные обозначают готовые команды. Их имена обращаются к
набору команд COM_xxx , который
используется в сетевом уровне. Другими словами, их значения увеличиваются
всякий раз, когда подготовленный запрос вызывается через
mysql_stmt_prepare(),
mysql_stmt_execute() и т.д. Однако,
Com_stmt_prepare , Com_stmt_execute и
Com_stmt_close также увеличены для
PREPARE ,
EXECUTE или
DEALLOCATE PREPARE ,
соответственно. Дополнительно, значения переменных
Com_prepare_sql , Com_execute_sql и
Com_dealloc_sql растут для
PREPARE ,
EXECUTE и
DEALLOCATE PREPARE .
Com_stmt_fetch считает общее количество сетевых
обменов от курсоров.
Com_stmt_reprepare указывает, сколько раз запросы были
автоматически повторно подготовлены сервером после того, как метаданные
изменяются в таблице или представление ссылается на упомянутый запрос.
Повторная подготовка увеличивает
Com_stmt_reprepare и Com_stmt_prepare .
Com_explain_other указывает число
EXPLAIN FOR CONNECTION . См.
раздел 9.8.4.
Com_change_repl_filter указывает число
CHANGE REPLICATION FILTER .
-
Compression
Использует ли соединение клиента сжатие в протоколе клиент-сервер.
-
Connection_errors_xxx
Эти переменные предоставляют информацию об ошибках, которые происходят во
время процесса соединения клиента. Они только глобальны и представляют
количество ошибок всех соединений от всех узлов. Эти переменные отслеживают
ошибки, не для кэша узла (см. раздел
9.12.4.2), такие как ошибки, которые не связаны с соединениями TCP,
(происходящие прежде, чем IP-адрес будет известен), или не являются
определенными для любого IP-адреса.
Connection_errors_xxx
невидимы во встроенном сервере, потому что для того сервера они
ничего не делают.
Connections
Число попыток соединения (успешный или нет) к серверу MySQL.
-
Created_tmp_disk_tables
Число внутренних временных таблиц на диске, составленных
сервером, выполняя запросы.
Если внутренняя временная таблица составлена первоначально как таблица
в памяти, но становится слишком большой, MySQL автоматически преобразовывает
ее в таблицу на диске. Максимальный размер для временных таблиц в памяти это
минимум значений
tmp_table_size и
max_heap_table_size
. Если
Created_tmp_disk_tables является большим, Вы можете хотеть
увеличить tmp_table_size
или
max_heap_table_size , чтобы уменьшить вероятность, что внутренние
временные таблицы в памяти будут преобразованы в таблицы на диске.
Вы можете сравнить число внутренних временных таблиц на диске с общим
количеству внутренних временных таблиц, сравнивая значения
Created_tmp_disk_tables и
Created_tmp_tables .
См. раздел 9.4.4.
-
Created_tmp_files
Сколько временных файлов
mysqld создано.
-
Created_tmp_tables
Число внутренних временных таблиц, составленных
сервером, выполняя запросы.
Вы можете сравнить число внутренних временных таблиц на диске и
общее количество внутренних временных таблиц, сравнивая значения
Created_tmp_disk_tables и
Created_tmp_tables .
См. раздел 9.4.4.
Каждый вызов SHOW STATUS
использует внутреннюю временную таблицу и увеличивает глобальное
значение
Created_tmp_tables .
-
Delayed_errors
Эта переменная состояния устарела (потому что DELAYED вставки
не поддержаны) и будет удалена в будущем выпуске.
-
Delayed_insert_threads
Эта переменная состояния устарела (потому что DELAYED вставки
не поддержаны) и будет удалена в будущем выпуске.
-
Delayed_writes
Эта переменная состояния устарела (потому что DELAYED вставки
не поддержаны) и будет удалена в будущем выпуске.
-
Flush_commands
Сколько раз сервер сбрасывает таблицы, потому что пользователь выполнял
FLUSH TABLES
или из-за внутренней работы сервера. Это также постепенно увеличено пакетами
COM_REFRESH . Это в отличие от
Com_flush ,
который указывает сколько было запросов FLUSH
FLUSH TABLES ,
FLUSH LOGS и т.д.
-
Handler_commit
Число внутренних COMMIT .
-
Handler_delete
Сколько раз строки были удалены из таблиц.
-
Handler_external_lock
Сервер увеличивает эту переменную для каждого вызова
external_lock() , которая вообще происходит в начале и в конце
доступа к табличному экземпляру. Среди механизмов хранения могли бы быть
различия. Эта переменная может использоваться, например, чтобы обнаружить
для запроса, что произошли доступы к разделам таблицы, сколько разделов было
сокращено прежде, чем заблокировать: проверьте, на сколько счетчик увеличился
для запроса, вычтите 2 (2 обращения к таблице непосредственно), затем
разделитесь на 2, чтобы получить число заблокированных разделов.
-
Handler_mrr_init
Сколько раз сервер использует собственное выполнение
Multi-Range Read механизма хранения для табличного доступа.
-
Handler_prepare
Счетчик для фазы подготовки двухфазовых операций commit.
-
Handler_read_first
Сколько раз первый вход в индексировании был считан.
Если это значение высоко, оно предполагает, что сервер делает много полных
индексных просмотров, например, SELECT col1 FROM foo
предполагает, что col1 индексирован.
-
Handler_read_key
Число просьб считать строку, основанную на ключе. Если это значение
высоко, это хороший признак, что Ваши таблицы должным образом индексированы
для Ваших запросов.
-
Handler_read_last
Число просьб считать последний ключ в индексировании. С
ORDER BY сервер выпустит запрос первого ключа, сопровождаемый
несколькими следующими ключевыми запросами, тогда как с
ORDER BY DESC сервер выпустит последний ключевой запрос,
сопровождаемый несколькими предыдущими ключевыми запросами.
-
Handler_read_next
Число просьб считать следующую строку в ключевом порядке.
Это значение постепенно увеличено, если Вы запрашиваете индексированный
столбец с ограничением диапазона или если Вы делаете просмотр индекса.
-
Handler_read_prev
Число просьб считать предыдущую строку в ключевом порядке.
Этот метод чтения, главным образом, используется, чтобы оптимизировать
ORDER BY ... DESC .
-
Handler_read_rnd
Число запросов считать строку, основанных на фиксированной позиции. Это
значение высоко, если Вы делаете много запросов, которые требуют сортировки
результата. У Вас, вероятно, есть много запросов, которые требуют, чтобы
MySQL просмотрел все таблицы, или у Вас есть соединения, которые
не используют ключи должным образом.
-
Handler_read_rnd_next
Число запросов считать следующую строку в файле с данными. Это значение
высоко, если Вы делаете большое сканирование таблицы. Вообще это
предполагает, что Ваши таблицы должным образом не индексированы или что Ваши
запросы не написаны, чтобы использовать в своих интересах индексирование.
-
Handler_rollback
Число запросов механизму хранения, чтобы выполнить работу отката.
-
Handler_savepoint
Число запросов механизму хранения, чтобы поместить точку сохранения.
-
Handler_savepoint_rollback
Число запросов механизму хранения, чтобы откатиться
назад к сохраненной точке.
-
Handler_update
Число запросов обновить строку в таблице.
-
Handler_write
Число запросов вставить строку в таблицу.
-
Innodb_available_undo_logs
Общее количество доступных журанлов
отмены InnoDB . Дополнение системной переменной
innodb_undo_logs
, которая сообщает о числе активных журналов отмены.
Один журнал отмены всегда находится в системном табличном пространстве,
и 32 журнала отмены сохранены для использования временными таблицами и
размещены во временном табличном пространстве (ibtmp1 ). См.
раздел 16.4.11.1.
Если Вы начинаете экземпляр MySQL с 32 или меньшим количеством журналов
отмены, InnoDB все еще назначает один журнал отмены на
системное табличное пространство и 32 журнала отмены к временному табличному
пространству. В этом случае Innodb_available_undo_logs сообщает
о 33 доступных журналах отмены даже при том, что сервер был инициализирован с
меньшим значением
innodb_undo_logs .
-
Innodb_buffer_pool_dump_status
Продвижение работы, чтобы сделать запись
страниц из
буферного пула
InnoDB , вызванную установкой
innodb_buffer_pool_dump_at_shutdown или
innodb_buffer_pool_dump_now .
См. раздел 16.6.3.8.
-
Innodb_buffer_pool_load_status
Продвижение работы, чтобы
нагреть
буферный пул
InnoDB , читая страницы,
соответствующие более раннему моменту времени, вызванному установкой
innodb_buffer_pool_load_at_startup или
innodb_buffer_pool_load_now . Если работа вызывает слишком большие
издержки Вы можете отменить ее, устанавливая
innodb_buffer_pool_load_abort .
См. раздел 16.6.3.8.
-
Innodb_buffer_pool_bytes_data
Общее количество байтов в
буферном пуле InnoDB , содержащим данные. Число включает
грязные
и чистые страницы. Для более точных вычислений использования памяти,
применяется
Innodb_buffer_pool_pages_data , когда
сжатые таблицы заставляют
буферный бассейн содержать страницы различных размеров.
-
Innodb_buffer_pool_pages_data
Число страниц в
буферном пуле
InnoDB , содержащих данные. Число включает
грязные и чистые страницы. Когда
используются сжатые таблицы
, значение
Innodb_buffer_pool_pages_data может быть больше
Innodb_buffer_pool_pages_total (Bug #59550).
-
Innodb_buffer_pool_bytes_dirty
Полное текущее число байтов в
грязных страницах в
буферном пуле.
-
Innodb_buffer_pool_pages_dirty
Текущее число грязных страниц
в буферном пуле.
-
Innodb_buffer_pool_pages_flushed
Число запросов flush
для страниц из
буферного пула.
-
Innodb_buffer_pool_pages_free
Число свободных страниц в
буферном пуле.
-
Innodb_buffer_pool_pages_latched
Число заблокированных страниц в
буферном пуле.
Это страницы, которые читаются или пишутся сейчас, или не могут быть
сброшены по некоторой другой причине.
Вычисление этой переменной дорого, таким образом, это доступно только когда
UNIV_DEBUG определена при сборке сервера.
-
Innodb_buffer_pool_pages_misc
Число страниц в
буферном пуле
InnoDB , которые заняты, потому что они были выделены для
административных задач, например,
блокировки строки или
адаптивного хеш индекса. Это значение может также быть вычислено как
Innodb_buffer_pool_pages_total
-
Innodb_buffer_pool_pages_free
-
Innodb_buffer_pool_pages_data . При использовании
сжатых таблиц,
Innodb_buffer_pool_pages_misc может сообщить о
большем значении (Bug #59550).
-
Innodb_buffer_pool_pages_total
Полный размер буферного пула
InnoDB в страницах.
Когда использованны сжатые
таблицы, значение
Innodb_buffer_pool_pages_data может быть больше, чем
Innodb_buffer_pool_pages_total (Bug #59550).
-
Innodb_buffer_pool_read_ahead
Число страниц в
буферном пуле, читаемых фоновым
потоком предвыборки.
-
Innodb_buffer_pool_read_ahead_evicted
Число страниц в
буферном пуле, читаемых фоновым
потоком предвыборки, которые были
впоследствии вычеркнуты
не будучи прочитанными запросами.
-
Innodb_buffer_pool_read_ahead_rnd
Число случайных чтений, начатых
InnoDB . Это происходит, когда запрос просматривает значительную
часть таблицы, но в случайном порядке.
-
Innodb_buffer_pool_read_requests
Число запросов логического чтения.
-
Innodb_buffer_pool_reads
Число логических чтений, которые InnoDB
не мог удовлетворить из буферного
пула и должен был читать непосредственно с диска.
-
Innodb_buffer_pool_resize_status
Состояние работы, чтобы изменить размеры
буферного пула динамически,
вызванные установкой
innodb_buffer_pool_size .
innodb_buffer_pool_size является динамическим, что позволяет Вам
изменять размеры буферного пула, не перезапуская сервер.
-
Innodb_buffer_pool_wait_free
Обычно запись в InnoDB
буферный пул
происходит на заднем плане. Когда InnoDB надо читать или
создать страницу
и никакие чистые страницы не доступны, InnoDB сбрасывает
некоторые грязные страницы
сначала и ждет окончания этой работы. Это счетчик количества таких ожиданий.
Если
innodb_buffer_pool_size был установлен должным образом, это
значение должно быть маленьким.
-
Innodb_buffer_pool_write_requests
Число записей в
буферный пул InnoDB .
-
Innodb_data_fsyncs
Число вызовов fsync() . Частота fsync() зависит
от параметра конфигурации
innodb_flush_method .
-
Innodb_data_pending_fsyncs
Текущее число ожидающих запросов fsync() . Частота
fsync() зависит от параметра конфигурации
innodb_flush_method .
-
Innodb_data_pending_reads
Текущее число чтений в ожидании.
-
Innodb_data_pending_writes
Текущее число записей в ожидании.
-
Innodb_data_read
Объем прочитанных данных, начиная с запуска сервера (в байтах).
-
Innodb_data_reads
Общее количество чтений данных (чтения файлов OS).
-
Innodb_data_writes
Общее количество записанных данных.
-
Innodb_data_written
Объем данных, записанный до сих пор, в байтах.
-
Innodb_dblwr_pages_written
Число страниц, которые были записаны
в буфер doublewrite. См.
раздел 16.11.1.
-
Innodb_dblwr_writes
Число операций doublewrite, которые были выполнены. См.
See раздел 16.11.1.
-
Innodb_have_atomic_builtins
Указывает, был ли сервер создан с
atomic instructions.
-
Innodb_log_waits
Сколько раз буфер журнала
был слишком маленьким и ожидание
требовалось для его сброса.
-
Innodb_log_write_requests
Число запросов записи в InnoDB
журнала redo.
-
Innodb_log_writes
Число физических записей в файл InnoDB
журнала redo.
-
Innodb_num_open_files
Число файлов, которые InnoDB в настоящее
время считает открытыми.
-
Innodb_os_log_fsyncs
Число записей fsync() , сделанных InnoDB в файлы
журнала redo.
-
Innodb_os_log_pending_fsyncs
Число ожидающих операций fsync() для файлов
журнала redo.
-
Innodb_os_log_pending_writes
Число ожидаюищх записей в файлы
журнала redo.
-
Innodb_os_log_written
Число байтов, написанных в файлы
журнала redo.
-
Innodb_page_size
Размер страницы InnoDB (значение по умолчанию 16 КБ). Много
значений посчитаны в страницах, размер страницы позволяет им быть
легко преобразованными в байты.
-
Innodb_pages_created
Число страниц, создаваемых операциями на таблицах InnoDB .
-
Innodb_pages_read
Число страниц, прочитанных из буферного пула InnoDB .
-
Innodb_pages_written
Число страниц, написанных операциями на таблицах InnoDB .
-
Innodb_row_lock_current_waits
Число блокировок строки,
ждущих операций на таблицах InnoDB .
-
Innodb_row_lock_time
Полное время, проведенное в приобретении
строковых блокирвок
для таблиц InnoDB в миллисекундах.
-
Innodb_row_lock_time_avg
Среднее время, чтобы приобрести
блокировку строки
для таблиц InnoDB в миллисекундах.
-
Innodb_row_lock_time_max
Максимальное время, чтобы приобрести
блокировку строки
для таблиц InnoDB в миллисекундах.
-
Innodb_row_lock_waits
Сколько раз операции InnoDB ждали
блокировку строки.
-
Innodb_rows_deleted
Число строк, удаленных из таблиц InnoDB .
-
Innodb_rows_inserted
Число строк, вставленных в таблицы InnoDB .
-
Innodb_rows_read
Число строк, прочитанных из таблиц InnoDB .
-
Innodb_rows_updated
Число строк, обновленных в таблицах InnoDB .
-
Innodb_truncated_status_writes
Сколько раз усекался вывод SHOW ENGINE INNODB STATUS .
-
Key_blocks_not_flushed
Число ключевых блоков в ключевом кэше MyISAM , которые
изменились, но еще не сброшены на диск.
-
Key_blocks_unused
Число неиспользованных блоков в ключевом кэше MyISAM .
Вы можете использовать это значение, чтобы определить, сколько ключевого кэша
используется, см. обсуждение
key_buffer_size в
разделе 6.1.5.
-
Key_blocks_used
Число использованных блоков в ключевом кэше MyISAM .
Это значение высшая точка, которая указывает на максимальное количество
блоков, которые когда-либо использовались.
-
Key_read_requests
Число запросов считать ключевой блок из ключевого кэша
MyISAM .
-
Key_reads
Число физических чтений ключевого блока с диска в ключевой кэш
MyISAM . Если
Key_reads является большим, тогда Ваш
key_buffer_size
является, вероятно, слишком маленьким. Коэффициент промахов кэша может
быть вычислен как Key_reads
/
Key_read_requests .
-
Key_write_requests
Число запросов записи ключевого блока в ключевой кэш MyISAM .
-
Key_writes
Число физических записей ключевого блока из ключевого кэша на диск.
-
Last_query_cost
Общая стоимость последнего собранного запроса как вычислено оптимизатором
запросов. Это полезно для сравнения стоимости различных планов запроса
для того же самого запроса. Значение по умолчанию 0 указывает, что никакой
запрос еще не был собран. Значение по умолчанию 0.
Last_query_cost
имеет контекст сеанса.
Last_query_cost
может быть вычислено точно только для простых запросов, а не сложных,
например, с подзапросами или с UNION
. Для последнего значение установлено в 0.
-
Last_query_partial_plans
Число итераций оптимизатора запросов, планируя конструкцию предыдущего
запроса.
Last_query_cost имеет контекст сеанса.
-
Locked_connects
Число попыток соединиться с заблокированными учетными записями
пользователя. Для информации о блокировке учетной записи см.
раздел 7.3.11.
-
Max_execution_time_exceeded
Число SELECT для которых был
превышен тайм-аут выполнения.
-
Max_execution_time_set
Число SELECT для которых
был установлен тайм-аут выполнения отличный от нуля. Это включает запросы,
которые включают отличную от нуля подсказку оптимизатора
MAX_EXECUTION_TIME , и запросы, которые не включают такой
подсказки, но выполняются как тайм-аут, обозначенный переменной
max_execution_time
, которая является отличной от нуля.
-
Max_execution_time_set_failed
Число SELECT
для который попытка установить тайм-аут выполнения провалилась.
-
Max_used_connections
Максимальное количество соединений, которые использовались одновременно,
начиная с запуска сервера.
-
Max_used_connections_time
Время, когда
Max_used_connections достиг его текущего значения.
-
Not_flushed_delayed_rows
Эта переменная состояния устарела (потому что DELAYED вставки
не поддержаны) и будет удалена в будущем выпуске.
-
mecab_charset
Набор символов, в настоящее время используемый полнотекстовым плагином
анализатора MeCab, см. раздел
13.9.9.
-
Ongoing_anonymous_transaction_count
Показывает число продолжающихся транзакций, которые были отмечены как
анонимные. Это может использоваться, чтобы гарантировать, что никакие
дальнейшие транзакции не ждут, чтобы быть обработанными.
-
Ongoing_anonymous_gtid_violating_transaction_count
Эта переменная состояния доступна только в отладочных сборках.
Показывает число продолжающихся транзакций, которые используют
gtid_next=ANONYMOUS
и нарушают последовательность GTID.
-
Ongoing_automatic_gtid_violating_transaction_count
Эта переменная состояния доступна только в отладочных сборках.
Показывает число продолжающихся транзакций, которые используют
gtid_next=AUTOMATIC
и нарушают последовательность GTID.
-
Open_files
Число файлов, которые открыты. Это количество включает регулярные файлы,
открытые сервером. Это не включает другие типы файлов, такие как сокеты
или каналы. Кроме того, количество не включает файлы, которые механизмы
хранения открывают для использования их собственных внутренних функций вместо
того, чтобы просить уровень сервера.
-
Open_streams
Число потоков, которые открыты (используется, главным образом, для
того, чтобы зарегистрировать).
-
Open_table_definitions
Число кэшируемых табличных определений.
-
Open_tables
Число таблиц, которые открыты.
-
Opened_files
Число файлов, которые были открыты с помощью
my_open() (функция библиотеки
mysys ). Части сервера, которые открывают файлы, не используя эту
функцию, не увеличивают это количество.
-
Opened_table_definitions
Число табличных определений, которые кэшировались.
-
Opened_tables
Число таблиц, которые были открыты. Если
Opened_tables
является большим, Ваше значение
table_open_cache является, вероятно, слишком маленьким.
Performance_schema_xxx
Статусные переменные Performance Schema перечислены в
разделе 23.13.
Эти переменные предоставляют информацию об инструментовке, которая не могла
быть загружена или создана из-за ограничений памяти.
-
Prepared_stmt_count
Текущее число готовых запросов. Максимальное количество запросов дано
max_prepared_stmt_count .
-
Qcache_free_blocks
Число свободных блоков памяти в кэше запроса.
-
Qcache_free_memory
Количество свободной памяти для кэша запроса.
-
Qcache_hits
Число хитов кэша запроса.
Обсуждение в начале этого раздела указывает, как связать эту
переменную состояния с другими такими переменными.
-
Qcache_inserts
Число запросов, добавленных к кэшу запроса.
-
Qcache_lowmem_prunes
Число запросов, которые были удалены из кэша запроса
из-за нехватки памяти.
-
Qcache_not_cached
Число некэшируемых запросов (не кэшируемых из-за настройки
query_cache_type
).
-
Qcache_queries_in_cache
Число запросов, зарегистрированных в кэше запроса.
-
Qcache_total_blocks
Общее количество блоков в кэше запроса.
-
Queries
Число запросов, выполненных сервером. Эта переменная включает запросы,
выполненные в пределах сохраненных программ, в отличие от переменной
Questions . Это не
учитывает команды COM_PING или COM_STATISTICS .
Обсуждение в начале этого раздела указывает, как связать эту
переменную состояния с другими такими переменными.
-
Questions
Число запросов, выполненных сервером. Это включает только запросы,
посланные в сервер клиентами, но не запросы, выполненные в пределах
сохраненных программ, в отличие от переменной
Queries .
Эта переменная не учитывает команды COM_PING ,
COM_STATISTICS , COM_STMT_PREPARE ,
COM_STMT_CLOSE или COM_STMT_RESET .
Обсуждение в начале этого раздела указывает, как связать эту
переменную состояния с другими такими переменными.
-
Rpl_semi_sync_master_clients
Число полусинхронных ведомых устройств.
Эта переменная доступна, только если основная сторона
полусинхронного плагина установлена.
-
Rpl_semi_sync_master_net_avg_wait_time
Среднее время в микросекундах, которое ведущее устройство ждало ведомого.
Эта переменная всегда 0 , устарела и будет
удалена в будущей версии.
Эта переменная доступна, только если основная сторона
полусинхронного плагина установлена.
-
Rpl_semi_sync_master_net_wait_time
Полное время в микросекундах, которое ведущее устройство ждало ведомых.
Эта переменная всегда 0 , устарела и будет
удалена в будущей версии.
Эта переменная доступна, только если основная сторона
полусинхронного плагина установлена.
-
Rpl_semi_sync_master_net_waits
Общее количество времент, которое ведущее устройство ждало ведомых.
Эта переменная доступна, только если основная сторона
полусинхронного плагина установлена.
-
Rpl_semi_sync_master_no_times
Сколько раз ведущее устройство выключило полусинхронную репликацию.
Эта переменная доступна, только если основная сторона
полусинхронного плагина установлена.
-
Rpl_semi_sync_master_no_tx
Число транзакций, которые не были признаны успешными ведомым устройством.
Эта переменная доступна, только если основная сторона
полусинхронного плагина установлена.
-
Rpl_semi_sync_master_status
Является ли полусинхронная репликация в настоящее время
операционным на ведущем устройстве. Значение ON , если плагин был
включен, и признание транзакции произошло. Это OFF , если плагин
не включен, или ведущее устройство отступило к асинхронной репликации.
Эта переменная доступна, только если основная сторона
полусинхронного плагина установлена.
-
Rpl_semi_sync_master_timefunc_failures
Сколько раз ведущее устройство потерпело неудачу, вызывая функции времени,
такую как gettimeofday() .
Эта переменная доступна, только если основная сторона
полусинхронного плагина установлена.
-
Rpl_semi_sync_master_tx_avg_wait_time
Среднее время в микросекундах, которое ведущее
устройство ждало транзакции.
Эта переменная доступна, только если основная сторона
полусинхронного плагина установлена.
-
Rpl_semi_sync_master_tx_wait_time
Полное время в микросекундах, которое ведущее устройство ждало транзакций.
Эта переменная доступна, только если основная сторона
полусинхронного плагина установлена.
-
Rpl_semi_sync_master_tx_waits
Общее количество времени, которое ведущее устройство ждало транзакций.
Эта переменная доступна, только если основная сторона
полусинхронного плагина установлена.
-
Rpl_semi_sync_master_wait_pos_backtraverse
Общее количество времени, которое ведущее устройство ждало события
с двоичными координатами ниже чем событие, ожидаемое ранее. Это может
произойти, когда порядок, в котором транзакции начинают ждать репликации,
отличается от порядка, в котором написаны их события в двоичный журнал.
Эта переменная доступна, только если основная сторона
полусинхронного плагина установлена.
-
Rpl_semi_sync_master_wait_sessions
Число сеансов, в настоящее время ожидающих ведомых устройств.
Эта переменная доступна, только если основная сторона
полусинхронного плагина установлена.
-
Rpl_semi_sync_master_yes_tx
Число транзакций, которые были признаны успешно ведомым устройством.
Эта переменная доступна, только если основная сторона
полусинхронного плагина установлена.
-
Rpl_semi_sync_slave_status
Является ли полусинхронная репликация в настоящее время операционной
на ведомом устройстве. Это ON , если плагин был включен, и
ведомый поток ввода/вывода работает, иначе OFF .
Эта переменная доступна, только если ведомая сторона
полусинхронного плагина установлена.
-
Rsa_public_key
Эта переменная доступна, если MySQL использует OpenSSL (см.
раздел 7.4.1).
Это значение открытого ключа RSA, используемое плагином аутентификации
sha256_password . Значение непусто, только если сервер успешно
инициализирует ключи в файлах, названных в переменных
sha256_password_private_key_path и
sha256_password_public_key_path . Значение
Rsa_public_key
прибывает из последнего файла.
См. раздел 7.5.1.2
.
-
Select_full_join
Число соединений, которые выполняют сканирование таблицы, потому что они
не используют индексы. Если это значение не 0, Вы должны тщательно проверить
индексирование своих таблиц.
-
Select_full_range_join
Число соединений, которые использовали поиск диапазона
на ссылочной таблице.
-
Select_range
Число соединений, которые использовали диапазоны на первой таблице. Это
обычно не критическая проблема, даже если значение является довольно большим.
-
Select_range_check
Число соединений без ключей, которые проверяют на ключевое использование
после каждой строки. Если это не 0, Вы должны тщательно проверить
индексирование своих таблиц.
-
Select_scan
Число соединений, которые сделали полный просмотр первой таблицы.
-
Slave_heartbeat_period
Показывает интервал тактирования (в секундах) на ведомом устройстве.
Эта переменная затронута значением
show_compatibility_56 , см.
здесь.
Эта переменная только показывает состояние канала
по умолчанию. Чтобы контролировать использование многих каналов, примените
столбец HEARTBEAT_INTERVAL в таблице
replication_connection_status для канала репликации.
Slave_last_heartbeat
Показывает, когда новый сигнал тактирования был получен ведомым
устройством, как TIMESTAMP .
Эта переменная затронута значением
show_compatibility_56 .
Эта переменная только показывает состояние канала по умолчанию.
Чтобы контролировать использование многих каналов, примените столбец
LAST_HEARTBEAT_TIMESTAMP в таблице
replication_connection_status для канала репликации.
Slave_open_temp_tables
Число временных таблиц, которые ведомый поток SQL в настоящее время имеет
открытыми. Если значение больше, чем ноль, не безопасно закрывать ведомое
устройство, см. раздел
19.4.1.24. Эта переменная сообщает о полном количестве открытых временных
таблиц для всех каналов репликации.
-
Slave_received_heartbeats
Это считает каждый такт репликации, полученным ведомым устройством с
прошлого раза, когда ведомое устройство было перезапущено или сброшено, или
была команда CHANGE MASTER TO
.
Эта переменная затронута значением
show_compatibility_56 .
Эта переменная показывает только состояние канала по умолчанию.
Чтобы контролировать использование многих каналов, примените столбец
COUNT_RECEIVED_HEARTBEATS в таблице
replication_connection_status для канала репликации.
Slave_retried_transactions
Общее количество времени, начиная с запуска, которое поток SQL ведомого
устройствп повторяет транзакции.
Эта переменная затронута значением
show_compatibility_56 .
Эта переменная показывает только состояние канала по умолчанию.
Чтобы контролировать использование многих каналов, примените столбец
COUNT_TRANSACTIONS_RETRIES в таблице
replication_applier_status .
Slave_running
Это ON , если этот сервер ведомое устройство, которое
соединено с ведущим устройством, потоки ввода/вывода и SQL работают,
иначе это OFF .
Эта переменная затронута значением
show_compatibility_56 .
Эта переменная показывает только состояние канала по умолчанию.
Чтобы контролировать использование многих каналов, примените столбец
SERVICE_STATE в таблице
replication_applier_status или
replication_connection_status .
Slow_launch_threads
Число потоков, которые взяли больше, чем
slow_launch_time
секунд для создания.
Эта переменная не является значащей во встроенном сервере
(libmysqld ) и невидима в пределах встроенного сервера.
-
Slow_queries
Число запросов, которые взяли больше, чем
long_query_time
секунд. Этот счетчик увеличивается независимо от того, включен ли медленный
журнал запроса. Для информации об этом журнале см.
раздел 6.4.5.
-
Sort_merge_passes
Число проходов слияния, которые должен был сделать алгоритм сортировки.
Если это значение является большим, Вы должны рассмотреть увеличение значения
sort_buffer_size
.
-
Sort_range
Число сортировок, которые были сделаны, используя диапазоны.
-
Sort_rows
Число сортированных строк.
-
Sort_scan
Число сортировок, которые были сделаны, просматривая таблицу.
-
Ssl_accept_renegotiates
Число обменов, чтобы установить соединение.
-
Ssl_accepts
Число принятых соединений SSL.
-
Ssl_callback_cache_hits
Число хитов кэша отзыва.
-
Ssl_cipher
Текущий шифр (пусто для незашифрованных соединений).
-
Ssl_cipher_list
Список возможных шифров SSL (пустой для не-SSL соединений).
-
Ssl_client_connects
Число соединений SSL с ведущим устройством.
-
Ssl_connect_renegotiates
Число обменов, чтобы установить соединение с ведущим устройством по SSL.
-
Ssl_ctx_verify_depth
Глубина проверки контекста SSL (сколько сертификатов в цепочке проверено).
-
Ssl_ctx_verify_mode
Режим проверки контекста SSL.
-
Ssl_default_timeout
Значение по умолчанию тайм-аута SSL.
-
Ssl_finished_accepts
Число успешных соединений по SSL с сервером.
-
Ssl_finished_connects
Число успешных ведомых соединений с ведущим устройством по SSL.
-
Ssl_server_not_after
Последняя дата, для которой сертификат SSL допустим.
Чтобы проверить информацию об истечении сертификата SSL,
используйте этот запрос:
mysql> SHOW STATUS LIKE 'Ssl_server_not%';
+-----------------------+--------------------------+
| Variable_name | Value |
+-----------------------+--------------------------+
| Ssl_server_not_after | Apr 28 14:16:39 2025 GMT |
| Ssl_server_not_before | May 1 14:16:39 2015 GMT |
+-----------------------+--------------------------+
-
Ssl_server_not_before
Первая дата, для которой сертификат SSL допустим.
-
Ssl_session_cache_hits
Число хитов кэша сеанса SSL.
-
Ssl_session_cache_misses
Число промахов кэша сеанса SSL.
-
Ssl_session_cache_mode
Режим кэша сеанса SSL.
-
Ssl_session_cache_overflows
Число переполнений кэша сеанса SSL.
-
Ssl_session_cache_size
Размер кэша сеанса SSL.
-
Ssl_session_cache_timeouts
Число тайм-аутов кэша сеанса SSL.
-
Ssl_sessions_reused
Сколько соединений SSL было снова использовано из кэша.
-
Ssl_used_session_cache_entries
Сколько записей кэша сеанса SSL использовалось.
-
Ssl_verify_depth
Глубина проверки для репликации соединения SSL.
-
Ssl_verify_mode
Режим проверки для репликации соединения SSL.
-
Ssl_version
Версия протокола SSL соединения, например, TLSv1. Если соединение не
зашифровано, значение пусто.
-
Table_locks_immediate
Сколько табличных блокировок можно было немедленно предоставить.
-
Table_locks_waited
Сколько раз табличную блокировку нельзя было немедленно
предоставить и ожидание было необходимо. Если это высоко, и у Вас есть
исполнительные проблемы, Вы должны сначала оптимизировать свои запросы, а
затем разделить Вашу таблицу (или таблицы) или использовать репликацию.
-
Table_open_cache_hits
Число хитов для поисков в кэше открытых таблиц.
-
Table_open_cache_misses
Число промахов для поисков в кэше открытых таблиц.
-
Table_open_cache_overflows
Число переполнений для кэша открытых таблиц. Это число раз, когда после
того, как таблица открыта или закрыта, у кэша есть неиспользованная запись, и
размер кэша больше
table_open_cache /
table_open_cache_instances .
-
Tc_log_max_pages_used
Для отображенного на память выполнения журнала, который используется
mysqld,
когда это действует как операционный координатор для восстановления
внутренних транзакций XA, эта переменная указывает на наибольшее число
страниц, используемых для журнала, начиная с запуска сервера. Если
произведение
Tc_log_max_pages_used и
Tc_log_page_size
всегда значительно меньше чем размер журнала, размер больше, чем
необходимый и может быть уменьшен. Размер установлен опцией
--log-tc-size .
Эта переменная неиспользована: это является ненужным для двоичного
основанного на журнале восстановления, и отображенный на память метод журнала
восстановления не используется, если число механизмов хранения, которые
способны к двухфазовым транзакциям и поддерживают транзакции XA, больше
одного (InnoDB единственный применимый механизм).
-
Tc_log_page_size
Размер страницы, которая используется для отображенного на память
выполнения журнала восстановления XA. Значение по умолчанию определено,
используя getpagesize() . Эта переменная не использована по тем
же самым причинам, как описано для
Tc_log_max_pages_used .
-
Tc_log_page_waits
Для отображенного на память выполнения журнала восстановления эта
переменная постепенно увеличивается каждый раз, когда сервер не смог передать
транзакцию и должен был ждать свободной страницы в журнале. Если это значение
является большим, Вы могли бы увеличить размер журнала (с помощью опции
--log-tc-size
). Для двоичного основанного на журнале восстановления эта переменная
постепенно увеличивается каждый раз, когда двоичный журнал не может быть
закрыт, потому что там происходят двухфазовые транзакции.
Операция закрытия ждет, пока все такие транзакции не закончены.
-
Threads_cached
Число потоков в кэше потока.
Эта переменная не является значащей во встроенном сервере
(libmysqld ) и невидима в пределах встроенного сервера.
-
Threads_connected
Число в настоящее время открытых соединений.
-
Threads_created
Число потоков, создаваемых, чтобы обработать соединения. Если
Threads_created
является большим, Вы можете хотеть увеличить
thread_cache_size
. Коэффициент промахов кэша может быть вычислен как
Threads_created
/Connections .
-
Threads_running
Число потоков, которые не спят.
-
Uptime
Число секунд, которые работает сервер.
-
Uptime_since_flush_status
Число секунд начиная с последнего запроса FLUSH STATUS .
6.1.8. Режимы SQL сервера
Сервер MySQL может работать в различных режимах SQL и может применить эти
режимы по-другому для различных клиентов, в зависимости от значения
value of the sql_mode .
DBA может установить глобальный режим SQL, чтобы соответствовать
эксплуатационным требованиям сервера, каждое приложение может установить свой
сеансовый режим SQL
Режимы затрагивают синтаксис SQL и подтверждение правильности данных.
Это облегчает использовать MySQL в различной окружающей среде и использование
MySQL вместе с другими серверами базы данных.
Для ответов на вопросы, которые часто спрашивают о режимах SQL в MySQL см.
раздел A.3.
Работая с InnoDB , рассмотрите также переменную
innodb_strict_mode
. Это включает дополнительные проверки в InnoDB .
Установка режима SQL
Значение по умолчанию режима SQL в MySQL 8.0 включает эти режимы:
ONLY_FULL_GROUP_BY
,
STRICT_TRANS_TABLES
,
NO_ZERO_IN_DATE ,
NO_ZERO_DATE ,
ERROR_FOR_DIVISION_BY_ZERO ,
NO_AUTO_CREATE_USER и
NO_ENGINE_SUBSTITUTION .
ONLY_FULL_GROUP_BY
и
STRICT_TRANS_TABLES
были добавлены в MySQL 5.7.5.
NO_AUTO_CREATE_USER
был добавлен в MySQL 5.7.7.
ERROR_FOR_DIVISION_BY_ZERO ,
NO_ZERO_DATE и
NO_ZERO_IN_DATE
были добавлены в MySQL 5.7.8. Для дополнительного обсуждения относительно
этих изменений значения по умолчанию режима SQL см.
здесь.
Чтобы установить режим SQL при запуске сервера, используйте опцию
командной строки
--sql-mode="modes " или
sql-mode="modes
" в файле опций, например, в
my.cnf (Unix) или my.ini (Windows).
modes это список различных режимов, отделенных запятыми.
Чтобы очистить режим SQL явно, установите это в пустую строку с помощью
--sql-mode="" в
командной строке или
sql-mode="" в файле опций.
Программы установки MySQL могут сконфигурировать режим SQL во
время процесса установки.
Если режим SQL отличается от значения по умолчанию или от того, что Вы
ожидаете, проверьте на установку в файле опций, который сервер
читает при запуске.
Чтобы изменить режим SQL во время выполнения, установите глобальное или
сеансовое значение sql_mode
через SET :
SET GLOBAL sql_mode = 'modes ';
SET SESSION sql_mode = 'modes ';
Установка GLOBAL требует привилегию
SUPER
и влияет на работу всех клиентов, которые соединяются с этого времени.
Установка SESSION затрагивает только текущего клиента. Каждый
клиент может изменить его сеансовое значение
sql_mode в любое время.
Чтобы определить глобальное или сеансовое значение
sql_mode ,
используйте следующие запросы:
SELECT @@GLOBAL.sql_mode;
SELECT @@SESSION.sql_mode;
Режимы SQL и определяемое пользователем разделение.
Изменение режима SQL после создания и вставки данных в разделенные таблицы
может вызвать существенные изменения в поведении таких таблиц и привести к
потере или повреждению данных. Сильно рекомендуется, чтобы Вы никогда не
изменяли режим SQL, как только Вы составили таблицы, использующие
определяемое пользователем разделение.
При репликации разделенных таблиц разные режимы SQL на ведущем и ведомом
устройствах могут также привести к проблемам. Для лучших результатов Вы
должны всегда использовать тот же самый режим SQL на
ведущем и ведомом серверах.
См. раздел 20.6.
Самые важные режимы SQL
Самые важные sql_mode
:
ANSI
Этот режим изменяет синтаксис и поведение, чтобы соответствовать наиболее
близко стандартному SQL. Это один из специальных
режимов комбинации, перечисленных в
конце этого раздела.
STRICT_TRANS_TABLES
Если значение не могло быть вставлено как дано в транзакционную таблицу,
прервать запрос. Для нетранзакционной таблицы прервать запрос, если значение
в запросе единственной строки или первой строке мультистрочного запроса.
Больше деталей дано позже в этом разделе.
TRADITIONAL
Заставить MySQL вести себя как традиционные
системы SQL. Простое описание этого режима
выдавать ошибку вместо предупреждения, вставляя
неправильное значение в столбец. Это один из специальных
режимов комбинации, перечисленных в
конце этого раздела.
INSERT или
UPDATE прерваны,
как только ошибка замечена. Это, возможно, не то, что Вы хотите, если Вы
используете нетранзакционной механизм хранения, потому что изменения данных,
произведенные до ошибки, не могут быть отменены,
приводя к частичному обновлению.
Когда это руководство отсылает к строгому режиму
, это означает режим с
STRICT_TRANS_TABLES
,
STRICT_ALL_TABLES или обоими.
Полный список режимов SQL
Следующий список описывает все режимы SQL:
ALLOW_INVALID_DATES
Не выполнять полную проверку дат. Проверьте только, что месяц находится в
диапазоне от 1 до 12, и день находится в диапазоне от 1 до 31. Это очень
удобно для Веб-приложений, где Вы получаете год, месяц и день в трех
различных областях, и Вы хотите сохранить точно, что пользователь вставил
(без проверки допустимости даты). Этот режим относится к столбцам
DATE и
DATETIME . Это не применяется к
TIMESTAMP , которые всегда
требуют допустимой даты.
Сервер требует, чтобы значения месяца и дня были законными, а не просто в
диапазоне 1-12 и 1-31, соответственно. Со строгим режимом отключены
недопустимые даты, например, '2004-04-31' преобразована в
'0000-00-00' , и предупреждение произведено. С включенным строгим
режимом недопустимые даты производят ошибку. Чтобы разрешить такие даты,
включите
ALLOW_INVALID_DATES .
-
ANSI_QUOTES
Обработка " как символа кавычки идентификатора (как
` ), а не как строковый символ кавычки. Вы можете все еще
использовать ` , чтобы заключить идентификаторы в кавычки с этим
включенным режимом. С
ANSI_QUOTES Вы не можете использовать двоичные кавычки, чтобы
заключить буквальные строки в кавычки, потому что это
интерпретируется как идентификатор.
-
ERROR_FOR_DIVISION_BY_ZERO
ERROR_FOR_DIVISION_BY_ZERO влияет на обработку деления на ноль,
что включает MOD(N
,0) . Для операций изменения данных
(INSERT ,
UPDATE )
эффект также зависит от того, включен ли строгий режим SQL.
Для SELECT деление на ноль
вернет NULL . Включение
ERROR_FOR_DIVISION_BY_ZERO заставляет предупреждение быть
произведенным также, независимо от того, включен ли строгий режим.
ERROR_FOR_DIVISION_BY_ZERO
имеет эффект когда названо явно и не часть строгого режима.
Однако, это должно использоваться в соединении со строгим режимом и
включено по умолчанию. Предупреждение происходит, если
ERROR_FOR_DIVISION_BY_ZERO включен, не включая строгий режим или
наоборот. Для дополнительного обсуждения см.
здесь.
Поскольку
ERROR_FOR_DIVISION_BY_ZERO устарел, это будет удалено в будущем
выпуске MySQL как отдельное имя режима и его эффект, включенный в эффекты
строгого режима SQL.
-
HIGH_NOT_PRECEDENCE
Приоритет оператора NOT
таков, что такие выражения как NOT a BETWEEN b AND c
разобраны как NOT (a BETWEEN b AND c) .
В некоторых более старых версиях MySQL выражение было разобрано как
(NOT a) BETWEEN b AND c .
Старое поведение более высокого приоритета может быть получено, включая режим
SQL
HIGH_NOT_PRECEDENCE .
mysql> SET sql_mode = '';
mysql> SELECT NOT 1 BETWEEN -5 AND 5;
-> 0
mysql> SET sql_mode = 'HIGH_NOT_PRECEDENCE';
mysql> SELECT NOT 1 BETWEEN -5 AND 5;
-> 1
-
IGNORE_SPACE
Разрешение располагать пробелы между именем функции и символом
( . Это заставляет встроенные имена функций быть обработанными
как зарезервированные слова. В результате идентификаторы, которые являются
теми же самыми, как имена функций, должны быть заключены в кавычки, как
описано в разделе 10.2. Например, потому
что есть функция COUNT() ,
использование count как имени таблицы в следующем
запросе вызывает ошибку:
mysql> CREATE TABLE count (i INT);
ERROR 1064 (42000): You have an error in your SQL syntax
Имя таблицы должно быть заключено в кавычки:
mysql> CREATE TABLE `count` (i INT);
Query OK, 0 rows affected (0.00 sec)
Режим SQL IGNORE_SPACE
относится к встроенным функциям, а не к определяемым
пользователем или сохраненным функциям. Всегда допустимо иметь пробелы после
имени UDF или сохраненной функции, независимо от
IGNORE_SPACE .
Для дальнейшего обсуждения
IGNORE_SPACE см.
раздел 10.2.4.
-
NO_AUTO_CREATE_USER
Предотвратить GRANT
от автоматического создания новых учетных записей пользователя, если это
иначе сделало бы так, если информация об аутентификации не определена. Запрос
должен определить непустое использование пароля IDENTIFIED BY
или использование плагина аутентификации с IDENTIFIED WITH .
Предпочтительно создать учетные записи MySQL с
CREATE USER вместо
GRANT . С MySQL 5.7.6
NO_AUTO_CREATE_USER
устарел. С 5.7.7 по умолчанию режим SQL включает
NO_AUTO_CREATE_USER
и назначение sql_mode
изменения режима
NO_AUTO_CREATE_USER выдает предупреждение, кроме назначений,
которые устанавливают sql_mode
в DEFAULT .
NO_AUTO_CREATE_USER
будет удален в будущем выпуске MySQL, в котором его эффект будет
включен всегда (GRANT
не будет создавать учетные записи).
-
NO_AUTO_VALUE_ON_ZERO
NO_AUTO_VALUE_ON_ZERO затрагивает обработку столбцов
AUTO_INCREMENT . Обычно Вы производите следующий порядковый номер
для столбца, вставляя NULL или 0 .
NO_AUTO_VALUE_ON_ZERO подавляет это поведение для 0
так, что только NULL производит следующий порядковый номер.
Этот режим может быть полезным если 0 был сохранен в столбце
AUTO_INCREMENT . Например, если Вы выводите таблицу в дамп с
mysqldump
и затем перезагружаете ее, MySQL обычно производит новые порядковые номера,
когда сталкивается с 0 , приводящие к таблице с содержанием,
отличающимся от того, которое был выведено. Включение
NO_AUTO_VALUE_ON_ZERO прежде, чем перезагрузить файл дампа решает
эту проблему. mysqldump
теперь автоматически включает в его вывод запрос,
который включает
NO_AUTO_VALUE_ON_ZERO .
-
NO_BACKSLASH_ESCAPES
Отключить использование символа наклонной черты влево (\ ) как
символа ESC в пределах строк. С этим включенным режимом наклонная черта влево
становится обычным символом как любой другой.
-
NO_DIR_IN_CREATE
Составляя таблицу, проигнорировать все параметры
INDEX DIRECTORY и DATA DIRECTORY .
Эта опция полезна на ведомых серверах.
-
NO_ENGINE_SUBSTITUTION
Управляет автоматической заменой механизма хранения по умолчанию, когда
такой запрос, как CREATE TABLE
или ALTER TABLE
определяет механизм хранения, который отключен или не собран.
Значение по умолчанию режима SQL включает
NO_ENGINE_SUBSTITUTION .
Поскольку механизмы хранения могут быть подключаемыми
во время выполнения, недоступные механизмы обработаны тем же самым путем:
С выключенным
NO_ENGINE_SUBSTITUTION для
CREATE TABLE механизм по умолчанию используется, и предупреждение
происходит, если желаемый механизм недоступен. Для
ALTER TABLE
предупреждение происходит, и таблица не изменена.
С включенным
NO_ENGINE_SUBSTITUTION ошибка происходит, и таблица не составлена
или изменена, если желаемый механизм недоступен.
-
NO_FIELD_OPTIONS
Не печатать опции столбца MySQL в выводе
SHOW CREATE TABLE .
Этот режим используется
mysqldump в режиме мобильности.
-
NO_KEY_OPTIONS
Не печатать опции индекса MySQL в выводе
SHOW CREATE TABLE .
Этот режим используется
mysqldump в режиме мобильности.
-
NO_TABLE_OPTIONS
Не печатать опции таблицы MySQL (например, ENGINE ) в выводе
SHOW CREATE TABLE .
Этот режим используется
mysqldump в режиме мобильности.
-
NO_UNSIGNED_SUBTRACTION
Вычитание между целочисленными значениями, где каждое имеет тип
UNSIGNED , приводит к unsigned по умолчанию. Если результат иначе
был бы отрицателен, будет ошибка:
mysql> SET sql_mode = '';
Query OK, 0 rows affected (0.00 sec)
mysql> SELECT CAST(0 AS UNSIGNED) - 1;
ERROR 1690 (22003): BIGINT UNSIGNED value is out of range in
'(cast(0 as unsigned) - 1)'
Если включен
NO_UNSIGNED_SUBTRACTION , результат отрицателен:
mysql> SET sql_mode = 'NO_UNSIGNED_SUBTRACTION';
mysql> SELECT CAST(0 AS UNSIGNED) - 1;
+-------------------------+
| CAST(0 AS UNSIGNED) - 1 |
+-------------------------+
| -1 |
+-------------------------+
Если результат такой работы используется, чтобы обновить столбец
UNSIGNED integer, результат отсечен к максимальному значению для
типа столбца, или отсечен к 0, если включен
NO_UNSIGNED_SUBTRACTION . Если строгий режим SQL включен, ошибка
происходит, и столбец остается неизменным.
Когда включен
NO_UNSIGNED_SUBTRACTION , результат вычитания signed,
даже если какой-либо операнд unsigned. Например, сравните тип
столбца c2 в таблице t1 со столбцом
c2 в t2 :
mysql> SET sql_mode='';
mysql> CREATE TABLE test (c1 BIGINT UNSIGNED NOT NULL);
mysql> CREATE TABLE t1 SELECT c1 - 1 AS c2 FROM test;
mysql> DESCRIBE t1;
+-------+---------------------+------+-----+---------+-------+
| Field | Type | Null | Key | Default | Extra |
+-------+---------------------+------+-----+---------+-------+
| c2 | bigint(21) unsigned | NO | | 0 | |
+-------+---------------------+------+-----+---------+-------+
mysql> SET sql_mode='NO_UNSIGNED_SUBTRACTION';
mysql> CREATE TABLE t2 SELECT c1 - 1 AS c2 FROM test;
mysql> DESCRIBE t2;
+-------+------------+------+-----+---------+-------+
| Field | Type | Null | Key | Default | Extra |
+-------+------------+------+-----+---------+-------+
| c2 | bigint(21) | NO | | 0 | |
+-------+------------+------+-----+---------+-------+
Это означает, что BIGINT UNSIGNED не на 100% применимо во
всех контекстах. См. раздел 13.10.
-
NO_ZERO_DATE
NO_ZERO_DATE
затрагивает, разрешает ли сервер '0000-00-00'
как допустимую дату. Его эффект также зависит от того, включен ли
строгий режим SQL.
С MySQL 5.7.4
NO_ZERO_DATE
устарел. В MySQL 5.7.4 до 5.7.7
NO_ZERO_DATE ничего не делает, когда назван явно. Вместо
этого его эффект включен в эффекты строгого режима SQL. В MySQL 5.7.8 и позже
NO_ZERO_DATE
действительно имеет эффект, когда назван явно и не часть строгого режима, как
перед MySQL 5.7.4. Однако, это должно использоваться в соединении со строгим
режимом и включено по умолчанию. Предупреждение происходит, если
NO_ZERO_DATE
включен, также не включая строгий режим или наоборот. Для дополнительного
обсуждения см. здесь.
Так как NO_ZERO_DATE
устарел, это будет удалено в будущем выпуске MySQL как отдельное
имя режима, а его эффект включен в эффекты строгого режима SQL.
-
NO_ZERO_IN_DATE
NO_ZERO_IN_DATE
затрагивает, разрешает ли сервер даты, в которых часть года является
отличной от нуля, но часть месяца или дня 0. Этот режим затрагивает такие
даты, как '2010-00-01' или '2010-01-00' , но не
'0000-00-00' . Управлять, разрешает ли сервер '0000-00-00'
, можно через режим
NO_ZERO_DATE . Эффект
NO_ZERO_IN_DATE также зависит от того, включен ли
строгий режим SQL.
С MySQL 5.7.4
NO_ZERO_IN_DATE устарел. С MySQL 5.7.4 до 5.7.7
NO_ZERO_IN_DATE
ничего не делает, когда назван явно. Вместо этого его эффект включен в
эффекты строгого режима SQL. В MySQL 5.7.8 и позже
NO_ZERO_IN_DATE
действительно имеет эффект, когда назван явно и не часть строгого режима, как
перед MySQL 5.7.4. Однако, это должно использоваться в соединении со строгим
режимом и включено по умолчанию. Предупреждение происходит, если
NO_ZERO_IN_DATE
включен также не включая строгий режим или наоборот.
Поскольку
NO_ZERO_IN_DATE устарел, это будет удалено в будущем выпуске MySQL
как отдельное имя режима, а его эффект включен в эффекты строгого режима SQL.
-
ONLY_FULL_GROUP_BY
Отклонить запросы для которых список выборки,
HAVING или ORDER BY
обращается к несоединенным столбцам, которые не называют в
GROUP BY и не зависят функционально от (уникально определенных)
столбцов GROUP BY .
Расширение MySQL к стандартному SQL разрешает ссылки в
HAVING к выражениям-псевдонимам в избранном списке.
HAVING может отнестись к псевдонимам независимо от
ONLY_FULL_GROUP_BY
.
См. раздел 13.19.3.
-
PAD_CHAR_TO_FULL_LENGTH
По умолчанию конечные пробелы обрезаны от столбцов
CHAR при извлечении. Если включен
PAD_CHAR_TO_FULL_LENGTH , обрезка не происходит и полученный
CHAR дополнен до его полной длины.
Этот режим не относится к VARCHAR ,
для которых конечные пробелы сохранены при извлечении.
mysql> CREATE TABLE t1 (c1 CHAR(10));
Query OK, 0 rows affected (0.37 sec)
mysql> INSERT INTO t1 (c1) VALUES('xy');
Query OK, 1 row affected (0.01 sec)
mysql> SET sql_mode = '';
Query OK, 0 rows affected (0.00 sec)
mysql> SELECT c1, CHAR_LENGTH(c1) FROM t1;
+------+-----------------+
| c1 | CHAR_LENGTH(c1) |
+------+-----------------+
| xy | 2 |
+------+-----------------+
1 row in set (0.00 sec)
mysql> SET sql_mode = 'PAD_CHAR_TO_FULL_LENGTH';
Query OK, 0 rows affected (0.00 sec)
mysql> SELECT c1, CHAR_LENGTH(c1) FROM t1;
+----+-----------------+
| c1 | CHAR_LENGTH(c1) |
+----+-----------------+
| xy | 10 |
+----+-----------------+
1 row in set (0.00 sec)
-
PIPES_AS_CONCAT
Обработка оператора ||
как строковый оператор связи (то же самое, как
CONCAT() ) вместо
синонима для OR .
-
REAL_AS_FLOAT
Обработка REAL
как синонима для FLOAT
. По умолчанию MySQL обрабатывает
REAL как синоним
для DOUBLE .
-
STRICT_ALL_TABLES
Включить строгий режим SQL для всех механизмов хранения. Отклонены
недопустимые значения данных.
-
STRICT_TRANS_TABLES
Включить строгий режим SQL для транзакционных механизмов хранения, когда
возможно, и для нетранзакционных механизмов хранения.
Комбинация режимов SQL
Следующие специальные режимы обеспечены как сокращения
для комбинаций значений режимов из предыдущего списка.
ANSI
Аналог REAL_AS_FLOAT
,
PIPES_AS_CONCAT ,
ANSI_QUOTES ,
IGNORE_SPACE и
ONLY_FULL_GROUP_BY
.
ANSI
также заставляет сервер возвращать ошибку для запросов, где функция множества
S с внешней ссылкой
S (outer_ref )
не может быть соединена во внешнем запросе, против которого была решена
внешняя ссылка. Это такой запрос:
SELECT * FROM t1 WHERE t1.a IN (SELECT MAX(t1.b) FROM t2 WHERE ...);
Здесь MAX(t1.b)
не может быть соединена во внешнем запросе, потому что это появляется в
WHERE этого запроса. Стандартный SQL требует ошибки в этой
ситуации. Если ANSI
выключен, сервер обработает
S (outer_ref )
в таких запросах тем же самым способом, которым это интерпретировало бы
S (const ) .
См. раздел 1.8.
-
DB2
Аналог PIPES_AS_CONCAT
,
ANSI_QUOTES ,
IGNORE_SPACE ,
NO_KEY_OPTIONS ,
NO_TABLE_OPTIONS
и NO_FIELD_OPTIONS
.
-
MAXDB
Аналог PIPES_AS_CONCAT
,
ANSI_QUOTES ,
IGNORE_SPACE ,
NO_KEY_OPTIONS ,
NO_TABLE_OPTIONS
, NO_FIELD_OPTIONS
и
NO_AUTO_CREATE_USER .
-
MSSQL
Аналог PIPES_AS_CONCAT
,
ANSI_QUOTES ,
IGNORE_SPACE ,
NO_KEY_OPTIONS ,
NO_TABLE_OPTIONS
и NO_FIELD_OPTIONS
.
-
MYSQL323
Аналог MYSQL323 и
HIGH_NOT_PRECEDENCE
. Это означает
HIGH_NOT_PRECEDENCE плюс некоторая логика
SHOW CREATE TABLE ,
определенная для MYSQL323
:
MYSQL40
Аналог MYSQL40 и
HIGH_NOT_PRECEDENCE
. Это означает
HIGH_NOT_PRECEDENCE плюс некоторая логика, определенная для
MYSQL40 . Это то же
самое, что касается MYSQL323
, кроме того, что SHOW
CREATE TABLE не выводит на экран HEAP как механизм
хранения для таблиц MEMORY
.
-
ORACLE
Аналог PIPES_AS_CONCAT
,
ANSI_QUOTES ,
IGNORE_SPACE ,
NO_KEY_OPTIONS ,
NO_TABLE_OPTIONS
, NO_FIELD_OPTIONS
и
NO_AUTO_CREATE_USER .
-
POSTGRESQL
Аналог PIPES_AS_CONCAT
,
ANSI_QUOTES ,
IGNORE_SPACE ,
NO_KEY_OPTIONS ,
NO_TABLE_OPTIONS
и NO_FIELD_OPTIONS
.
-
TRADITIONAL
Перед MySQL 5.7.4, в MySQL 5.7.8 и позже
TRADITIONAL аналог
STRICT_TRANS_TABLES
,
STRICT_ALL_TABLES
,
NO_ZERO_IN_DATE ,
NO_ZERO_DATE ,
ERROR_FOR_DIVISION_BY_ZERO ,
NO_AUTO_CREATE_USER
и
NO_ENGINE_SUBSTITUTION .
Строгий режим SQL
Строгий режим управляет, как MySQL обрабатывает недопустимые или
недостающие значения в запросах изменения данных, например, в
INSERT или
UPDATE .
Значение может быть недопустимым по нескольким причинам. Например, у этого
мог бы быть неправильный тип данных для столбца, или это могло бы быть вне
диапазона. Значение отсутствует, когда новая строка, которая будет вставлена,
не содержит значение для столбца не-NULL , который не имеет явный
параметр DEFAULT в его определении. Для столбца
NULL если значение отсутствует, вставлено NULL .
Строгий режим также затрагивает запросы DDL, например,
CREATE TABLE .
Если строгий режим не включен, MySQL вставляет скорректированные значения
для недопустимых или недостающих значений и производит предупреждения (см.
раздел 14.7.5.40).
В строгом режиме Вы можете произвести это поведение при использовании
INSERT IGNORE или
UPDATE IGNORE .
Для запросов SELECT
которые не изменяют данные, недопустимые значения производят предупреждение в
строгом режиме, а не ошибку.
Строгий режим производит ошибку для попыток создать ключ, который
превышает максимальную длину ключа. Когда строгий режим не включен, это
приводит к предупреждению и усечению ключа к максимальной длине ключа.
Строгий режим не затрагивает, проверены ли ограничения внешнего ключа.
foreign_key_checks
может использоваться для этого. См.
раздел 6.1.5.
Строгий режим SQL работает, если также
STRICT_ALL_TABLES
или
STRICT_TRANS_TABLES включены, хотя эффекты этих
режимов несколько отличаются:
Строгий режим влияет на обработку деления на ноль, на нулевые даты и ноли
в датах следующим образом:
Строгий режим влияет на обработку деления на ноль, что включает
MOD(N ,0)
:
Для операций изменения данных
(INSERT ,
UPDATE ):
Для SELECT деление на ноль
вернет NULL . Включение строгого режима заставляет предупреждение
быть произведенным также.
- Строгий режим затрагивает, разрешает ли сервер
'0000-00-00' как допустимую дату:
Строгий режим затрагивает, разрешает ли сервер даты, в которых
часть года является отличной от нуля, но часть месяца или дня 0, например,
'2010-00-01' или '2010-01-00' ):
Строгий режим влияет на обработку деления на ноль, на нулевые даты и ноли
в датах в соединении с режимами
ERROR_FOR_DIVISION_BY_ZERO ,
NO_ZERO_DATE и
NO_ZERO_IN_DATE
.
Сравнение ключевого слова IGNORE и
строгого режима SQL
Этот раздел сравнивает эффект на выполнение запроса ключевого слова
IGNORE (которое понижает ошибки до предупреждений)
и строгого режима SQL (который повышает предупреждения до ошибок). Это
описывает, какие запросы они затрагивают, и к каким ошибкам относятся.
Следующая таблица представляет итоговое сравнение поведения запросов,
когда значение по умолчанию должно произвести ошибку против предупреждения.
Пример того, когда значение по умолчанию должно произвести ошибку: вставка
NULL в столбец NOT NULL .
Пример того, когда значение по умолчанию должно произвести предупреждение:
вставка значения неправильного типа данных в столбец (например,
вставка строки 'abc' в столбец целого числа).
Операционный режим |
Когда значение по умолчанию выдаст ошибку |
Когда значение по умолчанию выдаст предупреждение
|
Без IGNORE или строгий режим SQL |
Ошибка | Предупреждение |
Без IGNORE | Предупреждение |
Warning (как если без IGNORE или строгий режим SQL) |
Со строгим режимом SQL |
Error (как если без IGNORE или строгий режим SQL) |
Ошибка |
С IGNORE и строгий режим SQL |
Предупреждение | Предупреждение |
Когда одновременно указаны IGNORE
и строгий режим SQL, IGNORE имеет приоритет. Это означает, что,
хотя IGNORE и строгий режим SQL имеют противоположные эффекты на
обработку ошибок, они не отменяют друг друга, когда используются вместе.
Действие IGNORE на выполнение запросов
Несколько запросов в MySQL поддерживают дополнительное ключевое слово
IGNORE . Это ключевое слово заставляет сервер понижать
определенные типы ошибок и производить предупреждения вместо них. Для
запросов с многими строками IGNORE
заставляет запрос переходить к следующей строке вместо прерывания.
Например, если таблица t имеет столбец первичного ключа
i , попытка вставить то же самое значение i
в много строк обычно производит ключевую ошибку:
mysql> INSERT INTO t (i) VALUES(1),(1);
ERROR 1062 (23000): Duplicate entry '1' for key 'PRIMARY'
С IGNORE строка, содержащая дубликат ключа, не вставлена, но
предупреждение происходит вместо ошибки:
mysql> INSERT IGNORE INTO t (i) VALUES(1),(1);
Query OK, 1 row affected, 1 warning (0.01 sec)
Records: 2 Duplicates: 1 Warnings: 1
mysql> SHOW WARNINGS;
+---------+------+---------------------------------------+
| Level | Code | Message |
+---------+------+---------------------------------------+
| Warning | 1062 | Duplicate entry '1' for key 'PRIMARY' |
+---------+------+---------------------------------------+
1 row in set (0.00 sec)
Эти запросы поддерживают ключевое слово IGNORE :
CREATE TABLE
... SELECT : IGNORE не относится к части
CREATE TABLE или
SELECT , но применяется к вставкам в
таблицу строк, произведенных SELECT
. Отказываются от строк, которые дублируют существующую строку на
уникальном значении ключа.
DELETE : IGNORE
предписывает MySQL проигнорировать ошибки во время процесса удаления строк.
INSERT : С IGNORE
отказываются от строк, которые дублируют существующую строку на уникальном
значении ключа. Значения, которые вызвали бы конверсионные ошибки данных,
установлены в самые близкие допустимые значения вместо этого.
Для разделенных таблиц, где никакой раздел, соответствующий данному
значению, не найден, IGNORE заставляет работу вставки терпеть
неудачу тихо для строк, содержащих неподходящее значение.
LOAD DATA ,
LOAD XML : С IGNORE
отказываются от строк, которые дублируют существующую строку на
уникальном значении ключа.
UPDATE : С IGNORE
строки, для которых ключевые конфликты происходят на уникальном значении
ключа, не обновлены. Строки, обновленные к значениям, которые вызвали бы
конверсионные ошибки данных, обновлены к самым близким допустимым
значениям вместо этого.
Ключевое слово IGNORE относится к следующим ошибкам:
ER_BAD_NULL_ERROR
ER_DUP_ENTRY
ER_DUP_ENTRY_WITH_KEY_NAME
ER_DUP_KEY
ER_NO_PARTITION_FOR_GIVEN_VALUE
ER_NO_PARTITION_FOR_GIVEN_VALUE_SILENT
ER_NO_REFERENCED_ROW_2
ER_ROW_DOES_NOT_MATCH_GIVEN_PARTITION_SET
ER_ROW_IS_REFERENCED_2
ER_SUBQUERY_NO_1_ROW
ER_VIEW_CHECK_FAILED
Действие строгого режима SQL
на выполнение запросов
Сервер MySQL может работать в различных режимах SQL и применить эти режимы
по-другому для различных клиентов, в зависимости от значения
sql_mode .
В строгом режиме SQL сервер повышает определенные
предупреждения до ошибок.
Например, в нестрогом режиме SQL вставка строки 'abc' в
столбец integer приводит к преобразованию значения к 0 и предупреждению:
mysql> SET sql_mode = '';
Query OK, 0 rows affected (0.00 sec)
mysql> INSERT INTO t (i) VALUES('abc');
Query OK, 1 row affected, 1 warning (0.01 sec)
mysql> SHOW WARNINGS;
+---------+------+--------------------------------------------------------+
| Level | Code | Message |
+---------+------+--------------------------------------------------------+
| Warning | 1366 | Incorrect integer value: 'abc' for column 'i' at row 1 |
+---------+------+--------------------------------------------------------+
1 row in set (0.00 sec)
В строгом режиме SQL недопустимое значение отклонено с ошибкой:
mysql> SET sql_mode = 'STRICT_ALL_TABLES';
Query OK, 0 rows affected (0.00 sec)
mysql> INSERT INTO t (i) VALUES('abc');
ERROR 1366 (HY000): Incorrect integer value: 'abc' for column 'i' at row 1
См. раздел 6.1.8.
Строгий режим SQL относится к следующим запросым при условиях, для которых
некоторое значение могло бы быть вне диапазона, или недопустимая строка
вставлена или удалена из таблицы:
В пределах сохраненных программ отдельные запросы выполняются в строгом
режиме SQL, если программа была определена в то время, как строгий
режим был включен.
Строгий режим SQL относится к следующим ошибкам, представляющимм
класс ошибок, по которым входное значение является или недопустимым или
недостающим. Значение недопустимо, если оно имеет неправильный тип данных для
столбца или могло бы быть вне диапазона. Значение отсутствует, если новая
строка, которая будет вставлена, не содержит значение для столбца NOT
NULL , который имеет не явного параметра DEFAULT .
ER_BAD_NULL_ERROR
ER_CUT_VALUE_GROUP_CONCAT
ER_DATA_TOO_LONG
ER_DATETIME_FUNCTION_OVERFLOW
ER_DIVISION_BY_ZERO
ER_INVALID_ARGUMENT_FOR_LOGARITHM
ER_NO_DEFAULT_FOR_FIELD
ER_NO_DEFAULT_FOR_VIEW_FIELD
ER_TOO_LONG_KEY
ER_TRUNCATED_WRONG_VALUE
ER_TRUNCATED_WRONG_VALUE_FOR_FIELD
ER_WARN_DATA_OUT_OF_RANGE
ER_WARN_NULL_TO_NOTNULL
ER_WARN_TOO_FEW_RECORDS
ER_WRONG_ARGUMENTS
ER_WRONG_VALUE_FOR_TYPE
WARN_DATA_TRUNCATED
Изменения режима SQL в MySQL 5.7
В MySQL 5.7.5 режим SQL
ONLY_FULL_GROUP_BY включен по умолчанию потому что обработка
GROUP BY стала более сложной, чтобы включать обнаружение
функциональных зависимостей. Однако, если Вы считаете
ONLY_FULL_GROUP_BY
причиной проблем для существующих приложений, которые будут
отклонены, любое из этих действий должно восстановить работу:
Если возможно изменить незаконный запрос, сделайте так,
чтобы несоединенные столбцы функционально зависели от GROUP BY
или обращаясь к несоединенному столбцу, используйте
ANY_VALUE() .
- Если не возможно изменить незаконный запрос (например, если это
произведено имеющим отношение к третьей стороне приложением), установите
sql_mode при запуске сервера, чтобы не включить
ONLY_FULL_GROUP_BY
.
С MySQL 5.7.4
ERROR_FOR_DIVISION_BY_ZERO ,
NO_ZERO_DATE и
NO_ZERO_IN_DATE
устарели. С MySQL 5.7.4 до 5.7.7 они ничего не делают когда названы явно.
Вместо этого их эффекты включены в эффекты строгого режима SQL
(STRICT_ALL_TABLES
или
STRICT_TRANS_TABLES ). Другими словами, строгий режим означает ту
же самую вещь в тех версиях как строгий режим до 5.7.4 плюс
ERROR_FOR_DIVISION_BY_ZERO ,
NO_ZERO_DATE и
NO_ZERO_IN_DATE
.
MySQL 5.7.4 изменен, чтобы сделать строгий режим более строгим включением
ERROR_FOR_DIVISION_BY_ZERO ,
NO_ZERO_DATE и
NO_ZERO_IN_DATE .
Это вызывает некоторые проблемы. Например, в MySQL 5.6 со строгим режимом без
NO_ZERO_DATE
столбцы TIMESTAMP
могут быть определены с DEFAULT '0000-00-00 00:00:00' . В MySQL
5.7.4 с теми же самыми настройками режима строгий режим включает эффект
NO_ZERO_DATE , и
столбцы TIMESTAMP
не могут быть определены с DEFAULT '0000-00-00 00:00:00' .
В итоге репилкация CREATE TABLE
с 5.6 до 5.7.4 терпит неудачу, если запросы содержат такой столбец
TIMESTAMP .
Долгосрочный план состоит в том, чтобы все еще иметь три затронутых режима
включенными в строгом режиме SQL и удалить их как явные режимы в будущем
выпуске MySQL. Но, чтобы восстановить совместимость строгих режимов в MySQL
5.7 с MySQL 5.6 и обеспечить дополнительное время для затронутых приложений,
которые будут изменены, следующие изменения были произведены в MySQL 5.7.8:
ERROR_FOR_DIVISION_BY_ZERO ,
NO_ZERO_DATE и
NO_ZERO_IN_DATE
имеют эффект, когда вызваны явно.
Это возвращается изменение, произведенное в MySQL 5.7.4.
ERROR_FOR_DIVISION_BY_ZERO ,
NO_ZERO_DATE и
NO_ZERO_IN_DATE
не часть строгого режима SQL.
Это возвращается изменение, произведенное в MySQL 5.7.4.
ERROR_FOR_DIVISION_BY_ZERO ,
NO_ZERO_DATE и
NO_ZERO_IN_DATE
включены в значение по умолчанию
sql_mode , которое в
результате включает эти режимы:
ONLY_FULL_GROUP_BY
,
STRICT_TRANS_TABLES
,
NO_ZERO_IN_DATE ,
NO_ZERO_DATE ,
ERROR_FOR_DIVISION_BY_ZERO ,
NO_AUTO_CREATE_USER
и
NO_ENGINE_SUBSTITUTION .
С предыдущими изменениями более строгая проверка данных все еще включена
по умолчанию, но отдельные режимы могут быть отключены в среде, где это в
настоящее время желательно или необходимо сделать.
Хотя в MySQL 5.7.8 и позже
ERROR_FOR_DIVISION_BY_ZERO ,
NO_ZERO_DATE и
NO_ZERO_IN_DATE
могут использоваться отдельно от строгого режима, это предназначено, чтобы
они использовались вместе. Как напоминание, происходит предупреждение, если
их включают, также не включая строгий режим или наоборот.
Следующее обсуждение применяется только для версий от MySQL 5.7.4 до
5.7.7. Для обновлений от версии более старой, чем MySQL 5.7.4, мы рекомендуем
обновить до MySQL 5.7.8 или позже.
Остаток этого раздела описывает настройки режима SQL, чтобы использовать в
MySQL с 5.7.4 до 5.7.7, чтобы достигнуть того же самого выполнения запроса,
как до 5.7.4, включая случаи для
INSERT и
UPDATE , в которых задано
IGNORE . Это также обеспечивает мысли для того, чтобы Вы
определили, нуждаются ли приложения в модификации, чтобы вести себя так же
прежде и после изменений режима SQL.
Следующая таблица показывает, как управлять обработкой деления на ноль
для версий, кроме MySQL с 5.7.4 до 5.7.7 и для MySQL с 5.7.4 до 5.7.7.
Желаемое поведение | MySQL
5.7.x, кроме с 5.7.4 до 5.7.7 | MySQL с 5.7.4 до 5.7.7
|
Вставить NULL , не производить
предупреждение | ERROR_FOR_DIVISION_BY_ZERO выключен |
Строгий режим не включен |
Вставить NULL , производить предупреждение
| ERROR_FOR_DIVISION_BY_ZERO , или
ERROR_FOR_DIVISION_BY_ZERO + строгий режим + IGNORE
| Строгий режим + IGNORE |
Ошибка | ERROR_FOR_DIVISION_BY_ZERO +
строгий режим | Строгий режим |
Следующая таблица показывает, как управлять, разрешает ли сервер
'0000-00-00' как допустимую дату в версиях, кроме MySQL с 5.7.4
до 5.7.7 и для MySQL с 5.7.4 до 5.7.7.
Желаемое поведение | MySQL
5.7.x, кроме с 5.7.4 до 5.7.7 | MySQL с 5.7.4 до 5.7.7
|
Вставить '0000-00-00' без
предупреждения | NO_ZERO_DATE выключен |
Строгий режим выключен |
Вставить '0000-00-00' с предупреждением |
NO_ZERO_DATE или NO_ZERO_DATE +
строгий режим + IGNORE | Строгий режим +
IGNORE |
Ошибка | NO_ZERO_DATE + строгий режим
| Строгий режим |
Следующая таблица показывает, как управлять, разрешает ли сервер даты с
нулевыми частями для версий кроме MySQL с 5.7.4 до 5.7.7 и для MySQL с 5.7.4
до 5.7.7.
Желаемое поведение | MySQL
5.7.x, кроме с 5.7.4 до 5.7.7 | MySQL с 5.7.4 до 5.7.7
|
Вставить дату без предупреждения |
NO_ZERO_IN_DATE выключен | Строгий режим выключен |
Вставить '0000-00-00' с предупреждением |
NO_ZERO_IN_DATE или NO_ZERO_IN_DATE + строгий
режим + IGNORE | Строгий режим + IGNORE |
Ошибка | NO_ZERO_IN_DATE +
строгий режим | Строгий режим |
Следующее обсуждение описывает условия, при которых данный запрос приводит
к тому же самому или различному результату под изменениями режима SQL в MySQL
с 5.7.4 до 5.7.7. Это рассматривает только строгий режим
(STRICT_ALL_TABLES
или
STRICT_TRANS_TABLES ) и три устаревших режима
(
ERROR_FOR_DIVISION_BY_ZERO ,
NO_ZERO_DATE и
NO_ZERO_IN_DATE
). Другие режимы SQL, например,
ANSI_QUOTES или
ONLY_FULL_GROUP_BY
считаются постоянными до и после обновления.
Это обсуждение также описывает, как подготовиться к обновлению до 5.7.4 и
до 5.7.7 от версии, более старой, чем 5.7.4. Любые модификации
должны быть сделаны перед обновлением!
Нет никакого изменения в поведении между MySQL 5.6 и 5.7 для следующих
настроек режима SQL. Запрос, который выполняется при одной из этих настроек,
не нуждается ни в какой модификации, чтобы привести к тому же самому
результату в ветках версий 5.6 и 5.7:
Изменение происходит от предупреждений в MySQL 5.6 к отсутствию
предупреждений в MySQL 5.7 для следующих настроек режима SQL. Результат
выполнения запросы тот же самый в 5.6 и 5.7, таким образом, запросы не
нуждаются ни в какой модификации, если предупреждения
не считаются существенными:
Изменение поведения происходит при следующих настройках режима SQL.
Запрос, который выполняется при одной из этих настроек, должен быть изменен,
чтобы привести к тому же самому результату в 5.6 и 5.7:
Строгий режим не включен,
NO_ZERO_IN_DATE
включен. Для этой установки режима, ожидайте эти различия в выполнении:
Строгий режим включен вместе с некоторыми, но не всеми, устаревшими
режимами. Для этой установки режима ожидайте эти различия в выполнении:
Запросы, которые были бы затронуты, включая устаревшие режимы,
производят ошибки в 5.7, но не в 5.6. Предположите, что включены строгий
режим, NO_ZERO_DATE
и NO_ZERO_IN_DATE
, а запрос изменения данных выполняет деление на ноль:
Чтобы подготовиться к обновлению до MySQL с 5.7.4 до 5.7.7, основной
принцип должен удостовериться, что Ваши приложения будут управлять тем же
самым путем в MySQL 5.6 и 5.7. Например, Вы можете принять любой из этих
подходов к совместимости приложения:
Измените приложение, чтобы установить режим SQL на определенной
для версии основе. Если мы предполагаем, что приложение не будет
использоваться с версиями развития MySQL 5.7 до 5.7.4, возможно установить
sql_mode
для приложения, основанного на текущей версии сервера следующим образом:
SET sql_mode = IF(LEFT(VERSION(),3)<'5.7',5.6 mode ,5.7 mode );
Таблицы, показанные ранее в этом разделе, служат руководством по
соответствующим эквивалентным режимам для MySQL 5.6 и 5.7.
- Измените приложение, чтобы выполнять в режиме SQL, для которого запросы
приводят к тому же самому результату в MySQL 5.6 и 5.7.
Режим SQL TRADITIONAL
в MySQL 5.6 включает строгий режим и три устаревших
режима. Если Вы пишете приложения, чтобы работать в
TRADITIONAL в
MySQL 5.6, нет никакого изменения для MySQL 5.7.
Оценивая совместимость режима SQL между MySQL 5.6 и 5.7, рассмотрите
особенно эти контексты выполнения:
Репликация. Вы столкнетесь с несовместимостью, связанной с
изменениями режима SQL при следующих условиях:
Чтобы обработать эту несовместимость, используйте одно из
этих обходных решений:
Сохраненные программы (хранимые процедуры и функции, триггеры и
события). Каждая сохраненная программа выполняется с использованием режима
SQL, который был в то время, когда это создавалось. Чтобы идентифицировать
сохраненные программы, которые могут быть затронуты различиями между MySQL
5.6 и 5.7 в обработке режима SQL, используйте эти запросы:
SELECT ROUTINE_SCHEMA, ROUTINE_NAME, ROUTINE_TYPE, SQL_MODE
FROM INFORMATION_SCHEMA.ROUTINES
WHERE SQL_MODE LIKE '%STRICT%' OR SQL_MODE LIKE '%DIVISION%' OR
SQL_MODE LIKE '%NO_ZERO%';
SELECT TRIGGER_SCHEMA, TRIGGER_NAME, SQL_MODE
FROM INFORMATION_SCHEMA.TRIGGERS WHERE SQL_MODE LIKE '%STRICT%' OR
SQL_MODE LIKE '%DIVISION%' OR SQL_MODE LIKE '%NO_ZERO%';
SELECT EVENT_SCHEMA, EVENT_NAME, SQL_MODE FROM INFORMATION_SCHEMA.EVENTS
WHERE SQL_MODE LIKE '%STRICT%' OR SQL_MODE LIKE '%DIVISION%' OR
SQL_MODE LIKE '%NO_ZERO%';
6.1.9. Поддержка IPv6
Поддержка IPv6 в MySQL включает эти способности:
MySQL Server может принять соединения TCP/IP от клиентов,
соединяющихся по IPv6. Например, эта команда соединяется по IPv6 с сервером
MySQL на местном узле:
shell> mysql -h ::1
Чтобы использовать эту способность, две вещи должны быть истиной:
Имена учетной записи MySQL разрешают адресам IPv6 определить
привилегии для клиентов, которые соединяются с сервером по IPv6. См.
раздел 7.2.3. Адреса IPv6 могут
быть определены на именах учетных записей в таких запросах, как
CREATE USER ,
GRANT и
REVOKE :
mysql> CREATE USER 'bill'@'::1' IDENTIFIED BY 'secret';
mysql> GRANT SELECT ON mydb.* TO 'bill'@'::1';
- Функции IPv6 включают преобразование между строкой и внутренними
форматами адреса формата IPv6 и проверку, представляют ли значения допустимые
адреса IPv6. Например,
INET6_ATON() и
INET6_NTOA()
подобны INET_ATON() и
INET_NTOA() ,
но обрабатывают адреса IPv6 в дополнение к адресам IPv4. См.
раздел 13.18.
Следующие разделы описывают, как настроить MySQL так, чтобы клиенты могли
соединиться с сервером по IPv6.
6.1.9.1.
Подтверждение системной поддержки IPv6
Прежде, чем сервер MySQL может принять соединения IPv6, операционная
система на Вашем узле сервера должна поддерживать IPv6. Как простой тест,
чтобы определить, является ли это истиной, попробуйте эту команду:
shell> ping6 ::1
16 bytes from ::1, icmp_seq=0 hlim=64 time=0.171 ms
16 bytes from ::1, icmp_seq=1 hlim=64 time=0.077 ms
...
Чтобы произвести описание сетевых интерфейсов Вашей системы, вызовите
ifconfig -a и ищите адреса IPv6 в выводе.
Если Ваш узел не поддерживает IPv6, консультируйтесь со своей системной
документацией для инструкций по включению. Может быть Вы должны только
реконфигурировать существующий сетевой интерфейс, чтобы добавить адрес IPv6.
Или более обширное изменение могло бы быть необходимо, такое как пересборка
ядра с включенными опциями IPv6.
Эти ссылки могут быть полезными в установке IPv6
на различных платформах:
6.1.9.2. Конфигурирование сервера MySQL,
чтобы разрешить соединения IPv6
Сервер MySQL слушает на единственном сетевом сокете для соединений TCP/IP.
Это связано с единственным адресом, но для адреса возможно отобразиться на
многократные сетевые интерфейсы. Чтобы определить адрес, используйте опцию
--bind-address=
addr при запуске сервера, где
addr IPv4 или адрес IPv6 или имя хоста. Если
addr имя хоста, сервер решает имя к IP-адресу и
связывается с тем адресом.
Сервер обрабатывает различные типы адресов следующим образом:
Если адрес * , сервер признает соединения TCP/IP на
всех интерфейсах IPv6 и IPv4, если узел сервера поддерживает IPv6, или
принимает соединения TCP/IP на всех адресах IPv4 иначе. Используйте этот
адрес, чтобы разрешить соединения IPv4 и IPv6 на всех интерфейсах сервера.
Это значение по умолчанию.
- Если адрес
0.0.0.0 , сервер признает
соединения TCP/IP на всех интерфейсах IPv4.
- Если адрес
:: , сервер признает
соединения TCP/IP на всех интерфейсах IPv4 и IPv6.
Используйте этот адрес, чтобы разрешить соединения IPv4 и IPv6 на
всех интерфейсах сервера.
- Если это IPv4-отображенный адрес, сервер принимает соединения TCP/IP для
этого адреса в формате IPv4 или IPv6. Например, если сервер связан с
::ffff:127.0.0.1 , клиенты могут соединиться с использованием
--host=127.0.0.1 или --host=::ffff:127.0.0.1 .
- Если адрес обычный IPv4 или IPv6
(например,
127.0.0.1 или ::1 ), сервер принимает
соединения TCP/IP только для того адреса IPv4 или IPv6.
Если Вы намереваетесь связать сервер с определенным адресом, убедитесь что
таблица mysql.user содержит учетную запись с административными
привилегиями, которую Вы можете использовать, чтобы соединиться с тем
адресом. Иначе Вы не будете в состоянии закрыть сервер. Например, если Вы
связываете сервер с * , Вы можете соединиться с этим, используя
все существующие учетные записи. Но если Вы связываете сервер с
::1 , это принимает соединения только на этом адресе. В этом
случае сначала удостоверьтесь, что 'root'@'::1' присутствует в
mysql.user , таким образом, Вы можете соединиться с сервером,
чтобы закрыть его.
6.1.9.3.
Соединение, используя местный адрес узла IPv6
Следующая процедура показывает, как сконфигурировать MySQL, чтобы
разрешить соединения IPv6 клиентам, которые соединяются с локальным сервером,
используя ::1 . Инструкции, данные здесь, предполагают, что Ваша
система поддерживает IPv6.
Запустите сервер MySQL с соответствующей опцией
--bind-address
, чтобы разрешить принимать соединения IPv6. Например, поместите
следующие строки в свой файл параметров сервера и перезапустите сервер:
[mysqld]
bind-address = *
Альтернативно, Вы можете связать сервер с ::1 ,
но это делает сервер более строгим для соединений TCP/IP. Это принимает
только соединения IPv6 для того единственного адреса и отклоняет соединения
IPv4. Для получения дополнительной информации см.
раздел 6.1.9.2.
- Как администратор соединитесь с сервером и создайте учетную запись
на местного пользователя, который соединится от
::1 :
mysql> CREATE USER 'ipv6user'@'::1' IDENTIFIED BY 'ipv6pass';
Для разрешенного синтаксиса адресов IPv6 в имени учетной записи см.
see раздел 7.2.3.
В дополнение к CREATE USER
Вы можете применить GRANT , который
дает определенные привилегии учетной записи, хотя это не необходимо для
остающихся шагов в этой процедуре.
- Вызовите клиент
mysql, чтобы соединиться с сервером,
используя новую учетную запись:
shell> mysql -h ::1 -u ipv6user -pipv6pass
- Попробуйте некоторые простые запросы:
mysql> STATUS
...
Connection: ::1 via TCP/IP
...
mysql> SELECT CURRENT_USER(), @@bind_address;
+----------------+----------------+
| CURRENT_USER() | @@bind_address |
+----------------+----------------+
| ipv6user@::1 | :: |
+----------------+----------------+
6.1.9.4.
Соединение, используя нелокальные адреса узла IPv6
Следующая процедура показывает, как сконфигурировать MySQL, чтобы
разрешить соединения IPv6 отдаленным клиентам. Это подобно предыдущей
процедуре для местных клиентов, но сервер и хосты клиента отличны, и у
каждого есть его собственный нелокальный адрес IPv6.
Пример использует эти адреса:
Server host: 2001:db8:0:f101::1
Client host: 2001:db8:0:f101::2
Эти адреса выбраны из nonroutable адресного пространства, рекомендуемого
IANA в целях документации и достаточны для того, чтобы
проверить на Вашей местной сети. Чтобы принять соединения IPv6 от клиентов
вне местной сети, у узла сервера должен быть общественный адрес. Если Ваш
сетевой провайдер назначает Вам адрес IPv6, Вы можете использовать его. Иначе
другой способ получить адрес состоит в том, чтобы использовать
брокера IPv6, см. раздел 6.1.9.5.
Запустите сервер MySQL с соответствующей опцией
--bind-address
, чтобы разрешить этому принимать соединения IPv6. Например, поместите
следующие строки в свой файл параметров сервера и перезапустите сервер:
[mysqld]
bind-address = *
Альтернативно, Вы можете связать сервер с
2001:db8:0:f101::1 , но это делает сервер более строгим
для соединений TCP/IP. Это принимает только соединения IPv6 для этого
единственного адреса и отклоняет соединения IPv4. Для получения
дополнительной информации см.
раздел 6.1.9.2.
- На узле сервера (
2001:db8:0:f101::1 )
создайте учетку на пользователя, который соединится от хоста клиента
(2001:db8:0:f101::2 ):
mysql> CREATE USER 'remoteipv6user'@'2001:db8:0:f101::2' IDENTIFIED BY 'remoteipv6pass';
- На хосте клиента (
2001:db8:0:f101::2 ) вызовите
mysql,
чтобы соединиться с сервером, используя новую учетную запись:
shell> mysql -h 2001:db8:0:f101::1 -u remoteipv6user -premoteipv6pass
- Попробуйте некоторые простые запросы:
mysql> STATUS
...
Connection: 2001:db8:0:f101::1 via TCP/IP
...
mysql> SELECT CURRENT_USER(), @@bind_address;
+-----------------------------------+----------------+
| CURRENT_USER() | @@bind_address |
+-----------------------------------+----------------+
| remoteipv6user@2001:db8:0:f101::2 | :: |
+-----------------------------------+----------------+
6.1.9.5. Получение адреса IPv6 от брокера
Если у Вас нет общественного адреса IPv6, который позволяет Вашей системе
общаться по IPv6 вне Вашей местной сети, Вы можете получить один
от брокера IPv6. Wikipedia IPv6 Tunnel Broker page
перечисляет несколько брокеров и их особенности, например, обеспечивают
ли они статические адреса и поддержанные протоколы маршрутизации.
После конфигурирования Вашего узла сервера, чтобы использовать
предоставленный брокером адрес IPv6, запустите сервер MySQL с соответствующей
опцией --bind-address
, чтобы разрешить серверу принимать соединения IPv6. Например,
поместите следующие строки в файл параметров сервера и перезапустите сервер:
[mysqld]
bind-address = *
Альтернативно, Вы можете связать сервер с определенным адресом IPv6,
обеспеченным брокером, но это делает сервер более строгим для соединений
TCP/IP. Это принимает только соединения IPv6 для того единственного адреса и
отклоняет соединения IPv4. Для получения дополнительной информации см.
раздел 6.1.9.2.
Кроме того, если брокер выделяет динамические адреса, адрес Вашей системы
мог бы измениться в следующий раз, когда Вы соединяетесь с брокером. Если
так, любые учетные записи, которые Вы создаете для этого адреса, становятся
недопустимыми. Чтобы связать с определенным адресом, но избежать этой
проблемы смены адреса, работайте с брокером статического адреса IPv6.
Следующий пример показывает, как использовать Freenet6 в качестве брокера
и пакет клиента IPv6 gogoc в Gentoo Linux.
Создайте учетную запись в Freenet6, посещая этот URL:
http://gogonet.gogo6.com
- После создания учетной записи
создайте здесь пользовательское ID и пароль для брокера IPv6:
http://gogonet.gogo6.com/page/freenet6-registration
- Как
root установите gogoc:
shell> emerge gogoc
- Редактируйте
/etc/gogoc/gogoc.conf , чтобы установить
userid и password , например:
userid=gogouser
passwd=gogopass
- Запустите gogoc:
shell> /etc/init.d/gogoc start
Чтобы запустить gogoc
каждый раз при запуске Вашей системы, выполните эту команду:
shell> rc-update add gogoc default
- Используйте ping6,
чтобы попытаться проверить с помощью ping-запросов узел:
shell> ping6 ipv6.google.com
- Чтобы увидеть Ваш адрес IPv6:
shell> ifconfig tun
6.1.10. Серверная справка
MySQL Server поддерживает запрос HELP
, который возвращает информацию из MySQL Reference manual
(см. раздел 14.8.3). Несколько таблиц в
системной базе данных mysql содержат информацию, чтобы
поддержать этот запрос (см. раздел 6.3
). Правильное функционирование этого запроса требует, чтобы эти таблицы
справки были инициализированы, что сделано скриптом
fill_help_tables.sql .
Если Вы устанавливаете MySQL, используя исходные тексты или двоичный
дистрибутив в Unix, инициализация контента справки происходит, когда Вы
инициализируете каталог данных (см.
раздел 2.9.1). Для
RPM в Linux или двоичного дистрибутива в Windows
инициализация контента происходит как часть процесса установки MySQL.
Если Вы обновляете MySQL, используя двоичный дистрибутив, табличный
контент справки не обновлен автоматически, но Вы можете обновить это вручную.
Определите местонахождение файла fill_help_tables.sql в каталоге
share или share/mysql . Перейдите в тот каталог и
обработайте файл с помощью клиента
mysql:
shell> mysql -u root mysql < fill_help_tables.sql
Вы можете также получить последний fill_help_tables.sql
в любое время, чтобы обновить Ваши таблицы справки. Загрузите надлежащий файл
для своей версии MySQL с http://dev.mysql.com/doc/index-other.html.
После загрузки и распаковки файла обработайте это с
mysql,
как описано ранее.
Если Вы работаете с Git и исходным деревом развития MySQL, Вы должны
использовать загруженную копию fill_help_tables.sql , потому что
исходное дерево содержит только версию stub.
Для сервера, который участвует в репликации, процесс обновления контента
справки вовлекает много серверов. Для деталей см.
раздел 19.4.1.29
.
6.1.11. Ответ сервера на сигналы
В Unix сигналы можно послать в процессы.
mysqld
отвечает на сигналы, посланные ему, следующим образом:
SIGTERM заставляет сервер закрываться.
SIGHUP заставляет сервер перезагружать таблицы привилегий
и сбросить таблицы, журналы, кэш потока и кэш узла. Эти действия походят на
различные формы FLUSH .
Сервер также пишет отчет о состоянии в журнал ошибок, у которого
есть этот формат:
Status information:
Current dir: /var/mysql/data/
Running threads: 0 Stack size: 196608
Current locks:
Key caches:
default
Buffer_size: 8388600
Block_size: 1024
Division_limit:100
Age_limit: 300
blocks used: 0
not flushed: 0
w_requests: 0
writes:0
r_requests: 0
reads: 0
handler status:
read_key:0
read_next: 0
read_rnd 0
read_first:1
write: 0
delete 0
update: 0
Table status:
Opened tables:5
Open tables:0
Open files: 7
Open streams: 0
Alarm status:
Active alarms: 1
Max used alarms: 2
Next alarm time: 67
6.1.12. Процесс завершения работы сервера
Процесс завершения работы сервера таков:
Процесс завершения работы начат.
Это может произойти разными способами. Например, пользователь с
привилегией SHUTDOWN
выполнил mysqladmin shutdown
.
mysqladmin может использоваться на любой платформе,
поддержанной MySQL. Другие определенные для системы методы инициирования
завершения работы возможны также: сервер закрывается в Unix, когда получает
сигнал SIGTERM . Сервер, работающий как служба на Windows,
закрывается, когда менеджер служб говорит ему это.
- Сервер создает поток завершения работы в случае необходимости.
В зависимости от того, как было начато завершение работы, сервер мог бы
создать поток, чтобы обработать процесс завершения работы. Если завершение
работы требовал клиент, поток завершения работы создается.
Если завершение работы результат получения сигнала SIGTERM ,
поток сигнала мог бы обработать завершение работы непосредственно, или это
могло бы создать отдельный поток. Если сервер пытается создать поток
завершения работы, и не может (например, если память исчерпана), это выдает
диагностическое сообщение, которое появляется в журнале ошибок:
Error: Can't create thread to kill server
- Сервер прекращает принимать новые соединения.
Чтобы препятствовать тому, чтобы новая деятельность была начата во время
завершения работы, сервер прекращает принимать новые соединения клиента,
закрывая обработчики для сетевых интерфейсов, которыми слушает соединения:
порт TCP/IP, файл сокета Unix, именованный канал Windows и
совместно используемую память в Windows.
- Сервер заканчивает текущую деятельность.
Для каждого потока, связанного с соединением клиента, сервер ломает
соединение с клиентом и отмечает поток как уничтоженный. Потоки умирают,
когда замечают, что так отмечены. Потоки для неактивных соединений
закрываются быстро. Потоки, которые в настоящее время обрабатывают запросы,
периодически проверяют свое состояние и занимают больше времени.
Для дополнительной информации о завершении потока см.
раздел 14.7.6.4, в особенности для инструкций об
уничтожении REPAIR TABLE или
OPTIMIZE TABLE
на таблицах MyISAM .
Для потоков, у которых есть открытая транзакция, она отменяется.
Если поток обновляет нетранзакционную таблицу, такая работа, как
многострочный запрос UPDATE или
INSERT может частично обновить
данные, потому что работа может закончиться перед завершением.
Если сервер основной сервер репликации, он обрабатывает потоки, связанные
с в настоящее время соединяемыми ведомыми устройствами как другие потоки
клиента. Таким образом, каждый отмечен как уничтоженный и закроется, когда
затем проверяет свое состояние.
Если сервер это ведомый сервер репликации, он останавливает
потоки ввода/вывода и SQL, если они являются активными, прежде, чем отметить
потоки клиента как уничтоженные. Потоку SQL разрешают закончить его текущий
запрос (чтобы избежать проблем), и затем останавливается. Если поток SQL
находится в середине транзакции, сервер ждет, пока текущая группа событий
(если есть) не закончит выполняться, или до пользовательского запроса
KILL QUERY (или
KILL CONNECTION ). См.
раздел 14.4.2.7. Так как нетранзакционные
запросы не могут быть отменены, чтобы гарантировать безопасную от
катастрофического отказа репликацию, только транзакционные
таблицы должны использоваться.
Чтобы гарантировать безопасность на ведомом устройстве, Вы должны
выполнить ведомое устройство с опцией
--relay-log-recovery .
См. раздел 19.2.4.
- Сервер закрывает механизмы хранения.
На данном этапе сервер сбрасывает табличный кэш и закрывает
все открытые таблицы.
Каждый механизм хранения выполняет любые действия, необходимые для таблиц,
которыми он управляет. InnoDB сбрасывает буферный пул на диск
(если
innodb_fast_shutdown =2), пишет текущий LSN в табличное
пространство и заканчивает свои собственные внутренние потоки.
MyISAM сбрасывает потоки, которые ожидают записи
индекса для таблицы.
- Все, сервер завершился.
Чтобы предоставить информацию управленческим процессам, сервер возвращает
один из кодов завершения, описанных в следующем списке. Фраза в круглых
скобках указывает на меры, предпринятые systemd в ответ на код, для платформ,
на которых systemd используется, чтобы управлять сервером.
6.2. Каталог данных MySQL
Информация, которой управляет сервер MySQL, хранится в соответствии с
якаталогом, известным как каталог данных. Следующий список кратко описывает
элементы, как правило найденные в каталоге данных,
с перекрестными ссылками для дополнительной информации:
Подкаталоги. Каждый подкаталог это каталог базы данных и
соответствует базе данных, которой управляет сервер. У всех установок MySQL
есть базы данных определенного стандарта:
Другие подкаталоги соответствуют базам данных, создаваемым
пользователями или приложениями.
INFORMATION_SCHEMA
стандартная база данных, но ее выполнение не использует соответствующего
каталога базы данных.
Файлы системного журнала, написанные сервером. См.
раздел 6.4.
- Табличное пространство
InnoDB
и файлы системного журнала. См. главу 16.
- Сертификаты SSL и RSA, а также файлы ключей. См.
раздел 7.4.6.
- Файл process ID сервера (в то время, как сервер работает).
Некоторые элементы в предыдущем списке могут быть перемещены в другое
место, реконфигурировав сервер. Кроме того, опция
--datadir
позволяет менять непосредственно местоположение каталога данных. Для
данной установки MySQL проверьте конфигурацию сервера, чтобы определить,
были ли элементы перемещены.
6.3. Системная база данных mysql
Это содержит таблицы, которые хранят информацию, требуемую сервером MySQL.
Широкая классификация состоит в том, что
mysql содержит таблицы словаря данных, которые хранят метаданные
об объекте базы данных, и системные таблицы, используемые в других
операционных целях. Следующее обсуждение далее подразделяет набор системных
таблиц на меньшие категории.
Остаток от этого раздела перечисляет таблицы в каждой категории
с перекрестными ссылками для дополнительной информации.
Таблицы словаря данных и системные таблицы используют механизм хранения
InnoDB , если иначе не обозначено.
Таблицы словаря данных
Эти таблицы включают словарь данных, который содержит метаданные об
объектах базы данных. Для дополнительной информации см.
главу 15.
Словарь данных нов в MySQL 8.0. Данные, включенные в словарь, влекут за
собой некоторые общие операционные различия по сравнению с предыдущими
выпусками MySQL. Для деталей см.
раздел 15.6.
Кроме того, для обновлений до MySQL 8.0 от MySQL 5.7 процедура обновления
несколько отличается от предыдущего MySQL и требует, чтобы Вы проверили
готовность обновления своей установки, проверяя определенные предпосылки. Для
получения дополнительной информации см.
раздел 2.10.1.
Таблицы словаря данных невидимы. Они не могут быть считаны
SELECT ,
не появляются в выводе SHOW TABLES
, не перечислены в INFORMATION_SCHEMA.TABLES и т.д.
Однако, в большинстве случаев есть соответствующие таблицы
INFORMATION_SCHEMA , которые могут быть запрошены. Концептуально
INFORMATION_SCHEMA обеспечивает представление, через которое
MySQL выставляет метаданные о словаре данных. Например, Вы не можете выбрать
из mysql.schemata напрямую:
mysql> SELECT * FROM mysql.schemata;
ERROR 3554 (HY000): Access to data dictionary table
'mysql.schemata' is rejected.
Вместо этого выберите ту информацию из INFORMATION_SCHEMA :
mysql> SELECT * FROM INFORMATION_SCHEMA.SCHEMATA\G
*************************** 1. row ***************************
CATALOG_NAME: def
SCHEMA_NAME: mysql
DEFAULT_CHARACTER_SET_NAME: latin1
DEFAULT_COLLATION_NAME: latin1_swedish_ci
SQL_PATH: NULL
*************************** 2. row ***************************
CATALOG_NAME: def
SCHEMA_NAME: information_schema
DEFAULT_CHARACTER_SET_NAME: utf8
DEFAULT_COLLATION_NAME: utf8_general_ci
SQL_PATH: NULL
...
Это не таблица INFORMATION_SCHEMA , которая соответствует
точно mysql.indexes , но
INFORMATION_SCHEMA.STATISTICS
содержит большую часть той же самой информации.
Пока еще нет таблицы в INFORMATION_SCHEMA , которая
соответствует точно mysql.foreign_keys ,
mysql.foreign_key_column_usage .
Стандартный SQL способ получить информацию о внешнем ключе при использовании
INFORMATION_SCHEMA это таблицы
REFERENTIAL_CONSTRAINTS и
KEY_COLUMN_USAGE
, эти таблицы теперь осуществлены как представления
foreign_keys , foreign_key_column_usage ,
и других таблиц словаря данных.
Некоторые системные таблицы до MySQL 8.0 были заменены таблицами словаря
данных и больше не присутствуют в базе данных mysql :
Системные таблицы привилегий
Эти системные таблицы содержат информацию об учетных записях пользователя
и привилегиях. Для дополнительной информации о структуре содержания и цели
этих таблиц см. раздел 7.2.2.
С MySQL 8.0 это InnoDB (транзакционные) таблицы. Ранее они
были MyISAM (нетранзакционные) таблицы. Изменение механизма
хранения таблиц лежит в основе изменения в MySQL 8.0 поведения запросов
управления учетными записями, например,
CREATE USER и GRANT .
Ранее запрос, который назвал многочисленных пользователей, мог преуспеть для
некоторых пользователей и потерпеть неудачу для других. Запросы являются
теперь транзакционными и преуспевают для всех названных пользователей или
откатываются назад и не имеют никакого эффекта, если ошибка происходит.
Если MySQL обновлен от более старой версии, но таблицы привилегий
не были обновлены с MyISAM на InnoDB ,
сервер считает их только для чтения, и запросы управления
производят ошибку. Для инструкций обновления см.
раздел 2.10.1.
Таблицы информационной системы объекта
Эти системные таблицы содержат информацию о сохраненных программах,
компонентах, определяемых пользователем функциях и серверных плагинах:
Системные таблицы журнала
Сервер использует эти системные таблицы для того, чтобы зарегистрировать:
Таблицы журнала используют механизм хранения CSV .
См. раздел 6.4.
Серверные таблицы системы справочной информации
Эти системные таблицы содержат серверную справочную информацию:
См. раздел 6.1.10.
Системные таблицы часового пояса
Эти системные таблицы содержат информацию о часовом поясе:
См. раздел 11.6.
Таблицы репликации
Сервер использует эти системные таблицы, чтобы поддержать репликацию:
gtid_executed : Таблица для того, чтобы сохранить
значения GTID. См.
mysql.gtid_executed.
ndb_binlog_index : Двоичная информация о журнале для
MySQL Cluster, см.
MySQL Cluster Replication Schema and Tables.
ndb_binlog_index использует механизм хранения
MyISAM . Это создается, только если
сервер создан с NDB .
slave_master_info , slave_relay_log_info ,
slave_worker_info : Используются, чтобы хранить информацию на
ведомых серверах. См. раздел 19.2.4.
Системные таблицы оптимизатора
Эти системные таблицы для оптимизатора:
Разные системные таблицы
Другие системные таблицы не соответствуют предыдущим категориям:
6.4. Журналы сервера MySQL
MySQL Server имеет несколько журналов, которые могут помочь Вам узнать,
какая деятельность имеет место.
Тип журнала |
Что туда пишется |
Журнал ошибок |
Проблемы с запуском, выполнением или остановкой
mysqld |
Общий журнал запроса |
Установленные соединения клиента и запросы от клиентов |
Двоичный журнал |
Запросы об изменении данных (также используется для репликации) |
Журнал реле | Изменения данных, полученные от
главного сервера репликации |
Медленный журнал запроса | Запросы, которые заняли
больше, чем long_query_time
секунд для выполнения |
Журнал DDL (журнал метаданных) |
Операции с метаданными из запросов DDL |
По умолчанию, никакие журналы не включены, кроме журнала ошибок в Windows.
Журнал DDL всегда создается когда надо и не имеет никаких конфигурируемых
пользователем опций, см. раздел 6.4.6.
Следующие определенные для журнала разделы предоставляют информацию о
параметрах сервера, которые позволяют регистрировать события.
По умолчанию сервер пишет файлы для всех включенных журналов в
каталоге данных. Вы можете вынудить сервер закрыть и вновь открыть файлы
системного журнала (или в некоторых случаях переключиться на новый файл
системного журнала), сбрасывая журналы. Сброс журнала происходит, когда Вы
командуете FLUSH LOGS , выполняете
mysqladmin
с параметром flush-logs или refresh или
выполняете mysqldump
с параметром
--flush-logs или
--master-data
. См. разделы 14.7.6.3,
5.5.2 и
5.5.4. Кроме того, двоичный журнал
сбрасывается, когда его размер достигает значения переменной
max_binlog_size
.
Вы можете управлять журналами общих запросов и медленных запросов во время
выполнения. Вы можете включить или отключить журналирование или поменять имя
файла системного журнала. Вы можете сказать серверу писать общий запрос и
медленные запросы в таблицы, файлы системного журнала или оба места. Для
деталей см. разделы 6.4.1,
6.4.3 и
6.4.5.
Журнал реле используется только на ведомых серверах репликации, чтобы
хранить изменения данных от главного сервера, которые должны также быть
сделаны на ведомом устройстве. Для обсуждения содержания журнала реле и
конфигурации см. раздел 19.2.4.1
.
См. раздел 6.4.7.
См. раздел 7.1.2.3.
6.4.1. Выбор мест назначения журналов
общих и медленных запросов
MySQL Server обеспечивает гибкое управление местом назначения вывода
журналов, если те журналы включены. Возможные места назначения для записей
журнала это файлы системного журнала или таблицы general_log и
slow_log в базе данных mysql .
Оба места назначения могут быть выбраны совместно.
Управление журналом при запуске сервера.
Опция --log-output
определяет место назначения для вывода журнала. Эта опция сама по себе
не включает журналы. Ее синтаксис
--log-output[=
value ,...] :
Если
--log-output дана со значением, то это значение должно быть
списком из разделенных запятой одного или больше слов TABLE
(журналировать в таблицу), FILE (журналировать в файл) или
NONE (не журналировать). NONE , если есть,
имеет полный приоритет.
- Если
--log-output
пропущена, место назначения журналирования
по умолчанию FILE .
general_log
управляет журналированием общих запросов для выбранных мест назначения
журнала. Если определено при запуске сервера,
general_log
берет дополнительный параметр 1 или 0, чтобы включить или отключить журнал.
Чтобы определить имя файла кроме значения по умолчанию для журналирования
файла, установите
general_log_file . Точно так же
slow_query_log
управляет журналированием медленных запросов для выбранных мест назначения,
установка
slow_query_log_file определяет имя файла для журналирования.
Если любой журнал включен, сервер открывает соответствующий файл системного
журнала и пишет сообщения в него. Однако, далее журналирование запросов к
файлу не происходит, если место назначения журнала FILE выбрано.
Примеры:
Чтобы написать общие записи журнала запроса в таблицу журнала и
файл системного журнала, надо использовать
--log-output=TABLE,FILE
, чтобы выбрать места назначения журнала, и
--general_log , чтобы
включить общий журнал запроса.
- Чтобы написать общие и медленные записи журнала запроса только в таблицы
журнала, следует использовать
--log-output=TABLE , чтобы выбрать таблицы как место
назначения журнала,
--general_log и
--slow_query_log , чтобы включить оба журнала.
- Чтобы написать медленные записи журнала запроса только в файл системного
журнала, надо использовать
--log-output=FILE , чтобы выбрать файлы как место назначения
журнала и --slow_query_log
, чтобы включить медленный журнал запроса. В этом случае, потому
что место назначения журнала по умолчанию FILE , можно пропустить
опцию --log-output
.
Управление журналом во время выполнения.
Системные переменные, связанные с таблицами журнала и файлами, включают
управление во время выполнения журналирования:
Использование таблиц для журнала дает такие преимущества:
У записей журнала есть стандартный формат. Чтобы вывести на экран
текущую структуру таблиц журнала, используйте эти запросы:
SHOW CREATE TABLE mysql.general_log;
SHOW CREATE TABLE mysql.slow_log;
- Содержание журнала доступно через запросы SQL. Это включает использование
запросов, которые выбирают только те записи журнала, которые удовлетворяют
определенным критериям. Например, чтобы выбрать содержание журнала, связанное
с особым клиентом (что может быть полезным для идентификации проблематичных
запросов от того клиента), легче сделать это с использованием таблицы, чем
файла системного журнала.
- Журналы доступны отдаленно через любого клиента, который может
соединиться с сервером и выпустить запросы (если у клиента есть
соответствующие табличные привилегии). Не надо входить в систему сервера и
непосредственно получать доступ к файловой системе.
У табличного выполнения журнала есть следующие характеристики:
Вообще, основная цель таблиц журнала состоит в том, чтобы
предоставить интерфейс пользователям, чтобы наблюдать выполнение во время
выполнения сервера, а не вмешаться в его выполнение.
CREATE TABLE ,
ALTER TABLE и
DROP TABLE
допустимые операции на таблице журнала. Для
ALTER TABLE и
DROP TABLE
таблица журнала не может использоваться и должна быть отключена,
как описано позже.
- По умолчанию таблицы журнала используют механизм хранения
CSV . Для пользователей, у которых есть доступ к файлам
.CSV , которые содержат табличные данные, файлы легко
импортировать в другие программы, такие как электронные таблицы, которые
могут обработать ввод CSV.
Таблицы журнала могут быть изменены, чтобы использовать
механизм хранения MyISAM . Вы не можете использовать
ALTER TABLE , чтобы
изменить таблицу журнала, которая используется. Журнал должен быть отключен
сначала. Никакие механизмы, кроме CSV или MyISAM ,
не являются законными для таблиц журнала.
- Чтобы отключить журналирование так, чтобы Вы могли изменить таблицу
журнала, Вы можете использовать следующую стратегию. Пример использует общий
журнал запроса, процедура для медленного журнала запроса подобна, но
использует таблицу
slow_log и переменную
slow_query_log .
SET @old_log_state = @@global.general_log;
SET GLOBAL general_log = 'OFF';
ALTER TABLE mysql.general_log ENGINE = MyISAM;
SET GLOBAL general_log = @old_log_state;
TRUNCATE TABLE
допустима на таблице журнала. Это может использоваться, чтобы
истечь записи журнала.
RENAME TABLE
допустима на таблице журнала. Вы можете атомарно переименовать таблицу
журнала (чтобы выполнить ротацию журнала, например) с
использованием следующей стратегии:
USE mysql;
DROP TABLE IF EXISTS general_log2;
CREATE TABLE general_log2 LIKE general_log;
RENAME TABLE general_log TO general_log_backup, general_log2 TO general_log;
CHECK TABLE
допустима на таблице журнала.
LOCK TABLES
не может использоваться на таблице журнала.
INSERT ,
DELETE и
UPDATE
не может использоваться на таблице журнала. Эти операции разрешены только
внутренне непосредственно серверу.
FLUSH TABLES WITH READ LOCK и
системная переменная read_only
не имеют никакого эффекта на таблицы журнала. Сервер может всегда
писать таблицы журнала.
- Записи, написанные в таблицы журнала, не написаны в двоичный журнал и
таким образом не копируются к ведомым серверам.
- Чтобы сбросить таблицы журнала или файлы системного журнала, надо
использовать
FLUSH TABLES или
FLUSH LOGS , соответственно.
- Разделение таблиц журнала не разрешено.
- mysqldump
включает запросы, чтобы обновить те таблицы так, чтобы они не
отсутствовали после перезагрузки файла дампа. Табличное содержание журнала
не выведено в дамп.
6.4.2. Журнал ошибок
Журнал ошибок содержит информацию, указывающую, когда
mysqld
был запущен и остановлен, а также любые критические ошибки, которые
происходят в то время, как сервер работает. Если
mysqld
замечает таблицу, которая должна быть автоматически проверена или
восстановлена, он пишет сообщение в журнал ошибок.
На некоторых операционных системах журнал ошибок содержит трассировку
стека, если mysqld
выходит неправильно. Трассировка может использоваться, чтобы
определить, где mysqld
вылетел, см. раздел 26.5.
Если mysqld_safe
используется, чтобы запустить
mysqld, и
mysqld
вылетает, mysqld_safe
замечает это, перезапускает
mysqld
и пишет сообщение mysqld restarted в журнал ошибок.
В следующем обсуждении консоль значит
stderr , стандартный вывод ошибок, это Ваше окно терминала или
консоль, если стандартный вывод ошибок не был перенаправлен.
В Windows опции
--log-error ,
--pid-file и
--console
затрагивают регистрацию ошибок:
Кроме того, в Windows сервер по умолчанию пишет события и сообщения об
ошибках в Windows Event Log в Application log. Записи, отмеченные как
Error , Warning и Note , написаны в
Event Log, но не к информационным сообщениям, таким как информационные
запросы от отдельных механизмов хранения. У этих записей журнала есть
источник MySQL . Информацией, записанной в Windows Event Log,
можно управлять, используя
log_syslog , как описано позже.
В Unix mysqld
пишет сообщения журнала ошибок следующим образом:
Yum или APT установкам пакета свойственно сконфигурировать местоположение
журнала ошибок под /var/log с параметром вроде
log-error=/var/log/mysqld.log в конфигурационном файле сервера.
Удаление имени файла из этой записи заставляетиспользоваться файл системного
журнала по умолчанию, который написан в каталоге данных.
Если сервер пишет сообщения об ошибках на консоль, он устанавливает
log_error в
stderr . Иначе
log_error указывает на имя файла журнала ошибок. В частности, в
Windows --console
переопределяет файл журнала ошибок и посылает сообщения об ошибках на
консоль, таким образом, сервер устанавливает
log_error в
stderr . Это происходит даже, если также задана
--log-error .
Если Вы определяете
--log-error в файле опций в разделе
[mysqld] , [server] или [mysqld_safe] ,
mysqld_safe
находит и использует опцию.
Использование Syslog для журнала ошибок
Возможно, чтобы mysqld
писал журнал ошибок в syslog в Unix и в Windows
Event Log в Windows. Чтобы сделать так, используйте эти системные переменные:
В Unix перенаравление вывода к syslog также доступно с
использованием mysqld_safe
, который может получить ошибочный вывод сервера и
передать его в syslog .
Использование mysqld_safe
для регистрации ошибок в syslog устарело,
Вы должны использовать системные переменные сервера вместо этого.
mysqld_safe
имеет три опции регистрации ошибок,
--syslog ,
--skip-syslog
и --log-error
. Значение по умолчанию без опций журналирования или с
--skip-syslog
должно использовать файл системного журнала по умолчанию. Чтобы явно
определить использование файла журнала ошибок, надо определить
--log-error=
file_name в
mysqld_safe и
mysqld_safe
предпишет mysqld
писать сообщения в файл системного журнала. Чтобы использовать
syslog вместо этого, определите опцию
--syslog .
Для вывода syslog тег может быть определен с помощью
--syslog-tag=
tag_val , это приложено к идентификатору сервера
mysqld с ведущим дефисом.
Подробность журнала ошибок
log_error_verbosity
управляет многословием сервера для того, чтобы написать ошибку,
предупреждение и сообщение примечания в журнал ошибок. Разрешенные значения
1 (ошибки только), 2 (ошибки и предупреждения), 3 (ошибки, предупреждения и
примечания), со значением по умолчанию 3. Если значение больше 2, сервер
журналирует прерванные соединения и ошибки запрета доступа для новых попыток
соединения. См. раздел B.5.2.10.
Формат сообщения журнала ошибок
log_timestamps
управляет часовым поясом сообщений, написанных в журнал ошибок (так же, как
общему журналу запросов и медленному журналу запросов). Разрешенные значения:
UTC (значение по умолчанию) и SYSTEM (местный
системный часовой пояс).
ID, включенное в сообщения журнала ошибок, является идентификатором
потока в пределах mysqld
, ответственного за запись сообщения. Это указывает, какая часть
сервера произвела сообщение и совместима с общим журналом запроса и медленным
журналом запроса, которые включают ID потока соединения.
Сброс и переименование файла журнала ошибок
Если Вы сбрасываете журналы командами
FLUSH LOGS или
mysqladmin flush-logs
, и mysqld
пишут журнал ошибок в файл (например, если это было
запущено с опцией
--log-error ), сервер закрывает и вновь открывает файл системного
журнала. Чтобы переименовать файл, сделайте это вручную перед сбросом. Сброс
журналов тогда вновь открывает новый файл с оригинальным именем файла.
Например, чтобы переименовать файл и создать новый, используйте следующие
команды (считается, что имя файла системного журнала
host_name .err ):
shell> mv host_name .err host_name .err-old
shell> mysqladmin flush-logs
shell> mv host_name .err-old backup-directory
В Windows используйте rename вместо
mv.
Если сервер не пишет в названный файл, никакое переименование журнала
ошибок не происходит, когда журналы сбрасываются
6.4.3. Общий журнал запроса
Общий журнал запроса это общий отчет того, что делает
mysqld.
Сервер пишет информацию в этот журнал, когда клиенты соединяются или
разъединяются, и это регистрирует каждый запрос SQL, полученный от клиентов.
Общий журнал запроса может быть очень полезным, когда Вы подозреваете ошибку
в клиенте и хотите знать точно, что клиент послал в
mysqld.
Каждая строка, которая показывает, когда клиент соединяется, включает
using connection_type , чтобы указать на
протокол. connection_type одно из
TCP/IP (Соединение TCP/IP, установленное без SSL),
SSL/TLS (TCP/IP с SSL), Socket (Соединение файла
сокета Unix), Named Pipe (Соединение именованного канала в
Windows) или Shared Memory (Соединение совместно
используемой памяти в Windows).
mysqld
пишет запросы в порядке их получения, который мог бы отличаться от порядка, в
котором они выполнены. Этот порядок журналирования отличается от порядка из
двоичного журнала, для которого запросы написаны после того, как они
выполнены, но прежде, чем любые блокировки будут выпущены. Кроме того, журнал
запроса может содержать запросы, которые только выбирают данные в то время,
как такие запросы никогда не пишутся в двоичный журнал.
Используя основанный на запросе двоичный журнал главного сервера
репликации, запросы, полученные его ведомыми устройствами, написаны в журнал
запроса каждого ведомого устройства. Запросы написаны в журнал запроса
главного сервера, если клиент читает события с
mysqlbinlog
и передает их серверу.
Однако, используя основанное на строке двоичное журналирование, обновления
посылают, когда строка изменяется, а не выполняются запросы SQL, и таким
образом эти запросы никогда не пишутся в журнал запроса, когда
binlog_format
ROW . Данное обновление также не может быть написано в журнал
запроса, когда эта переменная установлена в MIXED ,
в зависимости от используемого запроса. См.
раздел 19.2.1.1.
По умолчанию общий журнал отключен. Чтобы определить начальное состояние
общего журнала запроса явно, надо использовать
--general_log[={0|1}]
. Без параметра или с параметром 1,
--general_log
включает журнал. С параметром 0 эта опция отключает журнал. Чтобы определить
имя файла системного журнала, надо использовать
--general_log_file=
file_name . Чтобы определить место назначения
журнала, надо использовать
--log-output (как описано в
разделе 6.4.1).
Если Вы не определяете названия общего файла системного журнала запроса,
имя по умолчанию host_name .log .
Сервер создает файл в каталоге данных, если абсолютный путь не дан, чтобы
определить отличный каталог.
Чтобы отключить или включить общий журнал или изменить название файла
системного журнала во время выполнения, используйте глобальные переменные
general_log и
general_log_file
. Установите general_log
в 0 (или OFF ), чтобы отключить журнал, или в 1 (или
ON ), чтобы включить. Установите
general_log_file
, чтобы определить название файла системного журнала. Если файл
системного журнала уже открыт, он будет закрыт, а новый файл открыт.
Когда общий журнал запроса включен, сервер пишет вывод к любым местам
назначения, определенным
--log-output или
log_output . Если Вы включаете журнал, сервер открывает файл
системного журнала и пишет сообщения запуска ему. Однако, далее
журналирование запросов к файлу не происходит, если выбрано назначение
журнала FILE . Если назначение журнала NONE ,
сервер не пишет запросы, даже если общий журнал включен. Определение имени
файла системного журнала не имеет никакого эффекта на журналирование, если
целевое значение журнала не содержит FILE .
Перезапуски сервера и сброс журнала не заставляют новый общий файл
системного журнала запроса быть произведенным (хотя сброс переоткрывает это).
Чтобы переименовать файл и создать новый, используйте следующие команды:
shell> mv host_name .log host_name -old.log
shell> mysqladmin flush-logs
shell> mv host_name -old.log backup-directory
В Windows используйте rename вместо
mv.
Вы можете также переименовать общий файл системного журнала во время
выполнения, отключая журнал:
SET GLOBAL general_log = 'OFF';
С отключенным журналом, переименуйте файл системного журнала внешне,
например, из командной строки. Тогда включите журнал снова:
SET GLOBAL general_log = 'ON';
Этот метод работает с любой платформой и не требует перезапуска сервера.
Сессионная переменная
sql_log_off может быть установлена в ON или
OFF , чтобы отключить или включить общее журналирование запроса
для текущего соединения.
Пароли в запросах, написанных в общий журнал, переписаны сервером, чтобы
не появляться буквально в простом тексте. Перезапись пароля может быть
подавлена для общего журнала запроса, запуская сервер с опцией
--log-raw .
Эта опция может быть полезной в диагностических целях, чтобы видеть точный
текст запросов как получен сервером, но из соображений безопасности не
рекомендуется для производственного использования. См. также
раздел 7.1.2.3.
Значение перезаписи пароля в том, что запросы, которые не могут быть
разобраны (например, из-за синтаксических ошибок), не написаны в общий журнал
запроса, потому что они содержат пароли. Используйте случаи, которые требуют,
журналирование всех запросов, включая те, которые с ошибками, используя
опцию --log-raw ,
принимая во внимание, что это также обходит перезапись пароля.
Перезапись пароля происходит только, когда пароли простого текста
ожидаются. Для запросов с синтаксисом, которые ожидают значение хеша пароля,
не происходит никакая перезапись. Если пароль простого текста поставляется
ошибочно для такого синтаксиса, пароль зарегистрирован как дан, без
перезаписи. Например, следующий запрос зарегистрирован как показано, потому
что значение хеша пароля ожидается:
CREATE USER 'user1'@'localhost' IDENTIFIED BY PASSWORD 'not-so-secret';
Переменная log_timestamps
управляет часовым поясом сообщений, написанных в общий файл
системного журнала запроса (так же как в медленный файл и журнал ошибок).
Это не затрагивает часовой пояс сообщений общего и медленного журналов
запроса, написанные в таблицы, но строки, полученные от тех таблиц, могут
быть преобразованы от местного системного часового пояса до любого желаемого
часового пояса с помощью
CONVERT_TZ() или устанавливая сеансовую переменную
time_zone .
6.4.4. Двоичный журнал
Двоичный журнал содержит события, которые
описывают изменения базы данных, такие как табличные операции создания или
изменения табличных данных. Это также содержит события для запросов, которые
потенциально, возможно, произвели изменения (например,
DELETE , который не соответствовал
строкам), если основанное на строке журналирование не используется.
Двоичный журнал также содержит информацию о том, сколько времени каждый
запрос обновлял данные. У двоичного журнала есть две важных цели:
Для репликации основной сервер обеспечивает отчет о данных, чтобы
послать ведомым серверам. Главный сервер посылает события, содержавшиеся в
его двоичном журнале к его ведомым устройствам, которые запускают те события,
чтобы произвести те же самые изменения данных, которые были сделаны на
ведущем устройстве. См.
раздел 19.2.
- Определенные операции восстановления данных требуют использования
двоичного журнала. После того, как резервная копия была восстановлена,
события в двоичном журнале, которые были зарегистрированы после того, как
резервное копирование было сделано, повторно выполнены. Эти события
осовременивают базы данных от точки резервного копирования. См.
раздел 8.5.
Двоичный журнал не используется для таких запросов, как
SELECT или
SHOW , которые не меняют данные.
Чтобы регистрировать все запросы (например, чтобы идентифицировать проблемный
запрос), используют общий журнал запроса. См.
раздел 6.4.3.
Выполнение сервера с включенным двоичным журналированием
делает работу немного медленнее. Однако, этот журнал позволяет Вам настроить
репликацию и его рпименение для операций восстановления вообще перевешивает
это незначительное снижение работоспособности.
Двоичный журнал безопасен от катастрофического отказа. Только полные
события или транзакции зарегистрированы.
Пароли в запросах, написанных в двоичный журнал, переписаны сервером,
чтобы не светиться буквально в простом тексте. См. также
раздел 7.1.2.3.
Следующее обсуждение описывает некоторые из параметров сервера и
переменных, которые затрагивают работу двоичного журналирования. Для полного
списка см. раздел
19.1.6.4.
Чтобы включить двоичный журнал, запустите сервер с опцией
--log-bin[=
base_name ] . Если не задать
base_name , имя по умолчанию это значение опции
pid-file (которле по умолчанию является названием машины узла),
сопровождаемое -bin . Если базовое имя дано, сервер пишет файл в
каталоге данных, если базовое имя не дано с ведущим абсолютным путем, чтобы
определить отличный каталог. Рекомендуется, чтобы Вы определили базовое имя
явно вместо того, чтобы использовать значение по умолчанию, см.
раздел B.5.7.
Если Вы поставляете расширение на имя журнала (например,
--log-bin=
base_name.extension ),
расширение тихо удалено и проигнорировано.
mysqld
прилагает числовое расширение к двоичному базовому имени журнала, чтобы
произвести двоичные имена файла системного журнала. Число увеличивается
каждый раз, когда сервер создает новый файл системного журнала, таким образом
создавая упорядоченную серию файлов. Сервер создает новый файл в ряду каждый
раз, когда это запускает или сбрасывает журналы. Сервер также создает новый
двоичный файл системного журнала автоматически после того, как размер
текущего журнала достигает
max_binlog_size
. Двоичный файл системного журнала может стать больше чем
max_binlog_size
, если Вы используете большие транзакции, потому что транзакция написана
в файл целиком, никогда не разделяясь между файлами.
Чтобы отслеживать, которые из двоичных файлов журнала использовались,
mysqld
также создает двоичный индексный файл журнала, который содержит названия всех
используемых двоичных файлов системного журнала. По умолчанию у этого есть то
же самое базовое имя, как у двоичного файла системного журнала, с расширением
'.index' . Вы можете поменять имя двоичного индексного файла
журнала с помощью опции
--log-bin-index[=file_name ] .
Вы не должны вручную редактировать этот файл в то время, как работает
mysqld.
Клиент, который имеет привилегию
SUPER , может отключить двоичное журналирование своих собственных
запросов при использовании SET sql_log_bin=0 , см.
раздел 6.1.5.
По умолчанию сервер регистрирует продолжительность события так же, как
событие непосредственно и использует это, чтобы проверить, что все было
написано правильно. Вы можете также заставить сервер писать контрольные суммы
для событий, устанавливая
binlog_checksum . Читая назад из двоичного журнала, ведущее
устройство использует длину событий по умолчанию, но может быть заставлено
использовать контрольные суммы при наличии, включая
master_verify_checksum . Ведомый поток ввода/вывода также проверяет
события, полученные от ведущего устройства. Вы можете заставить ведомый поток
SQL использовать контрольные суммы при наличии, читая из журнала реле,
включая
slave_sql_verify_checksum .
Формат событий, зарегистрированных в двоичном журнале, зависит от
двоичного формата журналирования. Три типа формата поддержаны: основанное на
строке, основанное на запросе и смешанное журналирование. Используемый формат
журналирования зависит от версии MySQL. Для общих описаний форматов
журналирования см. раздел 6.4.4.1
и MySQL Internals: The Binary Log.
Сервер оценивает
--binlog-do-db и
--binlog-ignore-db
таким же образом, как опции
--replicate-do-db
и
--replicate-ignore-db . См.
раздел 19.2.5.1.
Ведомый сервер по умолчанию не пишет в собственный двоичный журнал
модификаций данных, которые получены от ведущего устройства. Чтобы
регистрировать эти модификации, запустите ведомое устройство с опцией
--log-slave-updates в дополнение к
--log-bin
(см. раздел 19.1.6.3).
Это сделано, когда ведомое устройство должно также действовать как ведущее
устройство к другим ведомым устройствам в цепной репликации.
Вы можете удалить все двоичные файлы системного журнала с
RESET MASTER или их
подмножество с PURGE BINARY LOGS
. См. разделы 14.7.6.6 и
14.4.1.1.
Если Вы используете репликацию, Вы не должны удалить старые двоичные файлы
системного журнала на ведущем устройстве, пока Вы не уверены, что никакое
ведомое устройство все еще не должно использовать их. Например, если Ваши
ведомые устройства никогда не выполняются с отставанием больше, чем на три
дня, один раз в день Вы можете выполнить
mysqladmin flush-logs
на ведущем устройстве, а затем удалить любые журналы, которые старше трех
дней. Вы можете удалить файлы вручную, но предпочтительно использовать
PURGE BINARY LOGS ,
который также безопасно обновляет двоичной индексный файл журнала для Вас (и
который может взять параметр даты). См.
раздел 14.4.1.1.
Вы можете вывести на экран содержание двоичных файлов системного журнала с
помощью mysqlbinlog
. Это может быть полезно, когда Вы хотите подвергнуть переработке
запросы в журнале для работы восстановления. Например, Вы можете обновить
сервер MySQL от двоичного журнала следующим образом:
shell> mysqlbinlog log_file | mysql -h server_name
mysqlbinlog
также может использоваться, чтобы вывести на экран содержание
ведомого файла системного журнала реле репликации, потому что они написаны,
используя тот же самый формат в качестве двоичных файлов системного журнала.
Для получения дополнительной информации о
mysqlbinlog
см. раздел 5.6.8. Для получения
дополнительной информации о двоичном журнале и операциях восстановления см.
раздел 8.5.
Двоичное журналирование сделано немедленно после завершения запроса или
транзакции, но прежде, чем любые блокировки будут выпущены.
Это гарантирует, что журнал зарегистрировал события в нужном порядке.
Обновления нетранзакционных таблиц немедленно сохранены в двоичном
журнале после выполнения.
В пределах нейтральной транзакции, все обновления
(UPDATE ,
DELETE или
INSERT ), которые
меняют транзакционные таблицы, такие как InnoDB , кэшируются до
COMMIT . В этом пункте
mysqld
пишет всю транзакцию двоичному журналу перед выполнением
COMMIT .
Модификации нетранзакционных таблиц не могут быть отменены. Если
транзакция, которая отменена, включает модификации нетранзакционных таблиц,
вся транзакция зарегистрирована с ROLLBACK
в конце, чтобы гарантировать, что модификации
тех таблиц копируются.
Когда поток, который обрабатывает транзакцию, запускается, это выделяет
буфер binlog_cache_size
, чтобы буферизовать запросы. Если запрос больше, чем это, поток
открывает временный файл, чтобы сохранить транзакцию. Временный файл удален,
когда поток заканчивается.
Binlog_cache_use
показывает число транзакций, которые использовали этот буфер (и
возможно временный файл) для того, чтобы сохранить запросы.
Binlog_cache_disk_use показывает, сколько из тех транзакций
фактически должно было использовать временный файл. Эти две переменные могут
использоваться для того, чтобы настроить
binlog_cache_size
к достаточно большому значению, которое избегает
использования временных файлов.
max_binlog_cache_size (значение по умолчанию 4GB, которое является
также максимумом) может использоваться, чтобы ограничить полный размер,
используемый, чтобы кэшировать транзакцию из многих запросов. Если транзакция
больше, чем это число байтов, она терпит
неудачу и откатывается. Минимальное значение 4096.
Если Вы используете двоичный журнал и основанное на строке журналирование,
параллельные вставки преобразованы в нормальные вставки для CREATE ...
SELECT или INSERT ...
SELECT . Это сделано, чтобы гарантировать, что Вы можете обновить
точную копию своих таблиц, применяя журнал. Если Вы используете основанное на
запросе журналирование, оригинальный запрос написан в журнал.
У двоичного формата журнала есть некоторые известные ограничения, которые
могут затронуть восстановление после резервных копий. См.
See раздел 19.4.1.
Двоичное журналирование для сохраненных программ сделано как описано в
разделе 21.7.
Отметьте, что двоичной формат журнала отличается в MySQL 8.0 от предыдущих
версий MySQL, из-за улучшений в репликации, см.
раздел 19.4.2.
Запись в двоичный файл системного журнала и индексный файл журнала
обработаны таким же образом, как запись таблиц MyISAM , см.
раздел B.5.3.4.
По умолчанию двоичный журнал синхронизирован с диском в каждой записи
(sync_binlog=1 ).
Если sync_binlog
не был включена, и операционная система или машина (не только сервер MySQL)
разрушены, есть шанс, что последние запросы двоичного журнала могли быть
потеряны. Чтобы предотвратить это, включите
sync_binlog , чтобы
синхронизировать двоичный журнал с диском после каждых
N групп передач. См.
раздел 6.1.5. Самое
безопасное значение для
sync_binlog 1 (по умолчанию), но это является
также самым медленным.
В более ранних выпусках MySQL был шанс несогласованности между табличным
контентом и двоичным контентом журнала, если катастрофический отказ
произошел, даже с sync_binlog
= 1. Например, если Вы используете таблицы InnoDB и
сервер MySQL обрабатывает COMMIT ,
это пишет много готовых транзакций в журнал последовательно, синхронизирует
двоичный журнал, а затем передает транзакцию в InnoDB .
Если бы сервер разрушился между теми двумя операциями, транзакция была бы
отменена InnoDB при перезапуске, но все еще существовала бы в
двоичном журнале. Такой вопрос был решен в предыдущих выпусках, включая
в InnoDB поддержку двухфазовой передачи в транзакциях XA.
В 5.8.0 и выше InnoDB эта поддержка всегда включается.
InnoDB поддерживая двухфазовую передачу
в транзакциях XA, гарантирует что двоичный журнал и файлы с данными
InnoDB синхронизированы. Однако, сервер MySQL должен также быть
сконфигурирован, чтобы синхронизировать двоичный журнал и журналы
InnoDB на диске прежде, чем передать транзакцию.
InnoDB журналы синхронизированы по умолчанию, и
sync_binlog=1 гарантирует, что двоичный журнал синхронизирован.
Это гарантирует, что двоичный журнал отражает точные данные таблицы
InnoDB , а поэтому ведомое устройство остается в синхронизации с
ведущим устройством, потому что это не получает запрос, который был отменен.
Если сервер MySQL обнаруживает при восстановлении катастрофического
отказа, что двоичный журнал короче, чем это должно было быть, это испытывает
недостаток в по крайней мере одной успешно переданной транзакции
InnoDB . Это не должно произойти, если
sync_binlog=1 и диск/файловая система делает фактическую
синхронизацию, когда надо (некоторые не делают), таким образом, сервер
печатает сообщение об ошибке The binary log file_name
is shorter than its expected size .
В этом случае двоичный журнал неправилен, и репликация должна быть
перезапущена от нового снимка данных ведущего устройства.
Значения сеанса следующих системных переменных написаны в двоичный
журнал соблюдаются ведомым устройством, разбирая двоичный журнал:
6.4.4.1. Двоичные форматы журналирования
Сервер использует несколько форматов журналирования, чтобы сделать запись
информации в двоичном журнале:
Формат журналирования может также быть установлен или ограничен
используемым механизмом хранения. Это помогает устранить проблемы, копируя
определенные запросы между ведущим устройством и ведомым устройством, которые
используют различные механизмы хранения.
С основанным на запросе журналированием могут быть проблемы с
мультиплицированием недетерминированных запросов. В решении, безопасен ли
данный запрос для основанного на запросе варианта, MySQL определяет, может ли
это гарантировать, что запрос может копироваться, используя основанное на
запросе журналирование. Если MySQL не может дать эту гарантию, он отмечает
запрос как потенциально ненадежный и выпускает предупреждение,
Statement may not be safe to log in statement format.
Вы можете избежать этих проблем при использовании основанной на строке
репликации MySQL вместо этого.
6.4.4.2.
Установка двоичного формата журнала
Вы можете выбрать двоичной формат журналирования явно, запуская сервер
MySQL с опцией
--binlog-format=type .
Поддержанные значения для type :
Формат журналирования также может быть переключен во время выполнения.
Чтобы определить формат глобально для всех клиентов, установите глобальное
значение binlog_format
:
mysql> SET GLOBAL binlog_format = 'STATEMENT';
mysql> SET GLOBAL binlog_format = 'ROW';
mysql> SET GLOBAL binlog_format = 'MIXED';
Отдельный клиент может управлять форматом журналирования для его
собственных запросов, устанавливая значение сеансовой переменной
binlog_format :
mysql> SET SESSION binlog_format = 'STATEMENT';
mysql> SET SESSION binlog_format = 'ROW';
mysql> SET SESSION binlog_format = 'MIXED';
Каждый сервер MySQL может установить свой собственный и только свой
собственный двоичной формат журналирования (неважно, задана ли
binlog_format
с глобальным или сеансовым контекстом). Это означает, что изменение формата
журналирования на ведущем устройстве не заставляет ведомое устройство
изменять свой формат журналирования, чтобы соответствовать. Использование
binlog_format
не копируется, используя MIXED или ROW ,
это копируется, но проигнорировано ведомым устройством. Изменение двоичного
журналирования на ведущем устройстве в то время, как репликация продолжается,
или также не изменяя это на ведомом устройстве, можно заставить репликацию
терпеть неудачу с ошибками, такими как Error executing row event:
'Cannot execute statement: impossible to write to binary log since
statement is in row format and BINLOG_FORMAT = STATEMENT.'.
Чтобы изменить глобальное или сеансовое значение
binlog_format ,
значение, Вы должны иметь привилегию
SUPER .
Есть несколько причин, почему клиент мог бы хотеть установить
журналирование для сеанса:
Есть исключения, когда Вы не можете переключить формат во время выполнения:
Попытка переключить формат в любом из этих случаев приводит к ошибке.
Если Вы используете InnoDB и
операционный уровень изоляции
READ COMMITTED или
READ
UNCOMMITTED , только основанное на строке журналирование может
использоваться. Можно изменить формат журналирования на
STATEMENT , но выполнение этого во время выполнения приводит
очень быстро к ошибкам потому, что InnoDB больше
не может вставлять.
Переключение формата во время выполнения не рекомендуется, когда любые
временные таблицы существуют, потому что временные таблицы зарегистрированы
только, используя основанный на запросе формат, тогда как с основанным на
строке форматом они не зарегистрированы. Со смешанным форматом обычно
регистрируются временные таблицы, исключения происходят с определяемыми
пользователем функциями (UDF) и с функцией
UUID() .
С двоичным журналом в формате ROW много изменений написаны
в двоичный журнал, используя основанный на строке формат. Некоторые
изменения, однако, все еще используют основанный на запросе формат. Примеры
включают весь DDL (язык определения данных), например,
CREATE TABLE ,
ALTER TABLE или
DROP TABLE .
Опция
--binlog-row-event-max-size доступна для серверов, которые
способны к основанному на строке формату. Строки сохранены в двоичный
журнал кусками, имеющими размер в байтах, не превышающими значение этой
опции. Значение должно быть кратным числом 256. Значение по умолчанию 8192.
Используя основанное на запросе журналирование для
репликации, для данных по ведущему и ведомому устройствам возможно стать
отличающимся, если запрос разработан таким способом, которым модификация
данных недетерминирована,
то есть, оптимизатор запросов может внести изменения. Вообще, это не хорошая
практика даже за пределами репликации. Для подробного объяснения этой
проблемы см. раздел B.5.7.
См. раздел 19.2.4.
6.4.4.3.
Смешанный двоичной формат журналирования
Работая в формате MIXED , сервер автоматически переключается
с основанного на запросе на основанное на строке журналирование
при следующих условиях:
Когда функция содержит
UUID() .
- Когда одна или более таблиц с
AUTO_INCREMENT
обновлены и вызван триггер или сохраненная функция. Как все другие опасные
запросы, это производит предупреждение, если
binlog_format = STATEMENT
.
См. раздел
19.4.1.1.
- Когда тело представления требует основанного на строке ответа, запрос,
создающий представление, также использует это. Например, это происходит,
когда запрос, создающий представление, использует функцию
UUID() .
- Когда вызывается UDF.
- Если запрос зарегистрирован строкой и сеансом, который выполнял запрос,
имеет любые временные таблицы, регистрация строкой используется для всех
последующих запросов (за исключением тех, которые получают доступ к временным
таблицам), пока все временные таблицы, используемые тем сеансом не удалены.
Это истина безотносительно того, зарегистрированы ли какие-либо
временные таблицы фактически.
Временные таблицы не могут быть зарегистрированы, используя основанный на
строке формат, таким образом, как только основанное на строке журналирование
используется, все последующие запросы, использующие эту таблицу опасны.
Сервер учитывает это условие, обрабатывая все запросы, выполненные во время
сеанса как опасные, пока сеанс больше не использует временные таблиц.
- Когда используются функции
FOUND_ROWS() или
ROW_COUNT() (Bug #12092, Bug #30244).
- Когда используются функции
USER()
, CURRENT_USER()
или CURRENT_USER
(Bug #28086).
- Когда запрос относится к одной или более системным переменным (Bug
#31168).
Исключение. Следующие системные переменные, когда используются с
контекстом сеанса (только), не заставляют формат журналирования переключаться:
Для информации об определении системного контекста переменной см.
раздел 6.1.6.
Для информации о том, как репликация обрабатывает
sql_mode см.
раздел 19.4.1.38.
- Когда одна из вовлеченных таблиц является таблицей журнала в
базе данных
mysql .
- Когда используется функция
LOAD_FILE() (Bug #39701).
Предупреждение произведено, если Вы пытаетесь выполнить запрос, используя
основанное на запросе журналирование, которое должно быть написано, используя
основанное на строке журналирование. Предупреждение показывает в клиенте (в
выводе SHOW WARNINGS ) и
через журнал ошибок mysqld
. Предупреждение добавлено к таблице
SHOW WARNINGS
каждый раз, когда такой запрос выполнен. Однако, только первый запрос,
который произвел предупреждение для каждого сеанса клиента, написан в журнал
ошибок, чтобы предотвратить наводнение журнала.
В дополнение к решениям выше, отдельные механизмы могут также определить
формат журналирования, используемый, когда информация в таблице обновлена.
Способности журналирования отдельного механизма могут быть
определены следующим образом:
Если механизм поддерживает основанное на строке журналирование,
механизм, как говорят, является
способным к журналированию строки.
- Если механизм поддерживает основанное на
запросе журналирование, механизм, как говорят, является
способным к журналированию запроса.
Данный механизм хранения может поддержать оба формата журналирования.
Следующая таблица приводит форматы, поддержанные каждым механизмом.
Механизм хранения |
Поддержанное журналирование строки |
Поддержанное журналирование запроса |
ARCHIVE | Да |
Да |
BLACKHOLE | Да | Да |
CSV | Да | Да |
EXAMPLE | Да | Нет |
FEDERATED | Да | Да |
HEAP | Да | Да |
InnoDB | Да |
Да, когда операционный уровень изоляции
REPEATABLE READ
или SERIALIZABLE
, иначе нет. |
MyISAM | Да | Да |
MERGE | Да | Да |
NDB | Да | Нет |
Должен ли запрос быть зарегистрирован, и режим журналирования, который
будет использоваться, определен согласно типу запроса (безопасный, опасный),
двоичному формату журналирования (STATEMENT , ROW
или MIXED ) и способности журналирования механизма хранения.
Запросы могут быть зарегистрированы с или без предупреждения,
неудавшиеся запросы не зарегистрированы, но производят ошибки в журнале. Это
показывают в следующей таблице решения, где
SLC означает
журналирование запроса, а
RLC означает
журналирование строки.
Выражение |
Действие |
Тип |
binlog_format |
SLC | RLC |
Ошибка\предупреждение |
Зарегистрированный как |
* | * | Нет |
Нет | Error: Cannot execute statement:
двоичное журналирование невозможно, так как по крайней мере один механизм
вовлечен, который не способен к строке и запросу. |
- |
Safe | STATEMENT | Да |
Нет | - | STATEMENT |
Safe | MIXED | Да |
Нет | - | STATEMENT |
Safe | ROW | Да | Нет |
Error: Cannot execute statement: двоичное журналирование
невозможно, так как BINLOG_FORMAT = ROW и по крайней мере одна
таблица использует механизм хранения, который не способен к основанному
на строке журналированию. | - |
Unsafe | STATEMENT | Да |
Нет | Warning: Unsafe statement binlogged in statement
format, поскольку BINLOG_FORMAT = STATEMENT |
STATEMENT |
Unsafe | MIXED | Да |
Нет | Error: Cannot execute statement:
двоичное журналирование опасного запроса невозможно, когда механизм хранения
ограничен основанным на запросе журналированием, даже если
BINLOG_FORMAT = MIXED . | - |
Unsafe | ROW | Да |
Нет | Error: Cannot execute statement:
двоичное журналирование невозможно, так как BINLOG_FORMAT = ROW
и по крайней мере одна таблица использует механизм хранения, который не
способен к основанному на строке журналированию. | - |
Row Injection | STATEMENT |
Да | Нет | Error: Cannot execute row injection:
двоичное журналирование невозможно, так как по крайней мере одна таблица
использует механизм хранения, который не способен к основанному
на строке журналированию. | - |
Row Injection | MIXED | Да |
Нет | Error: Cannot execute row injection:
двоичное журналирование невозможно, так как по крайней мере одна таблица
использует механизм хранения, который не способен к основанному
на строке журналированию. | - |
Row Injection | ROW | Да |
Нет | Error: Cannot execute row injection:
двоичное журналирование невозможно, так как по крайней мере одна таблица
использует механизм хранения, который не способен к основанному
на строке журналированию. | - |
Safe | STATEMENT | Нет |
Да | Error: Cannot execute statement:
двоичное журналирование невозможно с тех пор, как
BINLOG_FORMAT = STATEMENT и по крайней мере одна таблица
использует механизм хранения, который не способен к основанному
на запросе журналированию. | - |
Safe | MIXED | Нет |
Да | - | ROW |
Safe | ROW | Нет | Да |
- | ROW |
Unsafe | STATEMENT | Нет |
Да | Error: Cannot execute statement:
двоичное журналирование невозможно с тех пор, как
BINLOG_FORMAT = STATEMENT и по крайней мере одна таблица
использует механизм хранения, который не способен к основанному
на запросе журналированию. | - |
Unsafe | MIXED | Нет |
Да | - | ROW |
Unsafe | ROW | Нет |
Да | - | ROW |
Row Injection | STATEMENT |
Нет | Да | Error: Cannot execute row injection:
двоичное журналирование невозможно с тех пор, как
BINLOG_FORMAT = STATEMENT . | - |
Row Injection | MIXED | Нет |
Да | - | ROW |
Row Injection | ROW | Нет |
Да | - | ROW |
Safe | STATEMENT | Да |
Да | - | STATEMENT |
Safe | MIXED | Да |
Да | - | STATEMENT |
Safe | ROW | Да | Да |
- | ROW |
Unsafe | STATEMENT | Да |
Да | Warning: Unsafe statement binlogged in statement
format поскольку BINLOG_FORMAT = STATEMENT . |
STATEMENT |
Unsafe | MIXED | Да |
Да | - | ROW |
Unsafe | ROW | Да |
Да | - | ROW |
Row Injection | STATEMENT |
Да | Да | Error: Cannot execute row injection:
двоичное журналирование невозможно потому, что
BINLOG_FORMAT = STATEMENT . | - |
Row Injection | MIXED | Да |
Да | - | ROW |
Row Injection | ROW | Да |
Да | - | ROW |
Когда предупреждение произведено определением,
стандартное предупреждение MySQL произведено (и доступно через
SHOW WARNINGS ). Информация
также написана в журнал ошибок
mysqld. Только одна ошибка для каждого ошибочного случая
за соединение клиента зарегистрирована, чтобы предотвратить наводнение
журнала. Сообщение журнала включает запрос SQL, который был предпринят.
Если ведомый сервер был запущен с
log_error_verbosity
, чтобы вывести на экран предупреждения, ведомое устройство
печатает сообщения в журнал ошибок, чтобы предоставить информацию о таком
состоянии, как двоичный журнал и координаты журнала реле, где это запускает
свое задание, когда это переключается на другой журнал реле, когда это
повторно соединяется после разъединения, запросы, которые опасны для
основанного на запросе журналирования и т.д.
6.4.4.4.
Формат журналирования для изменений таблиц базы данных mysql
Содержание таблиц привилегий в базе данных mysql может быть
изменено непосредственно (например, через
INSERT или
DELETE ) или косвенно (например,
через GRANT или
CREATE USER ).
Запросы, вовлекающие таблицы базы данных mysql , написаны
в двоичный журнал, используя следующие правила:
Запросы манипуляции данных, которые меняют данные в
базе данных mysql непосредственно зарегистрированы согласно
установке binlog_format
. Это принадлежит таким запросам, как
INSERT ,
UPDATE ,
DELETE ,
REPLACE ,
DO ,
LOAD DATA INFILE ,
SELECT и
TRUNCATE TABLE .
- Запросы, которые изменяют базу данных
mysql косвенно,
зарегистрированы как запросы, независимо от значения
binlog_format .
Это принадлежит таким запросам, как
GRANT ,
REVOKE ,
SET PASSWORD ,
RENAME USER ,
CREATE (все формы, кроме
CREATE TABLE ... SELECT ),
ALTER (все формы) и DROP (все формы).
CREATE TABLE ... SELECT
комбинация манипуляции данными и определения данных.
Часть CREATE TABLE
зарегистрирована, используя формат запроса, а часть
SELECT зарегистрирована,
согласно значению
binlog_format .
6.4.5. Медленный журнал запроса
Медленный журнал запроса состоит из запросов SQL, которые взяли больше,
чем long_query_time
секунд, чтобы выполнить и требуют, по крайней мере,
min_examined_row_limit строк, которые будут исследованы.
Минимальные и значения по умолчанию
long_query_time
это 0 и 10, соответственно. Значение может быть определено до микросекунд.
Для того, чтобы зарегистрировать в файле, времена написаны, включая часть
микросекунд. Для того, чтобы зарегистрировать в таблицы, написаны только
времена целого числа, часть микросекунд проигнорирована.
По умолчанию административные запросы не зарегистрированы, так же как
запросы, которые не используют индекс для поисков. Это поведение может быть
изменено, используя
log_slow_admin_statements и
log_queries_not_using_indexes .
Время, чтобы приобрести начальные блокировки не посчитано как время
выполнения. mysqld
пишет запрос в медленный журнал после того, как это было
выполнено и после того, как все блокировки были выпущены, таким образом,
порядок журнала мог бы отличаться от порядка выполнения.
По умолчанию медленный журнал запроса отключен. Чтобы определить
начальное состояние журнала явно, надо использовать
--slow_query_log[={0|1}]
. Без параметра или с параметром 1
--slow_query_log
включает журнал. С параметром 0 эта опция отключает журнал. Чтобы определить
имя файла системного журнала, надо использовать
--slow_query_log_file=
file_name . Чтобы определить место назначения
журнала, надо использовать
--log-output (как описано в
разделе 6.4.1).
Если Вы не определяете название медленного файла системного журнала, имя
по умолчанию host_name -slow.log .
Сервер создает файл в каталоге данных, если абсолютный путь не дан, чтобы
определить отличный каталог.
Чтобы отключить или включить медленный журнал или изменить название файла
системного журнала во время выполнения, используйте глобальные параметры
slow_query_log и
slow_query_log_file
. Установите
slow_query_log в 0 (или OFF ), чтобы выключить, или в
1 (или ON ), чтобы включить. Установите
slow_query_log_file
определить название файла системного журнала. Если файл
системного журнала уже открыт, он будет закрыт, а новый файл открыт.
Когда медленный журнал запроса включен, сервер пишет вывод в
любые места назначения, определенные опцией
--log-output
или переменной log_output
. Если Вы включаете журнал, сервер открывает файл системного журнала и
пишет сообщения запуска в него. Однако, далее журналирование запросов в файл
не происходит, если место назначения FILE выбрано. Если место
назначения NONE , сервер не пишет запросов, даже если медленный
журнал запроса включен. Определение имени файла системного журнала не имеет
никакого эффекта на журналирование, если целевое значение журнала
не содержит FILE .
Сервер пишет меньше информации в медленный журнал запроса, если Вы
используете опцию
--log-short-format .
Чтобы включать медленные административные запросы в запросы, написанные в
медленный журнал запроса, используйте переменную
log_slow_admin_statements . Административные запросы включают
ALTER TABLE ,
ANALYZE TABLE ,
CHECK TABLE ,
CREATE INDEX ,
DROP INDEX ,
OPTIMIZE TABLE и
REPAIR TABLE .
Чтобы включать запросы, которые не используют индекс
для поисков строки в запросах, написанных в медленный журнал запроса,
включите
log_queries_not_using_indexes . Когда такие запросы
зарегистрированы, медленный журнал запроса может вырасти быстро. Возможно
поместить ограничение скорости в эти запросы, устанавливая
log_throttle_queries_not_using_indexes .
По умолчанию эта переменная 0, что означает, что нет никакого предела.
Положительные значения налагают минутный предел на журналировании запросов,
которые не используют индекс. Первый такой запрос открывает 60-секундное
окно, в пределах которого сервер журналирует запросы до данного предела,
затем подавляет дополнительные запросы. Если там подавлены запросы, когда
окно заканчивается, сервер регистрирует резюме, которое указывает, сколько
было и совокупное время, проведенное в них. Следующее 60-секундное окно
начинается, когда сервер регистрирует следующий запрос, который
не использует индекс.
Сервер использует параметры управления в следующем порядке, чтобы
определить, написать ли запрос в медленный журнал запроса:
Запрос не должен быть административным запросом, или
log_slow_admin_statements должен быть включен.
- Запрос должен занять минимум
long_query_time
секунд или
log_queries_not_using_indexes должен быть включен, и запрос не
использует индекс для поисков строки.
- Запрос должен исследовать, по крайней мере,
min_examined_row_limit строк.
- Запрос не должен быть подавлен согласно
log_throttle_queries_not_using_indexes .
log_timestamps
управляет часовым поясом сообщений, написанных в медленный файл системного
журнала запроса (так же, как в общий файл системного журнала запроса и
журнал ошибок). Это не затрагивает часовой пояс сообщений общего и медленного
журналов запроса, написанные в таблицы, но строки, полученные от тех таблиц,
могут быть преобразованы из местного системного часового пояса в любой
желаемый часовой пояс с применением
CONVERT_TZ() или установкой сессионного значения
time_zone .
Все строки журнала содержат timestamp.
Сервер не пишет запросы, обработанные кэшем запроса, в
медленный журнал запроса, как и запросы, которые не извлекли бы выгоду из
присутствия индексирования, потому что у таблицы есть нулевые строки
или одна строка.
яПо умолчанию ведомое устройство не пишет копируемые запросы в медленный
журнал запроса. Чтобы изменить это, используйте
log_slow_slave_statements .
Пароли в запросах, написанных в медленный журнал запроса, переписаны
сервером, чтобы не светиться буквально в простом тексте. См. также
раздел 7.1.2.3.
Медленный журнал запроса может использоваться, чтобы найти запросы,
которые занимают много времени, чтобы выполнить и являются поэтому
кандидатами на оптимизацию. Однако, исследование длинного медленного журнала
запроса может стать трудной задачей. Чтобы сделать это легче, Вы можете
обработать медленный журнал, используя
mysqldumpslow, чтобы суммировать запросы,
которые появляются в журнале. См. раздел
5.6.9.
6.4.6. Журнал DDL
Журнал DDL или журнал метаданных делает запись операций метаданных,
произведенных запросами определения данных, например,
DROP TABLE и
ALTER TABLE . MySQL
использует этот журнал, чтобы оправиться от катастрофических отказов,
происходящих в середине работы с метаданными. Выполняя запрос
DROP TABLE t1, t2 , мы должны гарантировать удаление
t1 и t2 , и что каждое табличное удаление прошло
полностью. Другой пример этого типа запросов SQL:
ALTER
TABLE t3 DROP PARTITION p2 , где мы должны удостовериться, что
разделение полностью удалено и что его определение удалено из списка
разделов для таблицы t3 .
Отчет об операциях с метаданными, таких как только описанные, написан в
файл ddl_log.log в каталоге данных MySQL.
Это двоичный файл, это не предназначено, чтобы быть удобочитаемым, и Вы не
должны пытаться изменить это в любом случае.
ddl_log.log не создается, пока это не фактически необходимо
для того, чтобы сделать запись запросов метаданных, таким образом, для этого
файла возможно не присутствовать на сервере MySQL, который функционирует в
абсолютно нормальной манере.
Нет никаких конфигурируемых пользователем параметров сервера или
переменных, связанных с этим файлом.
6.4.7. Обслуживание журнала сервера
Как сказано в разделе 6.4, MySQL
Server может создать несколько различных файлов системного журнала, чтобы
помочь Вам видеть, какая деятельность имеет место. Однако, Вы должны очистить
эти файлы регулярно, чтобы гарантировать, что журналы не занимают слишком
много дискового пространства.
Используя MySQL с журналированием, Вы можете хотеть зарезервировать и
удалить старые файлы системного журнала время от времени и сказать MySQL
начать регистрировать к новым файлам. См.
раздел 8.2.
В Linux (Red Hat) Вы можете использовать скрипт
mysql-log-rotate . Если Вы устанавливали MySQL из RPM,
этот скрипт должен был быть установлен автоматически. Будьте осторожны с
этим, если Вы используете двоичный журнал для репликации. Вы не должны
удалить двоичные журналы, пока Вы не уверены, что их содержание было
обработано всеми ведомыми устройствами.
На других системах Вы должны установить короткий скрипт
самостоятельно, что Вы запускаете из cron
для того, чтобы обработать файлы системного журнала.
Для двоичного журнала Вы можете установить
expire_logs_days
, чтобы истечь двоичные файлы системного журнала автоматически после
данного числа дней (см. раздел
6.1.5). Если Вы используете репликацию, Вы должны установить переменную
не ниже, чем максимальное количество дней, на которое Ваши ведомые устройства
могли бы отстать от ведущего устройства. Чтобы удалить двоичные журналы по
требованию, используйте PURGE
BINARY LOGS (см. раздел
14.4.1.1).
Вы можете вынудить MySQL начать использовать новые файлы системного
журнала, сбрасывая журналы. Это происходит, когда Вы используете
FLUSH LOGS
или mysqladmin flush-logs
,
mysqladmin refresh
, mysqldump
--flush-logs или
mysqldump --master-data. См. разделы
14.7.6.3, 5.5.2
и 5.5.4. Кроме того, двоичный
журнал сбрасывается, когда его размер достигает значения
max_binlog_size
.
FLUSH LOGS
поддерживает дополнительные модификаторы, чтобы включить сброс
отдельных журналов (например, FLUSH BINARY LOGS
).
Сбрасывающая журнал работа делает следующее:
Сервер создает новый двоичный файл системного журнала, когда Вы
сбрасываете журналы. Однако, это только закрывает и вновь открывает общие и
медленные файлы системного журнала запроса. Чтобы заставить новые файлы
создаваться в Unix, переименуйте текущие файлы системного журнала прежде, чем
сбросить их. Во время сброса сервер открывает новые файлы системного журнала
с настоящими именами. Например, если общие и медленные файлы системного
журнала запроса называют mysql.log и mysql-slow.log
, Вы можете использовать ряд команд:
shell> cd mysql-data-directory
shell> mv mysql.log mysql.old
shell> mv mysql-slow.log mysql-slow.old
shell> mysqladmin flush-logs
В этом пункте Вы можете сделать резервное копирование
mysql.old и mysql-slow.old . Подобная стратегия
может использоваться, чтобы поддержать файл журнала ошибок.
Вы можете переименовать общий журнал запроса
во время выполнения, отключая журнал:
SET GLOBAL general_log = 'OFF';
SET GLOBAL slow_query_log = 'OFF';
С отключенными журналами, переименуйте файлы системного журнала внешне,
например, из командной строки. Тогда включите журналы снова:
SET GLOBAL general_log = 'ON';
SET GLOBAL slow_query_log = 'ON';
Этот метод работает с любой платформой и не требует перезапуска сервера.
6.5. Серверные компоненты
MySQL Server включает основанную на компоненте инфраструктуру для того,
чтобы улучшить расширяемость сервера:
Компонент оказывает услуги, которые доступны серверу и другим
компонентам. Относительно использования службы сервер это компонент, равный
другим компонентам. Компоненты взаимодействуют с друг другом только через
услуги, которые они оказывают.
- Компоненты установлены и удалены с использованием запросов SQL
INSTALL COMPONENT и
UNINSTALL COMPONENT .
- Служба загрузчика обрабатывает установку компонентов, а также перечисляет
установленные компоненты в системной таблице
mysql.component .
Запросы SQL для управления компонентами затрагивают работу сервера и
системной таблицы mysql.component :
INSTALL COMPONENT
ставит компоненты в сервер. Компоненты становятся активными немедленно.
Служба загрузчика также регистрирует установленные компоненты в
таблице mysql.component . Для последующих перезапусков сервера
любые компоненты, перечисленные в mysql.component ,
установлены службой загрузчика во время последовательности запуска. Это
происходит, даже если сервер запущен с опцией
--skip-grant-tables (это отличается от эффекта той опции в
подавлении загрузки системных таблиц mysql.event ,
mysql.func и mysql.proc ).
UNINSTALL COMPONENT
дезактивирует компоненты и удаляет их из сервера. Служба загрузчика
также разрегистрирует компоненты из таблицы mysql.component
так, чтобы они больше не были установлены во время последовательности запуска
для последующих перезапусков сервера.
См.
http://dev.mysql.com/doc/dev/mysql-server/.
6.6. Плагины MySQL Server
MySQL поддерживает API, который включает создание серверных компонентов.
Плагины могут быть загружены при запуске сервера, или загружены и выгружены
во время выполнения, не перезапуская сервер. Компоненты, поддержанные этим
интерфейсом, включают, но не ограничены, механизмы хранения, таблицы
INFORMATION_SCHEMA , полнотекстовые плагины
анализатора и расширения сервера.
6.6.1. Доступные плагины сервера
MySQL включает несколько плагинов, которые
осуществляют расширения сервера:
Следующие разделы описывают, как установить и удалить плагины, как
определить во время выполнения какие плагины установлены и получить
информацию о них. Для информации о создании плагинов см.
раздел 26.2.
6.6.2. Установка и удаление плагинов
Плагины сервера должны быть загружены в сервер прежде, чем они смогут
использоваться. MySQL поддерживает плагин, загружающийся при запуске сервера
и во время выполнения. Также возможно управлять статусом активации
загруженных плагинов при запуске и выгрузить их во время выполнения.
В то время как плагин загружен, информация об этом доступна во время
выполнения через таблицу
INFORMATION_SCHEMA.PLUGINS и запрос
SHOW PLUGINS , см.
раздел 6.6.3.
Установка плагинов
Прежде, чем плагин сервера может использоваться, он должен быть
установлен, используя один из следующих методов. В описаниях
plugin_name означает имя плагина.
Встроенные плагины:
Встроенный плагин известен серверу автоматически. Обычно сервер включает
плагин при запуске. Некоторые встроенные плагины разрешают их менять с опцией
--plugin_name [=activation_state
] .
Плагины зарегистрированные в системной таблице
mysql.plugin :
Таблица mysql.plugin служит регистрацией плагинов (кроме
встроенных плагинов, которые не должны быть зарегистрированы). При запуске
сервер загружает каждый плагин, перечисленный в таблице. Обычно для плагина,
загруженного из mysql.plugin , сервер также включает плагин. Это
может быть изменено с опцией --plugin_name [=
activation_state ] .
Если сервер запущен с опцией
--skip-grant-tables , он не читает таблицу
mysql.plugin и не загружает плагины, перечисленные там.
Плагины с параметрами командной строки:
Плагин, расположенный в файле библиотеки, может быть загружен при запуске
сервера с опциями
--plugin-load ,
--plugin-load-add
или
--early-plugin-load . Обычно для плагина, загруженного при запуске,
сервер также включает плагин. Это может быть изменено с опцией
--plugin_name [=activation_state
] .
Опции --plugin-load
и
--plugin-load-add загружают плагины после встроенных плагинов и
механизмов хранения во время последовательности запуска сервера. Опция
--early-plugin-load используется, чтобы загрузить плагины, которые
должны быть доступными до инициализации встроенных
плагинов и механизмов хранения.
Значение каждой загружающей плагин опции: отделенный точкой с запятой
список из значений name =
plugin_library и plugin_library .
Каждое name это название плагина, чтобы загрузить, а
plugin_library название файла библиотеки, который
содержит код. Если библиотеку называют без какого-либо предыдущего имени,
сервер загружает все плагины в библиотеке. Сервер ищет файлы библиотеки в
каталоге, названном в переменной
plugin_dir .
Загружающие плагин опции не регистрируют плагин в таблице
mysql.plugin . Для последующих перезапусков сервер загружает
плагин снова только, если снова задана опция
--plugin-load
,
--plugin-load-add или
--early-plugin-load . Таким образом, опция производит одноразовую
работу установки, которая сохраняется для единственной загрузки сервера.
--plugin-load
,
--plugin-load-add и
--early-plugin-load позволяют плагинам быть загруженными даже
когда
--skip-grant-tables задана (которая заставляет сервер игнорировать
таблицу mysql.plugin ).
--plugin-load
,
--plugin-load-add и
--early-plugin-load также позволяют загрузить плагины при запуске,
которые не могут быть загружены во время выполнения.
--plugin-load-add
дополняет опцию
--plugin-load :
Например, эти опции:
--plugin-load=x --plugin-load-add=y
эквивалентны этой опции:
--plugin-load="x;y"
Но эти опции:
--plugin-load-add=y --plugin-load=x
эквивалентны этой опции:
--plugin-load=x
Плагины, установленные запросом
INSTALL PLUGIN :
Плагин, расположенный в файле библиотеки, может быть загружен во время
выполнения с INSTALL PLUGIN
. Запрос также регистрирует плагин в таблице mysql.plugin ,
чтобы заставить сервер загружать это при последующих перезапусках. Поэтому
INSTALL PLUGIN требует
привилегии INSERT для
таблицы mysql.plugin .
Базовое имя файла библиотеки зависит от Вашей платформы. Общие суффиксы
.so для Unix и .dll для Windows.
Пример: опция
--plugin-load устанавливает плагин при запуске сервера. Чтобы
установить плагин myplugin из файла библиотеки
somepluglib.so , используйте эти строки в
файле my.cnf :
[mysqld]
plugin-load=myplugin=somepluglib.so
В этом случае плагин не зарегистрирован в mysql.plugin .
Перезапуск сервера без
--plugin-load не загружает плагин при запуске.
Альтернативно INSTALL PLUGIN
заставляет сервер загружать код плагина из файла библиотеки
во время выполнения:
INSTALL PLUGIN myplugin SONAME 'somepluglib.so';
INSTALL PLUGIN
также регистрирует плагин, перечисляя в таблице mysql.plugin ,
чтобы гарантировать, что сервер загружает это при последующих перезапусках.
Много плагинов могут быть загружены при запуске сервера или во время
выполнения. Однако, если плагин разработан таким образом, что он должен быть
загружен и инициализирован во время запуска сервера, попытка загрузить это
во время выполнения при использовании
INSTALL PLUGIN произведет ошибку:
mysql> INSTALL PLUGIN myplugin SONAME 'somepluglib.so';
ERROR 1721 (HY000): Plugin 'myplugin' is marked as not dynamically
installable. You have to stop the server to install it.
В этом случае Вы должны использовать
--plugin-load
,
--plugin-load-add или
--early-plugin-load .
Если плагин называют в опции
--plugin-load
,
--plugin-load-add или
--early-plugin-load и в таблице mysql.plugin
(как результат INSTALL PLUGIN
), сервер запускается, но пишет эти сообщения в журнал ошибок:
[ERROR] Function 'plugin_name ' already exists
[Warning] Couldn't load plugin named 'plugin_name '
with soname 'plugin_object_file '.
Управление статусом активации плагина
Если сервер знает о плагине, когда он запускается (например, потому что
плагин называют, используя опцию
--plugin-load
или он зарегистрирован в таблице mysql.plugin ), сервер загружает
и включает плагин по умолчанию. Возможно управлять статусом активации для
такого плагина, используя опцию --plugin_name
[=activation_state ] , где
plugin_name название плагина, например,
innodb , csv или validate_password .
Как с другими опциями, тире и подчеркивания являются взаимозаменяемыми в
именах опций. Кроме того, значения статуса активации не являются
чувствительными к регистру. Например, --my_plugin=ON и
--my-plugin=on эквивалентны.
--plugin_name =OFF
Говорит серверу отключить плагин. Это, возможно, невыполнимо для
определенных встроенных плагинов, например,
mysql_native_password .
--plugin_name [=ON]
Говорит серверу включить плагин. Определение опции как
--plugin_name без значения имеет тот
же самый эффект. Если плагин не в состоянии инициализироваться, сервер
выполнен с отключенным плагином.
--plugin_name =FORCE
Говорит серверу включить плагин, но если инициализация терпит неудачу,
сервер не запускается. Другими словами, эта опция вынуждает сервер работать с
включенным плагином или не работать вовсе.
--plugin_name =FORCE_PLUS_PERMANENT
Аналог FORCE , но кроме того препятствует тому, чтобы плагин
был выгружен во время выполнения. Если пользователь пытается сделать так с
UNINSTALL
PLUGIN , происходит ошибка.
Статусы активации видимы в столбце LOAD_OPTION таблицы
INFORMATION_SCHEMA.PLUGINS
.
Предположите, что встроенные подключаемые механизмы хранения
CSV , BLACKHOLE и ARCHIVE ,
и что Вы хотите, чтобы сервер загрузил их при запуске согласно этим условиям:
серверу разрешают работать, если инициализация CSV
терпит неудачу, должен потребовать, чтобы инициализация
BLACKHOLE была успешной, и отключил ARCHIVE .
Чтобы достигнуть этого, используйте эти строки в файле опций:
[mysqld]
csv=ON
blackhole=FORCE
archive=OFF
Опция --enable-plugin_name
синоним для --plugin_name =ON .
Опция --disable-plugin_name и
--skip-plugin_name синонимы для
--plugin_name =OFF .
Если плагин отключен, явно с помощью OFF
или неявно потому что включили ON ,
но инициализация провалилась, аспекты работы сервера, которые требуют плагин,
изменятся. Например, если плагин осуществляет механизм хранения, существующие
таблицы для механизма хранения становятся недоступными, и сервер пытается
составить новые таблицы для механизма хранения в таблицах, которые не
используют механизм хранения значения по умолчанию, если режим SQL
NO_ENGINE_SUBSTITUTION позволяет вызвать ошибку вместо этого.
Отключение плагина может потребовать корректировки других опций. Например,
если Вы запускаете сервер c использованием
--skip-innodb ,
чтобы отключить InnoDB , другие опции
innodb_xxx , вероятно, должны будут быть
опущены при запуске. Кроме того, потому что InnoDB
механизм хранения по умолчанию, это не будет запускаться, если Вы
не определите другой доступный механизм хранения с помощью
--default_storage_engine . Вы должны также установить
--default_tmp_storage_engine .
Удаление плагинов
Во время выполнения запрос
UNINSTALL PLUGIN отключает и удаляет плагин, известный серверу.
Запрос выгружает плагин и удаляет его из таблицы mysql.plugin ,
если это зарегистрировано там. Поэтому
UNINSTALL PLUGIN требует привилегии
DELETE для
mysql.plugin . Сервер не будет загружать плагин автоматически
для последующих перезапусков.
UNINSTALL PLUGIN
может выгрузить плагин независимо от того, было ли это загружено во время
выполнения с INSTALL PLUGIN
или при запуске с загружающей плагин опцией согласно этим условиям:
Чтобы удалить плагин, который в настоящее время загружается при запуске
сервера с загружающей плагин опцией, используйте эту процедуру:
Удалите любые опции, связанные с плагином, из
файла my.cnf .
- Перезапустите сервер.
- Плагины обычно устанавливаются, используя или загружающую плагин опцию
при запуске или с
INSTALL PLUGIN
во время выполнения, но не оба способа. Однако, удаление опций
для плагина из my.cnf , возможно, недостаточно, чтобы удалить
это, если в некоторый момент INSTALL
PLUGIN также использовался. Если плагин все еще появляется в
выводе INFORMATION_SCHEMA.PLUGINS
или SHOW PLUGINS ,
надо использовать UNINSTALL PLUGIN
, чтобы удалить это из таблицы mysql.plugin .
Тогда перезапустите сервер снова.
6.6.3.
Получение информации о плагине сервера
Есть несколько способов определить, какие плагины установлены в сервере:
Таблица
INFORMATION_SCHEMA.PLUGINS содержит строку для каждого
загруженного плагина. Любой, у которого есть значение
PLUGIN_LIBRARY = NULL ,
встроен и не может быть выгружен.
mysql> SELECT * FROM information_schema.PLUGINS\G
*************************** 1. row ***************************
PLUGIN_NAME: binlog
PLUGIN_VERSION: 1.0
PLUGIN_STATUS: ACTIVE
PLUGIN_TYPE: STORAGE ENGINE
PLUGIN_TYPE_VERSION: 50158.0
PLUGIN_LIBRARY: NULL
PLUGIN_LIBRARY_VERSION: NULL
PLUGIN_AUTHOR: MySQL AB
PLUGIN_DESCRIPTION: This is a pseudo storage engine to represent the binlog in a transaction
PLUGIN_LICENSE: GPL
LOAD_OPTION: FORCE
...
*************************** 10. row ***************************
PLUGIN_NAME: InnoDB
PLUGIN_VERSION: 1.0
PLUGIN_STATUS: ACTIVE
PLUGIN_TYPE: STORAGE ENGINE
PLUGIN_TYPE_VERSION: 50158.0
PLUGIN_LIBRARY: ha_innodb_plugin.so
PLUGIN_LIBRARY_VERSION: 1.0
PLUGIN_AUTHOR: Innobase Oy
PLUGIN_DESCRIPTION: Supports transactions, row-level locking,
and foreign keys
PLUGIN_LICENSE: GPL
LOAD_OPTION: ON
...
SHOW PLUGINS
выводит на экран строку для каждого загруженного плагина.
Любой, у которого есть значение Library = NULL ,
встроен и не может быть выгружен.
mysql> SHOW PLUGINS\G
*************************** 1. row ***************************
Name: binlog
Status: ACTIVE
Type: STORAGE ENGINE
Library: NULL
License: GPL
...
*************************** 10. row ***************************
Name: InnoDB
Status: ACTIVE
Type: STORAGE ENGINE
Library: ha_innodb_plugin.so
License: GPL
...
- Таблица
mysql.plugin покажет, какие плагины были
зарегистрированы INSTALL PLUGIN
. Таблица содержит только имена плагинов и файлов библиотек, таким
образом, она не предоставляет такую большую информацию, как таблица
PLUGINS или запрос
SHOW PLUGINS .
6.6.4.
Плагин перезаписи запроса
MySQL Server поддерживает плагины перезаписи запроса, которые могут
исследовать и возможно изменить запросы, полученные сервером прежде, чем
сервер выполнит их.
MySQL включает плагин перезаписи запроса постразбора Rewriter
и скрипты для того, чтобы установить плагин и его связанные компоненты. Эти
компоненты сотрудничают, чтобы обеспечить
SELECT способность перезаписи:
Серверный плагин Rewriter исследует запросы
SELECT
и может переписать их, основанный на его кэш-памяти из правил подстановки.
Автономный SELECT и
SELECT
в готовых запросых подвергаются перезаписи.
SELECT , происходящие в пределах
определений представления или сохраненных программ,
не подвергаются перезаписи.
Rewriter использует базу данных query_rewrite ,
содержащую таблицу rewrite_rules . Таблица обеспечивает
постоянное хранение для правил, чтобы решить, переписать ли запросы.
Пользователи общаются с плагином, изменяя ряд правил, сохраненный в этой
таблице. Плагин общается с пользователями, устанавливая столбец
message строк таблицы.
- База данных
query_rewrite содержит хранимую процедуру
flush_rewrite_rules() , которая загружает содержание
таблицы правил в плагин.
- Определяемая пользователем функция
load_rewrite_rules()
используется хранимой процедурой flush_rewrite_rules() .
- Плагин
Rewriter выставляет системные переменные, которые
включают конфигурацию и переменные состояния, которые предоставляют
операционную информацию во время выполнения.
Следующие разделы описывают, как установить и использовать плагин
Rewriter и предоставляет информацию о ссылке для
своих связанных компонентов.
6.6.4.1.
Установка или удаление плагина перезаписи запроса
Если установлено, Rewriter вовлекает некоторые затраты
даже когда отключен. Чтобы избежать этого, не устанавливайте плагин, если Вы
не планируете использовать его.
Чтобы устанавливать или удалять Rewriter , выбирают скрипт в
каталоге share MySQL:
install_rewriter.sql : Выберите этот скрипт, чтобы
установить плагин Rewriter и его связанные компоненты.
Столбцы pattern_digest и normalized_columns
также создаются. Для деталей о столбцах таблицы см.
раздел 6.6.4.3.1
.
uninstall_rewriter.sql : Выберите этот скрипт, чтобы
удалить плагин Rewriter и его связанные компоненты.
Выполните выбранный скрипт следующим образом:
shell> mysql -u root -p < install_rewriter.sql
Enter password: (enter root password here)
Пример здесь использует install_rewriter.sql .
Сделайте соответствующую замену, если Вы выбираете другой скрипт.
Выполнение скрипта установки должно установить и включить плагин. Чтобы
проверить что, соединитесь с сервером и выполните этот запрос:
mysql> SHOW GLOBAL VARIABLES LIKE 'rewriter_enabled';
+------------------+-------+
| Variable_name | Value |
+------------------+-------+
| rewriter_enabled | ON |
+------------------+-------+
См. разделы
6.6.4.2 и
6.6.4.3.
6.6.4.2.
Применение плагина перезаписи запроса
Чтобы включить или отключить плагин, включите или отключите
rewriter_enabled
. По умолчанию Rewriter включен, когда Вы устанавливаете
его (см.
раздел 6.6.4.1). Чтобы установить статус плагина явно, Вы можете
установить переменную при запуске сервера. Например, чтобы включить плагин в
файле опций, используйте эти строки:
[mysqld]
rewriter_enabled=ON
Также возможно включить или отключить плагин во время выполнения:
mosql> SET GLOBAL rewriter_enabled = ON;
mysql> SET GLOBAL rewriter_enabled = OFF;
Когда плагин включен, он исследует и возможно изменяет каждый запрос
SELECT , полученный сервером. Плагин
определяет, переписать ли запрос, основываясь на правилах, которые загружены
из таблицы rewrite_rules в базе данных query_rewrite
.
Добавление правил подстановки
Чтобы добавить правила для плагина Rewriter , добавляют строки
к таблице rewrite_rules , затем вызывают хранимую процедуру
flush_rewrite_rules() , чтобы загрузить правила из таблицы в
плагин. Следующий пример создает простое правило соответствия запросам,
которые выбирают единственное буквальное значение:
mysql> INSERT INTO query_rewrite.rewrite_rules (pattern, replacement)
-> VALUES('SELECT ?', 'SELECT ? + 1');
Получающееся табличное содержание похоже на это:
mysql> SELECT * FROM query_rewrite.rewrite_rules\G
*************************** 1. row ***************************
id: 1
pattern: SELECT ?
pattern_database: NULL
replacement: SELECT ? + 1
enabled: YES
message: NULL
pattern_digest: NULL
normalized_pattern: NULL
Правило определяет шаблон образца, указывающий, который
SELECT
соответствует, и шаблон замены, указывающий, как переписать соответствие
запросов. Однако, добавлить правило к таблице rewrite_rules
недостаточно, чтобы вызвать его применение в Rewriter .
Вы должны вызвать flush_rewrite_rules() , чтобы
загрузить табличное содержание в плагин в кэш-памяти:
mysql> CALL query_rewrite.flush_rewrite_rules();
Если Ваши правила подстановки, кажется, не работают должным образом,
удостоверьтесь, что Вы перезагрузили таблицу правил, вызывая
flush_rewrite_rules() .
Когда плагин читает каждое правило из таблицы правил, это вычисляет
нормализованную форму (обзор) от образца и значения хеша обзора и обновляет
столбцы normalized_pattern и pattern_digest :
mysql> SELECT * FROM query_rewrite.rewrite_rules\G
*************************** 1. row ***************************
id: 1
pattern: SELECT ?
pattern_database: NULL
replacement: SELECT ? + 1
enabled: YES
message: NULL
pattern_digest: 46b876e64cd5c41009d91c754921f1d4
normalized_pattern: select ?
См. раздел 23.7
.
Образцы используют тот же самый синтаксис, как подготовленные запросы
(см. раздел 14.5.1).
В пределах шаблона образца символы ? действуют как маркеры
параметра, соответствуя значениям данных. Маркеры параметра могут
использоваться только там, где значения данных должны появиться, но не для
ключевых слов SQL, идентификаторов и т.д. Символ ?
не должны быть приложены в пределах кавычек.
Как образец, замена может содержать символы ? .
Для запроса, который соответствует шаблону образца, плагин переписывает это,
заменяя маркеры параметра ? , используя значения данных,
соответствующие маркерам в образце. Результат: полная строка запроса. Плагин
просит, чтобы сервер разобрал это и возвращает результат серверу как
представление переписанного запроса.
После добавления и загрузки правила, проверьте, происходит ли перезапись
согласно тому, соответствуют ли запросы образцу правила:
mysql> SELECT PI();
+----------+
| PI() |
+----------+
| 3.141593 |
+----------+
1 row in set (0.01 sec)
mysql> SELECT 10;
+--------+
| 10 + 1 |
+--------+
| 11 |
+--------+
1 row in set, 1 warning (0.00 sec)
Никакая перезапись не происходит для первого
SELECT ,
но делается для второго. Второй запрос иллюстрирует это, когда плагин
Rewriter переписывает запрос, он производит предупреждающее
сообщение. Чтобы просмотреть сообщение, надо использовать
SHOW WARNINGS :
mysql> SHOW WARNINGS\G
*************************** 1. row ***************************
Level: Note
Code: 1105
Message: Query 'SELECT 10' rewritten to 'SELECT 10 + 1' by
a query rewrite plugin
Чтобы включить или отключить существующее правило, измените столбец
enabled и перезагрузите таблицу в плагин. Отключить правило 1:
mysql> UPDATE query_rewrite.rewrite_rules SET enabled = 'NO' WHERE id = 1;
mysql> CALL query_rewrite.flush_rewrite_rules();
Это позволяет Вам дезактивировать правило, не удаляя его из таблицы.
Повторно включить правило 1:
mysql> UPDATE query_rewrite.rewrite_rules SET enabled = 'YES'
WHERE id = 1;
mysql> CALL query_rewrite.flush_rewrite_rules();
Таблица rewrite_rules содержит столбец
pattern_database , который Rewriter
использует для того, чтобы соответствовать именам таблиц, которые не
квалифицированы с именем базы данных:
Предположите, что таблица appdb.users имеет столбец
id , приложение выберет строки из таблицы, используя запрос одной
из этих форм, где второй может использоваться, только если база данных
по умолчанию appdb :
SELECT * FROM users WHERE appdb.id = id_value ;
SELECT * FROM users WHERE id = id_value ;
Предположите также, что столбец id переименован в
user_id (возможно, таблица должна быть изменена, чтобы добавить
другой тип ID и необходимо указать более определенно, какой ID
задает столбец id ).
Изменение означает, что приложения должны отнестись к
user_id вместо id в WHERE .
Но если есть старые приложения, которые не могут быть переписаны, чтобы
изменить запросы SELECT , которые они производят, они больше не
будут работать должным образом. Плагин Rewriter может решить эту
проблему. Чтобы соответствовать и переписать запросы, добавьте следующие два
правила и перезагрузите таблицу правил:
mysql> INSERT INTO query_rewrite.rewrite_rules
-> (pattern, replacement) VALUES(
-> 'SELECT * FROM appdb.users WHERE id = ?',
-> 'SELECT * FROM appdb.users WHERE user_id = ?');
mysql> INSERT INTO query_rewrite.rewrite_rules
-> (pattern, replacement, pattern_database) VALUES(
-> 'SELECT * FROM users WHERE id = ?',
-> 'SELECT * FROM users WHERE user_id = ?', 'appdb');
mysql> CALL query_rewrite.flush_rewrite_rules();
Rewriter использует первое правило, чтобы соответствовать
запросам, которые используют компетентное имя таблицы. Это использует второе,
чтобы соответствовать запросам, которые использовали неквалифицированное имя,
но только если база данных по умолчанию appdb
(значение в pattern_database ).
Как работает соответствие
Rewriter использует обзоры запросов, чтобы соответствовать
поступающим запросам против правил подстановки шаг за шагом.
max_digest_length определяет размер буфера, используемого для
вычислительных обзоров запроса. Большие значения включают вычисление обзоров,
которые отличают более длинные запросы. Меньшие значения используют меньше
памяти, но увеличивают вероятность более длинных запросов, сталкивающихся с
тем же самым значением обзора.
Плагин соответствует каждый запрос правилам подстановки следующим образом:
Вычисляет хеш обзора запроса, оценивает и сравнивает это
со значениями хеша обзора правила. Это подвергается ложным положительным
срабатываниям, но служит быстрым тестом отклонения.
- Если значение хеша обзора соответствует какому-либо значению хеша обзора
образца, нормализованная форма запроса соответствует нормализованной форме
соответствующих образцов правила.
- Если нормализованный запрос соответствует правилу, сравниваются
буквальные значения в запросе и образце.
? в образце
соответствует любому буквальному значению в запросе. Если запрос готовит
SELECT , ?
в образце также соответствует ? в запросе. Иначе
соответствующие литералы должны быть теми же самыми.
Если многократные правила соответствуют запросу, не определено, которое
использовано, чтобы переписать запрос.
Если образец содержит больше маркеров, чем замена, плагин отказывается от
лишних значений данных. Если образец содержит меньше маркеров, чем замена,
это ошибка. Плагин замечает это, когда таблица правил загружена, пишет
сообщение об ошибке в столбец message
строки правила, чтобы сообщить проблему, и ставит
Rewriter_reload_error в ON .
Перезапись готовых запросов
Готовые запросы переписаны во время разбора (то есть, когда они
подготовлены), а не когда они выполнены позже.
Готовые запросы отличаются от неготовых запросов, в которых они могут
содержать символы ? как маркеры параметра. Чтобы соответствовать
? в готовом запросе, образец Rewriter
должен содержать ? в том же самом местоположении.
Предположите, что у правила подстановки есть этот образец:
SELECT ?, 3
Следующая таблица показывает несколько подготовленных
SELECT
и соответствует ли образец правила им.
Готовый запрос |
Соответствует ли образец запросу |
PREPARE s AS 'SELECT 3, 3' |
Да |
PREPARE s AS 'SELECT ?, 3' | Да |
PREPARE s AS 'SELECT 3, ?' | Нет |
PREPARE s AS 'SELECT ?, ?' | Нет |
Операционная информация плагина Rewriter
Плагин Rewriter делает информацию о работе доступной
посредством нескольких переменных состояния:
mysql> SHOW GLOBAL STATUS LIKE 'Rewriter%';
+-----------------------------------+-------+
| Variable_name | Value |
+-----------------------------------+-------+
| Rewriter_number_loaded_rules | 1 |
| Rewriter_number_reloads | 5 |
| Rewriter_number_rewritten_queries | 1 |
| Rewriter_reload_error | ON |
+-----------------------------------+-------+
См.
раздел 6.6.4.3.4.
Когда Вы загружаете таблицу правил, вызывая хранимую процедуру
flush_rewrite_rules() , если ошибка
происходит для правила, CALL производит ошибку, и плагин
устанавливает Rewriter_reload_error в ON :
mysql> CALL query_rewrite.flush_rewrite_rules();
ERROR 1644 (45000): Loading of some rule(s) failed.
mysql> SHOW GLOBAL STATUS LIKE 'Rewriter_reload_error';
+-----------------------+-------+
| Variable_name | Value |
+-----------------------+-------+
| Rewriter_reload_error | ON |
+-----------------------+-------+
В этом случае проверьте столбец message таблицы
rewrite_rules на значения не NULL ,
чтобы видеть, какова проблема была.
Использование плагином наборов символов
Когда таблица rewrite_rules загружена в
Rewriter , плагин интерпретирует запросы, используя текущее
глобальное значение
character_set_client . Если глобальная переменная
character_set_client
изменена впоследствии, таблица правил должна быть перезагружена.
У клиента должно быть сеансовое значение
character_set_client
идентичное тому, каким было глобальное значение, когда таблица
правил была загружена, или соответствующее правило не будет работать.
6.6.4.3.
Ссылка плагина Rewriter
Следующее обсуждение служит ссылкой на эти
компоненты, связанные с Rewriter :
6.6.4.3.1.
Таблица правил плагина перезаписи запроса
Таблица правил Rewriter в базе данных
query_rewrite обеспечивает постоянное хранение правил, которые
Rewriter применяет, чтобы решить, переписать ли запрос.
Пользователи общаются с плагином, изменяя ряд правил, сохраненный в этой
таблице. Плагин общается с пользователями через столбец message .
Таблица правил загружена в плагин хранимой процедурой
flush_rewrite_rules . Если ту процедуру не вызвали после новой
табличной модификации, табличное содержание не обязательно соответствует ряду
правил, который использует плагин.
Таблица rewrite_rules имеет столбцы:
id
ID правила. Этот столбец табличный первичный ключ. Вы можете использовать
ID, чтобы уникально идентифицировать любое правило.
pattern
Шаблон, который указывает на образец для запросов, которому правило
соответствует. Используйте ? , чтобы представлять маркеры
параметра, соответствующие значению данных.
pattern_database
База данных для соответствия неквалифицированных имен таблиц в запросах.
Компетентные имена таблиц в запросах соответствуют полностью определенным
именам в образце, если соответствующая база данных и имена таблиц идентичны.
Неквалифицированные имена таблиц в запросах соответствуют неквалифицированным
именам в образце, только если база данных по умолчанию та же самая, как в
pattern_database , а имена таблиц идентичны.
replacement
Шаблон, который указывает, как переписать запросы, соответствующие
столбцу pattern . Используйте ? , чтобы
представлять маркеры параметра, соответствующие значениям данных. В
переписанных запросах плагин меняет ? в replacement
с использованием значений данных, соответствующих
соответствующим маркерам в pattern .
enabled
Включено ли правило. Операции загрузки (flush_rewrite_rules()
) загружают правило из таблицы в кэш-память Rewriter
только если этот столбец YES .
Этот столбец позволяет дезактивировать правило, не удаляя его:
установите столбец в любое значение, кроме YES ,
и перезагрузите таблицу в плагин.
message
Плагин использует этот столбец для того, чтобы общаться с пользователями.
Если никакая ошибка не происходит, когда таблица правил загружена в память,
плагин устанавливает message в NULL . Значение
не-NULL указывает на ошибку, а содержимое столбца это сообщение
об ошибке. Ошибки могут произойти при этих обстоятельствах:
Если ошибка загрузки происходит, плагин также устанавливает
Rewriter_reload_error = ON .
pattern_digest
Этот столбец используется для отладки и диагностики. Если столбец
существует, когда таблица правил загружена в память, плагин обновляет это с
обзором образца. Этот столбец может быть полезным, если Вы пытаетесь
определить, почему некоторый запрос не в состоянии быть переписанным.
normalized_pattern
Этот столбец используется для отладки и диагностики. Если столбец
существует, когда таблица правил загружена в память, плагин обновляет это с
нормализованной формой образца. Этот столбец может быть полезным, если Вы
пытаетесь определить, почему некоторый запрос не в
состоянии быть переписанным.
6.6.4.3.2.
Процедуры и функции плагина перезаписи запроса
Rewriter использует хранимую процедуру, которая загружает
таблицу правил в его кэш-память, и вспомогателдьную определяемую
пользователем функцию (UDF). При нормальном функционировании пользователи
вызывают только хранимую процедуру. UDF предназначен, чтобы быть вызванным
хранимой процедурой, а не непосредственно пользователями.
flush_rewrite_rules()
Эта хранимая процедура использует UDF load_rewrite_rules() ,
чтобы загрузить содержание таблицы rewrite_rules в кэш
Rewriter . После загрузки таблицы это также очищает кэш запроса.
Запрос flush_rewrite_rules() подразумевает
COMMIT .
Вызовите эту процедуру после того, как Вы изменяете таблицу правил, чтобы
заставить плагин обновлять свой кэш от нового табличного содержания. Если
какие-либо ошибки происходят, плагин устанавливает столбец
message для соответствующих строк правил в таблице и
Rewriter_reload_error = ON .
load_rewrite_rules()
Эта UDF подпрограмма помощника, используемая
хранимой процедурой flush_rewrite_rules() .
6.6.4.3.3.
Системные переменные плагина перезаписи запроса
Плагин Rewriter использует следующие системные переменные.
Эти переменные доступны, только если плагин установлен (см.
раздел
6.6.4.1).
6.6.4.3.4.
Переменные статуса Rewriter
Rewriter поддерживает следующие переменные статуса.
Эти переменные доступны, только если плагин устанавлен (см.
раздел
6.6.4.1).
Rewriter_number_loaded_rules
Количество правил, успешно загруженных из таблицы
rewrite_rules в память для использования плагином.
-
Rewriter_number_reloads
Сколько раз таблица rewrite_rules была
загружена в кэш Rewriter .
-
Rewriter_number_rewritten_queries
Количество вопросов, переписанных Rewriter .
-
Rewriter_reload_error
Произошла ли ошибка, когда rewrite_rules
была загружена в кэш Rewriter . Если OFF ,
никакая ошибка не произошла. Если ON , ошибка произошла,
проверьте столбец message таблицы rewriter_rules
для сообщений об ошибках.
6.6.5. Version Tokens
MySQL включает Version Tokens,
особенность, которая позволяет создание и синхронизацию символов сервера,
которые запросы могут использовать, чтобы предотвратить доступ к неправильным
или устаревшим данным.
У интерфейса Version Tokens есть эти особенности:
Следующие разделы описывают компоненты Version Tokens,
обсуждают, как установить и использовать его и предоставляют
информацию для компонентов.
6.6.5.1. Компоненты Version Tokens
Version Tokens основаны на
библиотеке, которая осуществляет эти компоненты:
Плагин серверной стороны version_tokens
читает список символов вариантов связанным с сервером и подписывается на
уведомления для событий выполнения запроса. Плагин
version_tokens использует
audit plugin API, чтобы
контролировать поступающие запросы от клиентов и соответствует определенному
для сессии списку символов вариантов для каждого клиента против списка
символов версии для сервера. Если есть совпадение, плагин пропускает запрос,
и сервер продолжает обрабатывать его. Иначе плагин возвращает ошибку клиенту,
и запрос терпит неудачу.
- Ряд определенных пользователями функций (UDF) обеспечивает API SQL-уровня
для управления и просмотра списка символов версии
сервера, сохраняемых плагином.
- Системная переменная позволяет клиентам определить список символов
вариантов, которые регистрируют необходимое состояние сервера. Если у сервера
есть отличное состояние, когда клиент посылает запрос,
клиент получает ошибку.
6.6.5.2.
Установка или деинсталлирование Version Tokens
Если установлено, Version Tokens вовлекает некоторые издержки. Чтобы
избежать этого, не устанавливайте плагин, если вы не планируете использовать.
Этот раздел описывает, как установить или деинсталлировать Version Tokens,
который осуществляется в файле библиотеки, содержащем плагин и определенные
пользователями функции. См. разделы
6.6.2 и
26.4.2.5.
Чтобы быть применимым сервером, файл библиотеки должен быть расположен в
каталоге плагинов (каталог, названный в системной переменной
plugin_dir ).
Если необходимо, установите значение
plugin_dir
при запуске сервера, чтобы сказать серверу местоположение каталога.
Базовое имя файла библиотеки version_tokens .
Суффикс имени файла отличается в зависимости от платформы (например,
.so в Unix и .dll в Windows).
Чтобы установить плагин и UDF, используйте
INSTALL PLUGIN и
CREATE FUNCTION
(замените суффикс .so для вашей платформы
по мере необходимости):
INSTALL PLUGIN version_tokens SONAME 'version_token.so';
CREATE FUNCTION version_tokens_set RETURNS STRING SONAME 'version_token.so';
CREATE FUNCTION version_tokens_show RETURNS STRING SONAME 'version_token.so';
CREATE FUNCTION version_tokens_edit RETURNS STRING SONAME 'version_token.so';
CREATE FUNCTION version_tokens_delete RETURNS STRING SONAME 'version_token.so';
CREATE FUNCTION version_tokens_lock_shared RETURNS INT SONAME 'version_token.so';
CREATE FUNCTION version_tokens_lock_exclusive RETURNS INT SONAME 'version_token.so';
CREATE FUNCTION version_tokens_unlock RETURNS INT SONAME 'version_token.so';
Необходимо установить UDF, чтобы управлять списком
вариантов, но необходимо также установить плагин, потому что UDF не будет
работать правильно без него.
Если плагин и UDF используются на главном сервере репликации,
устанавливают их на всех ведомых серверах также, чтобы избежать проблем.
После того, как установлен, плагин Version Tokens и UDF
остаются установленными, пока не деинсталлированы. Чтобы удалить их,
используйте UNINSTALL PLUGIN
и DROP FUNCTION :
UNINSTALL PLUGIN version_tokens;
DROP FUNCTION version_tokens_set;
DROP FUNCTION version_tokens_show;
DROP FUNCTION version_tokens_edit;
DROP FUNCTION version_tokens_delete;
DROP FUNCTION version_tokens_lock_shared;
DROP FUNCTION version_tokens_lock_exclusive;
DROP FUNCTION version_tokens_unlock;
6.6.5.3. Применение Version Tokens
Перед использованием Version Tokens, установите его согласно инструкциям,
предоставленным в разделе
6.6.5.2.
Сценарий, в котором Version Tokens может быть полезным, является системой,
которая получает доступ к коллекции серверов MySQL, но должна управлять ими в
целях выравнивания нагрузки, контролируя их и регулируя назначения сервера
согласно изменениям. Такая система включает эти компоненты:
Version Tokens разрешают управлять доступом к серверу согласно назначению,
не требуя, чтобы клиенты неоднократно запрашивали серверы об их назначениях:
Приложение для управления выполняет назначения сервера и
устанавливает символы вариантов на каждом сервере, чтобы отразить его
назначение. Приложение кэширует эту информацию, чтобы предоставить
центральную точку доступа.
Если в какой-то момент приложение для управления должно изменить
назначение сервера, оно изменяет список символов
сервера и обновляет кэш.
- Чтобы улучшить работу, клиентские приложения получают информацию о
кэше из приложения для управления, позволяя им избежать необходимости
получать информацию о назначениях сервера при каждом запросе.
На основе типа запросов (например, читает или пишет), клиент выбирает
соответствующий сервер и соединяется с ним.
- Кроме того, клиент посылает в сервер его собственные определенные для
клиента символы вариантов, чтобы зарегистрировать назначение, которого он
требует от сервера. Для каждого запроса, посланного клиентом в сервер, сервер
сравнивает свой собственный символический список со списком клиента. Если
список символов сервера содержит все символы, существующие в списке символов
клиента с теми же самыми значениями, есть совпадение, и
сервер выполняет запрос.
С другой стороны, возможно приложение для управления изменило назначение
сервера и его список символов. В этом случае новое назначение сервера может
теперь быть несовместимым с требованиями клиента. Символическое
несоответствие между сервером и клиентом происходит, и сервер возвращает
ошибку в ответ на запрос. Это признак клиенту освежить информацию о символе
вариантов из кэша приложения для управления и выбрать новый сервер.
Клиентская логика для обнаружения ошибок символа
и отбора нового сервера может быть осуществлена различными путями:
Следующий пример иллюстрирует предыдущее обсуждение в
более конкретной форме.
Когда Version Tokens инициализируют на данном сервере, список вариантов
пуст. Обслуживание списка выполняется, вызывая определенные пользователями
функции (UDF). Трпебуется привилегия
SUPER , чтобы вызывать любую Version Token UDF,
таким образом, модификация списка, как ожидают, будет сделана приложением для
управления или административным приложением, у которого есть эта привилегия.
Предположим, что приложение для управления общается с рядом серверов,
которые запрашиваются клиентами, чтобы получить доступ к базам данных
emp и prod ). Всем серверам разрешают обработать
запросы поиска данных, но только некоторым из них разрешают сделать
обновления базы данных. Чтобы обращаться с этим на определенной для базы
данных основе, приложение для управления составляет список символов вариантов
на каждом сервере. В символическом списке для данного сервера символические
имена представляют имена базы данных и значения
read или write в зависимости от того, должна ли
база данных использоваться только для чтения или для обновления.
Клиентские приложения регистрируют список символов вариантов, которым они
требуют соответствия сервера, устанавливая системную переменную.
Это происходит на определенной для клиента основе, таким образом, различные
клиенты могут зарегистрировать различные требования. По умолчанию список
символа клиента пуст, что соответствует любому списку символов сервера.
Когда клиент устанавливает его символический список в непустое значение,
соответствие может иметь успех или потерпеть неудачу, в зависимости от
списка символов сервера.
Чтобы определить список вариантов для сервера, приложение для управления
вызывает UDF version_token_set() . Есть также UDF для изменения и
показа символического списка, описанные позже. Например, приложение могло бы
послать эти запросы группе из трех серверов:
Server 1:
mysql> SELECT version_tokens_set('emp=read;prod=read');
+------------------------------------------+
| version_tokens_set('emp=read;prod=read') |
+------------------------------------------+
| 2 version tokens set. |
+------------------------------------------+
Server 2:
mysql> SELECT version_tokens_set('emp=write;prod=read');
+-------------------------------------------+
| version_tokens_set('emp=write;prod=read') |
+-------------------------------------------+
| 2 version tokens set. |
+-------------------------------------------+
Server 3:
mysql> SELECT version_tokens_set('emp=read;prod=write');
+-------------------------------------------+
| version_tokens_set('emp=read;prod=write') |
+-------------------------------------------+
| 2 version tokens set. |
+-------------------------------------------+
Список в каждом случае определяется как отделенный точкой с запятой список
пар name =value .
Получающийся список оценивает результат в этих назначениях сервера:
В дополнение к назначению каждого сервера приложение для управления
также обслуживает кэш, который отражает назначения сервера.
Прежде, чем общаться с серверами, клиентское приложение связывается с
приложением для управления и получает информацию о назначениях сервера.
Тогда клиент выбирает сервер на основе тех назначений. Предположим, что
клиент хочет читать и писать базу данных emp .
На основе предыдущих назначений годится только сервер 2. Клиент соединяется с
сервером 2 и регистрирует его требования сервера, устанавливая его
системную переменную version_tokens_session :
mysql> SET @@session.version_tokens_session = 'emp=write';
Для последующих запросов, посланных клиентом в сервер 2, сервер сравнивает
свой собственный список вариантов со списком клиента, чтобы проверить,
соответствуют ли они. Если так, запросы выполняются:
mysql> UPDATE emp.employee SET salary = salary * 1.1 WHERE id = 4981;
Query OK, 1 row affected (0.07 sec)
Rows matched: 1 Changed: 1 Warnings: 0
mysql> SELECT last_name, first_name FROM emp.employee WHERE id = 4981;
+-----------+------------+
| last_name | first_name |
+-----------+------------+
| Smith | Abe |
+-----------+------------+
1 row in set (0.01 sec)
Несоответствия между списками сервера и версии клиента могут
произойти двумя путями:
Пока назначение сервера 2 не изменяется, клиент продолжает использовать
это для чтения и записи. Но предположите, что приложение для управления хочет
изменить назначения сервера так, чтобы записи в emp
нужно послать в сервер 1 вместо сервера 2. Чтобы сделать это, приложение
использует version_tokens_edit() , чтобы изменить значение
символа emp на этих двух серверах
(и обновить кэш назначений сервера):
Server 1:
mysql> SELECT version_tokens_edit('emp=write');
+----------------------------------+
| version_tokens_edit('emp=write') |
+----------------------------------+
| 1 version tokens updated. |
+----------------------------------+
Server 2:
mysql> SELECT version_tokens_edit('emp=read');
+---------------------------------+
| version_tokens_edit('emp=read') |
+---------------------------------+
| 1 version tokens updated. |
+---------------------------------+
version_tokens_edit() меняет названные символы в списке
сервера и оставляет другие символы без изменений.
В следующий раз, когда клиент посылает запрос серверу 2, его собственный
список больше не соответствует списку символов сервера, и ошибка происходит:
mysql> UPDATE emp.employee SET salary = salary * 1.1 WHERE id = 4982;
ERROR 3136 (42000): Version token mismatch for emp. Correct value read
В этом случае клиент должен связаться с приложением для управления, чтобы
получить обновленную информацию о назначениях сервера, выбрать новый сервер и
послать неудавшийся запрос новому серверу.
Каждый клиент должен сотрудничать с Version Tokens, посылая только запросы
в соответствии с символическим списком, который регистрируется в данном
сервере. Например, если клиент регистрирует символический список
'emp=read' , нет ничего в Version Tokens, чтобы препятствовать
тому, чтобы клиент послал обновления для базы данных emp .
Клиент самостоятельно должен воздержаться от выполнения этого.
Для каждого запроса, полученного от клиента, сервер неявно использует
блокировку следующим образом:
Сервер использует коллективные блокировки так, чтобы сравнения для
разных сессий могли произойти без блокирования, предотвращая изменения
символов для любой сессии, которая пытается приобрести монопольную
блокировку, прежде чем управлять символами с теми же самыми именами в
списке символов сервера.
Предыдущий пример использует только несколько определенных пользователями
функций, включенных в библиотеку плагина Version Tokens, но есть другие. Один
набор UDF разрешает управлять и просматривать список символов сервера. Другой
набор UDF разрешает блокировать символы.
Эти UDF разрешают списку сервера быть созданным,
измененным, удаленным и просмотренным:
Каждая из тех функций, в случае успеха, возвращает двоичную строку,
указывающую, какое действие произошло. Следующий пример составляет список
символов сервера, изменяет его, добавляя новый символ, удаляет некоторые
символы и показывает получающийся список:
mysql> SELECT version_tokens_set('tok1=a;tok2=b');
+-------------------------------------+
| version_tokens_set('tok1=a;tok2=b') |
+-------------------------------------+
| 2 version tokens set. |
+-------------------------------------+
mysql> SELECT version_tokens_edit('tok3=c');
+-------------------------------+
| version_tokens_edit('tok3=c') |
+-------------------------------+
| 1 version tokens updated. |
+-------------------------------+
mysql> SELECT version_tokens_delete('tok2;tok1');
+------------------------------------+
| version_tokens_delete('tok2;tok1') |
+------------------------------------+
| 2 version tokens deleted. |
+------------------------------------+
mysql> SELECT version_tokens_show();
+-----------------------+
| version_tokens_show() |
+-----------------------+
| tok3=c; |
+-----------------------+
Предупреждения происходят, если символический список неправилен:
mysql> SELECT version_tokens_set('tok1=a; =c');
+----------------------------------+
| version_tokens_set('tok1=a; =c') |
+----------------------------------+
| 1 version tokens set. |
+----------------------------------+
1 row in set, 1 warning (0.00 sec)
mysql> SHOW WARNINGS\G
*************************** 1. row ***************************
Level: Warning
Code: 42000
Message: Invalid version token pair encountered. The list provided
is only partially updated.
1 row in set (0.00 sec)
Как упомянуто ранее, символы вариантов определяются, используя
отделенный точкой с запятой список пар
name =value .
Рассмотрите этот вызов version_tokens_set() :
mysql> SELECT version_tokens_set('tok1=b;;; tok2= a = b ; tok1 = 1\'2 3"4')
+---------------------------------------------------------------+
| version_tokens_set('tok1=b;;; tok2= a = b ; tok1 = 1\'2 3"4') |
+---------------------------------------------------------------+
| 3 version tokens set. |
+---------------------------------------------------------------+
Version Tokens интерпретируют аргумент следующим образом:
Учитывая эти правила, предыдущий запрос version_tokens_set()
получит результаты в символическом списке с двумя символами:
tok1 имеет значение 1'2 3"4 , а tok2
имеет значение a = b . Чтобы проверить это, вызовите
version_tokens_show() :
mysql> SELECT version_tokens_show();
+--------------------------+
| version_tokens_show() |
+--------------------------+
| tok2=a = b;tok1=1'2 3"4; |
+--------------------------+
Если символический список содержит два символа, почему
version_tokens_set() вернул 3 значения символа ?
Это произошло, потому что оригинальный символический список содержал два
определения для tok1 , и второе определение заменило первое.
UDF Version Tokens имеет эти ограничения на имена и значения:
Version Tokens также включают ряд UDF,
предоставляющих возможности блокировки:
Каждая функция блокировки возвращает отличное от нуля значение для успеха.
Иначе ошибка происходит:
mysql> SELECT version_tokens_lock_shared('lock1', 'lock2', 0);
+-------------------------------------------------+
| version_tokens_lock_shared('lock1', 'lock2', 0) |
+-------------------------------------------------+
| 1 |
+-------------------------------------------------+
mysql> SELECT version_tokens_lock_shared(NULL, 0);
ERROR 3131 (42000): Incorrect locking service lock name '(null)'.
Блокировки, использующие функции блокировки Version Tokens,
консультативны, приложения должны согласиться сотрудничать.
Возможно заблокировать несуществующие символические имена.
Это не создает символы.
Функции блокировки Version Tokens основаны на сервисе из
раздела 26.3.1 и имеют ту же самую
семантику для коллективных и монопольных блокировок.
Version Tokens используют служебные подпрограммы, встроенные в сервер, а не
интерфейс UDF, таким образом, те UDF не должны быть установлены, чтобы
использовать Version Tokens. Блокировки, приобретенные Version Tokens,
используют сервисное пространство имен version_token_locks .
Блокировки могут быть проверены, используя Performance Schema,
таким образом, это также верно для блокировок Version Tokens. См.
раздел 26.3.1.2.3.
Для функций блокировки Version Tokens аргументы имени используются точно,
как определены. Окружение пробелами не проигнорировано и позволены
= и ; . Это вызвано тем, что Version Tokens
просто передают имена, которые будут заблокированы, сервису блокировок.
6.6.5.4.
Ссылки Version Tokens
Следующее обсуждение служит ссылкой на эти компоненты Version Tokens:
6.6.5.4.1.
Функции Version Tokens
Библиотека плагина Version Tokens включает несколько определенных
пользователями функций. Один набор UDF разрешает управлять и просматривать
список сервера символов вариантов. Другой набор UDF разрешает работать с
блокировками. Привилегия SUPER
требуется, чтобы вызывать любые Version Tokens UDF.
Следующие UDF разрешают создать, изменить, удалить и просмотреть
список маркеров версии сервера. Интерпретация параметров
name_list и token_list
(включая обработку пробелов) происходит, как описано в
разделе 6.6.5.3, который
предоставляет подробную информацию о синтаксисе для определения маркеров, а
также дополнительные примеры.
version_tokens_delete(name_list )
Удаляет маркеры из списка сервера, используя
name_list и возвращает двоичную строку, которая
указывает на результат операции. name_list
разделенный точкой с запятой список маркерных имен, чтобы удалить.
mysql> SELECT version_tokens_delete('tok1;tok3');
+------------------------------------+
| version_tokens_delete('tok1;tok3') |
+------------------------------------+
| 2 version tokens deleted. |
+------------------------------------+
Параметр NULL рассматривается как пустая строка, которая не
имеет никакого эффекта на маркерный список.
version_tokens_delete()
удаляет маркеры, названные в его параметре, если они существуют.
Не ошибка удалить несуществующие маркеры. Чтобы очистить маркерный список
полностью, не зная, какие маркеры находятся в списке, передайте
NULL или строку, не содержащую маркеры, в
version_tokens_set() :
mysql> SELECT version_tokens_set(NULL);
+------------------------------+
| version_tokens_set(NULL) |
+------------------------------+
| Version tokens list cleared. |
+------------------------------+
mysql> SELECT version_tokens_set('');
+------------------------------+
| version_tokens_set('') |
+------------------------------+
| Version tokens list cleared. |
+------------------------------+
version_tokens_edit(token_list )
Изменяет список сервера, используя token_list
и возвращает двоичную строку, которая указывает на результат операции.
token_list разделенный точкой с запятой список
пар name =value ,
определяющих имя каждого маркера, который будет определен, и его значение.
Если маркер существует, его значение обновляется с данным значением. Если
маркер не существует, он создается с данным значением. Если параметр
NULL или строка, не содержащая маркеры, маркерный
список остается неизменным.
mysql> SELECT version_tokens_set('tok1=value1;tok2=value2');
+-----------------------------------------------+
| version_tokens_set('tok1=value1;tok2=value2') |
+-----------------------------------------------+
| 2 version tokens set. |
+-----------------------------------------------+
mysql> SELECT version_tokens_edit('tok2=new_value2;tok3=new_value3');
+--------------------------------------------------------+
| version_tokens_edit('tok2=new_value2;tok3=new_value3') |
+--------------------------------------------------------+
| 2 version tokens updated. |
+--------------------------------------------------------+
version_tokens_set(token_list )
Заменяет список сервера маркерами, определенными в
token_list и возвращает двоичную строку, которая
указывает на результат операции. token_list is a
разделенный точкой с запятой список пар
name =value ,
определяющих имя каждого маркера, который будет определен, и его значение.
Если параметр NULL или строка, не содержащая маркеры,
маркерный список очищен.
mysql> SELECT version_tokens_set('tok1=value1;tok2=value2');
+-----------------------------------------------+
| version_tokens_set('tok1=value1;tok2=value2') |
+-----------------------------------------------+
| 2 version tokens set. |
+-----------------------------------------------+
version_tokens_show()
Возвращает список сервера как двоичную строку, содержащую разделенный
точкой с запятой список пар
name =value .
mysql> SELECT version_tokens_show();
+--------------------------+
| version_tokens_show() |
+--------------------------+
| tok2=value2;tok1=value1; |
+--------------------------+
Следующие UDFs разрешают управлять блокировкой маркеров:
version_tokens_lock_exclusive(token_name
[, token_name ] ...,
timeout )
Получает монопольные блокировки на одном или более маркеров, определенных
по имени как строки, с ошибкой, если блокировки не получены в пределах
данного значения тайм-аута.
mysql> SELECT version_tokens_lock_exclusive('lock1', 'lock2', 10);
+-----------------------------------------------------+
| version_tokens_lock_exclusive('lock1', 'lock2', 10) |
+-----------------------------------------------------+
| 1 |
+-----------------------------------------------------+
version_tokens_lock_shared(token_name [,
token_name ] ..., timeout )
Получает коллективные блокировки на одном или более маркеров, определенных
по имени как строки, с ошибкой, если блокировки не получены в пределах
данного значения тайм-аута.
mysql> SELECT version_tokens_lock_shared('lock1', 'lock2', 10);
+--------------------------------------------------+
| version_tokens_lock_shared('lock1', 'lock2', 10) |
+--------------------------------------------------+
| 1 |
+--------------------------------------------------+
version_tokens_unlock()
Снимает все блокировки, которые были получены в рамках текущего
использования version_tokens_lock_exclusive() и
version_tokens_lock_shared() .
mysql> SELECT version_tokens_unlock();
+-------------------------+
| version_tokens_unlock() |
+-------------------------+
| 1 |
+-------------------------+
Функции блокировки имеют эти особенности:
6.6.5.4.2.
Системные переменные Version Tokens
Version Tokens поддерживают следующие системные переменные. Эти переменные
недоступны, если плагин Version Tokens не установлен (см.
раздел 6.6.5.2).
version_tokens_session
Формат командной строки
|
--version_tokens_session=value |
Системная переменная
|
Имя |
version_tokens_session
|
Область действия |
Глобальная, Сеансовая |
Динамическая |
Да |
Допустимые значения
| Тип |
string |
Значение по умолчанию |
NULL |
Значение сеанса этой переменной определяет, список маркеров клиента и
указывает на маркеры, которые клиентский сеанс требует в списке сервера.
Если
version_tokens_session = NULL (по умолчанию) или
имеет пустое значение, любой серверный список соответствует.
В действительности пустое значение отключает соответствие требованиям.
Если
version_tokens_session имеет непустое значение, любое
несоответствие между его значением и маркерным списком сервера приводит к
ошибке для любого оператора, который сеанс отправляет в сервер.
Несоответствие происходит при этих условиях:
Если маркерный список сервера включает маркер, не названный в
version_tokens_session , это не несоответствие.
Предположим, что приложение управления установило маркерный список
сервера следующим образом:
mysql> SELECT version_tokens_set('tok1=a;tok2=b;tok3=c');
+--------------------------------------------+
| version_tokens_set('tok1=a;tok2=b;tok3=c') |
+--------------------------------------------+
| 3 version tokens set. |
+--------------------------------------------+
Клиент регистрирует маркеры, которым требует, чтобы сервер соответствовал,
устанавливая
version_tokens_session . Затем для каждого последующего оператора,
отправленного клиентом, сервер сравнивает свой маркерный список с клиентским
version_tokens_session
и производит ошибку, если есть несоответствие:
mysql> SET @@session.version_tokens_session = 'tok1=a;tok2=b';
mysql> SELECT 1;
+---+
| 1 |
+---+
| 1 |
+---+
mysql> SET @@session.version_tokens_session = 'tok1=b';
mysql> SELECT 1;
ERROR 3136 (42000): Version token mismatch for tok1. Correct value a
Первый SELECT
успешно выполняется потому, что клиентские маркеры tok1 и
tok2 присутствуют в маркерном списке сервера, и у каждого
маркера есть то же самое значение в списке сервера. Второй
SELECT терпит неудачу потому что,
хотя tok1 присутствует в маркерном списке сервера, у него есть
иное значение, чем указанное клиентом.
В этой точке терпит неудачу любой оператор, отправленный клиентом,
если маркерный список сервера не изменяется таким образом, что это
соответствует снова. Предположим, что приложение управления изменяет
маркерный список сервера следующим образом:
mysql> SELECT version_tokens_edit('tok1=b');
+-------------------------------+
| version_tokens_edit('tok1=b') |
+-------------------------------+
| 1 version tokens updated. |
+-------------------------------+
mysql> SELECT version_tokens_show();
+-----------------------+
| version_tokens_show() |
+-----------------------+
| tok3=c;tok1=b;tok2=b; |
+-----------------------+
Теперь клиентское значение
version_tokens_session соответствует маркерному списку
сервера, и клиент может еще раз успешно выполнить операторы:
mysql> SELECT 1;
+---+
| 1 |
+---+
| 1 |
+---+
-
version_tokens_session_number
Формат командной строки
| --version_tokens_session_number=N
|
Системная переменная
| Имя |
version_tokens_session_number |
Область действия |
Глобальная, Сеансовая |
Динамическая |
Нет |
Допустимые значения
| Тип |
integer |
Значение по умолчанию |
0 |
Эта переменная для внутреннего пользования.
6.7. Выполнение многих экземпляров MySQL
на одной машине
В некоторых случаях вы могли бы хотеть выполнить многократные экземпляры
MySQL на единственной машине. Вы могли бы хотеть протестировать новый выпуск
MySQL, оставляя существующую производственную установку без помех. Или вы
могли бы хотеть предоставить различный пользовательский доступ к различным
серверам mysqld
. Например, вы могли бы быть Интернет-провайдером, который хочет
предоставить независимые установки MySQL различным клиентам.
Возможно использовать различный двоичный файл сервера MySQL на экземпляр
или использовать тот же самый двоичный файл для многократных экземпляров или
любую комбинацию двух подходов. Например, вы могли бы выполнить серверы MySQL
5.7 и MySQL 8.0, чтобы видеть, как различные версии обрабатывают данную
рабочую нагрузку. Или вы могли бы выполнить многократные экземпляры текущей
производственной версии, каждый управляющий различным набором баз данных.
Используете ли вы отличные двоичные файлы сервера, каждый экземпляр,
который вы выполняете, должен быть сконфигурирован с уникальными значениями
для нескольких операционных параметров. Это устраняет потенциал для конфликта
между экземплярами. Параметры могут быть установлены в командной строке,
в файлах опций или установив переменные окружения. См.
раздел 5.2.3.
Чтобы видеть значения, используемые экземпляром, соединитесь с ним и
выполните SHOW VARIABLES .
Основной ресурс, которым управляет экземпляр MySQL, является каталогом
данных. Каждый экземпляр должен использовать различный каталог данных,
местоположение которого определяется, используя
--datadir=dir_name .
Для методов конфигурирования каждого экземпляра с его собственным каталогом
данных и предупреждений об опасностях см.
раздел 6.7.1.
В дополнение к использованию различных каталогов данных у нескольких
других опций должны быть различные значения для каждого экземпляра сервера:
--port=
port_num
--port
управляет номером порта для соединений TCP/IP. Альтернативно, если у узла
есть многократные сетевые адреса, можно использовать
--bind-address
, чтобы заставить каждый сервер слушать различный адрес.
--socket={
file_name |pipe_name }
--socket
управляет путем к файлу сокета Unix в Unix или именем именованного канала в
Windows. В Windows необходимо определить отличные имена каналов только для
тех серверов, которые разрешают соединения именованного канала.
--shared-memory-base-name=name
Эта опция используется только в Windows. Это называет имя общей памяти
Windows Server, чтобы разрешить клиентам подключаться, используя общую
память. Необходимо определить, что имя общей памяти называется только для тех
серверов, которые разрешают соединения с общей памятью.
--pid-file=
file_name
Эта опция указывает на путь файла, в котором сервер пишет
свой ID процесса.
При использовании следующих опций файла журнала, их значения должны
отличаться для каждого сервера:
Для дальнейшего обсуждения опций файла журнала посмотрите
раздел 6.4.
Чтобы достигнуть лучшей производительности, можно определить следующую
опцию по-другому для каждого сервера, чтобы распределить нагрузку между
несколькими физическими дисками:
Наличие различных временных каталогов также облегчает определять, какой
сервер MySQL создал любой данный временный файл.
Если у вас есть многократные установки MySQL в различных местах,
можно определить основной каталог для каждой установки с
--basedir=
dir_name . Это заставляет каждый экземпляр
автоматически использовать различный каталог данных, файлы журнала и файл
PID, потому что значение по умолчанию для каждого из этих параметров
задается относительно основного каталога. В этом случае единственные опции,
которые необходимо определить, это
--socket и
--port .
Предположим, что вы устанавливаете различные версии MySQL, используя
двоичные дистрибутивы tar . Они устанавливаются в различных
местах, таким образом, можно запустить сервер для каждой установки, используя
команду bin/mysqld_safe в соответствии с ее
основным каталогом.
mysqld_safe определяет надлежащую опцию
--basedir , чтобы
передать ее mysqld
, и вы должны определить только
--socket и
--port .
Как обсуждено в следующем разделs, возможно запустить дополнительные
серверы, определяя соответствующие опции команды или устанавливая переменные
окружения. Однако, если необходимо выполнить многократные серверы на более
постоянной основе, более удобно использовать файлы опции, чтобы определить
для каждого сервера те значения опции, которые должны быть уникальны для
него. Опция
--defaults-file очень полезна для этого.
6.7.1.
Установка многих каталогов данных
У каждого экземпляра MySQL на машине должен быть свой собственный каталог
данных. Местоположение определяется, используя опцию
--datadir=dir_name .
Есть различные методы установки каталога данных для нового экземпляра:
Следующее обсуждение обеспечивает больше деталей о каждом методе.
Обычно у вас никогда не должно быть двух серверов, которые обновляют
данные в тех же самых базах данных. Это может привести к неприятным
неожиданностям, если ваша операционная система не поддерживает блокировку
безотказной системы. Если (несмотря на это предупреждение) вы выполняете
много серверов, используя тот же самый каталог данных, и у них есть
включенное журналирование, необходимо использовать подходящие варианты, чтобы
определить имена файла журнала, которые уникальны для каждого сервера. Иначе
серверы пытаются писать те же самые файлы.
Даже когда предыдущие меры предосторожности выполняются,
этот вид установки работает только с таблицами MyISAM и
MERGE . Кроме того, это предупреждение против совместного
использования каталога данных среди серверов всегда применяется в окружающей
среде NFS. Разрешение многим серверам MySQL получить доступ к каталогу общих
данных по NFS является очень плохой идеей. Основная
проблема состоит в том, что NFS узкое место по скорости. Это не предназначено
для такого использования. Другой риск с NFS состоит в том, что необходимо
создать способ гарантировать, чтобы два или больше сервера не вмешивались
друг в друга. Обычно захват файла NFS обрабатывается сервисом
lockd , но в данный момент нет никакой платформы, которая
выполняет блокировку 100% достоверно в каждой ситуации.
Создайте новый каталог данных
С этим методом каталог данных будет в том же самом состоянии как тогда,
когда вы сначала устанавливаете MySQL. У этого будет набор по умолчанию
учетных записей MySQL и никаких пользовательских данных.
В Unix инициализируйте каталог данных. Посмотрите
раздел 2.9.
В Windows каталог данных включен в MySQL:
Скопируйте существующий каталог данных
С этим методом любые учетные записи MySQL или пользовательские данные,
существующие в каталоге данных, перенесены в новый каталог данных.
Остановите существующий экземпляр MySQL, используя
каталог данных. Это должно быть чистым завершением работы так, чтобы
экземпляр сбросил любые изменения на диск.
- Скопируйте каталог данных в место, где новый каталог данных должен быть.
- Скопируйте файл опции
my.cnf или my.ini ,
используемый существующим экземпляром. Это служит основанием
для нового экземпляра.
- Измените новый файл опции так, чтобы любые пути, обращающиеся к исходному
каталогу данных, обратились к новому каталогу данных. Кроме того, измените
любые другие опции, которые должны быть уникальными для экземпляра, такие как
номер порта TCP/IP и файлы журнала. Для списка параметров, которые должны
быть уникальными, посмотрите
раздел 6.7.
- Запустите новый экземпляр, указав ему использовать новый файл опции.
6.7.2.
Выполнение нескольких экземпляров MySQL в Windows
Можно выполнить много серверов в Windows, запустив их вручную из командной
строки, каждый с соответствующими операционными параметрами, или установив
несколько серверов как службы Windows и выполнив их. Общие инструкции для
работы MySQL из командной строки или как сервис даны в
разделе 2.3.
Следующие разделы описывают, как запустить каждый сервер с различными
значениями для тех опций, которые должны быть уникальными для сервера, такими
как каталог данных. Эти опции перечислены в
разделе 6.7.
6.7.2.1.
Запуск нескольких экземпляров MySQL в командной строке Windows
Процедура запуска единственного сервера MySQL вручную из командной строки
описана в разделе 2.3.5.6
. Чтобы запустить много серверов этим путем, можно определить подходящие
варианты в командной строке или в файле опции. Более удобно поместить опции в
файл опции, но необходимо удостовериться, что каждый сервер получает свой
собственный набор опций. Чтобы сделать это, создайте файл опции для каждого
сервера и скажите серверу имя файла с помощью опции
--defaults-file
.
Предположим, что вы хотите выполнить один экземпляр
mysqld
на порту 3307 с каталогом данных C:\mydata1 , а
другой экземпляр на порту 3308 с каталогом данных C:\mydata2 .
Используйте эту процедуру:
Удостоверьтесь, что каждый каталог данных существует,
включая его собственную копию базы данных mysql , которая
содержит таблицы привилегий.
- Создайте два файла опции. Например, создайте один файл
C:\my-opts1.cnf , который похож на это:
[mysqld]
datadir = C:/mydata1
port = 3307
Создайте второй файл C:\my-opts2.cnf :
[mysqld]
datadir = C:/mydata2
port = 3308
- Используйте опцию
--defaults-file , чтобы запустить каждый сервер с его
собственным файлом опций:
C:\> C:\mysql\bin\mysqld --defaults-file=C:\my-opts1.cnf
C:\> C:\mysql\bin\mysqld --defaults-file=C:\my-opts2.cnf
Каждый сервер запускается на переднем плане (никакое новое приглашение не
появляется, пока сервер не выходит позже), таким образом, необходимо будет
дать эти команды в отдельных консолях.
Чтобы закрыть серверы, соединитесь с каждым с использованием
соответствующего номера порта:
C:\> C:\mysql\bin\mysqladmin --port=3307 --host=127.0.0.1 --user=root --password shutdown
C:\> C:\mysql\bin\mysqladmin --port=3308 --host=127.0.0.1 --user=root --password shutdown
Серверы сконфигурированны, чтобы соединиться по TCP/IP. Если ваша версия
Windows поддерживает именованные каналы, и вы также хотите разрешить
соединения именованного канала, определите опции, которые включают
именованный канал и определяют его имя. Каждый сервер, который поддерживает
соединения именованного канала, должен использовать уникальное имя канала.
Например, файл C:\my-opts1.cnf мог бы быть записан так:
[mysqld]
datadir = C:/mydata1
port = 3307
enable-named-pipe
socket = mypipe1
Измените C:\my-opts2.cnf так же для использования вторым
сервером. Тогда запустите серверы, как описано ранее.
Подобная процедура применяется к серверам, которым вы хотите разрешить
сопряжения с общей памятью. Включите такие соединения с опцией
--shared-memory
и определяет уникальное имя общей памяти для каждого сервера с
--shared-memory-base-name .
6.7.2.2.
Запуск нескольких экземпляров MySQL как Windows Services
В Windows MySQL может работать как служба Windows. Процедуры установки,
управления и удаления единственной службы MySQL описаны в
разделе 2.3.5.8.
Чтобы установить много служб MySQL, необходимо удостовериться, что каждый
экземпляр использует различное имя службы в дополнение к другим параметрам,
которые должны быть уникальными у экземпляра.
Для следующих инструкций предположите, что вы хотите выполнить
mysqld
от двух различных версий MySQL, которые установлены в
C:\mysql-5.5.9 и C:\mysql-8.0.1 .
Это могло бы иметь место, если вы работаете с 5.5.9 как с рабочим сервером,
но также хотите провести тесты, используя 8.0.1.
Чтобы установить MySQL как службу Windows, используйте опцию
--install или --install-manual . См.
раздел 2.3.5.8.
Основываясь на предыдущей информации, у вас есть несколько способов
установить многократные службы. Следующие инструкции описывают некоторые
примеры. Прежде, чем пробовать любой из них, закройте и удалите любые
существующие службы MySQL.
Подход 1: Определите опции для всех служб в
одном из стандартных файлов опции. Чтобы сделать это, используйте различное
имя службы для каждого сервера. Предположим, что вы хотите выполнить 5.5.9
mysqld,
с использованием имени службы mysqld1 и 8.0.1
mysqld
с использованием имени службы mysqld2 .
В этом случае можно использовать группы
[mysqld1] для 5.5.9 и [mysqld2] для 8.0.1.
Например, можно установить C:\my.cnf :
# options for mysqld1 service
[mysqld1]
basedir = C:/mysql-5.5.9
port = 3307
enable-named-pipe
socket = mypipe1
# options for mysqld2 service
[mysqld2]
basedir = C:/mysql-8.0.1
port = 3308
enable-named-pipe
socket = mypipe2
Установите службы следующим образом, используя полные пути сервера, чтобы
гарантировать, что Windows регистрирует корректную исполняемую программу
для каждой службы:
C:\> C:\mysql-5.5.9\bin\mysqld --install mysqld1
C:\> C:\mysql-8.0.1\bin\mysqld --install mysqld2
Чтобы запустить службы, используйте менеджер служб или
NET START с соответствующими именами службы:
C:\> NET START mysqld1
C:\> NET START mysqld2
Чтобы остановить службы, используйте менеджер служб или
NET STOP с соответствующими именами службы:
C:\> NET STOP mysqld1
C:\> NET STOP mysqld2
- Подход 2: Определите опции для каждого
сервера в отдельных файлах и примените
--defaults-file
, когда вы устанавливаете службы, чтобы сказать каждому серверу,
какой файл использовать. В этом случае каждый файл должен перечислить опции,
используя группу [mysqld] .
С этим подходом, чтобы определить опции для 5.5.9
mysqld,
создают файл C:\my-opts1.cnf :
[mysqld]
basedir = C:/mysql-5.5.9
port = 3307
enable-named-pipe
socket = mypipe1
Для 8.0.1 mysqld
создайте файл C:\my-opts2.cnf :
[mysqld]
basedir = C:/mysql-8.0.1
port = 3308
enable-named-pipe
socket = mypipe2
Установите службы следующим образом
(введите каждую команду в одну строку):
C:\> C:\mysql-5.5.9\bin\mysqld --install mysqld1
--defaults-file=C:\my-opts1.cnf
C:\> C:\mysql-8.0.1\bin\mysqld --install mysqld2
--defaults-file=C:\my-opts2.cnf
Когда вы устанавливаете сервер MySQL как сервис и используете опцию
--defaults-file
, имя службы должно предшествовать опции.
После установки служб запустите и остановите их как в предыдущем примере.
Чтобы удалить многократные службы, используйте
mysqld --remove
для каждой, определяя имя службы после опции
--remove .
Если имя службы значение по умолчанию (MySQL ),
можно опустить его.
6.7.3.
Выполнение нескольких экземпляров MySQL в Unix
Обсуждение здесь использует
mysqld_safe. Для установки MySQL, используя
RPM, запуск сервера и завершение работы управляется systemd на нескольких
платформах Linux. На этих платформах не устанавливается
mysqld_safe
, потому что не нужен. Для получения информации об использовании systemd,
чтобы обработать многократные экземпляры MySQL, см.
раздел 2.5.9.
Один путь запустить разные копии MySQL в Unix: скомпилировать различные
серверы с различными портами TCP/IP по умолчанию и файлами сокета Unix так,
чтобы каждый слушал на различных сетевых интерфейсах. Компиляция в различных
основных каталогах для каждой установки также приводит автоматически к
отдельному вкомпилированному каталогу данных, файлу журнала и расположению
файла PID для каждого сервера.
Предположите, что существующий сервер 5.7 сконфигурирован для
номера порта TCP/IP по умолчанию (3306) и файла сокета Unix
(/tmp/mysql.sock ). Чтобы сконфигурировать новый сервер 8.0.1,
чтобы иметь различные операционные параметры, используйте команду
CMake:
shell> cmake . -DMYSQL_TCP_PORT=port_number \
-DMYSQL_UNIX_ADDR=file_name \
-DCMAKE_INSTALL_PREFIX=/usr/local/mysql-8.0.1
Здесь port_number и file_name
должны отличаться от номера порта TCP/IP по умолчанию и имени пути к файлу
сокета Unix, а
CMAKE_INSTALL_PREFIX должно определить каталог установки,
отличающийся от того, в котором расположена существующая установка MySQL.
Если у вас есть сервер MySQL, слушающий на данном порту, можно
использовать следующую команду, чтобы узнать, какие операционные параметры
это использует для нескольких важных конфигурируемых переменных, включая
основной каталог и имя файла сокета Unix:
shell> mysqladmin --host=host_name --port=port_number variables
С информацией, выведенной на экран этой командой, можно сказать, какие
значения опции не использовать,
конфигурируя дополнительный сервер.
Если вы определяете localhost как имя хоста,
mysqladmin
по умолчанию применяет сокет Unix вместо TCP/IP.
Чтобы явно определить протокол подключения, используйте опцию
--protocol={TCP|SOCKET|PIPE|MEMORY} .
Вы не должны компилировать новый сервер MySQL только чтобы запуститься с
иным файлом сокета Unix и номером порта TCP/IP. Также возможно использовать
тот же самый двоичный файл сервера и запустить каждый экземпляр с различными
значениями параметра во время выполнения. Один способ сделать так при помощи
параметров командной строки:
shell> mysqld_safe --socket=file_name --port=port_number
Чтобы запустить второй сервер, обеспечьте отличающиеся опции
--socket и
--port и
передайте --datadir=
dir_name в
mysqld_safe, чтобы сервер использовал
отличный каталог данных.
Альтернативно, поместите опции для каждого сервера в ином файле опций,
затем запустите каждый сервер, используя
--defaults-file
, которая определяет путь к файлу подходящего варианта. Например,
если файлы опции для двух экземпляров сервера называются
/usr/local/mysql/my.cnf и
/usr/local/mysql/my.cnf2 , запустите серверы так:
shell> mysqld_safe --defaults-file=/usr/local/mysql/my.cnf
shell> mysqld_safe --defaults-file=/usr/local/mysql/my.cnf2
Другой способ достигнуть подобного эффекта состоит в том, чтобы
использовать переменные окружения, чтобы установить имя файла сокета Unix и
номер порта TCP/IP:
shell> MYSQL_UNIX_PORT=/tmp/mysqld-new.sock
shell> MYSQL_TCP_PORT=3307
shell> export MYSQL_UNIX_PORT MYSQL_TCP_PORT
shell> bin/mysqld --initialize --user=mysql
shell> mysqld_safe --datadir=/path/to/datadir &
Это быстрый способ запустить второй сервер, чтобы использовать для
тестирования. Хорошая вещь этого метода состоит в том, что настройки
переменной окружения относятся к любым клиентским программам, которые вы
вызываете от той же самой оболочки. Таким образом, соединения для тех
клиентов автоматически направлены к второму серверу.
Раздел 5.9
включает список других переменных окружения, которые можно использовать,
чтобы затронуть программы MySQL.
В Unix скрипт
mysqld_multi обеспечивает другой способ запустить
многократные серверы. См.
раздел 5.3.4.
6.7.4.
Использование клиентских программ в многосерверной среде
Чтобы соединиться клиентской программой с сервером MySQL, который слушает
различные сетевые интерфейсы, можно использовать один из следующих методов:
Запустите клиент с опциями
--host=host_name
и
--port=port_number , чтобы подключиться
к удаленному серверу с использованием TCP/IP. Запустите клиент с опциями
--host=127.0.0.1
и --port=
port_number , чтобы подключиться к локальному серверу
с использованием TCP/IP или с опциями
--host=localhost
и --socket=
file_name , чтобы соединиться с локальным сервером,
используя файл сокета Unix или именованный канал Windows.
- Запустите клиент с опцией
--protocol=TCP
, чтобы соединиться с использованием TCP/IP,
--protocol=SOCKET
, чтобы соединиться с использованием файла сокета Unix,
--protocol=PIPE
, чтобы соединиться с использованием именованного канала или
--protocol=MEMORY
, чтобы соединиться с использованием общей памяти.
Для соединений TCP/IP вы, возможно, также должны определить
--host и
--port .
Для других типов соединений вы, возможно, должны определить
--socket ,
чтобы определить имя файла Unix или именованного канала Windows, или
--shared-memory-base-name , чтобы определить имя общей памяти.
Сопряжения с общей памятью поддерживаются только в Windows.
- В Unix примените переменные окружения
MYSQL_UNIX_PORT и
MYSQL_TCP_PORT , чтобы указать на файл сокета Unix и номер порта
TCP/IP, прежде чем вы запустите свои клиенты. Если вы обычно используете
определенное имя сокета или номер порта, можно поместить команды, чтобы
установить эти переменные окружения в вашем файле .login
так, чтобы они применялись каждый раз, когда вы входите в систему. Посмотрите
раздел 5.9.
- Определите файл сокета Unix по умолчанию и номер порта TCP/IP в группе
[client] файла опции. Например, можно использовать
C:\my.cnf в Windows и .my.cnf
в вашем корневом каталоге в Unix. См.
раздел 5.2.6.
- В программе C можно определить файл сокета или номер порта в
mysql_real_connect()
. У вас могут также быть использованы файлы опции программы, вызывая
mysql_options() . См.
раздел 25.8.7.
- При использовании Perl
DBD::mysql
можно считать опции из файлов опции MySQL. Например:
$dsn = "DBI:mysql:test;mysql_read_default_group=client;"
. "mysql_read_default_file=/usr/local/mysql/data/my.cnf";
$dbh = DBI->connect($dsn, $user, $password);
См. раздел 25.10.
Другие интерфейсы программирования могут обеспечить подобные возможности
чтения файлов опции.
6.8. Трассировка mysqld, используя DTrace
Зонды DTrace в сервере MySQL разработаны, чтобы предоставить информацию о
выполнении запросов в пределах MySQL и различных областей системы,
используемой во время процесса. Организация и инициирование зондов
подразумевают, что выполнение всего запроса может контролироваться с одним
уровнем зондов (query-start и query-done ),
но контролируя другие зонды можно получить последовательно более подробную
информацию о выполнении запроса с точки зрения используемых блокировок,
методов сортировки и даже строк и информации о выполнении
уровня механизма хранения.
Зонды DTrace организованы так, чтобы можно было следовать за всем
процессом запроса, от точки соединения клиента, посредством выполнения
запросов и операций уровня строки. Можно думать о зондах, как запускаемых в
пределах определенной последовательности во время типичной клиентской
последовательности соединяется/выполняет/разъединяется, как показано
на следующей картинке.
Рис. 6.1.
MySQL использует подключаемые механизмы хранения
Глобальная информация предоставляется в параметрах зондам DTrace на
различных уровнях. Глобальная информация, то есть ID соединения и
пользователь/узел и релевантная строка запроса предоставляется на ключевых
уровнях (connection-start ,
command-start , query-start и
query-exec-start ). Поскольку вы идете глубже в зонды, это
выдает любые сведения, которыми вы только интересуетесь (зонды уровня строки
предоставляют информацию только об имени базы данных и имени таблицы), или
если вы объедините зонды уровня строки с отвлеченными родительскими зондами,
чтобы предоставить информацию об определенном запросе. Примеры этого будут
даны как формат и параметры для каждого зонда.
MySQL включает поддержку зондов DTrace на этих платформах:
Включение зондов должно быть автоматическим на этих платформах.
Чтобы явно включить или отключить зонды во время сборки, используйте опции
-DENABLE_DTRACE=1
или
-DENABLE_DTRACE=0 для CMake.
Если платформа не-Solaris будет включать поддержку DTrace, то создание
mysqld
на этой платформе будет включать поддержку DTrace.
Дополнительные ресурсы
6.8.1. Обзор зондов mysqld DTrace
MySQL поддерживает следующие статические зонды,
организованные в группы функциональности.
Таблица 6.5. Зонды MySQL DTrace
Группа | Зонды |
Connection | connection-start ,
connection-done |
Command
| command-start , command-done |
Query |
query-start , query-done |
Query
Parsing | query-parse-start ,
query-parse-done |
Query
Cache | query-cache-hit , query-cache-miss
|
Query
Execution | query-exec-start , query-exec-done
|
Row Level
| insert-row-start , insert-row-done |
| update-row-start ,
update-row-done |
| delete-row-start ,
delete-row-done |
Row Reads
| read-row-start , read-row-done |
Index Reads
| index-read-row-start ,
index-read-row-done |
Lock |
handler-rdlock-start ,
handler-rdlock-done |
| handler-wrlock-start ,
handler-wrlock-done |
| handler-unlock-start ,
handler-unlock-done |
Filesort
| filesort-start , filesort-done |
Statement
| select-start , select-done |
| insert-start , insert-done
|
| insert-select-start ,
insert-select-done |
| update-start ,
update-done |
| multi-update-start ,
multi-update-done |
| delete-start ,
delete-done |
| multi-delete-start ,
multi-delete-done |
Network
| net-read-start , net-read-done ,
net-write-start , net-write-done |
Keycache | keycache-read-start ,
keycache-read-block , keycache-read-done ,
keycache-read-hit , keycache-read-miss ,
keycache-write-start , keycache-write-block ,
keycache-write-done |
Извлекая данные параметра из зондов, каждый параметр доступен как
argN , начиная с arg0 .
Чтобы определить каждый параметр в рамках определений, им предоставляют
описательное имя, но необходимо получить доступ к информации, используя
соответствующий параметр argN .
6.8.1.1. Зонды соединения
Зонды connection-start и connection-done
отслеживают соединение клиента, независимо от того, выполнено ли соединение
посредством сокетного или сетевого соединения.
connection-start(connectionid, user, host)
connection-done(status, connectionid)
connection-start : Инициирован после того, как
соединение и успешный вход в систему/аутентификация были завершены клиентом.
Параметры содержат информацию о соединении:
connection-done : Инициирован когда соединение с клиентом
было закрыто. Параметры:
Следующий D-скрипт будет определять количество и суммировать среднюю
продолжительность конкретных соединений, выводя информацию каждые 60 секунд:
#!/usr/sbin/dtrace -s
mysql*:::connection-start
{
self->start = timestamp;
}
mysql*:::connection-done
/self->start/
{
@ = quantize(((timestamp - self->start)/1000000));
self->start = 0;
}
tick-60s
{
printa(@);
}
Когда выполняется на сервере с большим количеством клиентов вы могли бы
видеть примерно такой вывод:
1 57413:tick-60s
value ------------- Distribution ------------- count
-1 | 0
0 |@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ 30011
1 | 59
2 | 5
4 | 20
8 | 29
16 | 18
32 | 27
64 | 30
128 | 11
256 | 10
512 | 1
1024 | 6
2048 | 8
4096 | 9
8192 | 8
16384 | 2
32768 | 1
65536 | 1
131072 | 0
262144 | 1
524288 | 0
6.8.1.2. Зонды команды
Зонды команды выполняются, прежде и после того, как клиентская команда
выполняется, включая любой SQL-оператор, который мог бы быть выполнен в
течение того периода. Команды включают операции, такие как инициализация DB,
использование COM_CHANGE_USER (поддержано протоколом MySQL) и
манипуляция подготовленными операторами. Многие из этих команд используются
только клиентским API MySQL от различных коннекторов, таких как PHP и Java.
command-start(connectionid, command, user, host)
command-done(status)
command-start : Инициирован, когда
команда представлена серверу.
connectionid :
ID соединения клиента, выполняющего команду.
command : Целое число, представляющее команду, которая
выполнялась. Возможные значения показывают в следующей таблице.
Значение | Имя |
Описание |
00 | COM_SLEEP |
Внутреннее состояние потока |
01 | COM_QUIT | Закрыть соединение |
02 | COM_INIT_DB | Выберите базу данных
(USE ... ) |
03 | COM_QUERY | Выполните запрос |
04 | COM_FIELD_LIST |
Список полей |
05 | COM_CREATE_DB |
Создайте базу данных (устарела) |
06 | COM_DROP_DB |
Удалить базу данных (устарела) |
07 | COM_REFRESH |
Соединение обновления |
08 | COM_SHUTDOWN |
Завершение работы |
09 | COM_STATISTICS |
Получите статистику |
10 | COM_PROCESS_INFO |
Получите процессы (SHOW PROCESSLIST
) |
11 | COM_CONNECT |
Инициализируйте соединение |
12 | COM_PROCESS_KILL |
Уничтожьте процесс |
13 | COM_DEBUG |
Получите отладочную информацию |
14 | COM_PING | Ping |
15 | COM_TIME |
Внутреннее состояние потока |
16 | COM_DELAYED_INSERT |
Внутреннее состояние потока |
17 | COM_CHANGE_USER |
Сменить пользователя |
18 | COM_BINLOG_DUMP |
Используется ведомой системой или
mysqlbinlog, чтобы инициировать
чтение двоичного журнала |
19 | COM_TABLE_DUMP |
Используется ведомой системой, чтобы получить основную табличную информацию
|
20 | COM_CONNECT_OUT |
Используется ведомой системой, чтобы зарегистрировать соединение с сервером
|
21 | COM_REGISTER_SLAVE |
Используется ведомой системой во время регистрации |
22 | COM_STMT_PREPARE |
Подготовьте оператор |
23 | COM_STMT_EXECUTE |
Выполните оператор |
24 | COM_STMT_SEND_LONG_DATA |
Используется клиентом, запрашивая расширенные данные |
25 | COM_STMT_CLOSE |
ЯЗакройте подготовленный оператор |
26 | COM_STMT_RESET |
Сбросьте подготовленный оператор |
27 | COM_SET_OPTION |
Установите параметр сервера |
28 | COM_STMT_FETCH |
Выберите подготовленный оператор |
user : Пользователь, выполняющий команду.
host : Хост клиента.
command-done : Инициирован, когда выполнение команды
завершается. status содержит 0, если команда выполнилась
успешно, или 1, если оператор был завершен перед нормальным завершением.
Зонды command-start и command-done
лучше всего используются, когда объединены с зондами оператора, чтобы понять
полное время выполнения.
6.8.1.3. Зонды запроса
Зонды query-start и query-done
инициированы, когда определенный запрос получен сервером и когда запрос был
завершен, а информация была успешно отправлена клиенту.
query-start(query, connectionid, database, user, host)
query-done(status)
query-start : Инициирован после того, как строка
запроса была получена от клиента. Параметры:
query-done : Инициирован, как только запрос был выполнен,
и информация была возвращена клиенту. Зонд включает отдельный аргумент,
status , который возвращает 0, когда запрос успешно выполняется и
1, если была ошибка.
Можно получить простой отчет о времени выполнения для каждого запроса,
используя следующий скрипт:
#!/usr/sbin/dtrace -s
#pragma D option quiet
dtrace:::BEGIN
{
printf("%-20s %-20s %-40s %-9s\n", "Who", "Database", "Query", "Time(ms)");
}
mysql*:::query-start
{
self->query = copyinstr(arg0);
self->connid = arg1;
self->db= copyinstr(arg2);
self->who = strjoin(copyinstr(arg3),strjoin("@",copyinstr(arg4)));
self->querystart = timestamp;
}
mysql*:::query-done
{
printf("%-20s %-20s %-40s %-9d\n",self->who,self->db,
self->query, (timestamp - self->querystart) / 1000000);
}
Выполняя вышеупомянутый скрипт необходимо получить общее представление о
времени выполнения запросов:
shell> ./query.d
WhoDatabase QueryTime(ms)
root@localhost test select * from t1 order by i limit 10 0
root@localhost test set global query_cache_size=00
root@localhost test select * from t1 order by i limit 10 776
root@localhost test select * from t1 order by i limit 10 773
root@localhost test select * from t1 order by i desc limit 10 795
6.8.1.4.
Зонды анализа запроса
Зонды анализа запроса инициированы, прежде чем исходный SQL-оператор
анализируется и когда парсинг оператора и определение модели выполнения,
требуемой, чтобы обработать оператор, были завершены:
query-parse-start(query)
query-parse-done(status)
Например, вы могли контролировать время выполнения для парсинга данного
запроса, используя следующий скрипт:
#!/usr/sbin/dtrace -s
#pragma D option quiet
mysql*:::query-parse-start
{
self->parsestart = timestamp;
self->parsequery = copyinstr(arg0);
}
mysql*:::query-parse-done
/arg0 == 0/
{
printf("Parsing %s: %d microseconds\n", self->parsequery,
((timestamp - self->parsestart)/1000));
}
mysql*:::query-parse-done
/arg0 != 0/
{
printf("Error parsing %s: %d microseconds\n",
self->parsequery,((timestamp - self->parsestart)/1000));
}
В вышеупомянутом скрипте предикат используется в
query-parse-done , чтобы различный вывод был произведен,
основываясь на значении состояния зонда.
Выполняя скрипт и контролируя выполнение будет вот что:
shell> ./query-parsing.d
Error parsing select from t1 join (t2) on (t1.i = t2.i) order by t1.s,t1.i
limit 10: 36 ms
Parsing select * from t1 join (t2) on (t1.i = t2.i) order by t1.s,t1.i
limit 10: 176 ms
6.8.1.5. Зонды кэша запроса
Зонды кэша запроса запущены, выполняя любой запрос.
query-cache-hit инициирован, когда запрос существует в кэше
запроса и может использоваться, чтобы возвратить информацию о кэше запроса.
Параметры содержат текст исходного запроса и число строк, возвращенных из
кэша запроса для запроса. Если запрос не в пределах кэша запроса, или кэш
запроса не включен, то вместо этого инициирован query-cache-miss
.
query-cache-hit(query, rows)
query-cache-miss(query)
query-cache-hit : Инициирован, когда запрос в пределах
кэша запроса. Первый параметр query содержит оригинальный текст
запроса. Второй параметр rows целое число, содержащее число
строк в кэшируемом запросе.
query-cache-miss : Инициирован, когда запрос не найден в
пределах кэша запроса. Первый параметр query
содержит оригинальный текст запроса.
Зонды кэша запроса лучше всего объединены с зондом на главном запросе так,
чтобы можно было определить различия во времени между использованием или не
использованием кэша запроса для указанных запросов. Например, в следующем
скрипте информация о кэше запроса и запроса объединена в вывод информации
во время контроля:
#!/usr/sbin/dtrace -s
#pragma D option quiet
dtrace:::BEGIN
{
printf("%-20s %-20s %-40s %2s %-9s\n", "Who", "Database", "Query",
"QC", "Time(ms)");
}
mysql*:::query-start
{
self->query = copyinstr(arg0);
self->connid = arg1;
self->db= copyinstr(arg2);
self->who = strjoin(copyinstr(arg3),strjoin("@",copyinstr(arg4)));
self->querystart = timestamp;
self->qc = 0;
}
mysql*:::query-cache-hit
{
self->qc = 1;
}
mysql*:::query-cache-miss
{
self->qc = 0;
}
mysql*:::query-done
{
printf("%-20s %-20s %-40s %-2s %-9d\n",self->who,self->db,
self->query,(self->qc ? "Y" : "N"),
(timestamp - self->querystart) / 1000000);
}
Выполняя скрипт, вы видите эффект кэша запроса. Первоначально кэш запроса
отключен. Если вы устанавливаете размер кэша запроса и затем выполняете
запрос многократно, видно, что кэш запроса используется, чтобы
возвратить данные запроса:
shell> ./query-cache.d
root@localhost test select * from t1 order by i limit 10 N 1072
root@localhostset global query_cache_size=262144 N 0
root@localhost test select * from t1 order by i limit 10 N 781
root@localhost test select * from t1 order by i limit 10 Y 0
6.8.1.6. Зонды выполнения запросов
Зонд выполнения запросов инициирован, когда фактическое выполнение запроса
запускается после парсинга и проверки кэша запроса, но перед любыми
проверками полномочий или оптимизацией. Сравнивая различие между запуском и
сделанными зондами можно контролировать время, фактически потраченное на
обслуживание запроса (вместо того, чтобы просто обработать парсинг и
другие элементы запроса).
query-exec-start(query, connectionid, database, user, host, exec_type)
query-exec-done(status)
Информация, предоставленная в параметрах для
query-start и query-exec-start
почти идентична и разработана так, чтобы можно было контролировать любой
процесс запроса целиком (используя query-start ) или только
выполнение (query-exec-start ), представляя базовую информацию о
пользователе, клиенте и выполняемом запросе.
query-exec-start : Инициирован, когда выполнение
отдельного запроса запускается. Параметры:
query-exec-done : Инициирован, когда выполнение запроса
завершилось. Зонд включает аргумент status , который возвращает
0, когда запрос успешно выполняется и 1, если была ошибка.
6.8.1.7. Зонды уровня строки
Зонды *row-{start,done} инициированы каждый раз, когда
операция по строке передана механизму хранения. Например, если вы выполняете
INSERT для 100 строк, то
insert-row-start и insert-row-done будут
инициированы 100 раз каждый, когда каждая строка вставляется.
insert-row-start(database, table)
insert-row-done(status)
update-row-start(database, table)
update-row-done(status)
delete-row-start(database, table)
delete-row-done(status)
Параметры, поддержанные зондами, последовательны для зондов
start и done в каждом случае:
Поскольку зонды уровня строки инициированы для каждого отдельного доступа
к строке, эти зонды могут быть инициированы много тысяч раз каждую секунду,
что может иметь неблагоприятный эффект на контролирующий скрипт и на MySQL.
Окружающая среда DTrace должна ограничить инициирование на этих зондах, чтобы
предотвратить оказываемое негативное влияние на работу. Используйте зонды
экономно или используйте счетчик или агрегатные функции, чтобы сообщить
данные относительно этих зондов и затем предоставить сводку, когда скрипт
завершится или как часть зондов query-done или
query-exec-done .
Следующий скрипт в качестве примера суммирует продолжительность каждой
операции по строке в пределах большего запроса:
#!/usr/sbin/dtrace -s
#pragma D option quiet
dtrace:::BEGIN
{
printf("%-2s %-10s %-10s %9s %9s %-s \n",
"St", "Who", "DB", "ConnID", "Dur ms", "Query");
}
mysql*:::query-start
{
self->query = copyinstr(arg0);
self->who = strjoin(copyinstr(arg3),strjoin("@",copyinstr(arg4)));
self->db = copyinstr(arg2);
self->connid = arg1;
self->querystart = timestamp;
self->rowdur = 0;
}
mysql*:::query-done
{
this->elapsed = (timestamp - self->querystart) /1000000;
printf("%2d %-10s %-10s %9d %9d %s\n", arg0, self->who, self->db,
self->connid, this->elapsed, self->query);
}
mysql*:::query-done
/ self->rowdur /
{
printf("%34s %9d %s\n", "", (self->rowdur/1000000), "-> Row ops");
}
mysql*:::insert-row-start
{
self->rowstart = timestamp;
}
mysql*:::delete-row-start
{
self->rowstart = timestamp;
}
mysql*:::update-row-start
{
self->rowstart = timestamp;
}
mysql*:::insert-row-done
{
self->rowdur += (timestamp-self->rowstart);
}
mysql*:::delete-row-done
{
self->rowdur += (timestamp-self->rowstart);
}
mysql*:::update-row-done
{
self->rowdur += (timestamp-self->rowstart);
}
Выполняя вышеупомянутый скрипт с запросом, который вставляет данные в
таблицу, можно контролировать точное время на выполнение
необработанной вставки строки:
St Who DBConn ID Dur ms Query
0 @localhost test 13 20767 insert into t1(select * from t2)
4827 -> Row ops
6.8.1.8. Зонды чтения строк
Зонды чтения строк инициированы на уровне механизма хранения каждый раз,
когда операция чтения строки происходит. Эти зонды определяются в пределах
каждого механизма хранения (в противоположность *row-start ,
которые находятся в интерфейсе механизма хранения). Эти зонды могут поэтому
использоваться, чтобы контролировать отдельные операции уровня строки
механизма хранения. Поскольку эти зонды инициированы в интерфейсе чтения
строки механизма хранения, они могут быть вызваны значительное количество
раз во время основного запроса.
read-row-start(database, table, scan_flag)
read-row-done(status)
read-row-start : Инициирован, когда строка читается
механизмом хранения из указанных database и table .
scan_flag установлен в 1 (true), когда чтение часть сканирования
таблицы (то есть, последовательное чтение), или 0 (false), когда
читается отдельная запись.
read-row-done : Инициирован, когда операция чтения строки в
пределах механизма хранения завершается. status вернет 0 при
успехе или положительное значение при неудаче.
6.8.1.9. Индексные зонды
Индексные зонды инициированы каждый раз, когда строка читается, используя
один из индексов для указанной таблицы. Зонд инициирован в пределах
соответствующего механизма хранения для таблицы.
index-read-row-start(database, table)
index-read-row-done(status)
6.8.1.10. Зонды блокировки
Зонды блокировки вызываются каждый раз, когда внешнюю блокировку требует
MySQL на таблицу, используя соответствующий механизм блокировки на таблице,
как определено типом механизма таблицы. Есть три различных типа блокировки:
блокировки чтения, блокировку записи и снятие блокировок. Используя зонды
можно определить продолжительность внешней подпрограммы блокировки (то есть,
время, потраченное механизмом хранения, чтобы реализовать блокировку, включая
любое время ожидания другой блокировки) и полную продолжительность
процесса блокировки/разблокировки.
handler-rdlock-start(database, table)
handler-rdlock-done(status)
handler-wrlock-start(database, table)
handler-wrlock-done(status)
handler-unlock-start(database, table)
handler-unlock-done(status)
Можно использовать массивы, чтобы контролировать блокировку отдельных
таблиц и затем вычислить продолжительность всей блокировки таблицы,
используя следующий скрипт:
#!/usr/sbin/dtrace -s
#pragma D option quiet
mysql*:::handler-rdlock-start
{
self->rdlockstart = timestamp;
this->lockref = strjoin(copyinstr(arg0),strjoin("@",copyinstr(arg1)));
self->lockmap[this->lockref] = self->rdlockstart;
printf("Start: Lock->Read %s.%s\n",copyinstr(arg0),copyinstr(arg1));
}
mysql*:::handler-wrlock-start
{
self->wrlockstart = timestamp;
this->lockref = strjoin(copyinstr(arg0),strjoin("@",copyinstr(arg1)));
self->lockmap[this->lockref] = self->rdlockstart;
printf("Start: Lock->Write %s.%s\n",copyinstr(arg0),copyinstr(arg1));
}
mysql*:::handler-unlock-start
{
self->unlockstart = timestamp;
this->lockref = strjoin(copyinstr(arg0),strjoin("@",copyinstr(arg1)));
printf("Start: Lock->Unlock %s.%s (%d ms lock duration)\n",
copyinstr(arg0),copyinstr(arg1),
(timestamp - self->lockmap[this->lockref])/1000000);
}
mysql*:::handler-rdlock-done
{
printf("End: Lock->Read %d ms\n",
(timestamp - self->rdlockstart)/1000000);
}
mysql*:::handler-wrlock-done
{
printf("End: Lock->Write %d ms\n",
(timestamp - self->wrlockstart)/1000000);
}
mysql*:::handler-unlock-done
{
printf("End: Lock->Unlock %d ms\n",
(timestamp - self->unlockstart)/1000000);
}
Когда выполняется, необходимо получить информацию о продолжительности
самого процесса блокировки, и блокировок на определенной таблице:
Start: Lock->Read test.t2
End: Lock->Read 0 ms
Start: Lock->Unlock test.t2 (25743 ms lock duration)
End: Lock->Unlock 0 ms
Start: Lock->Read test.t2
End: Lock->Read 0 ms
Start: Lock->Unlock test.t2 (1 ms lock duration)
End: Lock->Unlock 0 ms
Start: Lock->Read test.t2
End: Lock->Read 0 ms
Start: Lock->Unlock test.t2 (1 ms lock duration)
End: Lock->Unlock 0 ms
Start: Lock->Read test.t2
End: Lock->Read 0 ms
6.8.1.11. Зонды сортировки
Зонды сортировки инициированы каждый раз, когда операция filesort
применяется к таблице. Для получения дополнительной информации о filesort и
условиях, при которых это происходит см.
раздел 9.2.1.15.
filesort-start(database, table)
filesort-done(status, rows)
Пример этого находится в следующем скрипте, который отслеживает
продолжительность процесса filesort в дополнение к
продолжительности главного запроса:
#!/usr/sbin/dtrace -s
#pragma D option quiet
dtrace:::BEGIN
{
printf("%-2s %-10s %-10s %9s %18s %-s \n",
"St", "Who", "DB", "ConnID", "Dur microsec", "Query");
}
mysql*:::query-start
{
self->query = copyinstr(arg0);
self->who = strjoin(copyinstr(arg3),strjoin("@",copyinstr(arg4)));
self->db = copyinstr(arg2);
self->connid = arg1;
self->querystart = timestamp;
self->filesort = 0;
self->fsdb = "";
self->fstable = "";
}
mysql*:::filesort-start
{
self->filesort = timestamp;
self->fsdb = copyinstr(arg0);
self->fstable = copyinstr(arg1);
}
mysql*:::filesort-done
{
this->elapsed = (timestamp - self->filesort) /1000;
printf("%2d %-10s %-10s %9d %18d Filesort on %s\n",
arg0, self->who, self->fsdb,
self->connid, this->elapsed, self->fstable);
}
mysql*:::query-done
{
this->elapsed = (timestamp - self->querystart) /1000;
printf("%2d %-10s %-10s %9d %18d %s\n",
arg0, self->who, self->db,
self->connid, this->elapsed, self->query);
}
Выполнение запроса на большой таблице с ORDER BY , который
инициировал filesort и затем создание индекса на таблице c повторением того
же самого запроса, вы видите различие в скорости выполнения:
St Who DB ConnID Dur microsec Query
0 @localhost test 14 11335469 Filesort on t1
0 @localhost test 14 11335787 select * from t1 order by i limit 100
0 @localhost test 14 466734378 create index t1a on t1 (i)
0 @localhost test 14 26472 select * from t1 order by i limit 100
6.8.1.12. Зонды оператора
Отдельные зонды оператора обеспечиваются, чтобы дать определенную
информацию о различных типах оператора. Для запуска строка запроса
обеспечиваются как единственный параметр. В зависимости от типа оператора,
будет отличаться информация, предоставленная соответствующим зондом. Для всех
зондов состояние операции (0 для успеха, >0 для
неудачи), обеспечивается. Для
SELECT ,
INSERT ,
INSERT ... (SELECT FROM ...) ,
DELETE и
DELETE FROM t1,t2
число затронутых строк возвращается.
Для UPDATE и
UPDATE t1,t2 ...
число подобранных строк и число строк, фактически измененных, обеспечиваются.
Это потому, что число строк, фактически подобранных передачей
WHERE , и число измененных строк могут отличаться. MySQL не
обновляет значение строки, если значение уже соответствует новой установке.
select-start(query)
select-done(status,rows)
insert-start(query)
insert-done(status,rows)
insert-select-start(query)
insert-select-done(status,rows)
update-start(query)
update-done(status,rowsmatched,rowschanged)
multi-update-start(query)
multi-update-done(status,rowsmatched,rowschanged)
delete-start(query)
delete-done(status,rows)
multi-delete-start(query)
multi-delete-done(status,rows)
Параметры для зондов оператора:
query : Строка запроса.
status : Состояние запроса. 0 для успеха и
>0 для неудачи.
rows : Число строк затронуто оператором. Это возвращает
число строк, найденных для SELECT ,
число строк, удаленных DELETE
и число строк, успешно вставленных
INSERT .
rowsmatched : Число строк, подобранных WHERE в
UPDATE .
rowschanged : Число строк, фактически измененных во время
UPDATE .
Вы используете эти зонды, чтобы контролировать выполнение этих типов
оператора, не имея необходимость контролировать пользователя или клиент,
выполняющий операторы. Простой пример этого должен
отследить времена выполнения:
#!/usr/sbin/dtrace -s
#pragma D option quiet
dtrace:::BEGIN
{
printf("%-60s %-8s %-8s %-8s\n", "Query", "RowsU", "RowsM", "Dur (ms)");
}
mysql*:::update-start, mysql*:::insert-start,
mysql*:::delete-start, mysql*:::multi-delete-start,
mysql*:::multi-delete-done, mysql*:::select-start,
mysql*:::insert-select-start, mysql*:::multi-update-start
{
self->query = copyinstr(arg0);
self->querystart = timestamp;
}
mysql*:::insert-done, mysql*:::select-done,
mysql*:::delete-done, mysql*:::multi-delete-done, mysql*:::insert-select-done
/ self->querystart /
{
this->elapsed = ((timestamp - self->querystart)/1000000);
printf("%-60s %-8d %-8d %d\n", self->query, 0, arg1, this->elapsed);
self->querystart = 0;
}
mysql*:::update-done, mysql*:::multi-update-done
/ self->querystart /
{
this->elapsed = ((timestamp - self->querystart)/1000000);
printf("%-60s %-8d %-8d %d\n", self->query, arg1, arg2,
this->elapsed);
self->querystart = 0;
}
Когда выполняется вы видите основные времена
выполнения и соответствия строк:
QueryRowsURowsMDur (ms)
select * from t2 02750
insert into t2 (select * from t2)02759
update t2 set i=5 where i > 75 1101108
update t2 set i=5 where i < 25 25413412
delete from t2 where i < 5 000
Другая альтернатива должна использовать агрегатные функции в
DTrace, чтобы соединить время выполнения отдельных операторов вместе:
#!/usr/sbin/dtrace -s
#pragma D option quiet
mysql*:::update-start, mysql*:::insert-start,
mysql*:::delete-start, mysql*:::multi-delete-start,
mysql*:::multi-delete-done, mysql*:::select-start,
mysql*:::insert-select-start, mysql*:::multi-update-start
{
self->querystart = timestamp;
}
mysql*:::select-done
{
@statements["select"] = sum(((timestamp - self->querystart)/1000000));
}
mysql*:::insert-done, mysql*:::insert-select-done
{
@statements["insert"] = sum(((timestamp - self->querystart)/1000000));
}
mysql*:::update-done, mysql*:::multi-update-done
{
@statements["update"] = sum(((timestamp - self->querystart)/1000000));
}
mysql*:::delete-done, mysql*:::multi-delete-done
{
@statements["delete"] = sum(((timestamp - self->querystart)/1000000));
}
tick-30s
{
printa(@statements);
}
Скрипт соединяет времена, потраченные на выполнение каждой операции,
которая могла использоваться, чтобы помочь тестировать стандартный комплект
в сравнении с эталоном тестов.
delete 0
update 0
insert 23
select 2484
delete 0
update 0
insert 39
select 10744
delete 0
update 26
insert 56
select 10944
delete 0
update 26
insert 2287
select 15985
6.8.1.13. Сетевые зонды
Сетевые зонды контролируют передачу информации от сервера MySQL и клиентов
всех типов по сети. Зонды определяются следующим образом:
net-read-start()
net-read-done(status, bytes)
net-write-start(bytes)
net-write-done(status)
Можно использовать сетевые зонды, чтобы контролировать время,
потраченное на чтение и запись в сетевых клиентах во время выполнения.
Следующий скрипт обеспечивает пример этого. Совокупное время для чтения или
записи вычисляется и число байтов. Обратите внимание на то, что размер
динамической переменной был увеличен (с использованием опции
dynvarsize ), чтобы справляться с быстрым ростом данных
для сетевых чтений/записей.
#!/usr/sbin/dtrace -s
#pragma D option quiet
#pragma D option dynvarsize=4m
dtrace:::BEGIN
{
printf("%-2s %-30s %-10s %9s %18s %-s \n",
"St", "Who", "DB", "ConnID", "Dur microsec", "Query");
}
mysql*:::query-start
{
self->query = copyinstr(arg0);
self->who = strjoin(copyinstr(arg3),strjoin("@",copyinstr(arg4)));
self->db = copyinstr(arg2);
self->connid = arg1;
self->querystart = timestamp;
self->netwrite = 0;
self->netwritecum = 0;
self->netwritebase = 0;
self->netread = 0;
self->netreadcum = 0;
self->netreadbase = 0;
}
mysql*:::net-write-start
{
self->netwrite += arg0;
self->netwritebase = timestamp;
}
mysql*:::net-write-done
{
self->netwritecum += (timestamp - self->netwritebase);
self->netwritebase = 0;
}
mysql*:::net-read-start
{
self->netreadbase = timestamp;
}
mysql*:::net-read-done
{
self->netread += arg1;
self->netreadcum += (timestamp - self->netreadbase);
self->netreadbase = 0;
}
mysql*:::query-done
{
this->elapsed = (timestamp - self->querystart) /1000000;
printf("%2d %-30s %-10s %9d %18d %s\n", arg0, self->who, self->db,
self->connid, this->elapsed, self->query);
printf("Net read: %d bytes (%d ms) write: %d bytes (%d ms)\n",
self->netread, (self->netreadcum/1000000),
self->netwrite, (self->netwritecum/1000000));
}
Выполняя вышеупомянутый скрипт на машине с удаленным клиентом, вы видите,
что приблизительно одна треть времени, проведенного, выполняя запрос, связана
с обратной записью результатов запроса клиенту.
St Who DB ConnID Dur microsec Query
0 root@::ffff:192.168.0.108 test 31 3495 select * from t1 limit 1000000
Net read: 0 bytes (0 ms) write: 10000075 bytes (1220 ms)
6.8.1.14. Зонды ключевого кэша
Зонды ключевого кэша инициированы, используя индексный ключевой кэш,
используемый с механизмом хранения MyISAM. Зонды существуют, чтобы
контролировать, когда данные считаны в кэш, ключевые данные записаны из кэша
в кэшируемый файл или получен доступ к кэшу.
Использование указывает, когда данные считаны или записаны из индексных
файлов в кэш и могут использоваться, чтобы контролировать, как эффективно
используется память, выделенная ключевому кэшу. Высокое число чтений через
диапазон запросов может указать, что слишком маленький для
размера получаемых данных.
keycache-read-start(filepath, bytes, mem_used, mem_free)
keycache-read-block(bytes)
keycache-read-hit()
keycache-read-miss()
keycache-read-done(mem_used, mem_free)
keycache-write-start(filepath, bytes, mem_used, mem_free)
keycache-write-block(bytes)
keycache-write-done(mem_used, mem_free)
Считывая данные из индексных файлов в кэш,
процесс сначала инициализирует операцию чтения (обозначенную
keycache-read-start ), затем загружает блоки данных
(keycache-read-block ) и читает блоки данных, определяемые
любым совпадением (keycache-read-hit )
или больше данных должно быть считано (keycache-read-miss ).
Как только операция чтения завершилась, чтение остановлено с
keycache-read-done .
Данные будут считаны из индексного файла в кэш только когда указанный
ключ уже не будет в пределах кэша.
keycache-read-start : Инициирован когда операция
чтения запускается. Данные считаны из указанного filepath ,
выполняется чтение конкретного количества bytes .
mem_used и mem_avail указывают на память, в
настоящее время используемую кэшем и объем памяти, доступный в кэше.
keycache-read-block : Инициирован когда кэш
читает блок данных конкретного количества bytes
из индексного файла.
keycache-read-hit : Инициирован когда блок данных, считанный
из индексного файла, соответствует ключевым запрошенным данным.
keycache-read-miss : Инициирован когда блок данных, считанный
из индексного файла, не соответствует необходимым ключевым данным.
keycache-read-done : Инициирован когда операция чтения
завершилась. mem_used и mem_avail
указывают на память, в настоящее время используемую кэшем и объем памяти,
доступный в пределах кэша.
Записи происходят, когда информация об индексе обновляется во время
INSERT , UPDATE или DELETE , и
кэшируемая ключевая информация сбрасывается назад к индексному файлу.
keycache-write-start : Инициирован когда
операция записи запускается. Данные записаны в указанный
filepath в количестве bytes . mem_used
и mem_avail указывают на память, в настоящее время используемую
кэшем и объем памяти, доступный в пределах кэша.
keycache-write-block : Инициирован когда кэш
пишет блок данных конкретного размера bytes к индексному файлу.
keycache-write-done : Инициирован когда операция записи
завершилась. mem_used и mem_avail
указывают на память, в настоящее время используемую
кэшем и объем памяти, доступный в пределах кэша.
|
|