14.2.6. InnoDB Опции запуска и Системные Переменные

--ignore-builtin-innodb

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

--innodb[=value]

Загрузка средств управления InnoDB механизм хранения, если сервер был скомпилирован с InnoDB поддержка. У этой опции есть формат с тремя состояниями с возможными значениями OFF, ON, или FORCE. См. Раздел 5.1.8.1, "Устанавливая и Удаляя Плагины".

Отключить InnoDB, использовать --innodb=OFF или --skip-innodb. В этом случае, потому что механизм хранения значения по умолчанию InnoDB, сервер не будет запускаться, если Вы также не будете использовать --default-storage-engine и --default-tmp-storage-engine установить значение по умолчанию в некоторый другой механизм и для постоянного и для TEMPORARY таблицы.

--innodb-status-file

Средства управления, ли InnoDB создает названный файл innodb_status.pid в каталоге данных MySQL. Если включено, InnoDB периодически пишет вывод SHOW ENGINE INNODB STATUS к этому файлу.

По умолчанию файл не создается. Чтобы создать это, запустите mysqld с --innodb-status-file=1 опция. Файл удаляется во время нормального завершения работы.

--skip-innodb

Отключите InnoDB механизм хранения. См. описание --innodb.

daemon_memcached_enable_binlog

См. Раздел 14.2.9, "Интеграция InnoDB с memcached" для использования детализирует для этой опции.

daemon_memcached_engine_lib_name

См. Раздел 14.2.9, "Интеграция InnoDB с memcached" для использования детализирует для этой опции.

daemon_memcached_engine_lib_path

См. Раздел 14.2.9, "Интеграция InnoDB с memcached" для использования детализирует для этой опции.

daemon_memcached_option

См. Раздел 14.2.9, "Интеграция InnoDB с memcached" для использования детализирует для этой опции.

daemon_memcached_r_batch_size

Определяет сколько memcached операций чтения (get) выполнять прежде, чем сделать a COMMIT запустить новую транзакцию. Дубликат daemon_memcached_w_batch_size.

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

См. Раздел 14.2.9, "Интеграция InnoDB с memcached" для использования детализирует для этой опции.

daemon_memcached_w_batch_size

Определяет сколько memcached операций записи, такой как add, set, или incr, выполнять прежде, чем сделать a COMMIT запустить новую транзакцию. Дубликат daemon_memcached_r_batch_size.

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

См. Раздел 14.2.9, "Интеграция InnoDB с memcached" для использования детализирует для этой опции.

ignore_builtin_innodb

См. описание --ignore-builtin-innodb под"InnoDB Опции команды" ранее в этом разделе.

innodb_adaptive_flushing

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

innodb_adaptive_flushing_lwm

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

innodb_adaptive_hash_index

Ли InnoDB адаптивный хеш индексирует, включается или отключается. Адаптивный хеш индексирует функцию, полезно для некоторых рабочих нагрузок, а не для других; проведите сравнительные тесты с этим и включенный и отключенные, использующие реалистические рабочие нагрузки. См. Раздел 14.2.3.13.6, "Адаптивный Хеш Индексирует" для деталей. Эта переменная включается по умолчанию. Использовать --skip-innodb_adaptive_hash_index в сервере запускаются, чтобы отключить это.

innodb_adaptive_max_sleep_delay

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

innodb_additional_mem_pool_size

Размер в байтах пула памяти InnoDB использование, чтобы хранить информацию словаря данных и другие внутренние структуры данных. Чем больше таблиц, которые Вы имеете в своем приложении, тем больше памяти Вы выделяете здесь. Если InnoDB исчерпывает память в этом пуле, она начинает выделять память от операционной системы и пишет предупреждающие сообщения в журнал ошибок MySQL. Значение по умолчанию составляет 8 МБ.

Эта переменная касается InnoDB средство выделения внутренней памяти, которое неиспользовано если innodb_use_sys_malloc включается. С MySQL 5.6.3, innodb_additional_mem_pool_size осуждается и будет удален в будущем выпуске MySQL.

