14.2.4.2. InnoDB Производительность и Улучшения Масштабируемости

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

Запускаясь с MySQL 5.5 и InnoDB 1.1, встроенный механизм хранения InnoDB в пределах MySQL обновляется до полного набора функций и производительности прежнего Плагина InnoDB. Это изменение делает их производительностью и улучшениями масштабируемости доступный для намного более широкой аудитории чем прежде, и устраняет отдельный шаг установки Плагина InnoDB. После узнавания о технических характеристиках InnoDB в этом разделе продолжайте с Главой 8, Оптимизация, чтобы изучить лучшие методы для полной производительности MySQL, и Раздел 8.5, "Оптимизируя для InnoDB Таблицы" в особенности для подсказок InnoDB и направляющих линий.

Традиционно, InnoDB функция сжатия рекомендовалась прежде всего для только для чтения или рабочих нагрузок чтения главным образом, такой как в конфигурации хранилища данных. Повышение устройств хранения SSD, которые являются быстрыми, но относительно маленькими и дорогими, делает сжатие привлекательным также для OLTP рабочие нагрузки: высокий трафик, интерактивные веб-сайты могут уменьшить свои требования хранения и свои операции в секунду ввода-вывода (IOP) при использовании сжатых таблиц с приложениями, которые действительно часто посещают INSERT, UPDATE, и DELETE операции.

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

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

Для получения дополнительной информации по сжатию данных MySQL см. Раздел 5.4.6, "Работающий с InnoDB Сжатые Таблицы". Для аспектов производительности особенно см. Раздел раздела 5.4.6.3, "Настраивая Сжатие для Таблиц InnoDB".

Когда транзакция, как известно, только для чтения, InnoDB может избежать издержек, связанных с установкой ID транзакции (TRX_ID поле). ID транзакции только необходим для транзакции, которая могла бы выполнить операции записи или блокирующие чтения такой как SELECT ... FOR UPDATE. Устранение этих ненужных ID транзакции уменьшает размер внутренних структур данных, с которыми консультируются каждый раз, когда оператор запроса или DML создает представление чтения.

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

Таким образом, для интенсивного чтением приложения, такого как генератор отчетов, можно настроить последовательность InnoDB запросы, группируя их внутри START TRANSACTION READ ONLY и COMMIT, или включая autocommit установка прежде, чем работать SELECT операторы, или просто избегая любых операторов DML вкрапляются запросами.

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

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

Журналы отмены также известны как сегменты отката.

Эта функция включает следующие новые или переименованные параметры конфигурации:

Примечания использования

Чтобы использовать эту функцию, следуйте за этими шагами:

Производительность и Соображения Масштабируемости

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

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

Внутренности

Физические файлы табличной области называют undoN, где N ID пространства, включая начальные нули.

В настоящий момент экземпляры MySQL, содержащие отдельные табличные области отмены, не могут быть понижены к более ранним выпускам, таким как MySQL 5.5 или 5.1.

Преимущества InnoDB установка файла на таблицу, с которой идут компромисс, что каждый .ibd файл расширяется, поскольку данные в таблице растут. Эта работа ввода-вывода может быть узким местом для занятых систем со многими InnoDB таблицы. Когда все InnoDB таблицы сохранены в системной табличной области, эта работа расширения происходит менее часто как пространство, освобожденное DELETE или TRUNCATE операции в пределах одной таблицы могут быть снова использованы другой таблицей.

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

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

И под старыми и под новыми механизмами обнаружения, Вы могли бы встретиться с a search too deep ошибка, которая не является истинной мертвой блокировкой, но требует, чтобы Вы повторили транзакцию тот же самый путь как с мертвой блокировкой.

Можно включить параметру конфигурации innodb_checksum_algorithm=crc32 параметр конфигурации, чтобы изменить алгоритм контрольной суммы на более быстрый, который сканирует блок 32 бита за один раз, а не 8 битов за один раз. Когда алгоритм CRC32 включается, блоки данных, которые пишутся диску InnoDB содержите различные значения в их полях контрольной суммы чем прежде. Этот процесс мог быть постепенным с соединением старых и новых значений контрольной суммы в пределах той же самой таблицы или базы данных.

Для максимальной совместимости сверху вниз эта установка прочь по умолчанию:

Когда устанавливаете новый экземпляр MySQL, и можно убедиться что весь InnoDB данные создаются, используя алгоритм контрольной суммы CRC32, можно использовать установку innodb_checksum_algorithm=strict_crc32, который может быть быстрее чем crc32 установка, потому что это не делает дополнительных вычислений контрольной суммы, чтобы поддерживать и старые и новые значения.

innodb_checksum_algorithm у опции есть другие значения, которые позволяют ей заменять innodb_checksums опция. innodb_checksum_algorithm=none то же самое как innodb_checksums=OFF. innodb_checksum_algorithm=innodb то же самое как innodb_checksums=ON. Чтобы избежать конфликтов, удалите ссылки на innodb_checksums от Вашего конфигурационного файла и MySQL запускают сценарии. Новая опция также принимает значения strict_none и strict_innodb, снова предлагая лучшую производительность в ситуациях, где все InnoDB данные в экземпляре создаются с тем же самым алгоритмом контрольной суммы.

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

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

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

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

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

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

