daemon_memcached_enable_binlog

Включите этот параметр на исходном сервере, чтобы использовать плагин InnoDB memcached (daemon_memcached) с MySQL. Этот параметр можно установить только при запуске сервера. Необходимо также включить бинарный лог MySQL на исходном сервере, используя параметр --log-bin.

Для получения дополнительной информации см. Раздел 14.21.6, «Плагин InnoDB memcached и репликация».

daemon_memcached_engine_lib_name

Указывает общую библиотеку, которая реализует плагин InnoDB memcached.

Для получения дополнительной информации см. Раздел 14.21.3, «Настройка плагина InnoDB memcached».

daemon_memcached_engine_lib_path

Путь к каталогу, содержащему общую библиотеку, которая реализует плагин InnoDB memcached. Значение по умолчанию — NULL, представляющее каталог плагинов MySQL. Вам не нужно изменять этот параметр, если только вы не указываете плагин memcached для другого движка хранения, который находится за пределами каталога плагинов MySQL.

Для получения дополнительной информации см. Раздел 14.21.3, «Настройка плагина InnoDB memcached».

daemon_memcached_option

Используется для передачи параметров memcached, разделенных пробелами, базовому демону кэширования объектов памяти memcached при запуске. Например, можно изменить порт, который прослушивает memcached, уменьшить максимальное количество одновременных подключений, изменить максимальный размер памяти для пары ключ-значение или включить сообщения отладки для файла ошибок.

См. Раздел 14.21.3, «Настройка плагина InnoDB memcached» для получения подробных сведений об использовании. Для получения информации о параметрах memcached обратитесь к странице руководства memcached.

daemon_memcached_r_batch_size

Указывает, сколько операций чтения memcached (операции get) следует выполнить, прежде чем выполнить COMMIT для начала новой транзакции. Аналог daemon_memcached_w_batch_size.

Это значение по умолчанию равно 1, поэтому любые изменения, внесенные в таблицу с помощью операторов SQL, немедленно становятся видны для операций memcached. Можно увеличить это значение, чтобы уменьшить накладные расходы от частых фиксаций в системе, где доступ к базовой таблице осуществляется только через интерфейс memcached. Если установить слишком большое значение, объем данных отката или повтора может создать некоторые накладные расходы на хранение, как и любая длительная транзакция.

Для получения дополнительной информации см. Раздел 14.21.3, «Настройка плагина InnoDB memcached».

daemon_memcached_w_batch_size

Указывает, сколько операций записи memcached, таких как add, set и incr, следует выполнить, прежде чем выполнить COMMIT для начала новой транзакции. Аналог daemon_memcached_r_batch_size.

Это значение по умолчанию равно 1, исходя из предположения, что хранящиеся данные важно сохранить на случай сбоя и их следует немедленно зафиксировать. При хранении некритичных данных можно увеличить это значение, чтобы уменьшить накладные расходы от частых фиксаций; но тогда последние N-1 незафиксированных операций записи могут быть потеряны в случае неожиданного завершения работы.

Для получения дополнительной информации см. Раздел 14.21.3, «Настройка плагина InnoDB memcached».

ignore_builtin_innodb

В более ранних версиях MySQL включение этой переменной приводило к тому, что сервер вел себя так, как если бы встроенный InnoDB отсутствовал, что позволяло использовать InnoDB Plugin. В MySQL 5.7 InnoDB является движком хранения по умолчанию, и InnoDB Plugin не используется, поэтому эта переменная игнорируется.

innodb_adaptive_flushing

Указывает, следует ли динамически регулировать скорость очистки в InnoDB в зависимости от рабочей нагрузки. Динамическая регулировка скорости очистки предназначена для предотвращения всплесков активности ввода-вывода. Этот параметр включен по умолчанию. См. Раздел 14.8.3.5, «Настройка очистки буферного пула» для получения дополнительной информации. Для получения общих рекомендаций по настройке ввода-вывода см. Раздел 8.5.8, «Оптимизация ввода-вывода InnoDB на диск».

innodb_adaptive_flushing_lwm

Определяет нижнюю границу, представляющую процент от ёмкости, при котором включена. Для получения дополнительной информации см. Раздел 14.8.3.5, «Настройка очистки буферного пула».

innodb_adaptive_hash_index

Включён или выключен ли InnoDB. В зависимости от вашей рабочей нагрузки может быть желательно динамически включать или отключать для повышения производительности запросов. Поскольку адаптивный хеш-индекс может быть не полезен для всех рабочих нагрузок, проведите тесты с его включением и отключением, используя реальные рабочие нагрузки. См. Раздел 14.5.3, «Адаптивный хеш-индекс» для получения подробной информации.

Эта переменная включена по умолчанию. Вы можете изменить этот параметр, используя оператор SET GLOBAL, без перезапуска сервера. Изменение настройки во время работы требует прав, достаточных для установки глобальных системных переменных. См. Раздел 5.1.8.1, «Права на системные переменные». Вы также можете использовать --skip-innodb-adaptive-hash-index при запуске сервера, чтобы отключить его.

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

innodb_adaptive_hash_index_parts

Разделяет систему поиска адаптивного хеш-индекса. Каждый индекс привязан к определённому разделу, причём каждый раздел защищён отдельным затвором.

В более ранних выпусках система поиска адаптивного хеш-индекса защищалась одним затвором (btr_search_latch), который мог стать точкой конкуренции. С внедрением параметра innodb_adaptive_hash_index_parts система поиска по умолчанию разделена на 8 частей. Максимальное значение равно 512.

Для получения дополнительной информации см. Раздел 14.5.3, «Адаптивный хеш-индекс».

innodb_adaptive_max_sleep_delay

Позволяет InnoDB автоматически регулировать значение innodb_thread_sleep_delay вверх или вниз в зависимости от текущей рабочей нагрузки. Любое ненулевое значение включает автоматическую, динамическую настройку значения innodb_thread_sleep_delay вплоть до максимального значения, указанного в параметре innodb_adaptive_max_sleep_delay. Значение представляет собой количество микросекунд. Этот параметр может быть полезен в загруженных системах с более чем 16 потоками InnoDB. (На практике он наиболее ценен для систем MySQL с сотнями или тысячами одновременных подключений.)

Для получения дополнительной информации см. Раздел 14.8.5, «Настройка параллелизма потоков для InnoDB».

innodb_api_bk_commit_interval

Как часто выполнять автоматическую фиксацию неактивных соединений, использующих интерфейс InnoDB memcached, в секундах. Для получения дополнительной информации см. Раздел 14.21.5.4, «Управление поведением транзакций плагина InnoDB memcached».

innodb_api_disable_rowlock

Используйте этот параметр для отключения блокировок строк, когда InnoDB memcached выполняет операции DML. По умолчанию innodb_api_disable_rowlock отключен, это означает, что memcached запрашивает блокировки строк для операций get и set. Когда innodb_api_disable_rowlock включен, memcached запрашивает блокировку таблицы вместо блокировок строк.

innodb_api_disable_rowlock не является динамическим. Он должен быть указан в командной строке mysqld или введен в конфигурационный файл MySQL. Конфигурация вступает в силу при установке плагина, что происходит при запуске сервера MySQL.

Для получения дополнительной информации см. Раздел 14.21.5.4, «Управление поведением транзакций плагина InnoDB memcached».

innodb_api_enable_binlog

Позволяет использовать плагин InnoDB memcached с MySQL. Для получения дополнительной информации см. Включение двоичного журнала InnoDB memcached.

innodb_api_enable_mdl

Блокирует таблицу, используемую плагином memcached, так что она не может быть удалена или изменена через интерфейс SQL. Для получения дополнительной информации см. Раздел 14.21.5.4, «Управление поведением транзакций плагина InnoDB memcached».

innodb_api_trx_level

Управляет транзакциями запросов, обрабатываемых интерфейсом memcached. Константы, соответствующие известным именам:

Для получения дополнительной информации см. Раздел 14.21.5.4, «Управление поведением транзакций плагина InnoDB memcached».

innodb_autoextend_increment

Размер приращения (в мегабайтах) для увеличения размера файла автоматического расширения InnoDB при его заполнении. Значение по умолчанию равно 64. Для получения дополнительной информации см. Конфигурация данных файла системного табличного пространства и Изменение размера системного табличного пространства.

Настройка innodb_autoextend_increment не влияет на файлы табличного пространства или файлы. Эти файлы автоматически расширяются независимо от настройки innodb_autoextend_increment. Первоначальные расширения производятся небольшими объемами, после чего расширения происходят приращениями по 4 МБ.

innodb_autoinc_lock_mode

Режим, используемый для генерации значений. Допустимые значения: 0, 1 или 2, соответственно, традиционный, последовательный или чередующийся. Значение по умолчанию равно 1 (последовательный). Характеристики каждого режима блокировки см. в Режимах блокировки AUTO_INCREMENT InnoDB.

innodb_background_drop_list_empty

Включение параметра отладки innodb_background_drop_list_empty помогает избежать сбоев в тестовых сценариях, откладывая создание таблицы до тех пор, пока список отложенных удалений не станет пустым. Например, если тестовый сценарий A помещает таблицу t1 в список отложенных удалений, тестовый сценарий B ждет, пока список не станет пустым, прежде чем создать таблицу t1.

innodb_buffer_pool_chunk_size

innodb_buffer_pool_chunk_size определяет размер фрагмента для операций изменения размера буферного пула InnoDB.

Чтобы избежать копирования всех страниц буферного пула во время операций изменения размера, операция выполняется во фрагментах («chunks”). По умолчанию, innodb_buffer_pool_chunk_size составляет 128 МБ (134217728 байт). Количество страниц, содержащихся во фрагменте, зависит от значения innodb_page_size. innodb_buffer_pool_chunk_size можно увеличивать или уменьшать с шагом 1 МБ (1048576 байт).

При изменении значения innodb_buffer_pool_chunk_size применяются следующие условия:

Во избежание потенциальных проблем с производительностью, количество фрагментов (innodb_buffer_pool_size / innodb_buffer_pool_chunk_size) не должно превышать 1000.

Переменная innodb_buffer_pool_size является динамической, что позволяет изменять размер буферного пула во время работы сервера. Однако размер буферного пула должен быть равен или кратен innodb_buffer_pool_chunk_size * innodb_buffer_pool_instances, и изменение любой из этих настроек переменных требует перезапуска сервера.