innodb_api_bk_commit_interval

Как часто автоматически фиксировать неактивные соединения, которые используют InnoDB интерфейс memcached, в секундах. См. Раздел 14.2.9, "Интеграция InnoDB с memcached" для использования детализирует для этой опции.

innodb_api_disable_rowlock

См. Раздел 14.2.9, "Интеграция InnoDB с memcached" для использования детализирует для этой опции.

innodb_api_enable_binlog

Позволяет Вам использовать InnoDB плагин memcached с двоичным журналом MySQL. См. Раздел 14.2.9, "Интеграция InnoDB с memcached" для использования детализирует для этой опции.

innodb_api_enable_mdl

Блокирует таблицу, используемую InnoDB плагин memcached, так, чтобы это не могло быть отброшено или изменено DDL через интерфейс SQL. См. Раздел 14.2.9, "Интеграция InnoDB с memcached" для использования детализирует для этой опции.

innodb_api_trx_level

Позволяет Вам управлять уровнем изоляции транзакции на запросах, обработанных интерфейсом memcached. См. Раздел 14.2.9, "Интеграция InnoDB с memcached" для использования детализирует для этой опции. Константы, соответствующие знакомым именам:

innodb_autoextend_increment

Размер инкремента (в Мбайте) для того, чтобы расширить размер авторасширения InnoDB системный файл табличной области, когда это становится полным. Значение по умолчанию 64. Эта переменная не влияет на файлы табличной области на таблицу, которые создаются, если Вы используете innodb_file_per_table=1. Те файлы авторасширяются независимо от значения innodb_autoextend_increment. Начальные расширения небольшими количествами, после которых расширения происходят в инкрементах 4 МБ.

innodb_autoinc_lock_mode

Режим блокировки, чтобы использовать для того, чтобы генерировать автоинкрементные значения. Допустимые значения 0, 1, или 2, для "традиционного", "последовательного", или "чередованного" режима блокировки, соответственно. Раздел 5.4.4,"AUTO_INCREMENT Обработка в InnoDB" , описывает характеристики этих режимов.

У этой переменной есть значение по умолчанию 1 ("последовательный" режим блокировки).

innodb_buffer_pool_dump_at_shutdown

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

innodb_buffer_pool_dump_now

Сразу записывает страницы, кэшируемые в пуле буферов InnoDB. Обычно используемый в комбинации с innodb_buffer_pool_load_now.

innodb_buffer_pool_filename

Определяет файл, который содержит список номеров страниц, произведенных innodb_buffer_pool_dump_at_shutdown или innodb_buffer_pool_dump_now.

innodb_buffer_pool_instances

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

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

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

innodb_buffer_pool_load_abort

Прерывает процесс восстановления содержания пула буферов InnoDB, инициированного innodb_buffer_pool_load_at_startup или innodb_buffer_pool_load_now.

innodb_buffer_pool_load_at_startup

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

innodb_buffer_pool_load_now

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

innodb_buffer_pool_size

Размер в байтах пула буферов, область памяти, где InnoDB таблица кэшей и индексирует данные. Значение по умолчанию составляет 128 МБ. Максимальное значение зависит от архитектуры ЦП; максимум 4294967295 ^(232-1) на 32-разрядных системах и 18446744073709551615 ^(264-1) на 64-разрядных системах. На 32-разрядных системах архитектура ЦП и операционная система могут наложить более низкий практический максимальный размер чем установленный максимум. Когда размер пула буферов больше чем 1 Гбайт, устанавливая innodb_buffer_pool_instances к значению, больше чем 1, может улучшить масштабируемость относительно занятого сервера.

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

innodb_change_buffer_max_size

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

innodb_change_buffering