Эта функция включает переменные конфигурации:

и переменные состояния:

Сохранить текущее состояние InnoDB пул буферов, сделайте заявление:

SET innodb_buffer_pool_dump_now=ON;

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

По умолчанию состояние пула буферов сохраняется в файле ib_buffer_pool в InnoDB каталог данных.

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

SET innodb_buffer_pool_dump_now=ON;

SET innodb_buffer_pool_dump_at_shutdown=ON;

SET innodb_buffer_pool_load_at_startup=ON;

SET innodb_buffer_pool_load_now=ON;

SET innodb_buffer_pool_filename='filename';

SHOW STATUS LIKE 'innodb_buffer_pool_dump_status';

SELECT variable_value FROM information_schema.global_status WHEREvariable_name = 'INNODB_BUFFER_POOL_DUMP_STATUS';

SHOW STATUS LIKE 'innodb_buffer_pool_load_status';

SELECT variable_value FROM information_schema.global_status WHEREvariable_name = 'INNODB_BUFFER_POOL_LOAD_STATUS';

SET innodb_buffer_pool_load_abort=ON;

Новые параметры конфигурации innodb_flush_neighbors и innodb_lru_scan_depth позвольте Вам подстраивать определенные аспекты процесса сбрасывания для InnoDB пул буферов. Эти опции прежде всего помогают интенсивным записью рабочим нагрузкам. С тяжелым действием DML может отстать сбрасывание, если это не достаточно агрессивно, приводя к чрезмерному использованию памяти в пуле буферов; или, записи на диск из-за сбрасывания могут насыщать Вашу емкость ввода-вывода, если тот механизм слишком агрессивен. Идеальные настройки зависят от Вашей рабочей нагрузки, образцов доступа к данным, и конфигурации хранения (например, хранятся ли данные на HDD или устройствах SSD).

Для систем с постоянными тяжелыми рабочими нагрузками, или рабочими нагрузками, которые колеблются широко, несколько новых параметров конфигурации, которым позволяют Вы подстроить поведение сбрасывания для InnoDB таблицы: innodb_adaptive_flushing_lwm, innodb_max_dirty_pages_pct_lwm, innodb_io_capacity_max, и innodb_flushing_avg_loops. Эти опции питаются в улучшенную формулу, используемую innodb_adaptive_flushing опция.

Существующее innodb_adaptive_flushing, innodb_io_capacity и innodb_max_dirty_pages_pct работа опций как прежде, за исключением того, что они ограничиваются или расширяются другими опциями: innodb_adaptive_flushing_lwm, innodb_io_capacity_max и innodb_max_dirty_pages_pct_lwm:

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

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

Эта функция идет по умолчанию, включенная параметром конфигурации innodb_stats_persistent.

Вы управляете, сколько выборки делается, чтобы собрать статистические данные, устанавливая параметры конфигурации innodb_stats_persistent_sample_pages и innodb_stats_transient_sample_pages.

Параметр конфигурации innodb_stats_auto_recalc определяет, вычисляются ли статистические данные автоматически всякий раз, когда таблица подвергается существенным изменениям (больше чем к 10 % строк). Если та установка отключается, гарантируйте точность статистики оптимизатора, выходя ANALYZE TABLE оператор для каждой применимой таблицы после создания индексирования или создания существенных изменений к индексированным столбцам. Вы могли бы выполнить этот оператор в своих сценариях установки после того, как представительные данные были загружены в таблицу, и периодически выполняли ее после того, как операции DML значительно изменяют содержание индексированных столбцов, или в расписании во времена низкого действия.

Можно также установить innodb_stats_persistent, innodb_stats_auto_recalc, и innodb_stats_sample_pages опции на сеансовом уровне прежде, чем составить таблицу, или использование STATS_PERSISTENT, STATS_AUTO_RECALC, и STATS_SAMPLE_PAGES пункты на CREATE TABLE и ALTER TABLE операторы, чтобы переопределить установку в масштабе всей системы и сконфигурировать персистентную статистику для отдельных таблиц.

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

Чтобы вернуться к предыдущему методу собирания статистических данных, которые периодически стираются, выполняет команду ALTER TABLE tbl_name STATS_PERSISTENT=0.

Персистентная функция статистики полагается на внутренне управляемые таблицы в mysql база данных, названная innodb_table_stats и innodb_index_stats. Эти таблицы устанавливаются автоматически во всей установке, обновлении, и создают из источника процедуры.

innodb_table_stats и innodb_index_stats таблицы оба включают a last_update столбец, показывающий, когда индексируют статистику, обновлялся, как показано в следующем примере:

mysql> select * from INNODB_TABLE_STATS \G*************************** 1. row ***************************           database_name: sakila              table_name: actor             last_update: 2013-05-28 16:16:44                  n_rows: 200    clustered_index_size: 1sum_of_other_index_sizes: 1...