Для получения дополнительной информации см. Раздел 14.8.3.1, «Настройка размера буферного пула InnoDB».

innodb_buffer_pool_dump_at_shutdown

Указывает, следует ли записывать страницы, кэшированные в InnoDB, при выключении сервера MySQL, чтобы сократить процесс при следующем перезапуске. Обычно используется в сочетании с innodb_buffer_pool_load_at_startup. Параметр innodb_buffer_pool_dump_pct определяет процент наиболее часто используемых страниц буферного пула для дампа.

И innodb_buffer_pool_dump_at_shutdown, и innodb_buffer_pool_load_at_startup включены по умолчанию.

Для получения дополнительной информации см. Раздел 14.8.3.6, «Сохранение и восстановление состояния буферного пула».

innodb_buffer_pool_dump_now

Немедленно создает запись страниц, кэшированных в InnoDB. Обычно используется в сочетании с innodb_buffer_pool_load_now.

Включение innodb_buffer_pool_dump_now запускает действие записи, но не изменяет настройку переменной, которая всегда остается OFF или 0. Чтобы просмотреть состояние дампа буферного пула после запуска дампа, запросите переменную Innodb_buffer_pool_dump_status.

Для получения дополнительной информации см. Раздел 14.8.3.6, «Сохранение и восстановление состояния буферного пула».

innodb_buffer_pool_dump_pct

Указывает процент наиболее часто используемых страниц для каждого буферного пула для чтения и дампа. Диапазон от 1 до 100. Значение по умолчанию равно 25. Например, если есть 4 буферных пула по 100 страниц каждый, и innodb_buffer_pool_dump_pct установлено в 25, будут сдампированы 25 наиболее часто используемых страниц из каждого буферного пула.

Изменение значения по умолчанию innodb_buffer_pool_dump_pct совпадает с изменениями значений по умолчанию для innodb_buffer_pool_dump_at_shutdown и innodb_buffer_pool_load_at_startup, которые оба включены по умолчанию в MySQL 5.7.

innodb_buffer_pool_filename

Указывает имя файла, содержащего список идентификаторов табличных пространств и идентификаторов страниц, созданных innodb_buffer_pool_dump_at_shutdown или innodb_buffer_pool_dump_now. Идентификаторы табличных пространств и идентификаторы страниц сохраняются в следующем формате: space, page_id. По умолчанию файл называется ib_buffer_pool и расположен в каталоге данных InnoDB. Нестандартное расположение должно быть указано относительно каталога данных.

Имя файла можно указать во время выполнения, используя оператор SET:

SET GLOBAL innodb_buffer_pool_filename='file_name';

Вы также можете указать имя файла при запуске, в строке запуска или файле конфигурации MySQL. При указании имени файла при запуске файл должен существовать, иначе InnoDB вернёт ошибку запуска, указывая, что такого файла или каталога нет.

Дополнительную информацию см. в Разделе 14.8.3.6, «Сохранение и восстановление состояния буферного пула».

innodb_buffer_pool_instances

Количество областей, на которые разделяется буферный пул InnoDB. Для систем с буферными пулами объёмом в несколько гигабайт разделение буферного пула на отдельные инстансы может улучшить конкурентность, уменьшая конфликтность при чтении и записи в кешированные страницы различными потоками. Каждая страница, хранящаяся в или считываемая из буферного пула, случайным образом присваивается одному из инстансов буферного пула с помощью хеш-функции. Каждый буферный пул управляет собственными списками свободных объектов, и всеми другими связанными с буферным пулом структурами данных, а также защищён собственным буферным пулом.

Этот параметр действует только при установке innodb_buffer_pool_size на 1 ГБ или более. Общий размер буферного пула делится между всеми буферными пулами. Для наилучшей эффективности укажите сочетание innodb_buffer_pool_instances и innodb_buffer_pool_size так, чтобы каждый инстанс буферного пула составлял не менее 1 ГБ.

Значение по умолчанию для 32-битных систем Windows зависит от значения innodb_buffer_pool_size, как описано ниже:

На всех остальных платформах значение по умолчанию равно 8, когда innodb_buffer_pool_size больше или равно 1 ГБ. В противном случае значение по умолчанию равно 1.

Для получения дополнительной информации см. Раздел 14.8.3.1, «Настройка размера буферного пула InnoDB».

innodb_buffer_pool_load_abort

Прерывает процесс восстановления содержимого InnoDB, вызванный innodb_buffer_pool_load_at_startup или innodb_buffer_pool_load_now.

Включение innodb_buffer_pool_load_abort запускает действие прерывания, но не изменяет значение переменной, которое всегда остаётся OFF или 0. Для просмотра состояния загрузки буферного пула после запуска действия прерывания запросите переменную Innodb_buffer_pool_load_status.

Дополнительную информацию см. в Разделе 14.8.3.6, «Сохранение и восстановление состояния буферного пула».

innodb_buffer_pool_size

Размер в байтах , области памяти, где InnoDB кэширует данные таблиц и индексов. Значение по умолчанию равно 134217728 байт (128 МБ). Максимальное значение зависит от архитектуры процессора; максимальное значение составляет 4294967295 (2³²-1) на 32-разрядных системах и 18446744073709551615 (2⁶⁴-1) на 64-разрядных системах. На 32-разрядных системах архитектура процессора и операционная система могут наложить более низкое практическое максимальное значение, чем указанное максимальное значение. Если размер буфера пула превышает 1 ГБ, установка innodb_buffer_pool_instances на значение больше 1 может улучшить масштабируемость на загруженном сервере.

Более большой буфер пула требует меньшего ввода-вывода с диска для доступа к одним и тем же данным таблицы более одного раза. На выделенном сервере базы данных вы можете установить размер буфера пула на 80% от размера физической памяти машины. Учитывайте следующие потенциальные проблемы при настройке размера буфера пула и будьте готовы уменьшить размер буфера пула при необходимости.

При увеличении или уменьшении размера буфера пула операция выполняется порциями. Размер порции определяется переменной innodb_buffer_pool_chunk_size, которая имеет значение по умолчанию 128 МБ.

Размер буфера пула всегда должен быть равен или кратным innodb_buffer_pool_chunk_size * innodb_buffer_pool_instances. Если вы измените размер буфера пула на значение, которое не равно или не кратно innodb_buffer_pool_chunk_size * innodb_buffer_pool_instances, размер буфера пула автоматически корректируется до значения, которое равно или кратно innodb_buffer_pool_chunk_size * innodb_buffer_pool_instances.

innodb_buffer_pool_size может быть установлено динамически, что позволяет изменить размер буфера пула без перезапуска сервера. Статус онлайн-операций по изменению размера буфера пула отображается в переменной состояния Innodb_buffer_pool_resize_status. Подробнее см. Раздел 14.8.3.1, «Настройка размера буфера пула InnoDB».

innodb_change_buffer_max_size

Максимальный размер , в процентах от общего размера . Вы можете увеличить это значение для сервера MySQL с высокой активностью вставки, обновления и удаления или уменьшить для сервера MySQL с неизменными данными, используемыми для отчетов. Дополнительную информацию см. в Разделе 14.5.2, «Буфер изменений». Общие рекомендации по настройке ввода-вывода см. в Разделе 8.5.8, «Оптимизация ввода-вывода InnoDB».

innodb_change_buffering

Выполняется ли InnoDB, оптимизация, которая откладывает операции записи во вторичные индексы, чтобы операции ввода-вывода могли выполняться последовательно. Допустимые значения описаны в следующей таблице.

Дополнительную информацию см. в Разделе 14.5.2, «Буфер изменений». Общие рекомендации по настройке ввода-вывода см. в Разделе 8.5.8, «Оптимизация ввода-вывода InnoDB».

innodb_change_buffering_debug

Устанавливает флаг отладки для InnoDB буферизации изменений. Значение 1 принудительно выполняет все изменения в буфере изменений. Значение 2 приводит к неожиданному выходу при слиянии. Значение по умолчанию 0 означает, что флаг отладки буферизации изменений не установлен. Эта опция доступна только при отладке поддержки, скомпилированной с использованием опции WITH_DEBUG CMake.

innodb_checksum_algorithm

Указывает, как генерировать и проверять контрольные суммы, хранящиеся в блоках диска InnoDB. crc32 — значение по умолчанию с MySQL 5.7.7.

innodb_checksum_algorithm заменяет параметр innodb_checksums. Следующие значения предоставлены для совместимости, вплоть до MySQL 5.7.6 включительно:

Начиная с MySQL 5.7.7, со значением по умолчанию innodb_checksum_algorithm crc32, innodb_checksums=ON теперь эквивалентно innodb_checksum_algorithm=crc32. innodb_checksums=OFF по-прежнему эквивалентно innodb_checksum_algorithm=none.

Для предотвращения конфликтов, удалите ссылки на innodb_checksums из файлов конфигурации MySQL и скриптов запуска.

Значение innodb совместимо со старыми версиями MySQL. Значение crc32 использует алгоритм, который быстрее вычисляет контрольную сумму для каждого изменённого блока и проверяет контрольные суммы для каждого чтения с диска. Он сканирует блоки по 64 бита за раз, что быстрее, чем алгоритм контрольной суммы innodb, который сканирует блоки по 8 бит за раз. Значение none записывает постоянное значение в поле контрольной суммы, а не вычисляет значение на основе данных блока. Блоки в табличном пространстве могут использовать смесь старых, новых и отсутствующих значений контрольной суммы, постепенно обновляясь по мере изменения данных. После того, как блоки в табличном пространстве будут изменены для использования алгоритма crc32, соответствующие таблицы не смогут читаться более ранними версиями MySQL.

Строгий формат алгоритма контрольной суммы сообщает об ошибке, если он обнаруживает допустимое, но несовпадающее значение контрольной суммы в табличном пространстве. Рекомендуется использовать только строгие настройки в новом экземпляре для первой настройки табличных пространств. Строгие настройки несколько быстрее, так как им не нужно вычислять все значения контрольной суммы во время чтения с диска.

