Spec-Zone .ru
спецификации, руководства, описания, API

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

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

14.2.4.2.1. Краткий обзор Производительности InnoDB

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

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

14.2.4.2.2. Улучшения сжатия для Рабочих нагрузок OLTP

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

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

  • innodb_compression_level позволяет Вам поднимать степень сжатия или вниз. Более высокое значение позволяет Вам соответствовать большему количеству данных на устройство хранения, за счет большего количества издержек ЦП во время сжатия. Нижнее значение позволяет Вам уменьшать издержки ЦП, когда пространство памяти не будет критическим, или Вы ожидаете, что данные не особенно сжимаемы.

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

  • innodb_compression_pad_pct_max позволяет Вам корректировать максимальное количество пространства, зарезервированного в пределах каждой страницы, чтобы записать изменения к сжатым строкам, не будучи должен сжать всю страницу снова. Чем выше значение, тем больше изменений может быть записано, не повторно сжимая страницу. MySQL использует переменное количество свободного пространства для страниц в пределах каждой сжатой таблицы, только когда определяемый процент операций сжатия "перестал работать" во времени выполнения, требуя, чтобы дорогая работа разделила сжатую страницу.

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

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

14.2.4.2.3. Оптимизация для Транзакций Только для чтения

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

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

  • Транзакция запускается с START TRANSACTION READ ONLY оператор. В этом случае, пытаясь произвести любые изменения в базе данных (для InnoDB, MyISAM, или другие типы таблиц), вызывает ошибку, и транзакция продолжается в состоянии только для чтения:

    ERROR 1792 (25006): Cannot execute statement in a READ ONLY transaction.

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

  • Установка автоматической фиксации включается, так, чтобы транзакция, как гарантировали, будет единственным оператором, и единственный оператор, составляющий транзакцию, является "без блокировки" SELECT оператор. Таким образом, a SELECT это не использует a FOR UPDATE или LOCK IN SHARED MODE пункт.

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

Отметить

Транзакции, которые квалифицируют как автоматическая фиксация, без блокировки, и только для чтения (AC-NL-RO), не допускаются бесспорные внутренний InnoDB структуры данных и поэтому не перечисляются в SHOW ENGINE INNODB STATUS вывод. Эти транзакции только видимы в Информационной схеме.

14.2.4.2.4. Отдельные Табличные области для Журналов Отмены InnoDB

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

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

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

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

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

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

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

  2. Выберите ненулевое начальное значение для innodb_undo_logs опция. Можно запустить с относительно низкая стоимость и увеличить ее в течение долгого времени, чтобы исследовать эффект на производительность.

  3. Выберите ненулевое значение для innodb_undo_tablespaces опция. Многократные журналы отмены, определенные innodb_undo_logs значение делится между этим много отдельных табличных областей (представленный .ibd файлы). Это значение фиксируется для жизни экземпляра MySQL, так, если Вы не уверены в оптимальном значении, оценке на высокой стороне.

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

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

  6. Периодически увеличивайте значение innodb_undo_logs и восстановите тесты производительности. Найдите значение, где Вы прекращаете испытывать усиления в производительности ввода-вывода.

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

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

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

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

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

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

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

14.2.4.2.5. Более быстрое Расширение для Файлов данных InnoDB

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

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

14.2.4.2.6. Нерекурсивное Обнаружение Мертвой блокировки

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

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

14.2.4.2.7. Быстро Алгоритм Контрольной суммы CRC32

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

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

  • Текущие версии Резервного копирования MySQL Enterprise (до 3.8.0) не поддерживают поддержку табличных областей то использование crc32 контрольные суммы.

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

Когда устанавливаете новый экземпляр 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 значение.

Таблица 14.3. Позволенные Настройки для innodb_checksum_algorithm

Значение Сгенерированная контрольная сумма (при записи) Позволенные контрольные суммы (читая)
ни один Постоянное число. Любая из контрольных сумм, сгенерированных none, innodb, или crc32.
innodb Контрольная сумма, вычисленная в программном обеспечении, используя исходный алгоритм от InnoDB. Любая из контрольных сумм, сгенерированных none, innodb, или crc32.
crc32 Контрольная сумма вычислила использование crc32 алгоритм, возможно сделанный с аппаратными средствами, помогает. Любая из контрольных сумм, сгенерированных none, innodb, или crc32.
strict_none Постоянное число Только контрольная сумма, сгенерированная none.
strict_innodb Контрольная сумма, вычисленная в программном обеспечении, используя исходный алгоритм от InnoDB. Только контрольная сумма, сгенерированная innodb.
strict_crc32 Контрольная сумма вычислила использование crc32 алгоритм, возможно сделанный с аппаратными средствами, помогает. Только контрольная сумма, сгенерированная crc32.