mysql> select * from INNODB_INDEX_STATS \G*************************** 1. row ***************************   database_name: sakila      table_name: actor      index_name: PRIMARY     last_update: 2013-05-28 16:16:44       stat_name: n_diff_pfx01      stat_value: 200     sample_size: 1     ...

Если Вы вручную обновляете статистику в таблицах во время поиска и устранения неисправностей или настройки, даете команду FLUSH TABLE tbl_name заставить MySQL перезагрузить обновленную статистику.

В MySQL и InnoDB, многократных потоках доступа выполнения совместно использованные структуры данных. InnoDB синхронизирует эти доступы со своей собственной реализацией блокировок чтения-записи и взаимных исключений. InnoDB исторически защитил внутреннее состояние блокировки чтения-записи со взаимным исключением InnoDB. На платформах Unix и Linux внутреннее состояние взаимного исключения InnoDB защищается взаимным исключением Pthreads, как в Станд. IEEE 1003.1c (POSIX.1c).

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

InnoDB реализует взаимные исключения и блокировки чтения-записи со встроенными функциями, обеспеченными Набором Компилятора GNU (GCC) для атомарного доступа к памяти вместо того, чтобы использовать подход Pthreads, ранее используемый. Более определенно, InnoDB, который компилируется с версией 4.1.2 GCC или более поздним использованием атомарный builtins вместо a pthread_mutex_t реализовывать взаимные исключения InnoDB и блокировки чтения-записи.

На 32-разрядном Microsoft Windows InnoDB реализовал взаимные исключения (но не блокировки чтения-записи) с рукописными инструкциями ассемблера. Начинание с Microsoft Windows 2000, функции для Взаимно блокируемого Переменного Доступа доступны, которые подобны встроенным функциям, обеспеченным GCC. На Windows 2000 и выше, InnoDB использует Взаимно блокируемые функции. В отличие от старого рукописного ассемблерного кода, новая реализация поддерживает блокировки чтения-записи и 64-разрядные платформы.

Солярис 10 представленных библиотечных функций для атомарных операций, и InnoDB использует эти функции по умолчанию. Когда MySQL компилируется на Солярисе 10 с компилятором, который не поддерживает встроенные функции, обеспеченные Набором Компилятора GNU (GCC) для атомарного доступа к памяти, InnoDB использует библиотечные функции.

Это изменение улучшает масштабируемость InnoDB на многожильных системах. Эта опция активируется "из поля" на платформах, где это поддерживается. Вы не должны установить параметры или опцию, чтобы использовать в своих интересах улучшенную производительность. На платформах, где GCC, Windows, или функции Соляриса для атомарного доступа к памяти не доступны, InnoDB использует традиционный метод Pthreads реализации блокировки чтения-записи и взаимные исключения.

Когда MySQL запускается, InnoDB пишет сообщение в файл журнала, указывающий, используется ли атомарный доступ к памяти для взаимных исключений для взаимных исключений и блокировок чтения-записи, или ни одного. Если подходящие инструменты используются, чтобы создать InnoDB, и целевой ЦП поддерживает атомарные требуемые операции, InnoDB использует встроенные функции для mutexing. Если кроме того работа сравнивать-и-подкачивать может использоваться на идентификаторах потока (pthread_t), тогда InnoDB использует инструкции для блокировок чтения-записи также.

Отметьте: Если Вы создаете из источника, гарантируете, что процесс сборки должным образом использует в своих интересах Ваши возможности платформы.

Для получения дополнительной информации об импликациях производительности блокировки, см. Раздел 8.10, "Оптимизируя Блокировку Операций".

Когда InnoDB был разработан, средствам выделения памяти, предоставленным операционными системами и библиотеками времени выполнения, часто недоставало производительности и масштабируемости. Тогда, не было никаких библиотек средства выделения памяти, настроенных для многожильных ЦП. Поэтому, InnoDB, реализованный его собственное средство выделения памяти в mem подсистема. Это средство выделения охраняет единственное взаимное исключение, которое может стать узким местом. InnoDB также реализует интерфейс обертки вокруг системного средства выделения (malloc и free) это аналогично охраняет единственное взаимное исключение.

Сегодня, когда многожильные системы стали более широко доступными, и поскольку операционные системы назрели, существенные улучшения были сделаны в средствах выделения памяти, предоставленных операционные системы. Новые средства выделения памяти выполняют лучше и более масштабируемы, чем они были в прошлом. Ведущие высокоэффективные средства выделения памяти включают Hoard, libumem, mtmalloc, ptmalloc, tbbmalloc, и TCMalloc. Большинство рабочих нагрузок, особенно те, где память часто выделяется и выпускается (такие как мультитабличные соединения), преимущество от использования более чрезвычайно настроенного средства выделения памяти в противоположность внутреннему, InnoDB-специфичному средству выделения памяти.