В следующей таблице показано различие между значениями параметров none, innodb и crc32 и их строгими аналогами. none, innodb и crc32 записывают указанный тип значения контрольной суммы в каждый блок данных, но для совместимости принимают и другие значения контрольной суммы при проверке блока во время операции чтения. Строгие настройки также принимают допустимые значения контрольной суммы, но выводят сообщение об ошибке при обнаружении допустимого, но несовпадающего значения контрольной суммы. Использование строгого формата может ускорить проверку, если все файлы данных InnoDB в экземпляре созданы с одинаковым значением innodb_checksum_algorithm.

Версии MySQL Enterprise Backup до 3.8.0 не поддерживают резервное копирование табличных пространств, использующих контрольные суммы CRC32. MySQL Enterprise Backup добавляет поддержку CRC32 контрольных сумм в версии 3.8.1 с некоторыми ограничениями. Обратитесь к истории изменений MySQL Enterprise Backup 3.8.1 для получения дополнительной информации.

innodb_checksums

InnoDB может использовать проверку на всех страницах табличного пространства, считываемых с диска, для обеспечения дополнительной отказоустойчивости от аппаратных сбоев или поврежденных файлов данных. Эта проверка включена по умолчанию. В особых случаях (например, при проведении тестов производительности) эту функцию безопасности можно отключить с помощью --skip-innodb-checksums. Вы можете указать метод вычисления контрольной суммы, используя параметр innodb_checksum_algorithm.

innodb_checksums устарел и заменен на innodb_checksum_algorithm.

До MySQL 5.7.7, innodb_checksums=ON совпадал с innodb_checksum_algorithm=innodb. Начиная с MySQL 5.7.7, значение по умолчанию для innodb_checksum_algorithm равно crc32, а innodb_checksums=ON совпадает с innodb_checksum_algorithm=crc32. innodb_checksums=OFF совпадает с innodb_checksum_algorithm=none.

Удалите любые параметры innodb_checksums из ваших конфигурационных файлов и скриптов запуска, чтобы избежать конфликтов с innodb_checksum_algorithm. innodb_checksums=OFF автоматически устанавливает innodb_checksum_algorithm=none. innodb_checksums=ON игнорируется и переопределяется любой другой настройкой для innodb_checksum_algorithm.

innodb_cmp_per_index_enabled

Включает статистику, связанную со сжатием на уровне каждого индекса, в таблице Information Schema INNODB_CMP_PER_INDEX. Поскольку сбор этой статистики может быть дорогостоящим, включайте этот параметр только в экземплярах разработки, тестирования или репликации во время настройки производительности, связанной с таблицами InnoDB.

Для получения дополнительной информации см. Раздел 24.4.7, «Таблицы INFORMATION_SCHEMA INNODB_CMP_PER_INDEX и INNODB_CMP_PER_INDEX_RESET», и Раздел 14.9.1.4, «Мониторинг сжатия таблиц InnoDB во время выполнения».

innodb_commit_concurrency

Количество транзакций, которые могут одновременно завершать работу. Значение 0 (по умолчанию) допускает одновременное завершение любого количества транзакций.

Значение innodb_commit_concurrency не может быть изменено во время выполнения с нуля на ненулевое значение или наоборот. Значение может быть изменено с одного ненулевого значения на другое.

innodb_compress_debug

Сжимает все таблицы с использованием указанного алгоритма сжатия без необходимости определения атрибута COMPRESSION для каждой таблицы. Этот параметр доступен только в том случае, если поддержка отладки компилируется с использованием параметра WITH_DEBUG CMake.

Для получения дополнительной информации см. Раздел 14.9.2, «Сжатие страниц InnoDB».

innodb_compression_failure_threshold_pct

Определяет пороговое значение уровня сбоев сжатия для таблицы в процентах, при достижении которого MySQL начинает добавлять заполнение в страницы, чтобы избежать дорогостоящих операций. Когда этот порог превышен, MySQL начинает оставлять дополнительное свободное место в каждой новой сжатой странице, динамически регулируя объем свободного места до процента размера страницы, указанного параметром innodb_compression_pad_pct_max. Значение ноль отключает механизм, который отслеживает эффективность сжатия и динамически регулирует объем заполнения.

Для получения дополнительной информации см. Раздел 14.9.1.6, «Сжатие для OLTP-нагрузок».

innodb_compression_level

Указывает уровень сжатия zlib для использования в таблицах и индексах InnoDB. Более высокое значение позволяет разместить больше данных на устройстве хранения, за счет увеличения накладных расходов на ЦП во время сжатия. Более низкое значение позволяет уменьшить накладные расходы на ЦП, когда пространство хранения не является критичным, или вы ожидаете, что данные не будут особенно сжимаемыми.

Для получения дополнительной информации см. Раздел 14.9.1.6, «Сжатие для OLTP-нагрузок».

innodb_compression_pad_pct_max

Указывает максимальный процент, который может быть зарезервирован как свободное место в каждом сжатом блоке, позволяя переупорядочить данные и журнал изменений в пределах страницы при обновлении таблицы или индекса, когда данные могут быть сжаты повторно. Применяется только тогда, когда innodb_compression_failure_threshold_pct установлено ненулевым значением, и скорость обработки превышает пороговое значение.

Дополнительную информацию см. в разделе 14.9.1.6 «Сжатие для рабочих нагрузок OLTP».

innodb_concurrency_tickets

Определяет количество потоков, которые могут одновременно войти в InnoDB. Поток помещается в очередь, когда он пытается войти в InnoDB, если число потоков уже достигло предела конкурентности. Когда потоку разрешено войти в InnoDB, ему выдаётся количество «билетов» равное значению innodb_concurrency_tickets, и поток может свободно входить и выходить из InnoDB, пока не израсходует все билеты. После этого поток снова попадает под контроль проверки конкурентности (и возможного очередирования) при следующей попытке входа в InnoDB. Значение по умолчанию равно 5000.

При небольшом значении innodb_concurrency_tickets, небольшие транзакции, обрабатывающие только несколько строк, конкурируют честно с большими транзакциями, обрабатывающими много строк. Недостатком малого значения innodb_concurrency_tickets является то, что большие транзакции должны пройти по очереди много раз, прежде чем они смогут завершиться, что увеличивает время их выполнения.

При большом значении innodb_concurrency_tickets, большие транзакции тратят меньше времени на ожидание в конце очереди (управляемой innodb_thread_concurrency) и больше времени на извлечение строк. Большие транзакции также требуют меньшего количества проходов по очереди для завершения. Недостатком большого значения innodb_concurrency_tickets является то, что слишком много больших транзакций, выполняемых одновременно, могут заблокировать более мелкие транзакции, заставив их ждать дольше перед выполнением.

При ненулевом значении innodb_thread_concurrency, возможно, потребуется отрегулировать значение innodb_concurrency_tickets вверх или вниз, чтобы найти оптимальное равновесие между большими и малыми транзакциями. Отчёт SHOW ENGINE INNODB STATUS показывает количество оставшихся билетов для выполняющейся транзакции в её текущем проходе по очереди. Эти данные также можно получить из столбца TRX_CONCURRENCY_TICKETS таблицы Информационной схемы INNODB_TRX.

Дополнительную информацию см. в разделе 14.8.5 «Настройка конкурентности потоков для InnoDB».

innodb_data_file_path

Определяет имя, размер и атрибуты файлов данных системного табличного пространства InnoDB. Если вы не укажете значение для innodb_data_file_path, по умолчанию создаётся один автоматически расширяющийся файл данных размером немного больше 12 МБ, с именем ibdata1.

Полный синтаксис спецификации файла данных включает имя файла, размер файла, атрибут autoextend и атрибут max:

file_name:file_size[:autoextend[:max:max_file_size]]

Размеры файлов указываются в килобайтах, мегабайтах или гигабайтах путём добавления K, M или G к значению размера. Если вы указываете размер файла данных в килобайтах, делайте это кратно 1024. В противном случае значения KB округляются до ближайшей границы мегабайта (МБ). Сумма размеров файлов должна составлять как минимум немного больше 12 МБ.

Дополнительную информацию о настройке см. в Конфигурация файлов данных системного табличного пространства. Инструкции по изменению размеров см. в Изменение размера системного табличного пространства.

innodb_data_home_dir

Общая часть пути к каталогу файлов данных InnoDB табличного пространства. Значение по умолчанию — каталог MySQL data. Настройка объединяется с настройкой innodb_data_file_path. Если вы зададите значение пустой строкой, вы можете указать абсолютный путь для innodb_data_file_path.

В конце значения innodb_data_home_dir требуется слеш. Например:

[mysqld]
innodb_data_home_dir = /path/to/myibdata/

Эта настройка не влияет на расположение других табличных пространств.

Дополнительная информация см. в разделе 14.8.1 «Конфигурация запуска InnoDB».

innodb_deadlock_detect

Эта опция используется для отключения обнаружения тупиков. В системах с высокой параллельностью обнаружение тупиков может привести к замедлению, когда множество потоков ожидают одного и того же блокирования. Иногда может быть эффективнее отключить обнаружение тупиков и полагаться на настройку innodb_lock_wait_timeout для отката транзакции при возникновении тупика.

Дополнительную информацию см. в разделе 14.7.5.2 «Обнаружение тупиков».

innodb_default_row_format

Параметр innodb_default_row_format определяет формат строки по умолчанию для таблиц InnoDB и созданных пользователем временных таблиц. Настройка по умолчанию — DYNAMIC. Другие допустимые значения — COMPACT и REDUNDANT. Формат строки COMPRESSED, который не поддерживается для использования в , не может быть определен в качестве значения по умолчанию.

Вновь созданные таблицы используют формат строк, определенный параметром innodb_default_row_format, когда параметр ROW_FORMAT не указан явно или используется ROW_FORMAT=DEFAULT.

Когда параметр ROW_FORMAT не указан явно или используется ROW_FORMAT=DEFAULT, любая операция, которая перестраивает таблицу, также неявно изменяет формат строк таблицы на формат, определенный параметром innodb_default_row_format. Для получения дополнительной информации см. Defining the Row Format of a Table.

Внутренние временные таблицы InnoDB, созданные сервером для обработки запросов, используют формат строк DYNAMIC независимо от настройки innodb_default_row_format.

innodb_disable_sort_file_cache

Отключает кэш файловой системы операционной системы для временных файлов сортировки слиянием. Эффект заключается в открытии таких файлов с эквивалентом O_DIRECT.

innodb_disable_resize_buffer_pool_debug