Ли InnoDB выполняет буферизацию изменения, оптимизация, которая задерживает операции записи к вторичному, индексирует так, чтобы операции ввода-вывода могли быть выполнены последовательно. Разрешенные значения inserts (буферные операции вставки), deletes (буфер удаляет операции; строго говоря, записи, что метка индексирует записи для более позднего удаления во время работы чистки), changes (буферная вставка и удаленный отмеченные операции), purges (буферизуйте операции чистки, записи, когда удаленные элементы индекса наконец собираются "мусор"), all (буферная вставка, удаленный отмеченный, и операции чистки) и none (не буферизуйте операции). Значение по умолчанию all. Для получения дополнительной информации см. Раздел 14.2.4.2.13, "Управляя Буферизацией Изменения InnoDB". Для общего настраивающего совета ввода-вывода см. Раздел 8.5.7, "Оптимизируя InnoDB Дисковый ввод-вывод".

innodb_checksum_algorithm

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

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

strict_* формы работают то же самое как innodb, crc32, и none, за исключением того, что InnoDB остановы, если это встречается с соединением значений контрольной суммы в той же самой табличной области. Можно только использовать эти опции в абсолютно новом экземпляре, чтобы установить все табличные области впервые. strict_* настройки несколько быстрее, потому что они не должны вычислить и новые и старые значения контрольной суммы, чтобы принять обоих во время чтения с диска.

Для информации об использовании, включая матрицу допустимых комбинаций значений контрольной суммы во время операций чтения и операций записи, см. Раздел 14.2.4.2.7, "Быстро Алгоритм Контрольной суммы CRC32".

innodb_checksums

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

В MySQL 5.6.3 и выше, эта опция осуждается, заменяется innodb_checksum_algorithm. innodb_checksum_algorithm=innodb то же самое как innodb_checksums=ON (значение по умолчанию). innodb_checksum_algorithm=none то же самое как innodb_checksums=OFF. Удалите любого 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 сжатые таблицы.

innodb_commit_concurrency

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

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

innodb_compression_failure_threshold_pct

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

innodb_compression_level

innodb_compression_pad_pct_max

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

innodb_concurrency_tickets

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

innodb_data_file_path

Пути к человеку InnoDB файлы данных и их размеры. Полный путь к каталогу к каждому файлу данных формируется, конкатенируя innodb_data_home_dir к каждому пути, определенному здесь. Размеры файла определяются в Кбайте, Мбайте, или Гбайт (1024 МБ), добавляя K, M, или G к значению размера. Сумма размеров файлов должна быть, по крайней мере, немного больше чем 10 МБ. Если Вы не определяете innodb_data_file_path, поведение значения по умолчанию должно создать единственный авторасширяющийся файл данных, немного больше чем 12 МБ, названных ibdata1. Предел размера отдельных файлов определяется Вашей операционной системой. Можно установить размер файла больше чем в 4 Гбайт на тех операционных системах, которые поддерживают большие файлы. Можно также использовать необработанные разделы диска в качестве файлов данных. Для получения дальнейшей информации на конфигурировании InnoDB файлы табличной области, см. Раздел 14.2.1.2, "Конфигурируя InnoDB".

innodb_data_home_dir

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

innodb_disable_sort_file_cache

Если включено, эта переменная отключает кэш файловой системы операционной системы для сортировки с объединением временные файлы. Эффект состоит в том, чтобы открыть такие файлы с эквивалентом O_DIRECT.

innodb_doublewrite

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

innodb_fast_shutdown

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

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

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

innodb_file_format

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

innodb_file_format_check

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

innodb_file_format_max

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

innodb_file_per_table

Когда innodb_file_per_table включается (значение по умолчанию в 5.6.6 и выше), InnoDB хранит данные и индексирует для каждой недавно составленной таблицы в отдельном .ibd файл, а не в системной табличной области. Хранение для них InnoDB таблицы исправляются, когда такие таблицы отбрасываются или усеченные. Эта установка включает несколько другим InnoDB функции, такие как табличное сжатие. См. Раздел 5.4.1, "Управляя Табличными областями InnoDB" для деталей о таких функциях.