14.2.4.2.8. Более быстрый Перезапуск, Предварительно загружая Пул буферов InnoDB

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

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

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

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

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

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

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

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

SET innodb_buffer_pool_dump_now=ON;

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

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

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

Пример 14.1. Примеры Дампа и Восстановления Пула буферов InnoDB

Инициируйте дамп пула буферов вручную:

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';

Выводы любой из: не запускался, Выводя пул буферов 5/7, страницу 237/2873, Законченную в 110505 12:18:02

Продвижение дисплея загрузки:

SHOW STATUS LIKE 'innodb_buffer_pool_load_status';

или:

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

Выводы любой из: не запускался, Загруженные 123/22301 страницы, Законченные в 110505 12:23:24

Прервите загрузку пула буферов:

SET innodb_buffer_pool_load_abort=ON;

14.2.4.2.9. Улучшения Сбрасывания Пула буферов

Новые параметры конфигурации 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 адаптивный механизм сбрасывания не является соответствующим во всех случаях. Это приносит большинство пользы, когда журнал отката рискует заполниться. innodb_adaptive_flushing_lwm опция определяет процент емкости журнала отката; когда тот порог пересекается, InnoDB включает адаптивное сбрасывание даже если не определенный innodb_adaptive_flushing опция.

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

  • Когда innodb_max_dirty_pages_pct порог пересекается, InnoDB может начать настойчиво сбрасывать страницы к диску. innodb_max_dirty_pages_pct_lwm опция определяет более высокое значение в который InnoDB начинает мягко сбрасывать страницы, идеально препятствуя тому проценту грязных страниц достигнуть innodb_max_dirty_pages_pct. Значение innodb_max_dirty_pages_pct_lwm=0 отключает это поведение "перед сбрасыванием".

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

14.2.4.2.10. Персистентная Статистика Оптимизатора для Таблиц InnoDB

Устойчивость плана является требуемой целью для Ваших самых больших и самых важных запросов. 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_auto_recalc опция, или выполненный ANALYZE TABLE после создания каждый новый индексирует, когда персистентный режим статистики включается.

Можно также установить 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 перезагрузить обновленную статистику.

14.2.4.2.11. Быстрее Блокируя для Улучшенной Масштабируемости

В 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, "Оптимизируя Блокировку Операций".

14.2.4.2.12. Используя Средства выделения Памяти Операционной системы

Когда 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 отключается, InnoDB игнорирует значение параметра innodb_additional_mem_pool_size. Средство выделения памяти InnoDB использует дополнительный пул памяти для того, чтобы удовлетворить запросы выделения, не имея необходимость отступать к средству выделения системной памяти. Когда средство выделения памяти InnoDB отключается, все такие запросы выделения выполняются средством выделения системной памяти.

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

Так как InnoDB не может отследить все использование памяти, когда средство выделения системной памяти используется (innodb_use_sys_malloc ON), раздел "ПУЛ БУФЕРОВ И ПАМЯТЬ" в выводе SHOW ENGINE INNODB STATUS команда только включает статистику пула буферов в "Общую память, выделенную". Любая память выделила использование mem подсистема или использование ut_malloc исключается.

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

14.2.4.2.13. Управление Буферизацией Изменения InnoDB

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

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

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

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

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

  • all

    Значение по умолчанию: буфер вставляет, удаленный отмеченные операции, и чистки.

  • none

    Не буферизуйте операции.

  • inserts

    Буферные операции вставки.

  • deletes

    Буферизуйте удаленный отмеченные операции.

  • changes

    Буферизуйте и вставляет и удаленный отмеченный.

  • purges

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

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

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

14.2.4.2.14. Управление Адаптивной Индексацией Хеша

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

14.2.4.2.15. Изменения Относительно Параллелизма Потока

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".

Таблица 14.4. Изменения к innodb_thread_concurrency

Версия InnoDB MySQL Version Значение по умолчанию Предел значения по умолчанию параллельных потоков Значение, чтобы позволить неограниченные потоки
Встроенный Ранее чем 5.1.11 20 Никакой предел 20 или выше
Встроенный 5.1.11 и более новый 8 8 0
InnoDB прежде 1.0.3 (соответствие Плагину) 8 8 0
InnoDB 1.0.3 и более новый (соответствие Плагину) 0 Никакой предел 0