Отключает изменение размера пула буферов InnoDB. Этот параметр доступен только в том случае, если поддержка отладки включена с помощью параметра WITH_DEBUG CMake.

innodb_doublewrite

Когда включен (по умолчанию), InnoDB сохраняет все данные дважды, сначала в , затем в фактический . Эта переменная может быть отключена с помощью --skip-innodb-doublewrite для тестов производительности или случаев, когда требуется максимальная производительность, а не целостность данных или возможные сбои.

Если файлы данных системного табличного пространства (файлы ibdata*) расположены на устройствах Fusion-io, которые поддерживают атомарную запись, буферизация двойной записи автоматически отключается, и для всех файлов данных используются атомарные записи Fusion-io. Поскольку настройка буфера двойной записи является глобальной, буферизация двойной записи также отключается для файлов данных, расположенных на оборудовании, не относящемся к Fusion-io. Эта функция поддерживается только на оборудовании Fusion-io и включена только для Fusion-io NVMFS в Linux. Для того чтобы в полной мере воспользоваться преимуществами этой функции, рекомендуется настройка innodb_flush_method O_DIRECT.

Для получения дополнительной информации см. Раздел 14.6.5, «Doublewrite Buffer».

innodb_fast_shutdown

Режим InnoDB. Если значение равно 0, InnoDB выполняет , полную и слияние буфера изменений перед выключением. Если значение равно 1 (по умолчанию), InnoDB пропускает эти операции при выключении, процесс, известный как . Если значение равно 2, InnoDB очищает свои журналы и завершает работу аварийно, как если бы MySQL аварийно завершился; никакие подтвержденные транзакции не теряются, но операция делает следующий запуск более длительным.

Медленное завершение работы может занять несколько минут или даже часов в крайних случаях, когда значительные объемы данных все еще находятся в буфере. Используйте метод медленного завершения работы перед обновлением или понижением версии между основными выпусками MySQL, чтобы все файлы данных были полностью подготовлены на случай, если процесс обновления обновит формат файла.

Используйте innodb_fast_shutdown=2 в аварийных ситуациях или при устранении неполадок, чтобы обеспечить максимально быстрое завершение работы, если данные находятся под угрозой повреждения.

innodb_fil_make_page_dirty_debug

По умолчанию, установка innodb_fil_make_page_dirty_debug в ID табличного пространства немедленно делает первую страницу табличного пространства модифицированной. Если innodb_saved_page_number_debug установлено в значение, отличное от значения по умолчанию, установка innodb_fil_make_page_dirty_debug делает указанную страницу модифицированной. Параметр innodb_fil_make_page_dirty_debug доступен только в том случае, если поддержка отладки включена с помощью параметра WITH_DEBUG CMake.

innodb_file_format

Включает формат файла InnoDB для табличных пространств. Поддерживаемые форматы файлов — Antelope и Barracuda. Antelope — это исходный формат файлов InnoDB, который поддерживает форматы строк REDUNDANT и COMPACT. Barracuda — это новый формат файла, который поддерживает форматы строк COMPRESSED и DYNAMIC.

Форматы строк COMPRESSED и DYNAMIC обеспечивают важные функции хранения для таблиц InnoDB. См. Раздел 14.11, «Форматы строк InnoDB».

Изменение параметра innodb_file_format не влияет на формат файла существующих файлов табличного пространства InnoDB.

Параметр innodb_file_format не применяется к общим табличным пространствам, которые поддерживают таблицы всех форматов строк. См. Раздел 14.6.3.3, «Общие табличные пространства».

Значение по умолчанию параметра innodb_file_format было изменено на Barracuda в MySQL 5.7.

Настройка innodb_file_format игнорируется при создании таблиц, использующих формат строки DYNAMIC. Таблица, созданная с использованием формата строки DYNAMIC, всегда использует формат файла Barracuda независимо от настройки innodb_file_format. Для использования формата строки COMPRESSED, необходимо установить innodb_file_format на значение Barracuda.

Параметр innodb_file_format устарел; ожидается его удаление в будущих версиях. Цель параметра innodb_file_format состояла в возможности пользователей понизить версию встроенной версии InnoDB в более ранних версиях MySQL. Теперь, когда эти версии MySQL достигли конца своего жизненного цикла, поддержка понижения, предоставляемая этим параметром, больше не требуется.

Дополнительную информацию см. в Разделе 14.10, «Управление форматами файлов InnoDB».

innodb_file_format_check

При запуске сервера эта переменная может быть установлена в 1 или 0 для включения или отключения проверки InnoDB тега в (например, Antelope или Barracuda). Если тег проверяется и является более высоким, чем поддерживается текущей версией InnoDB, возникает ошибка, и InnoDB не запускается. Если тег не выше, InnoDB устанавливает значение innodb_file_format_max в тег формата файла.

Дополнительную информацию см. в Разделе 14.10.2.1, «Проверка совместимости при запуске InnoDB».

Параметр innodb_file_format_check устарел вместе с параметром innodb_file_format. Ожидается, что оба параметра будут удалены в будущих версиях.

innodb_file_format_max

При запуске сервера InnoDB устанавливает значение этой переменной в тег в (например, Antelope или Barracuda). Если сервер создаёт или открывает таблицу с «более высоким» форматом файла, он устанавливает значение innodb_file_format_max в этот формат.

Связанная информация: Раздел 14.10, «Управление форматами файлов InnoDB».

Параметр innodb_file_format_max устарел вместе с параметром innodb_file_format. Ожидается, что оба параметра будут удалены в будущих версиях.

innodb_file_per_table

При включенном innodb_file_per_table, таблицы по умолчанию создаются в табличных пространствах по принципу «файл на таблицу». При отключении по умолчанию таблицы создаются в системном табличном пространстве. Информация о табличных пространствах «файл на таблицу»: Раздел 14.6.3.2, «Табличные пространства „файл на таблицу“». Информация о системном табличном пространстве InnoDB: Раздел 14.6.3.1, «Системное табличное пространство».

Переменную innodb_file_per_table можно настроить во время работы, используя оператор SET GLOBAL, указанный в командной строке при запуске или в файле параметров. Настройка во время работы требует привилегий, достаточных для изменения глобальных системных переменных (см. Раздел 5.1.8.1, «Привилегии на системные переменные») и немедленно влияет на работу всех подключений.

При усечении или удалении таблицы, находящейся в табличном пространстве «файл на таблицу», освобождённое пространство возвращается операционной системе. Усечение или удаление таблицы, находящейся в системном табличном пространстве, освобождает пространство только в системном табличном пространстве. Освобождённое пространство в системном табличном пространстве может быть использовано повторно для InnoDB данных, но не возвращается операционной системе, так как файлы данных системного табличного пространства никогда не уменьшаются.

При включенном innodb_file_per_table операция копирования таблицы ALTER TABLE над таблицей, находящейся в системном табличном пространстве, неявно пересоздаёт таблицу в табличном пространстве «файл на таблицу». Чтобы этого избежать, отключите innodb_file_per_table перед выполнением операций копирования таблицы ALTER TABLE над таблицами, находящимися в системном табличном пространстве.

Настройка innodb_file_per-table не влияет на создание временных таблиц. Временные таблицы создаются во временном табличном пространстве. См. Раздел 14.6.3.5, «Временное табличное пространство».

innodb_fill_factor

InnoDB выполняет массовую загрузку при создании или перестроении индексов. Этот метод создания индексов известен как “построение индекса в отсортированном виде”.

innodb_fill_factor определяет процент заполнения каждой страницы B-дерева при построении индекса в отсортированном виде, при этом оставшееся пространство резервируется для будущего роста индекса. Например, установка innodb_fill_factor на 80 резервирует 20 процентов пространства на каждой странице B-дерева для будущего роста индекса. Фактические проценты могут отличаться. Настройка innodb_fill_factor интерпретируется как подсказка, а не как жёсткое ограничение.

Настройка innodb_fill_factor в значении 100 оставляет 1/16 свободного места на страницах кластеризованного индекса для будущего роста индекса.

innodb_fill_factor применяется как к листовым, так и к нелистовым страницам B-дерева. Она не применяется к внешним страницам, используемым для TEXT или BLOB записей.

Дополнительную информацию см. в разделе 14.6.2.3, “Построение индексов в отсортированном виде”.

innodb_flush_log_at_timeout

Запись и сброс журналов каждые N секунды. innodb_flush_log_at_timeout позволяет увеличить время ожидания между сбросами, чтобы уменьшить сбросы и избежать влияния на производительность группового коммита двоичного журнала. Значение по умолчанию для innodb_flush_log_at_timeout — раз в секунду.

innodb_flush_log_at_trx_commit

Контролирует баланс между строгим соответствием операциям и большей производительностью, которая возможна, когда операции ввода-вывода, связанные с коммитом, переупорядочиваются и выполняются группами. Вы можете добиться лучшей производительности, изменив значение по умолчанию, но затем вы можете потерять транзакции при аварии.

Для обеспечения целостности и согласованности в конфигурации репликации, использующей InnoDB с транзакциями:

Сведения о комбинации настроек на реплике, обеспечивающей наибольшую устойчивость к неожиданным остановкам, см. в разделе 16.3.2, “Обработка неожиданной остановки реплики”.

innodb_flush_method

Определяет метод, используемый для записи данных в InnoDB, что может влиять на производительность ввода-вывода.

Если innodb_flush_method установлено на NULL на системе Unix, по умолчанию используется опция fsync. Если innodb_flush_method установлено на NULL в Windows, по умолчанию используется опция async_unbuffered.

Опции innodb_flush_method для систем Unix-подобных систем включают:

Опции innodb_flush_method для систем Windows включают:

Влияние каждого значения на производительность зависит от конфигурации оборудования и рабочей нагрузки. Оцените вашу конкретную конфигурацию, чтобы определить, какое значение использовать или оставить значение по умолчанию. Изучите переменную состояния Innodb_data_fsyncs, чтобы увидеть общее количество вызовов fsync() для каждого значения. Соотношение операций чтения и записи в вашей рабочей нагрузке может повлиять на производительность значения. Например, на системе с контроллером RAID и кэшем записи с батарейным питанием, O_DIRECT может помочь избежать двойного буферизации между буфером InnoDB и кэшем файловой системы операционной системы. На некоторых системах, где файлы данных и журнальных записей InnoDB находятся на SAN, значение по умолчанию или O_DSYNC может быть быстрее для рабочей нагрузки с чтением, в основном с заявлениями SELECT. Всегда тестируйте этот параметр с оборудованием и рабочей нагрузкой, которые отражают вашу производственную среду. Для советов по настройке ввода-вывода см. Раздел 8.5.8, «Оптимизация ввода-вывода InnoDB».