Когда innodb_file_per_table отключается, InnoDB хранит данные для всех таблиц и индексирует в ibdata файлах, которые составляют системную табличную область. Эта установка уменьшает издержки производительности операций файловой системы для операций такой как DROP TABLE или TRUNCATE TABLE. Для серверной среды является самым уместным, где все устройства хранения посвящаются данным MySQL. Поскольку системная табличная область никогда не уменьшается, и совместно используется через все базы данных в экземпляре, избегите загружать огромное количество временных данных на ограниченной пространством системе когда innodb_file_per_table=OFF. Установите отдельный экземпляр в таких случаях, так, чтобы можно было отбросить весь экземпляр, чтобы исправить пространство.

По умолчанию, innodb_file_per_table включается с MySQL 5.6.6, отключенного перед этим. Рассмотрите отключение этого, если обратная совместимость с MySQL 5.5 или 5.1 является беспокойством. Это предотвратит ALTER TABLE от перемещения InnoDB таблицы от системной табличной области до человека .ibd файлы.

innodb_flush_log_at_timeout

Запишите и сбросьте журналы каждый N секунды. innodb_flush_log_at_timeout был представлен в MySQL 5.6.6. Это позволяет периоду тайм-аута между сбросами быть увеличенным, чтобы уменьшить сбрасывание и избежать воздействовать на производительность двоичной групповой фиксации журнала. До MySQL 5.6.6, сбрасывая частоту был однажды в секунду. Настройка по умолчанию для innodb_flush_log_at_timeout также однажды в секунду.

innodb_flush_log_at_trx_commit

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

Для самой большой длительности и непротиворечивости в использовании установки репликации InnoDB с транзакциями использовать innodb_flush_log_at_trx_commit=1 и sync_binlog=1 в Вашем главном сервере my.cnf файл.

innodb_flush_method

Управляет системными вызовами, используемыми, чтобы сбросить данные к InnoDB файлы данных и файлы журнала, которые могут влиять на пропускную способность ввода-вывода. Эта переменная важна только для систем Unix и Linux. На системах Windows метод сброса всегда async_unbuffered и не может быть изменен.

По умолчанию, InnoDB использование fsync() системный вызов, чтобы сбросить и файлы данных и файлы журнала. Если innodb_flush_method опция устанавливается в O_DSYNC, InnoDB использование O_SYNC открыть и сбросить файлы журнала, и fsync() сбросить файлы данных. Если O_DIRECT определяется (доступный на некоторых версиях GNU/Linux, FreeBSD, и Солярисе), InnoDB использование O_DIRECT (или directio() на Солярисе), чтобы открыть файлы данных, и использование fsync() сбросить и файлы данных и файлы журнала. Отметьте это InnoDB использование fsync() вместо fdatasync(), и это не использует O_DSYNC по умолчанию, потому что были проблемы с этим на многих вариантах Unix.

Альтернативная установка O_DIRECT_NO_FSYNC: это использует O_DIRECT флаг во время сбрасывания ввода-вывода, но пропусков fsync() системный вызов впоследствии. Эта установка является подходящей для некоторых типов файловых систем, но не других. Например, это не является подходящим для XFS. Если Вы не уверены, требует ли файловая система, которую Вы используете, fsync(), например, чтобы сохранить все метаданные файла, использовать O_DIRECT вместо этого.

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

Прежде, значение fdatasync также определенный поведение значения по умолчанию. Это значение было удалено, из-за беспорядка что значение fdatasync вызванный fsync() системные вызовы, а не fdatasync() для того, чтобы сбросить. Чтобы получить значение по умолчанию теперь, не устанавливайте значение для innodb_flush_method при запуске.

innodb_flush_neighbors

Определяет, сбрасывает ли сбрасывание страницы от пула буферов InnoDB также другие грязные страницы в той же самой степени.