Можно управлять, использует ли InnoDB свое собственное средство выделения памяти или средство выделения операционной системы, устанавливая значение параметра конфигурации системы innodb_use_sys_malloc в файле опции MySQL (my.cnf или my.ini). Если установлено в ON или 1 (значение по умолчанию), InnoDB использует malloc и free функции базовой системы, а не управляют, память объединяет себя в пул. Этот параметр не является динамичным, и вступает в силу только, когда система запускается. Чтобы продолжать использовать средство выделения памяти InnoDB, установить innodb_use_sys_malloc к 0.

Для получения дополнительной информации об импликациях производительности использования памяти InnoDB, см. Раздел 8.9, "Буферизуя и Кэшируясь".

Когда INSERT, UPDATE, и DELETE операции делаются к таблице, часто значения индексированных столбцов (особенно значения вторичных ключей) не находятся в сортированном порядке, требуя, чтобы существенный ввод-вывод, чтобы принести вторичный индексировал современный. У InnoDB есть буфер вставки, который кэши изменяют на вторичные элементы индекса, когда соответствующая страница не находится в пуле буферов, таким образом избегая операций ввода-вывода, не читая в странице из диска. Буферизованные изменения объединяются, когда страница загружается в пул буферов, и обновленная страница позже сбрасывается к диску, используя нормальный механизм. Буферизованные изменения слияний основного потока InnoDB, когда сервер почти неактивен, и во время медленного завершения работы.

Поскольку это может привести к меньшему количеству чтения с диска и записей, эта функция является самой ценной для рабочих нагрузок, которые являются I/O-bound, например приложения с большим объемом операций DML, такие как объем вставляют.

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

Можно управлять степенью, до которой InnoDB выполняет, вставляют буферизацию с параметром конфигурации системы innodb_change_buffering. Можно включить и выключить буферизацию для вставок, удалить операции (когда индексируют записи, первоначально отмечаются для удаления), и произведите чистку операций (когда индексируют записи, физически удаляются). Работа обновления представляется как комбинация вставки и удаления. В MySQL 5.5 и выше, значение по умолчанию изменяется от inserts к all.

Позволенные значения innodb_change_buffering :

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

Для получения дополнительной информации об ускорении INSERT, UPDATE, и DELETE операторы, см. Раздел 8.2.2, "Оптимизируя Операторы DML".

Если таблица соответствует почти полностью в оперативной памяти, самый быстрый способ выполнить запросы на этом состоит в том, чтобы использовать хеш, индексирует, а не поиски B-дерева. Поискы мониторов MySQL на каждом индексируют определенный для таблицы InnoDB. Если это замечает, что бесспорный индексируют значения, получаются доступ часто, это автоматически создает хэш-таблицу в памяти для этого, индексируют. См. Раздел 14.2.3.12.6, "Адаптивный Хеш Индексирует" для вводной информации, и направляющие линии использования для адаптивного хеша индексируют функцию и innodb_adaptive_hash_index параметр конфигурации.

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

В ситуациях, где полезно минимизировать контекстное переключение между потоками, InnoDB может использовать много методов, чтобы ограничить число параллельного выполнения потоков операционной системы (и таким образом число запросов, которые обрабатываются в любой момент). Когда InnoDB получает новый запрос с сеанса пользователя, если число потоков, одновременно выполняющихся, в предопределенном пределе, новых снах запроса в течение короткого времени прежде, чем это попробует еще раз. Запрос, который не может быть перенесен после сна, помещается в first-in/first-out очередь и в конечном счете обрабатывается. Потоки, ожидающие блокировок, не считаются в числе параллельного выполнения потоков.

Можно ограничить число параллельных потоков, устанавливая параметр конфигурации innodb_thread_concurrency. Как только число выполнения потоков достигает этого предела, дополнительного сна потоков в течение многих микросекунд, установленных параметром конфигурации innodb_thread_sleep_delay, прежде, чем быть помещенным в очередь.

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

Значение по умолчанию для innodb_thread_concurrency и подразумеваемый предел значения по умолчанию на числе параллельных потоков был изменен в различных выпусках MySQL и InnoDB. В настоящий момент, значение по умолчанию innodb_thread_concurrency 0, так, чтобы по умолчанию не было никакого предела на числе параллельного выполнения потоков, как показано в Таблице 14.4, "Изменяется на innodb_thread_concurrency".

Отметьте, что InnoDB заставляет потоки спать только, когда число параллельных потоков ограничивается. Когда нет никакого предела на числе потоков, все спорят одинаково, чтобы быть запланированными. Таким образом, если innodb_thread_concurrency 0, значение innodb_thread_sleep_delay игнорируется.

Когда есть предел на числе потоков, InnoDB уменьшает издержки контекстного переключения, разрешая многократные просьбы, обращенные во время выполнения единственного SQL-оператора ввести InnoDB, не наблюдая предела, установленного innodb_thread_concurrency. Так как SQL-оператор (такой как соединение) может включить многократные операции строки в пределах InnoDB, InnoDB присваивает "билеты", которые позволяют потоку неоднократно планироваться с минимальными издержками.