Отметьте, что 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".

14.2.4.2.16. Изменения в Алгоритме Чтения вперед

Запрос чтения вперед является запросом ввода-вывода, чтобы выбрать многократные страницы с упреждением в пуле буферов асинхронно в ожидании, что эти страницы скоро будут необходимы. Запросы вводят все страницы в одной степени. 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, "Оптимизируя Дисковый ввод-вывод".

14.2.4.2.17. Многократный Фон Потоки ввода-вывода InnoDB

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 Дисковый ввод-вывод".

14.2.4.2.18. Асинхронный ввод-вывод на Linux

Запускаясь в 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 Дисковый ввод-вывод".

14.2.4.2.19. Групповая Фиксация

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 Управление транзакциями".

14.2.4.2.20. Управление Ведущим Уровнем ввода-вывода Потока 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 Дисковый ввод-вывод".

14.2.4.2.21. Управление Уровнем Сбрасывания Грязных страниц от Пула буферов 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 Дисковый ввод-вывод".

14.2.4.2.22. Используя Инструкцию ПАУЗЫ в Циклах Вращения InnoDB

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

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

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

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

14.2.4.2.23. Управление Опроса Спин-блокировки

Много взаимных исключений 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, "Оптимизируя Блокировку Операций".

14.2.4.2.24. Создание Стойкого Сканирования Пула буферов

Вместо того, чтобы использовать строго алгоритм 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]
  • Old database pages число страниц в "старом" сегменте списка LRU.

  • Pages made young и not young общее количество "старых" страниц, которые были сделаны молодыми или не соответственно.

  • youngs/s и non-young/s уровень, на котором доступы страницы к "старым" страницам привели к созданию таких молодых страниц или иначе соответственно начиная с последнего вызова команды.

  • young-making rate и not обеспечивает тот же самый уровень, но с точки зрения полных доступов пула буферов вместо доступов только к "старым" страницам.

Отметить

В секунду средние числа, обеспеченные в InnoDB Вывод монитора основан на прошедшем времени между текущим временем и в прошлый раз InnoDB Вывод монитора был напечатан.

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

В смешанных рабочих нагрузках, где большая часть действия является типом 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 Пул буферов".

14.2.4.2.25. Улучшения, чтобы Разрушить Производительность Восстановления

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

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

14.2.4.2.26. Интеграция с MySQL Performance Schema

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

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

  • Следует выполнять MySQL 5.5 или выше. Следует создать сервер базы данных из источника, активируя опцию Схемы Производительности, создавая с --with-perfschema опция. Так как функция Схемы Производительности представляет некоторые издержки производительности, следует использовать это на тесте или системе разработки, а не на производственной системе.

  • Следует выполнять InnoDB 1.1 или выше.

  • Следует быть обычно знакомыми с тем, как использовать функцию Схемы Производительности, например чтобы запросить таблицы в performance_schema база данных.

  • Исследуйте следующие виды объектов InnoDB, запрашивая соответствующее performance_schema таблицы. Элементы, связанные с InnoDB, все содержат подстроку innodb в EVENT_NAME столбец.

    Для определений *_instances таблицы, см. Раздел 21.9.2, "Таблицы Экземпляра Схемы Производительности". Для определений *_summary_* таблицы, см. Раздел 21.9.8, "Сводные таблицы Схемы Производительности". Для определения thread таблица, см. Раздел 21.9.9, "Таблицы Разного Схемы Производительности". Для определения *_current_* и *_history_* таблицы, см. Раздел 21.9.3, "Схема Производительности Ожидает Таблицы События".

    • Взаимные исключения в mutex_instances таблица. (Взаимные исключения и RW-блокировки, связанные с InnoDB пул буферов не включается в это покрытие; то же самое применяется к выводу SHOW ENGINE INNODB MUTEX команда.)

    • RW-блокировки в rwlock_instances таблица.

    • RW-блокировки в rwlock_instances таблица.

    • Операции Файлового ввода-вывода в file_instances, file_summary_by_event_name, и file_summary_by_instance таблицы.

    • Потоки в PROCESSLIST таблица.

  • Во время тестирования производительности исследуйте данные о производительности в events_waits_current и events_waits_history_long таблицы. Если Вы интересуетесь особенно InnoDB-связанными объектами, используйте пункт WHERE EVENT_NAME LIKE '%innodb%' видеть только те записи; иначе, исследуйте статистику производительности на полный сервер MySQL.

  • Следует выполнять MySQL 5.5 со Схемой Производительности, включенной, создавая с --with-perfschema создайте опцию.

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