Когда табличные данные хранятся на традиционном устройстве хранения HDD, сбрасывание таких соседних страниц в одной работе уменьшает издержки ввода-вывода (прежде всего для операций поиска на диске) по сравнению со сбрасыванием отдельных страниц в разное время. Для табличных данных, хранивших на SSD, время поиска не является значимым фактором, и можно выключить эту установку, чтобы распространить операции записи. Для общего настраивающего совета ввода-вывода см. Раздел 8.5.7, "Оптимизируя InnoDB Дисковый ввод-вывод".

innodb_force_load_corrupted

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

innodb_force_recovery

Режим восстановления катастрофического отказа, обычно только измененный в серьезных ситуациях с поиском и устранением неисправностей. Возможные значения от 0 до 6. Значения этих значений описываются в Разделе 14.2.4.6, "Запускаясь InnoDB на Поврежденной Базе данных" .

innodb_ft_aux_table

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

innodb_ft_cache_size

Размер кэша, который содержит проанализированный документ в памяти, создавая InnoDB FULLTEXT индексировать.

innodb_ft_enable_diag_print

Включить ли дополнительному полнотекстовому выводу диагностики поиска.

innodb_ft_enable_stopword

Определяет, что ряд stopwords связывается с InnoDB FULLTEXT индексируйте в то время, когда индексирование создается. Если innodb_ft_user_stopword_table опция устанавливается, stopwords берутся от той таблицы. Еще, если innodb_ft_server_stopword_table опция устанавливается, stopwords берутся от той таблицы. Иначе, встроенный набор значения по умолчанию stopwords используется.

innodb_ft_max_token_size

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

innodb_ft_min_token_size

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

innodb_ft_num_word_optimize

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

innodb_ft_server_stopword_table

Имя таблицы, содержащей список слов, чтобы проигнорировать, создавая InnoDB FULLTEXT индексируйте в формате db_name/table_name.

innodb_ft_sort_pll_degree

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

innodb_ft_user_stopword_table

Имя таблицы, содержащей список слов, чтобы проигнорировать, создавая InnoDB FULLTEXT индексируйте в формате db_name/table_name.

innodb_io_capacity

innodb_io_capacity параметр устанавливает верхний предел, на экземпляр пула буферов, на действии ввода-вывода, выполняемом InnoDB фоновые задачи, такие как сбрасывание страниц от пула буферов и слияния данных от буфера вставки. Значение по умолчанию 200. Для занятых систем, способных к более высоким уровням ввода-вывода, можно установить более высокое значение при запуске сервера, чтобы помочь серверу обработать фоновую работу обслуживания, связанную с высоким показателем изменений строки.

Для систем с отдельными дисками на 7200 ОБ/МИН или на 5400 ОБ/МИН Вы могли бы понизить значение к прежнему значению по умолчанию 100.

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

Значение представляет предполагаемую пропорцию операций в секунду ввода-вывода (IOP), доступные дисководам старшего поколения, которые могли выполнить приблизительно 100 IOP. Текущее значение по умолчанию 200 отражает, что современные устройства хранения способны к намного более высоким уровням ввода-вывода.

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

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

Можно установить innodb_io_capacity оцените любому номеру 100 или больше, и значение по умолчанию 200. Можно установить значение этого параметра в файле опции MySQL (my.cnf или my.ini) или измените это динамически с SET GLOBAL команда, которая требует SUPER полномочие.

См. Раздел 14.2.4.2.20, "Управляя Ведущим Уровнем ввода-вывода Потока InnoDB" для большего количества направляющих линий об этой опции. Для получения общей информации о производительности ввода-вывода InnoDB, см. Раздел 8.5.7, "Оптимизируя InnoDB Дисковый ввод-вывод".

innodb_io_capacity_max

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

В течение краткого периода во время разработки MySQL 5.6 эта переменная была известна как innodb_max_io_capacity.

innodb_large_prefix

Позвольте этой опции позволить, индексируют ключевые префиксы дольше чем 767 байтов (до 3072 байтов), для InnoDB таблицы, которые используют DYNAMIC и COMPRESSED форматы строки. (Составление таких таблиц также требует значений опции innodb_file_format=barracuda и innodb_file_per_table=true.) См. Раздел 14.2.7, "Пределы на InnoDB Таблицы" для соответствующих максимумов, связанных с, индексируют ключевые префиксы при различных настройках.