Когда новый SQL-оператор запускается, у потока нет никаких билетов, и это должно наблюдать innodb_thread_concurrency. Как только поток называется, чтобы ввести InnoDB, он присваивается много билетов, которые он может использовать для того, чтобы впоследствии ввести InnoDB. Если билеты заканчиваются, innodb_thread_concurrency наблюдается снова, и дальнейшие билеты присваиваются. Число билетов, чтобы присвоиться определяется глобальной опцией innodb_concurrency_tickets, который является 500 по умолчанию. Потоку, который ожидает блокировки, дают один билет, как только блокировка становится доступной.

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

Для общей информации о производительности об обработке потока MySQL см. Раздел 8.11.5.1, "Как MySQL Uses Threads for Client Connections".

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

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

Новый параметр конфигурации innodb_read_ahead_threshold средства управления, как чувствительный InnoDB находится в обнаружении образцов последовательного доступа страницы. Если число чтения страниц последовательно от степени больше чем или равно innodb_read_ahead_threshold, InnoDB инициирует асинхронную работу чтения вперед всей следующей степени. Это может быть установлено в любое значение от 0-64. Значение по умолчанию 56. Чем выше значение, тем более строгий проверка схемы доступа. Например, если Вы устанавливаете значение в 48, InnoDB инициировал линейный запрос чтения вперед только, когда к 48 страницам в текущей степени получили доступ последовательно. Если бы значение 8, InnoDB инициировал бы асинхронное чтение вперед, даже если бы только к 8 страницам в степени получили доступ последовательно. Можно установить значение этого параметра в конфигурационном файле MySQL, или изменить это динамически с SET GLOBAL команда, которая требует SUPER полномочие.

Случайное чтение вперед является методом, который предсказывает, когда страницы могли бы скоро быть необходимы основанные на страницах уже в пуле буферов, независимо от порядка, в котором были считаны те страницы. Если 13 последовательных страниц от той же самой степени находятся в пуле буферов, InnoDB асинхронно выпускает запрос, чтобы выбрать остающиеся страницы с упреждением степени. Эта функция была первоначально выключена в MySQL 5.5. Это доступно еще раз запуск в MySQL 5.1.59 и 5.5.16 и выше, выключенное по умолчанию. Чтобы активировать эту опцию, установите переменную конфигурации innodb_random_read_ahead.

SHOW ENGINE INNODB STATUS команда выводит на экран статистику, чтобы помочь Вам оценить эффективность алгоритма чтения вперед. С возвратом случайного чтения вперед в MySQL 5.6, SHOW ENGINE INNODB STATUS команда еще раз включает Innodb_buffer_pool_read_ahead_rnd. Innodb_buffer_pool_read_ahead сохраняет его текущее имя. (В более ранних выпусках это было перечислено как Innodb_buffer_pool_read_ahead_seq.) См. Раздел 14.2.5.11, "Более Статистика Чтения вперед" для получения дополнительной информации.

Для получения дополнительной информации о производительности ввода-вывода, см. Раздел 8.5.7, "Оптимизируя InnoDB Дисковый ввод-вывод" и Раздел 8.11.3, "Оптимизируя Дисковый ввод-вывод".

InnoDB использует фоновые потоки, чтобы обслужить различные типы запросов ввода-вывода. Можно сконфигурировать число фоновых потоков, что чтение службы и пишет ввод-вывод на страницах данных, используя параметры конфигурации innodb_read_io_threads и innodb_write_io_threads. Эти параметры показывают число фоновых потоков, используемых для чтения и запросов записи соответственно. Они эффективны на всех поддерживаемых платформах. Можно установить значение этих параметров в файле опции MySQL (my.cnf или my.ini); невозможно изменить их динамически. Значение по умолчанию для этих параметров 4 и допустимые значения располагаются от 1-64.

Цель этого изменения состоит в том, чтобы сделать InnoDB более масштабируемым на системах высокого класса. Каждый фоновый поток может обработать до 256 запросов ввода-вывода на ожидании. Основной источник фонового ввода-вывода является запросами чтения вперед. InnoDB пытается сбалансировать загрузку входящих запросов таким способом, которым большей частью доли фоновых потоков работают одинаково. InnoDB также пытается выделить запросы чтения от той же самой степени до того же самого потока, чтобы увеличить возможности объединения запросов вместе. Если у Вас есть подсистема ввода-вывода высокого класса, и Вы видите больше чем 64 × innodb_read_io_threads чтение на ожидании запрашивает в SHOW ENGINE INNODB STATUS, Вы могли бы получить, увеличивая значение innodb_read_io_threads.

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

Запускаясь в InnoDB 1.1 с MySQL 5.5, асинхронная возможность ввода-вывода, которую InnoDB имел на системах Windows, теперь доступна на системах Linux. (Другие Подобные Unix системы продолжают использовать синхронные вызовы ввода-вывода.) Эта функция улучшает масштабируемость в большой степени систем I/O-bound, которые обычно показывают много чтений/записей на ожидании в выводе команды SHOW ENGINE INNODB STATUS\G.

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

EAGAIN: The specified maxevents exceeds the user's limit of available events. 