innodb_flush_neighbors

Указывает, будут ли страницы из InnoDB буфера также записываться в innodb_flush_neighbors.

Когда данные таблицы хранятся на традиционном устройстве хранения, запись таких блоков в одной операции снижает издержки на операции ввода-вывода (в основном операции поиска на диске) по сравнению с записью отдельных страниц в разное время. Для данных таблиц, хранящихся в памяти, время поиска не является значимым фактором, и вы можете отключить эту настройку, чтобы распределить операции записи. Для получения дополнительной информации см. Раздел 14.8.3.5, «Настройка сброса кэша буфера».

innodb_flush_sync

Переменная innodb_flush_sync, которая включена по умолчанию, приводит к игнорированию настройки innodb_io_capacity во время всплесков активности ввода-вывода, которые происходят в пиковые моменты. Чтобы соответствовать скорости ввода-вывода, определенной настройкой innodb_io_capacity, отключите innodb_flush_sync.

Для получения информации о настройке переменной innodb_flush_sync см. Раздел 14.8.8, «Настройка пропускной способности ввода-вывода InnoDB».

innodb_flushing_avg_loops

Число итераций, в течение которых InnoDB сохраняет ранее вычисленную моментальную фотографию состояния сброса, контролируя, насколько быстро отвечает на изменения . Увеличение значения делает скорость операций плавной и постепенной при изменении рабочей нагрузки. Уменьшение значения заставляет адаптивный сброс быстро реагировать на изменения рабочей нагрузки, что может вызвать всплески активности сброса, если рабочая нагрузка резко возрастает и уменьшается.

Для получения дополнительной информации см. Раздел 14.8.3.5, «Настройка сброса буфера пула».

innodb_force_load_corrupted

Разрешает InnoDB загружать таблицы при запуске, которые помечены как поврежденные. Используйте только во время устранения неполадок, чтобы восстановить данные, которые в противном случае недоступны. После завершения устранения неполадок отключите этот параметр и перезапустите сервер.

innodb_force_recovery

Режим , обычно изменяется только в серьезных ситуациях устранения неполадок. Возможные значения от 0 до 6. Для значений и важной информации о innodb_force_recovery см. Раздел 14.22.2, «Принудительное восстановление InnoDB».

innodb_ft_aux_table

Указывает полное имя таблицы InnoDB, содержащей индекс FULLTEXT. Эта переменная предназначена для диагностических целей и может быть установлена только во время выполнения. Например:

SET GLOBAL innodb_ft_aux_table = 'test/t1';

После установки этой переменной с именем в формате db_name/table_name, таблицы INFORMATION_SCHEMA INNODB_FT_INDEX_TABLE, INNODB_FT_INDEX_CACHE, INNODB_FT_CONFIG, INNODB_FT_DELETED и INNODB_FT_BEING_DELETED отображают информацию об индексе поиска для указанной таблицы.

Для получения дополнительной информации см. Раздел 14.16.4, «Таблицы InnoDB INFORMATION_SCHEMA FULLTEXT Index».

innodb_ft_cache_size

Объем памяти в байтах, выделенный для кеша индекса полнотекстового поиска InnoDB FULLTEXT, который хранит обработанный документ в памяти при создании индекса InnoDB FULLTEXT. Вставки и обновления индексов записываются на диск только при достижении размера предела кеша innodb_ft_cache_size. innodb_ft_cache_size определяет размер кеша для каждой таблицы. Чтобы установить глобальный предел для всех таблиц, см. innodb_ft_total_cache_size.

Для получения дополнительной информации см. InnoDB Full-Text Index Cache.

innodb_ft_enable_diag_print

Включить дополнительный вывод диагностики полнотекстового поиска (FTS). Этот параметр предназначен в основном для отладки FTS и не интересен большинству пользователей. Вывод печатается в журнале ошибок и включает информацию, такую как:

innodb_ft_enable_stopword

Указывает, что набор связан с индексом InnoDB FULLTEXT во время создания индекса. Если установлен параметр innodb_ft_user_stopword_table, стоп-слова берутся из этой таблицы. В противном случае, если установлен параметр innodb_ft_server_stopword_table, стоп-слова берутся из этой таблицы. В противном случае используется встроенный набор стоп-слов по умолчанию.

Для получения дополнительной информации см. Раздел 12.9.4, «Стоп-слова полного текста».

innodb_ft_max_token_size

Максимальная длина слов в символах, которые хранятся в индексе InnoDB FULLTEXT. Установка ограничения на это значение уменьшает размер индекса, тем самым ускоряя запросы, за счет пропуска длинных ключевых слов или произвольных наборов букв, которые не являются настоящими словами и вряд ли будут поисковыми запросами.

Для получения дополнительной информации см. Раздел 12.9.6, «Тонкая настройка поиска по полному тексту MySQL».

innodb_ft_min_token_size

Минимальная длина слов, которые хранятся в индексе InnoDB FULLTEXT. Увеличение этого значения уменьшает размер индекса, тем самым ускоряя запросы, за счет пропуска распространенных слов, которые вряд ли будут значимыми в контексте поиска, таких как английские слова “a” и “to”. Для контента, использующего кодировку CJK (китайский, японский, корейский), укажите значение 1.

Для получения дополнительной информации см. Раздел 12.9.6, «Тонкая настройка поиска по полному тексту MySQL».

innodb_ft_num_word_optimize

Количество слов для обработки во время каждой операции OPTIMIZE TABLE над индексом InnoDB FULLTEXT. Поскольку операция массовой вставки или обновления таблицы, содержащей индекс поиска по полному тексту, может потребовать значительного обслуживания индекса для учета всех изменений, вы можете выполнить серию инструкций OPTIMIZE TABLE, каждая из которых будет продолжать работу там, где остановилась предыдущая.

Для получения дополнительной информации см. Раздел 12.9.6, «Тонкая настройка поиска по полному тексту MySQL».

innodb_ft_result_cache_limit

Предел кэша результатов запроса поиска по полному тексту InnoDB (определяется в байтах) для каждого запроса поиска по полному тексту или для каждого потока. Промежуточные и окончательные результаты запроса поиска по полному тексту InnoDB обрабатываются в памяти. Используйте innodb_ft_result_cache_limit, чтобы установить ограничение размера для кэша результатов запроса поиска по полному тексту, чтобы избежать чрезмерного потребления памяти в случае очень больших результатов запроса поиска по полному тексту InnoDB (например, миллионы или сотни миллионов строк). Память выделяется по мере необходимости при обработке запроса поиска по полному тексту. Если достигнут предел размера кэша результатов, возвращается ошибка, указывающая на то, что запрос превышает максимально допустимый объем памяти.

Максимальное значение innodb_ft_result_cache_limit для всех типов платформ и разрядности равно 2**32-1.

innodb_ft_server_stopword_table

Этот параметр используется для указания собственного списка стоп-слов индекса InnoDB FULLTEXT для всех таблиц InnoDB. Чтобы настроить собственный список стоп-слов для конкретной таблицы InnoDB, используйте innodb_ft_user_stopword_table.

Установите innodb_ft_server_stopword_table в имя таблицы, содержащей список стоп-слов, в формате db_name/table_name.

Таблица стоп-слов должна существовать до настройки innodb_ft_server_stopword_table. innodb_ft_enable_stopword должен быть включен, и параметр innodb_ft_server_stopword_table должен быть настроен до создания индекса FULLTEXT.

Таблица стоп-слов должна быть таблицей InnoDB, содержащей один столбец VARCHAR с именем value.

Для получения дополнительной информации см. Раздел 12.9.4, «Стоп-слова полного текста».

innodb_ft_sort_pll_degree

Количество потоков, используемых параллельно для индексации и токенизации текста в индексе InnoDB FULLTEXT при построении .

Для получения дополнительной информации см. Раздел 14.6.2.4, «Индексы полного текста InnoDB», и innodb_sort_buffer_size.

innodb_ft_total_cache_size

Общий объем выделенной памяти, в байтах, для кэша индекса полнотекстового поиска InnoDB для всех таблиц. Создание многочисленных таблиц, каждая из которых имеет индекс FULLTEXT поиска, может потреблять значительную часть доступной памяти. innodb_ft_total_cache_size определяет глобальный предел памяти для всех индексов полнотекстового поиска, чтобы избежать чрезмерного потребления памяти. Если глобальный предел достигнут операцией индексации, инициируется принудительная синхронизация.

Для получения дополнительной информации см. InnoDB Full-Text Index Cache.

innodb_ft_user_stopword_table

Этот параметр используется для указания собственного списка стоп-слов индекса InnoDB FULLTEXT в определенной таблице. Чтобы настроить собственный список стоп-слов для всех таблиц InnoDB, используйте innodb_ft_server_stopword_table.

Установите innodb_ft_user_stopword_table в имя таблицы, содержащей список стоп-слов в формате db_name/table_name.

Таблица стоп-слов должна существовать до настройки innodb_ft_user_stopword_table. innodb_ft_enable_stopword должен быть включен, и innodb_ft_user_stopword_table должен быть настроен до создания индекса FULLTEXT.

Таблица стоп-слов должна быть таблицей InnoDB, содержащей один столбец VARCHAR с именем value.

Для получения дополнительной информации см. Раздел 12.9.4, «Стоп-слова полнотекстового поиска».

innodb_io_capacity

Переменная innodb_io_capacity определяет количество операций ввода-вывода в секунду (IOPS), доступных для фоновых задач InnoDB, таких как страниц из и слияние данных из .

Информацию о настройке переменной innodb_io_capacity см. в Разделе 14.8.8, «Настройка емкости ввода-вывода InnoDB».

innodb_io_capacity_max

Если активность очистки отстает, InnoDB может выполнять очистку более агрессивно, с более высокой скоростью операций ввода-вывода в секунду (IOPS), чем определено переменной innodb_io_capacity. Переменная innodb_io_capacity_max определяет максимальное количество операций IOPS, выполняемых фоновыми задачами InnoDB в таких ситуациях.