Для таблиц, используя REDUNDANT и COMPACT форматы строки, эта опция не влияет на позволенную ключевую длину префикса. Это действительно представляет новую ошибочную возможность. Когда эта установка включается, пытаясь создать индексировать префикс с длиной ключа, больше чем 3072 для a REDUNDANT или COMPACT таблица вызывает ошибку ER_INDEX_COLUMN_TOO_LONG (1727).

innodb_lock_wait_timeout

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

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

Когда блокировка ожидает, тайм-аут происходит, текущий оператор откатывается (не вся транзакция). Чтобы иметь всю транзакцию откатывают, запускают сервер с --innodb_rollback_on_timeout опция. См. также Раздел 14.2.3.15,"InnoDB Обработка ошибок".

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

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

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

innodb_locks_unsafe_for_binlog

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

Обычно, InnoDB использует алгоритм, названный следующим ключом, блокирующим, который комбинирует блокировку индексировать-строки с блокировкой разрыва. InnoDB выполняет привязку на уровне строки такого пути, которые, когда это ищет или сканирует таблицу, индексируют, это устанавливает коллективные или монопольные блокировки на индексировать записях, с которыми это встречается. Таким образом блокировки на уровне строки являются фактически блокировками индексировать-записи. Кроме того, следующая блокировка ключа на индексировать записи также влияет на "разрыв" прежде, чем это индексирует запись. Таким образом, следующая блокировка ключа является блокировкой индексировать-записи плюс разрыв, соединяют разрыв, предшествующий индексировать записи. Если у одного сеанса есть коллективная или монопольная блокировка на записи R в индексировании другой сеанс не может вставить новое, индексируют запись в разрыве сразу прежде R в индексировать порядке. См. Раздел 14.2.3.5,"InnoDB Запись, Разрыв, и Следующие блокировки ключа".

По умолчанию, значение 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. Для дополнительных деталей об эффекте уровня изоляции на блокировке разрыва см. Раздел 13.3.6,"SET TRANSACTION Синтаксис".

Включение 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.2.3.6, "Избегая Фантомной проблемы Используя Блокировку Следующего ключа".

Включение 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.2.3.13.2, "Кластеризируемый и Вторичный Индексирует").

Предположите, что один клиент выполняет 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-lockx-lock(2,3); update(2,3) to (2,5); retain x-lockx-lock(3,2); retain x-lockx-lock(4,3); update(4,3) to (4,5); retain x-lockx-lock(5,2); retain x-lock

Второе 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-lockx-lock(3,2); unlock(3,2)x-lock(4,3); update(4,3) to (4,5); retain x-lockx-lock(5,2); unlock(5,2)

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

x-lock(1,2); update(1,2) to (1,4); retain x-lockx-lock(2,3); unlock(2,3)x-lock(3,2); update(3,2) to (3,4); retain x-lockx-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 МБ. Большой буфер журнала позволяет большим транзакциям работать без потребности записать журнал в диск перед фиксацией транзакций. Таким образом, если у Вас есть транзакции, которые обновляют, вставляют, или удаляют много строк, заставляя журнал буферизовать больше сохраняет дисковый ввод-вывод. Для общего настраивающего совета ввода-вывода см. Раздел 8.5.7, "Оптимизируя InnoDB Дисковый ввод-вывод".

innodb_log_compressed_pages

Определяет, сохранены ли изображения пересжатый страницы в InnoDB журналы отката.

innodb_log_file_size