при записи более высокого предела /proc/sys/fs/aio-max-nr.

Вообще, если проблема с асинхронной подсистемой ввода-вывода в ОС препятствует тому, чтобы InnoDB запустился, установите опцию innodb_use_native_aio=0 в конфигурационном файле. Этот новый параметр конфигурации применяется к системам Linux только, и не может быть изменен, как только сервер работает.

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

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

Групповая фиксация в InnoDB работала до MySQL 4.x, и работ еще раз с MySQL 5.1 с Плагином InnoDB, и MySQL 5.5 и выше. Введение поддержки распределенных транзакций и Двухфазной фиксации (2PC) в MySQL 5.0 вмешалось в групповую функциональность фиксации InnoDB. Этот вопрос теперь решается.

Групповая функциональность фиксации в InnoDB работает с протоколом Двухфазной фиксации в MySQL. Перевключение групповой функциональности фиксации полностью гарантирует, что упорядочивание фиксации в MySQL binlog и файле журнала InnoDB является тем же самым, как это было прежде. Это означает, что полностью безопасно использовать Резервный продукт MySQL Enterprise с InnoDB 1.0.4 (то есть, Плагин InnoDB с MySQL 5.1) и выше. Когда binlog включается, Вы обычно также устанавливаете параметр конфигурации sync_binlog=0, потому что групповая фиксация для двоичного журнала только поддерживается, если это устанавливается в 0.

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

Для получения дополнительной информации о производительности COMMIT и другие транзакционные операции, см. Раздел 8.5.2, "Оптимизируя InnoDB Управление транзакциями".

Основной поток в InnoDB является потоком, который выполняет различные задачи в фоновом режиме. Большинством этих задач является связанный ввод-вывод, такой как сбрасывание грязных страниц от пула буферов или записи, что изменения от буфера вставки до соответствующего вторичного устройства индексируют. Основной поток пытается выполнить эти задачи в пути, который не оказывает негативное влияние на нормальную работу сервера. Это пытается оценить свободную доступную пропускную способность средств ввода-вывода и настроить ее действия, чтобы использовать в своих интересах эту свободную емкость. Исторически, InnoDB использовал твердое кодированное значение 100 IOP (операции ввода-вывода в секунду) как полная емкость ввода-вывода сервера.

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

Можно установить значение innodb_io_capacity к любому номеру 100 или больше. Значение по умолчанию 200, отражение, что производительность типичных современных устройств ввода-вывода выше чем в первые годы MySQL. Как правило, значения вокруг предыдущего значения по умолчанию 100 являются подходящими для устройств хранения потребительского уровня, такими как жесткие диски до 7200 ОБОРОТОВ В МИНУТУ. Более быстрые жесткие диски, конфигурации RAID, и SSD извлекают выгоду из более высоких значений.

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

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

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

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

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

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

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

Внутреннее сравнительное тестирование также показало, что этот алгоритм не только поддерживает пропускную способность в течение долгого времени, но и может также улучшить полную пропускную способность значительно.

Поскольку адаптивное сбрасывание является новой функцией, которая может значительно влиять на образец ввода-вывода рабочей нагрузки, новый параметр конфигурации позволяет Вам выключать эту функцию. Значение по умолчанию булева параметра innodb_adaptive_flushing TRUE, включение новому алгоритму. Можно установить значение этого параметра в файле опции MySQL (my.cnf или my.ini) или измените это динамически с SET GLOBAL команда, которая требует SUPER полномочие.

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

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

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

Вы не должны сделать ничего, чтобы использовать в своих интересах это улучшение производительности.

Для соображений производительности для InnoDB, блокирующего операции, см. Раздел 8.10, "Оптимизируя Блокировку Операций".

Много взаимных исключений InnoDB и rw-блокировок резервируются в течение короткого времени. На многожильной системе может быть более эффективно для потока непрерывно проверить, может ли это получить взаимное исключение или rw-блокировку некоторое время передо сном. Если взаимное исключение или rw-блокировка становятся доступными в течение этого периода опроса, поток может сразу продолжаться в том же самом интервале времени. Однако, также частый опрос многократными потоками совместно используемого объекта может вызвать "вонь ping кэша", различные процессоры, лишающие законной силы части кэша друг друга. InnoDB минимизирует эту проблему, ожидая случайное время между последующими опросами. Задержка реализуется как занятый цикл.

Можно управлять максимальной задержкой между тестированием взаимного исключения или rw-блокировки, используя параметр innodb_spin_wait_delay. Продолжительность цикла задержки зависит от компилятора C и целевого процессора. (В эру Pentium на 100 МГц модуль задержки был одной микросекундой.) На системе, где все ядра процессора совместно используют быструю кэш-память, Вы могли бы уменьшить максимальную задержку или отключить занятый цикл в целом, устанавливая innodb_spin_wait_delay=0. На системе с многократными микросхемами процессора эффект аннулирования кэша может быть более существенным, и Вы могли бы увеличить максимальную задержку.