Информацию о настройке переменной innodb_io_capacity_max см. в Разделе 14.8.8, «Настройка емкости ввода-вывода InnoDB».

innodb_large_prefix

Когда этот параметр включен, префиксы ключей индекса длиной более 767 байт (до 3072 байт) разрешены для таблиц InnoDB, использующих или формат строк. См. Раздел 14.23, «Ограничения InnoDB» для максимальных значений, связанных с префиксами ключей индекса при различных настройках.

Для таблиц, использующих или формат строк, этот параметр не влияет на допустимую длину префикса ключа индекса.

innodb_large_prefix включен по умолчанию в MySQL 5.7. Это изменение совпадает с изменением значения по умолчанию для innodb_file_format, которое по умолчанию установлено в Barracuda в MySQL 5.7. Вместе эти изменения значений по умолчанию позволяют создавать более длинные префиксы ключей индекса при использовании формата строк DYNAMIC или COMPRESSED. Если любой из параметров установлен в значение, отличное от значения по умолчанию, префиксы ключей индекса длиной более 767 байт будут неявно усечены.

innodb_large_prefix устарел; ожидается его удаление в будущей версии. innodb_large_prefix был введен для отключения больших префиксов ключей индекса для обеспечения совместимости с более ранними версиями InnoDB, которые не поддерживают большие префиксы ключей индекса.

innodb_limit_optimistic_insert_debug

Ограничивает количество записей на страницу. Значение по умолчанию 0 означает, что ограничение не накладывается. Этот параметр доступен только в том случае, если поддержка отладки скомпилирована с использованием параметра WITH_DEBUG CMake.

innodb_lock_wait_timeout

Время в секундах, которое InnoDB ждет блокировки, прежде чем отказаться. Значение по умолчанию составляет 50 секунд. Транзакция, которая пытается получить доступ к строке, заблокированной другой InnoDB транзакцией, ждет не более этого времени для записи в строку, прежде чем выдать следующую ошибку:

ERROR 1205 (HY000): Lock wait timeout exceeded; try restarting transaction

Когда происходит таймаут ожидания блокировки, выполняется текущая команда (а не вся транзакция). Чтобы откатить всю транзакцию, запустите сервер с параметром --innodb-rollback-on-timeout. См. также Раздел 14.22.4, «Обработка ошибок InnoDB».

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

innodb_lock_wait_timeout применяется только к блокировкам строк InnoDB. MySQL не происходит внутри InnoDB, и этот таймаут не применяется к ожиданиям блокировок таблиц.

Значение таймаута ожидания блокировки не применяется к случаям, когда innodb_deadlock_detect включено (по умолчанию), поскольку InnoDB сразу же обнаруживает тупиковые ситуации и отменяет одну из заблокированных транзакций. Если innodb_deadlock_detect отключено, InnoDB полагается на innodb_lock_wait_timeout для отката транзакции при возникновении тупика. См. Раздел 14.7.5.2, «Обнаружение тупиковых ситуаций».

innodb_lock_wait_timeout может быть установлено во время выполнения с помощью команды SET GLOBAL или SET SESSION. Изменение значения GLOBAL требует привилегий, достаточных для установки глобальных системных переменных (см. Раздел 5.1.8.1, «Привилегии системных переменных») и влияет на работу всех последующих подключений. Любой клиент может изменить значение SESSION для innodb_lock_wait_timeout, что влияет только на данного клиента.

innodb_locks_unsafe_for_binlog

Эта переменная влияет на то, как InnoDB использует блокировки для поиска и сканирования индексов. innodb_locks_unsafe_for_binlog устарела; ожидается, что она будет удалена в будущих выпусках MySQL.

Обычно InnoDB использует алгоритм блокировки следующего ключа, который объединяет блокировку строк индекса с . InnoDB выполняет блокировку на уровне строк таким образом, что при поиске или сканировании индекса таблицы он устанавливает общие или эксклюзивные блокировки на встречающиеся записи индекса. Таким образом, блокировки на уровне строк фактически являются блокировками записей индекса. Кроме того, блокировка следующего ключа на записи индекса также влияет на зазор перед записью индекса. То есть, блокировка следующего ключа — это блокировка записи индекса плюс блокировка зазора на зазоре, предшествующем записи индекса. Если у одной сессии есть общая или эксклюзивная блокировка записи R в индексе, другая сессия не может вставить новую запись индекса в зазор непосредственно перед R в порядке индекса. См. Раздел 14.7.1, «InnoDB Locking».

По умолчанию значение innodb_locks_unsafe_for_binlog равно 0 (выключено), что означает, что блокировка зазоров включена: InnoDB использует блокировки следующего ключа для поиска и сканирования индексов. Чтобы включить переменную, установите её в 1. Это приводит к отключению блокировки зазоров: InnoDB использует только блокировки записей индекса для поиска и сканирования индексов.

Включение innodb_locks_unsafe_for_binlog не отключает использование блокировки зазоров для проверки ограничений внешнего ключа или проверки дублирующихся ключей.

Воздействие включения innodb_locks_unsafe_for_binlog такое же, как установка уровня изоляции транзакции на READ COMMITTED, за исключением следующих случаев:

READ COMMITTED поэтому предоставляет более точный и гибкий контроль, чем innodb_locks_unsafe_for_binlog. Дополнительную информацию о влиянии уровня изоляции на блокировку зазоров см. в Разделе 14.7.2.1, «Transaction Isolation Levels».

Включение innodb_locks_unsafe_for_binlog может привести к проблемам с "фантомами", поскольку другие сессии могут вставлять новые строки в зазоры при отключенной блокировке зазоров. Предположим, что существует индекс по столбцу id таблицы child и вы хотите прочитать и заблокировать все строки из таблицы, имеющие идентификатор, больший, чем 100, с намерением позже обновить некоторые столбцы в выбранных строках:

SELECT * FROM child WHERE id > 100 FOR UPDATE;

Запрос сканирует индекс, начиная с первой записи, где id больше 100. Если блокировки, установленные на записях индекса в этом диапазоне, не предотвращают вставки в зазоры, другая сессия может вставить новую строку в таблицу. В результате, если вы выполните тот же SELECT снова в рамках той же транзакции, вы увидите новую строку в наборе результатов, возвращенном запросом. Это также означает, что если в базу данных добавляются новые элементы, InnoDB не гарантирует сериализуемость. Поэтому, если innodb_locks_unsafe_for_binlog включена, InnoDB гарантирует, как минимум, уровень изоляции READ COMMITTED. (Конфликтно-сериализуемость всё ещё гарантируется.) Дополнительную информацию о "фантомах" см. в Разделе 14.7.4, «Phantom Rows».

Включение innodb_locks_unsafe_for_binlog имеет дополнительное влияние:

Рассмотрим следующий пример, начиная с этой таблицы:

CREATE TABLE t (a INT NOT NULL, b INT) ENGINE = InnoDB;
INSERT INTO t VALUES (1,2),(2,3),(3,2),(4,3),(5,2);
COMMIT;

В этом случае таблица не имеет индексов, поэтому для поиска и сканирования индексов используется скрытый кластерный индекс для блокировки записей (см. Раздел 14.6.2.1, «Clustered and Secondary Indexes»).

Предположим, что один клиент выполняет UPDATE с помощью этих операторов:

SET autocommit = 0;
UPDATE t SET b = 5 WHERE b = 3;

Предположим также, что второй клиент выполняет UPDATE с помощью этих операторов после выполнения первого клиента:

SET autocommit = 0;
UPDATE t SET b = 4 WHERE b = 2;

Когда InnoDB выполняет каждый UPDATE, он сначала получает эксклюзивную блокировку для каждой строки, а затем определяет, следует ли её модифицировать. Если InnoDB не изменяет строку и innodb_locks_unsafe_for_binlog включена, он освобождает блокировку. В противном случае InnoDB удерживает блокировку до конца транзакции. Это влияет на обработку транзакций следующим образом.

Если innodb_locks_unsafe_for_binlog отключена, первый UPDATE получает x-блокировки и не освобождает ни одной из них:

x-lock(1,2); retain x-lock
x-lock(2,3); update(2,3) to (2,5); retain x-lock
x-lock(3,2); retain x-lock
x-lock(4,3); update(4,3) to (4,5); retain x-lock
x-lock(5,2); retain x-lock

Второй UPDATE блокируется, как только пытается получить какие-либо блокировки (потому что первый update удерживает блокировки на всех строках) и не продолжает выполнение, пока первый UPDATE не завершит или откажется:

x-lock(1,2); block and wait for first UPDATE to commit or roll back

Если innodb_locks_unsafe_for_binlog включена, первый UPDATE получает x-блокировки и освобождает те, для которых он не производит изменения:

x-lock(1,2); unlock(1,2)
x-lock(2,3); update(2,3) to (2,5); retain x-lock
x-lock(3,2); unlock(3,2)
x-lock(4,3); update(4,3) to (4,5); retain x-lock
x-lock(5,2); unlock(5,2)

Для второго UPDATE, InnoDB выполняет “полупоследовательный” чтения, возвращая последнюю подтверждённую версию каждой строки MySQL, чтобы MySQL мог определить, соответствует ли строка условию WHERE UPDATE:

x-lock(1,2); update(1,2) to (1,4); retain x-lock
x-lock(2,3); unlock(2,3)
x-lock(3,2); update(3,2) to (3,4); retain x-lock
x-lock(4,3); unlock(4,3)
x-lock(5,2); update(5,2) to (5,4); retain x-lock

innodb_log_buffer_size

Размер в байтах буфера, который InnoDB использует для записи на диск. Значение по умолчанию изменилось с 8 МБ на 16 МБ с внедрением значений 32 КБ и 64 КБ innodb_page_size. Большой буфер позволяет выполнять большие транзакции без необходимости записи журнала на диск до завершения транзакций. Таким образом, если у вас есть транзакции, которые обновляют, вставляют или удаляют много строк, увеличение размера буфера журнала экономит операции ввода-вывода на диске. Для получения дополнительной информации см. Конфигурация памяти и Раздел 8.5.4, «Оптимизация повторной записи журнала InnoDB». Для получения общих рекомендаций по настройке ввода-вывода см. Раздел 8.5.8, «Оптимизация дискового ввода-вывода InnoDB».