Размер в байтах каждого файла журнала в группе журнала. Объединенный размер файлов журнала (innodb_log_file_size * innodb_log_files_in_group) не может превысить максимальное значение, которое является немного меньше чем 512 Гбайт. Пара файлов журнала на 255 Гбайт, например, позволила бы Вам приближаться к пределу, но не превышать его. Значение по умолчанию составляет 48 МБ. Заметные значения колеблются от 1 МБ до 1/N-th размера пула буферов, где N число файлов журнала в группе. Чем больше значение, тем меньше действия сброса контрольной точки необходимо в пуле буферов, сохраняя дисковый ввод-вывод. Большие файлы журнала также делают восстановление катастрофического отказа медленнее, хотя улучшения производительности восстановления в MySQL 5.5 и выше делают размер файла журнала меньшим количеством рассмотрения. Для общего настраивающего совета ввода-вывода см. Раздел 8.5.7, "Оптимизируя 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_lru_scan_depth

Параметр, который влияет на алгоритмы и эвристику для работы сброса для InnoDB пул буферов. Прежде всего интереса для экспертов по производительности, настраивающих рабочие нагрузки I/O-intensive. Это определяет на экземпляр пула буферов, как далеко вниз пул буферов LRU перечисляет page_cleaner распараллельте сканирования, ища грязные страницы, чтобы сбросить. Это - фоновая работа, выполняемая однажды секунда. Если Вы имеете запасную емкость ввода-вывода при типичной рабочей нагрузке, увеличиваете значение. Если интенсивная записью рабочая нагрузка насыщает Вашу емкость ввода-вывода, уменьшите значение, особенно если у Вас есть большой пул буферов. Для общего настраивающего совета ввода-вывода см. Раздел 8.5.7, "Оптимизируя InnoDB Дисковый ввод-вывод".

innodb_max_dirty_pages_pct

InnoDB попытки сбросить данные от пула буферов так, чтобы процент грязных страниц не превысил это значение. Определите целое число в диапазоне от 0 до 99. Значение по умолчанию 75. Для общего настраивающего совета ввода-вывода см. Раздел 8.5.7, "Оптимизируя InnoDB Дисковый ввод-вывод".

innodb_max_dirty_pages_pct_lwm

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

innodb_max_purge_lag

Эта переменная управляет, как задержаться INSERT, UPDATE, и DELETE операции, когда операции чистки отстают (см. Раздел 14.2.3.11,"InnoDB Мультиуправление версиями"). Значение по умолчанию 0 (никакие задержки).

InnoDB система транзакции поддерживает список транзакций, которые имеют, индексируют записи, удаляют - отмеченный UPDATE или DELETE операции. Длина этого списка представляет purge_lag значение. Когда purge_lag превышает innodb_max_purge_lag, каждый INSERT, UPDATE, и DELETE работа задерживается.

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

Типичная установка для проблематичной рабочей нагрузки могла бы быть 1 миллионом, предполагая, что транзакции являются маленькими, только 100 байтов в размере, и допустимо иметь 100 МБ неочищенных InnoDB строки таблицы.

Значение задержки выводится на экран как длина списка предыстории в TRANSACTIONS раздел Монитора InnoDB выводится. Например, если вывод включает следующие строки, значение задержки 20:

------------TRANSACTIONS------------Trx id counter 0 290328385Purge done for trx's n:o < 0 290315608 undo n:o < 0 17History list length 20

Для общего настраивающего совета ввода-вывода см. Раздел 8.5.7, "Оптимизируя InnoDB Дисковый ввод-вывод".

innodb_max_purge_lag_delay

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

Для общего настраивающего совета ввода-вывода см. Раздел 8.5.7, "Оптимизируя InnoDB Дисковый ввод-вывод".

innodb_monitor_disable

Выключает один или более счетчиков в INFORMATION_SCHEMA.INNODB_METRICS таблица. Для информации об использовании см. Раздел 19.30.19," INFORMATION_SCHEMA INNODB_METRICS Таблица".

innodb_monitor_enable

Включает один или более счетчиков в INFORMATION_SCHEMA.INNODB_METRICS таблица. Для информации об использовании см. Раздел 19.30.19," INFORMATION_SCHEMA INNODB_METRICS Таблица".