Значение по умолчанию innodb_spin_wait_delay 6. Вращение ожидает, задержка является динамическим глобальным параметром, который можно определить в файле опции MySQL (my.cnf или my.ini) или изменение во времени выполнения с командой SET GLOBAL innodb_spin_wait_delay=delay, где delay требуемая максимальная задержка. Изменение настроек требует SUPER полномочие.

Для соображений производительности для InnoDB, блокирующего операции, см. Раздел 8.10, "Оптимизируя Блокировку Операций".

Вместо того, чтобы использовать строго алгоритм LRU, InnoDB использует метод, чтобы минимизировать объем данных, который приносится в пул буферов и никогда не получается доступ снова. Цель состоит в том, чтобы удостовериться, что часто ("горячие") страницы, к которым получают доступ, остаются в пуле буферов, как раз когда считано вперед, и полные сканирования таблицы вводят новые блоки, которые могли бы или не могли бы быть получены доступ позже.

Недавно читайте, блоки вставляются в середину списка, представляющего пул буферов. из списка LRU. Весь недавно страницы чтения вставляются в расположении, которое по умолчанию является 3/8 от хвоста списка LRU. Страницы перемещаются в переднюю сторону списка (последний раз используемый конец), когда к ним получают доступ в пуле буферов впервые. Таким образом страницы, к которым никогда не получают доступ, никогда не добираются до передней части списка LRU, и "возраста" скорее чем со строгим подходом LRU. Это расположение делит список LRU на два сегмента, где нисходящий поток страниц точки вставки считают "старым" и является требуемыми жертвами к замещению LRU.

Для объяснения внутренних работ пула буферов InnoDB и специфических особенностей его заменяющего алгоритма LRU, см. Раздел 8.9.1," InnoDB Пул буферов".

Можно управлять точкой вставки в списке LRU, и выбрать, применяет ли InnoDB ту же самую оптимизацию к блокам, принесенным в пул буферов таблицей, или индексируйте сканирования. Параметр конфигурации innodb_old_blocks_pct управляет процентом "старых" блоков в списке LRU. Значение по умолчанию innodb_old_blocks_pct 37, соответствие исходному фиксированному отношению 3/8. Диапазон значений 5 (новые страницы в возрасте пула буферов очень быстро) к 95 (только 5 % пула буферов резервируются для горячих страниц, делая алгоритм близко к знакомой стратегии LRU).

Оптимизация, которая препятствует пулу буферов взбалтываться чтением вперед, может избежать подобных проблем из-за таблицы или индексировать сканирования. На этих сканированиях к странице данных обычно получают доступ несколько раз в быстрой последовательности и никогда не затрагивается снова. Параметр конфигурации innodb_old_blocks_time определяет окно времени (в миллисекундах) после первого доступа к странице, во время которой к этому можно получить доступ, не будучи перемещенным в переднюю сторону (последний раз используемый конец) списка LRU. Значение по умолчанию innodb_old_blocks_time 0, соответствие исходному поведению перемещения страницы к последний раз используемому концу пула буферов перечисляет, когда к этому сначала получают доступ в пуле буферов. Увеличение этого значения делает все больше блоков, вероятно, чтобы стареть быстрее от пула буферов.

Оба innodb_old_blocks_pct и innodb_old_blocks_time являются динамичными, глобальными и может быть определен в файле опции MySQL (my.cnf или my.ini) или измененный во времени выполнения с SET GLOBAL команда. Изменение настроек требует SUPER полномочие.

Помочь Вам измерить эффект устанавливания этих параметров, SHOW ENGINE INNODB STATUS команда сообщает о дополнительной статистике. BUFFER POOL AND MEMORY раздел похож:

Total memory allocated 1107296256; in additional pool allocated 0Dictionary memory allocated 80360Buffer pool size   65535Free buffers       0Database pages     63920Old database pages 23600Modified db pages  34969Pending reads 32Pending writes: LRU 0, flush list 0, single page 0Pages made young 414946, not young 29306731274.75 youngs/s, 16521.90 non-youngs/sPages read 486005, created 3178, written 1605852132.37 reads/s, 3.40 creates/s, 323.74 writes/sBuffer pool hit rate 950 / 1000, young-making rate 30 / 1000 not 392 / 1000Pages read ahead 1510.10/s, evicted without access 0.00/sLRU len: 63920, unzip_LRU len: 0I/O sum[43690]:cur[221], unzip sum[0]:cur[0]

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

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

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

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

Эффект innodb_old_blocks_time параметр более трудно предсказать чем innodb_old_blocks_pct параметр, является относительно маленьким, и изменяется больше с рабочей нагрузкой. Чтобы достигнуть оптимального значения, проведите свои собственные сравнительные тесты если улучшение производительности от корректировки innodb_old_blocks_pct не достаточно.

Для получения дополнительной информации о пуле буферов InnoDB, см. Раздел 8.9.1," InnoDB Пул буферов".

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

Для получения дополнительной информации о восстановлении InnoDB, см. Раздел 14.2.3.13," InnoDB Процесс восстановления".