14.2.4.2.27. Улучшения Производительности от Многократных Пулов буферов

Это улучшение производительности прежде всего полезно для людей с большим размером пула буферов, обычно в диапазоне мультигигабайта. Чтобы использовать в своих интересах это ускорение, следует установить новое 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 Пул буферов".

14.2.4.2.28. Лучшая Масштабируемость с Многократными Сегментами Отката

Запускаясь в 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 Управление транзакциями".

14.2.4.2.29. Лучшая Масштабируемость с Улучшенным Планированием Чистки

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

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

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

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

14.2.4.2.30. Улучшенный Лог Сис Мутекс

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

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

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

14.2.4.2.31. Отдельное Взаимное исключение Списка Сброса

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

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

14.2.4.2.32. Взаимоисключающее Разделение ядра

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

14.2.4.2.33. InnoDB Конфигурируемый Кэш Словаря Данных

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

14.2.4.2.34. Улучшенное управление Табличной областью

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

14.2.4.2.35. Плагин memcached для InnoDB

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

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

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

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

  • Данные, которые являются запрошенными данными через memcached протокол, прозрачно запрашиваются от таблицы InnoDB, не проходя через уровень SQL MySQL.

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

  • InnoDB может обработать создание и разложение многократных значений столбцов в единственное memcached значение элемента, уменьшая количество строкового парсинга и связи, требуемой в Вашем приложении. Например, Вы могли бы сохранить строковое значение 2|4|6|8 в memcached кэше, и разделениях InnoDB, которые оценивают основанный на символе разделителя, затем хранит результат в четыре числовых столбца.

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

14.2.4.2.36. Онлайновый DDL

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

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

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

  • Создайте вторичный, индексирует: CREATE INDEX name ON table (col_list) или ALTER TABLE table ADD INDEX name (col_list). (Создание первичного ключа или a FULLTEXT индексируйте все еще требует блокировки таблицы.)

    Вторичное отбрасывание индексирует: DROP INDEX name ON table; или ALTER TABLE table DROP INDEX name

    Создание и отбрасывание вторичного индексируют на InnoDB таблицы избежали копирующего таблицу поведения со дней MySQL 5.1 с InnoDB Плагин. Теперь, таблица остается доступной для операций чтения и операций записи, в то время как индексирование создается или отбрасывается. CREATE TABLE или DROP TABLE оператор только заканчивается после того, как все транзакции, которые изменяют таблицу, завершаются, так, чтобы начальное состояние индексирования отразило новое содержание таблицы.

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

  • Изменение автоинкрементного значения для столбца: ALTER TABLE table AUTO_INCREMENT=next_value;

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

  • Добавление или отбрасывание ограничения внешнего ключа:

    ALTER TABLE tbl1 ADD CONSTRAINT fk_name FOREIGN KEY index (col1) REFERENCES tbl2(col2) referential_actions;ALTER TABLE tbl DROP FOREIGN KEY fk_name;

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

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

    show create table table\G

    Или, запросите information_schema.table_constraints таблица и использование constraint_name и constraint_type столбцы, чтобы идентифицировать имена внешнего ключа.

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

    ALTER TABLE table DROP FOREIGN KEY constraint, DROP INDEX index;
  • Переименование столбца: ALTER TABLE tbl CHANGE old_col_name new_col_name datatype

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

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

    • Изменение ROW_FORMAT или KEY_BLOCK_SIZE свойства для таблицы.

    • Изменение nullable состояния для столбца.

    • Добавление, отбрасывая, или переупорядочивая столбцы.

Отметить

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

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

Безотносительно последовательности CREATE TABLE, CREATE INDEX, ALTER TABLE, и подобные операторы вошли в соединение таблицы, можно получить SQL, должен был восстановить текущую форму таблицы, делая заявление SHOW CREATE TABLE table\G (верхний регистр \G требуемый для опрятного форматирования). Этот вывод показывает пункты, такие как числовая точность, NOT NULL, и CHARACTER SET это иногда добавляется негласно, и Вы могли бы иначе не учесть, клонируя таблицу на новой системе или устанавливая столбцы внешнего ключа с идентичным типом.