innodb_log_checkpoint_now

Включите этот параметр отладки, чтобы принудительно заставить InnoDB записать контрольную точку. Эта опция доступна только в том случае, если поддержка отладки включена в компиляцию с помощью опции WITH_DEBUG CMake.

innodb_log_checksums

Включает или отключает контрольные суммы для страниц журнала повторной записи.

innodb_log_checksums=ON включает алгоритм контрольной суммы CRC-32C для страниц журнала повторной записи. Когда innodb_log_checksums отключен, содержимое поля контрольной суммы страницы журнала повторной записи игнорируется.

Контрольные суммы на странице заголовка журнала повторной записи и страницах контрольных точек журнала повторной записи никогда не отключаются.

innodb_log_compressed_pages

Указывает, записываются ли образы страниц в журнал повторной записи. Повторная компрессия может происходить при внесении изменений в сжатые данные.

innodb_log_compressed_pages включен по умолчанию для предотвращения повреждения, которое может произойти, если во время восстановления используется другая версия алгоритма сжатия zlib. Если вы уверены, что версия zlib не изменится, вы можете отключить innodb_log_compressed_pages, чтобы уменьшить объем генерируемого журнала повторной записи для рабочих нагрузок, которые изменяют сжатые данные.

Чтобы измерить влияние включения или отключения innodb_log_compressed_pages, сравните объем генерируемого журнала повторной записи для обеих настроек при одной и той же рабочей нагрузке. Варианты измерения генерации журнала повторной записи включают наблюдение за Log sequence number (LSN) в разделе LOG вывода SHOW ENGINE INNODB STATUS или мониторинг состояния Innodb_os_log_written для количества байтов, записанных в файлы журнала повторной записи.

Для получения дополнительной информации см. Раздел 14.9.1.6, «Сжатие для рабочих нагрузок OLTP».

innodb_log_file_size

Размер в байтах каждого файла журнала в группе. Суммарный размер файлов журнала (innodb_log_file_size * innodb_log_files_in_group) не может превышать максимальное значение, которое немного меньше 512 ГБ. Например, пара файлов журнала размером 255 ГБ приближается к пределу, но не превышает его. Значение по умолчанию — 48 МБ.

Как правило, суммарный размер файлов журнала должен быть достаточно большим, чтобы сервер мог сглаживать пики и спады активности рабочей нагрузки, что часто означает наличие достаточного пространства в журнале повторной записи для обработки более чем часа активности записи. Чем больше значение, тем меньше требуется активности очистки контрольных точек в буферном пуле, что экономит операции ввода-вывода на диске. Более крупные файлы журнала также замедляют восстановление.

Минимальное значение innodb_log_file_size было увеличено с 1 МБ до 4 МБ в MySQL 5.7.11.

Для получения дополнительной информации см. Конфигурация файла журнала повторной записи. Для получения общих рекомендаций по настройке ввода-вывода см. Раздел 8.5.8, «Оптимизация дискового ввода-вывода InnoDB».

innodb_log_files_in_group

Количество файлов в группе журналов. InnoDB записывает в файлы циклически. Значение по умолчанию (и рекомендуемое) — 2. Расположение файлов указывается с помощью innodb_log_group_home_dir. Суммарный размер файлов журнала (innodb_log_file_size * innodb_log_files_in_group) может составлять до 512 ГБ.

Для получения дополнительной информации см. Конфигурация файла журнала повторной записи.

innodb_log_group_home_dir

Путь к каталогу файлов InnoDB, количество которых указывается с помощью innodb_log_files_in_group. Если вы не указываете никаких переменных журнала InnoDB, по умолчанию создаются два файла с именами ib_logfile0 и ib_logfile1 в каталоге данных MySQL. Размер файла журнала задается системной переменной innodb_log_file_size.

Для получения дополнительной информации см. Конфигурация файла журнала повторной записи.

innodb_log_write_ahead_size

Определяет размер блока предварительной записи для журнала отката в байтах. Для предотвращения «чтения при записи», установите innodb_log_write_ahead_size в соответствии с размером блока кэша операционной системы или файловой системы. Значение по умолчанию составляет 8192 байта. Чтение при записи происходит, когда блоки журнала отката не полностью кэшируются в операционной системе или файловой системе из-за несоответствия между размером блока предварительной записи для журнала отката и размером блока кэша операционной системы или файловой системы.

Допустимые значения для innodb_log_write_ahead_size являются кратными размеру блока файла журнала InnoDB (2ⁿ). Минимальное значение равно размеру блока файла журнала InnoDB (512). Предварительная запись не выполняется, когда указано минимальное значение. Максимальное значение равно значению innodb_page_size. Если вы укажете значение для innodb_log_write_ahead_size, которое больше, чем значение innodb_page_size, значение innodb_log_write_ahead_size усекается до значения innodb_page_size.

Установка значения innodb_log_write_ahead_size слишком низким по отношению к размеру блока кэша операционной системы или файловой системы приводит к «чтению при записи». Установка слишком высокого значения может незначительно повлиять на производительность операций записи в файл журнала из-за записи нескольких блоков одновременно.

Для получения дополнительной информации см. Раздел 8.5.4, «Оптимизация журнала отката InnoDB».

innodb_lru_scan_depth

Параметр, влияющий на алгоритмы и эвристики для работы InnoDB. В первую очередь интересен специалистам по производительности, настраивающим задачи с интенсивным вводом-выводом. Он определяет, насколько глубоко в список страниц буферного пула LRU поток очистки страниц сканирует в поисках страниц для вывода. Это фоновая операция, выполняемая один раз в секунду.

Значение, меньшее, чем значение по умолчанию, обычно подходит для большинства задач. Значение, намного большее, чем необходимо, может повлиять на производительность. Увеличивайте значение только в том случае, если у вас есть избыточная емкость ввода-вывода при типичной работе. И наоборот, если задача с интенсивным записью насыщает емкость ввода-вывода, уменьшите значение, особенно в случае большого буферного пула.

При настройке innodb_lru_scan_depth начинайте с низкого значения и увеличивайте его, стремясь к тому, чтобы редко видеть нулевое количество свободных страниц. Также рассмотрите возможность изменения innodb_lru_scan_depth при изменении числа экземпляров буферного пула, поскольку innodb_lru_scan_depth * innodb_buffer_pool_instances определяет объем работы, выполняемой потоком очистки страниц каждую секунду.

Для получения дополнительной информации см. Раздел 14.8.3.5, «Настройка сброса буферного пула». Общие рекомендации по настройке ввода-вывода см. в Разделе 8.5.8, «Оптимизация ввода-вывода InnoDB».

innodb_max_dirty_pages_pct

InnoDB пытается выгрузить данные из кэша, чтобы процент грязных страниц не превысил это значение. Значение по умолчанию составляет 75.

Параметр innodb_max_dirty_pages_pct устанавливает целевое значение для операций сброса. Он не влияет на скорость сброса. Подробности управления скоростью сброса см. в Разделе 14.8.3.5, «Настройка сброса буферного пула».

Для получения дополнительной информации см. Раздел 14.8.3.5, «Настройка сброса буферного пула». Общие рекомендации по настройке ввода-вывода см. в Разделе 8.5.8, «Оптимизация ввода-вывода InnoDB».

innodb_max_purge_lag_delay

Задает максимальную задержку в микросекундах для задержки, накладываемой при превышении порога innodb_max_purge_lag. Указанное значение innodb_max_purge_lag_delay является верхним пределом периода задержки, вычисляемого по формуле innodb_max_purge_lag.

Для получения дополнительной информации см. Раздел 14.8.10, «Конфигурация очистки».

innodb_max_undo_log_size

Определяет пороговый размер для табличных пространств отката. Если табличное пространство отката превышает порог, его можно пометить для усечения, когда включена опция innodb_undo_log_truncate. Значение по умолчанию — 1073741824 байта (1024 MiB).

Для получения дополнительной информации см. Усечение табличных пространств отката.

innodb_merge_threshold_set_all_debug

Определяет значение в процентах, заполненности страницы для страниц индекса, которое переопределяет текущую настройку MERGE_THRESHOLD для всех индексов, которые в данный момент находятся в кэше словаря. Эта опция доступна только в том случае, если поддержка отладки компилируется с использованием опции WITH_DEBUG CMake. Для получения дополнительной информации см. Раздел 14.8.12, «Настройка порогового значения слияния для страниц индекса».

innodb_monitor_disable

Эта переменная действует как переключатель, отключающий InnoDB. Данные счетчиков можно запрашивать с помощью таблицы Information Schema INNODB_METRICS. Для получения информации об использовании см. Раздел 14.16.6, «Таблица метрик InnoDB INFORMATION_SCHEMA».

innodb_monitor_disable='latch' отключает сбор статистики для SHOW ENGINE INNODB MUTEX. Для получения дополнительной информации см. Раздел 13.7.5.15, «Оператор SHOW ENGINE».

innodb_monitor_enable

Эта переменная действует как переключатель, включающий InnoDB. Данные счетчиков можно запрашивать с помощью таблицы Information Schema INNODB_METRICS. Для получения информации об использовании см. Раздел 14.16.6, «Таблица метрик InnoDB INFORMATION_SCHEMA».

innodb_monitor_enable='latch' включает сбор статистики для SHOW ENGINE INNODB MUTEX. Для получения дополнительной информации см. Раздел 13.7.5.15, «Оператор SHOW ENGINE».

innodb_monitor_reset

Эта переменная действует как переключатель, сбрасывающий значение счетчика для InnoDB в ноль. Данные счетчиков можно запрашивать с помощью таблицы Information Schema INNODB_METRICS. Для получения информации об использовании см. Раздел 14.16.6, «Таблица метрик InnoDB INFORMATION_SCHEMA».

innodb_monitor_reset='latch' сбрасывает статистику, предоставляемую SHOW ENGINE INNODB MUTEX. Для получения дополнительной информации см. Раздел 13.7.5.15, «Оператор SHOW ENGINE».

innodb_monitor_reset_all

Эта переменная действует как переключатель, сбрасывающий все значения (минимальное, максимальное и т.д.) для InnoDB. Данные счетчиков можно запрашивать с помощью таблицы Information Schema INNODB_METRICS. Для получения информации об использовании см. Раздел 14.16.6, «Таблица метрик InnoDB INFORMATION_SCHEMA».

innodb_numa_interleave

Включает политику NUMA для интерливирования памяти при выделении кэша страниц буфера InnoDB. Когда innodb_numa_interleave включено, политика NUMA устанавливается на MPOL_INTERLEAVE для процесса mysqld. После выделения кэша страниц буфера InnoDB, политика NUMA восстанавливается до MPOL_DEFAULT. Для того, чтобы параметр innodb_numa_interleave был доступен, MySQL должен быть скомпилирован на системе Linux с поддержкой NUMA.

Начиная с MySQL 5.7.17, CMake устанавливает значение по умолчанию для WITH_NUMA в зависимости от наличия поддержки NUMA на текущей платформе. Более подробная информация доступна в разделе 2.8.7, “Параметры конфигурации исходного кода MySQL”.

innodb_old_blocks_pct

Указывает приблизительный процент кэша страниц буфера InnoDB, используемый для старых блоков. Диапазон значений от 5 до 95. Значение по умолчанию равно 37 (то есть 3/8 кэша). Часто используется в сочетании с innodb_old_blocks_time.

Более подробная информация доступна в разделе 14.8.3.3, “Устойчивость буферного кэша к полным таблицам”. Сведения о управлении буферным кэшем, алгоритме и политиках см. в разделе 14.5.1, “Буферный кэш”.

innodb_old_blocks_time

ненулевые значения предотвращают заполнение кэша данными, к которым обращаются только кратковременно, например, во время запросов. Увеличение этого значения обеспечивает большую защиту от того, что полные сканирования таблиц будут мешать кэшированию данных в буферном кэше.

Указывает, в течение скольки миллисекунд блок, добавленный в старую подгруппу, должен оставаться в ней после первого обращения, прежде чем его можно будет перенести в новую. Если значение равно 0, блок, добавленный в старую подгруппу, сразу переходит в новую при первом обращении, независимо от того, как скоро после добавления произошло обращение. Если значение больше 0, блоки остаются в старой подгруппе до тех пор, пока доступ к ним не произойдет по крайней мере через заданное количество миллисекунд после первого обращения. Например, значение 1000 означает, что блоки останутся в старой подгруппе в течение 1 секунды после первого обращения, прежде чем они смогут переместиться в новую.

Значение по умолчанию равно 1000.

Эта переменная часто используется в сочетании с innodb_old_blocks_pct. Более подробная информация доступна в разделе 14.8.3.3, “Устойчивость буферного кэша к полным таблицам”. Сведения о управлении буферным кэшем, алгоритме и политиках см. в разделе 14.5.1, “Буферный кэш”.

innodb_online_alter_log_max_size

Устанавливает максимальный размер (в байтах) временных файлов журнала, используемых во время операций онлайн-изменения таблиц InnoDB. Для каждой создаваемой индекса или изменяемой таблицы есть один такой файл журнала. Этот файл журнала хранит данные, вставленные, обновленные или удаленные в таблице во время операции DDL. Временный файл журнала расширяется по мере необходимости на величину innodb_sort_buffer_size, до максимального значения, заданного innodb_online_alter_log_max_size. Если размер временного файла журнала превышает предел, операция ALTER TABLE завершается неудачно, и все неподтвержденные одновременные операции DML отменяются. Таким образом, большое значение для этого параметра позволяет выполнять больше операций DML во время онлайн-операции DDL, но также продлевает период блокировки таблицы в конце операции DDL для применения данных из журнала.

innodb_open_files

Указывает максимальное количество файлов, которые могут быть открыты InnoDB одновременно. Минимальное значение равно 10. Если innodb_file_per_table отключен, значение по умолчанию равно 300; в противном случае, значение по умолчанию равно 300 или значению table_open_cache, которое больше.

innodb_optimize_fulltext_only

Изменяет способ работы OPTIMIZE TABLE с InnoDB таблицами. Предполагается временное включение во время операций технического обслуживания InnoDB таблиц с FULLTEXT индексами.

По умолчанию OPTIMIZE TABLE переупорядочивает данные в OPTIMIZE TABLE таблицы. При включении данного параметра OPTIMIZE TABLE пропускает переупорядочивание данных таблицы, а вместо этого обрабатывает новые добавленные, удаленные и обновленные данные токенов для InnoDB FULLTEXT индексов. Для получения дополнительной информации см. Оптимизация индексов InnoDB Full-Text.

innodb_page_cleaners

Количество потоков обработчиков страниц, которые очищают грязные страницы из экземпляров буфера пула. Потоки обработчиков страниц выполняют очистку списков и очистку по алгоритму LRU. Поток обработчика страниц был введён в MySQL 5.6 для перегрузки работы по очистке буфера пула от потока InnoDB master. В MySQL 5.7, InnoDB поддерживает несколько потоков обработчиков страниц. Значение 1 сохраняет конфигурацию, существовавшую до MySQL 5.7, в которой был только один поток обработчика страниц. Когда используется несколько потоков обработчиков страниц, задачи по очистке буфера пула для каждого экземпляра буфера пула распределяются между свободными потоками обработчиков страниц. Значение по умолчанию для innodb_page_cleaners было изменено с 1 на 4 в MySQL 5.7. Если количество потоков обработчиков страниц превышает количество экземпляров буфера пула, innodb_page_cleaners автоматически устанавливается в то же значение, что и innodb_buffer_pool_instances.

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

Поддержка многопоточных обработчиков страниц расширена до фаз завершения и восстановления в MySQL 5.7.

Системный вызов setpriority() используется на платформах Linux, где он поддерживается, и где пользователь, под которым выполняется mysqld, имеет право назначать приоритет потокам page_cleaner перед другими потоками MySQL и InnoDB потоками, чтобы помочь очистке страниц соответствовать текущей рабочей нагрузке. Поддержка setpriority() указана в этом сообщении о запуске InnoDB:

[Note] InnoDB: If the mysqld execution user is authorized, page cleaner
thread priority can be changed. See the man page of setpriority().

Для систем, где запуск и остановка сервера не управляется systemd, авторизацию пользователя, под которым выполняется mysqld, можно настроить в /etc/security/limits.conf. Например, если mysqld запускается под пользователем mysql, вы можете авторизовать пользователя mysql, добавив эти строки в /etc/security/limits.conf:

mysql              hard    nice       -20
mysql              soft    nice       -20

В системах, управляемых systemd, это можно сделать, указав LimitNICE=-20 в локальном файле конфигурации systemd. Например, создайте файл с именем override.conf в /etc/systemd/system/mysqld.service.d/override.conf и добавьте эту запись:

[Service]
LimitNICE=-20

После создания или изменения override.conf перезагрузите конфигурацию systemd, а затем попросите systemd перезапустить службу MySQL:

systemctl daemon-reload
systemctl restart mysqld  # RPM platforms
systemctl restart mysql   # Debian platforms

Дополнительную информацию об использовании локального файла конфигурации systemd см. в разделе Настройка systemd для MySQL.

После авторизации пользователя, под которым выполняется mysqld, используйте команду cat для проверки настроенных Nice ограничений для процесса mysqld:

$> cat /proc/mysqld_pid/limits | grep nice
Max nice priority         18446744073709551596 18446744073709551596

innodb_page_size

Указывает размер страницы для InnoDB. Значения можно указывать в байтах или килобайтах. Например, значение размера страницы в 16 килобайт можно указать как 16384, 16КБ или 16к.

innodb_page_size можно настроить только до инициализации экземпляра MySQL и нельзя изменить после. Если значение не указано, экземпляр инициализируется с использованием значения размера страницы по умолчанию. См. Раздел 14.8.1, «Конфигурация запуска InnoDB».

Поддержка размеров страниц 32КБ и 64КБ была добавлена в MySQL 5.7. Для размеров страниц 32КБ и 64КБ максимальная длина строки составляет приблизительно 16000 байт. ROW_FORMAT=COMPRESSED не поддерживается, когда innodb_page_size установлено на 32КБ или 64КБ. Для innodb_page_size=32k размер экстента составляет 2 МБ. Для innodb_page_size=64KB размер экстента составляет 4 МБ. innodb_log_buffer_size следует установить не менее 16 МБ (значение по умолчанию) при использовании размеров страниц 32КБ или 64КБ.

Размер страницы по умолчанию 16КБ или больше подходит для широкого спектра, особенно для запросов, включающих сканирование таблиц и операций DML, связанных с массовыми обновлениями. Более мелкие размеры страниц могут быть эффективнее для рабочих нагрузок, включающих множество небольших записей, где проблема может заключаться в конкурентной ситуации, когда одна страница содержит много строк. Более мелкие страницы также могут быть эффективными с устройствами хранения данных, которые, как правило, используют небольшие размеры блоков. Поддержание размера страницы InnoDB близким к размеру блока устройства хранения минимизирует количество неизменённых данных, которые перезаписываются на диск.

Минимальный размер файла для первого файла данных системного пространства таблиц (ibdata1) отличается в зависимости от значения innodb_page_size. Дополнительную информацию см. в описании параметра innodb_data_file_path.

Экземпляр MySQL, использующий определённый размер страницы InnoDB, не может использовать файлы данных или журнальные файлы из экземпляра, использующего другой размер страницы.

Советы по общей настройке I/O см. в разделе Раздел 8.5.8, «Оптимизация ввода-вывода InnoDB на диске».

innodb_print_all_deadlocks

При включении этого параметра информация обо всех в транзакциях пользователя InnoDB записывается в журнал ошибок mysqld. В противном случае вы увидите информацию только о последнем тупике, используя команду SHOW ENGINE INNODB STATUS. Иногда InnoDB тупик не является проблемой, потому что InnoDB сразу обнаруживает это состояние и откатывает одну из транзакций автоматически. Вы можете использовать этот параметр для отладки причин возникновения тупиков, если приложение не имеет соответствующей логики обработки ошибок для обнаружения отката и повторного выполнения операции. Большое количество тупиков может указывать на необходимость перестройки транзакций, которые издают или SELECT ... FOR UPDATE операторы для нескольких таблиц, чтобы каждая транзакция обращалась к таблицам в одном и том же порядке, тем самым избегая тупиковой ситуации.

Для связанной информации см. Раздел 14.7.5, «Тупики в InnoDB».

innodb_purge_batch_size