Запускаясь с InnoDB 1.1 с MySQL 5.5, можно профилировать определенные внутренние операции InnoDB, использующие функцию MySQL Performance Schema. Этот тип настройки прежде всего для опытных пользователей, те, кто продвигает пределы производительности MySQL, читает исходный код MySQL, и оценивает стратегии оптимизации преодолеть узкие места производительности. DBA могут также использовать эту функцию для планирования мощностей, чтобы видеть, встречается ли их типичная рабочая нагрузка с какими-либо узкими местами производительности с определенной комбинацией ЦП, RAM, и памяти на диске; и если так, чтобы судить, может ли производительность быть улучшена, увеличивая емкость некоторой части системы.

Использовать эту функцию, чтобы исследовать производительность InnoDB:

Для получения дополнительной информации о MySQL Performance Schema, см. Главу 21, MySQL Performance Schema.

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

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

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

Для получения дополнительной информации о пуле буферов InnoDB, см. Раздел 8.9.1," InnoDB Пул буферов".

Запускаясь в InnoDB 1.1 с MySQL 5.5, предел на параллельных транзакциях значительно расширяется, удаляя узкое место с сегментом отката InnoDB, который влиял на системы большой емкости. Предел применяется к параллельным транзакциям, которые изменяют любые данные; транзакции только для чтения не говорят против того максимума.

Единственный сегмент отката теперь делится на 128 сегментов, каждый из которых может поддерживать до 1023 транзакций, которые выполняют записи для в общей сложности приблизительно 128 k параллельных транзакций. Исходный предел транзакции был 1023.

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

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

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

Для получения дополнительной информации о производительности InnoDB при высокой транзакционной загрузке, см. Раздел 8.5.2, "Оптимизируя InnoDB Управление транзакциями".

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

Чтобы управлять этой функцией, увеличьте значение параметра конфигурации innodb_purge_threads=n. Если действие DML концентрируется на единственной таблице или нескольких таблицах, сохраните установку низкой так, чтобы потоки не боролись друг с другом за доступ к занятым таблицам. Если операции DML распространяются через многие таблицы, увеличивают установку. Его максимум 32.

Есть другой связанный параметр конфигурации, innodb_purge_batch_size со значением по умолчанию 20 и максимумом 5000. Эта опция, главным образом, предназначается для экспериментирования и настройки операций чистки, и не должна быть интересной типичным пользователям.

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

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

Взаимное исключение, известное как журнал sys взаимное исключение, исторически сделало двойной режим работы, управляя доступом к внутренним структурам данных, связанным с записями журнала и LSN, так же как страницами в пуле буферов, которые изменяются, когда минитранзакция фиксируется. Запускаясь в InnoDB 1.1 с MySQL 5.5, эти два вида операций защищаются отдельными взаимными исключениями с новым log_buf взаимоисключающее управление пишет в страницы пула буферов из-за минитранзакций.

Для соображений производительности для InnoDB, блокирующего операции, см. Раздел 8.10, "Оптимизируя Блокировку Операций".

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

Для получения дополнительной информации о пуле буферов InnoDB, см. Раздел 8.9.1," InnoDB Пул буферов".

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

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

Несколько новых функций расширяют режим файла на таблицу, включенный innodb_file_per_table параметр конфигурации, позволяя большей гибкости войти, как .ibd файлы помещаются, экспортируются, и восстанавливаются. Мы характеризуем это как улучшение производительности, потому что оно решает общий потребительский запрос, чтобы поместить данные от различных таблиц на различные устройства хранения для самой выгодной цены / производительность в зависимости от схем доступа данных. Например, таблицы с высокими уровнями случайных чтений и записей могли бы быть помещены в устройство SSD, в то время как менее часто данные, к которым получают доступ, или данные, обработанные с большими пакетами последовательного ввода-вывода, могли бы быть помещены в устройство HDD. См. Раздел 5.4.1, "Управляя Табличными областями InnoDB" для деталей.

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

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

Эта функция комбинирует лучший из обоих миров:

Для получения дополнительной информации при использовании этого интерфейса NoSQL-стиля к MySQL, см. Раздел 14.2.9, "Интеграция InnoDB с memcached". Для дополнительного фона на memcached и соображениях для того, чтобы записать приложения для его API, см. Раздел 15.6, "Используя MySQL с memcached".

Эта функция является продолжением "Быстрого Создания индекса" функция, представленная в Быстром Создании индекса в Механизме Хранения InnoDB. Теперь можно выполнить другие виды операций DDL на таблицах InnoDB онлайн: то есть, с минимальной задержкой операций на той таблице, не восстанавливая всю таблицу, или обоих. Это улучшение улучшает скорость отклика и доступность в занятых продуктивных средах, где, делая таблицу, недоступную в течение многих минут или часов всякий раз, когда ее изменение определений столбца не практично.

Для полного изложения см. Раздел 5.5, "Онлайновый DDL для InnoDB Таблицы".

Операции DDL, улучшенные этой функцией, являются этими изменениями на ALTER TABLE оператор: