Spec-Zone .ru
спецификации, руководства, описания, API
|
Этот раздел суммирует функции майора Иннодба и улучшения для производительности и масштабируемости. Эта информация полезна для любого DBA или разработчика, который обеспокоен производительностью и масштабируемостью. Хотя некоторые из улучшений не требуют никакого действия с Вашей стороны, зная, что эта информация может все еще помочь Вам диагностировать проблемы производительности более быстро и модернизировать системы и приложения, которые полагаются на более старое, неэффективное поведение.
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 с акцентом на производительность и масштабируемость для интенсивных действий записи:
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".
Когда транзакция, как известно, только для чтения, 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
вывод. Эти транзакции только видимы в Информационной схеме.
Эта функция дополнительно перемещается InnoDB
отмените
журнал из системной
табличной области в одного или более отдельных табличных областей. Образцы
ввода-вывода для журнала отмены делают эти новые табличные области хорошими кандидатами, чтобы переместиться
в хранение SSD, сохраняя системную табличную
область на хранении жесткого диска. Пользователи не могут отбросить отдельные табличные области,
создаваемые, чтобы содержать InnoDB
отмените журналы, или отдельные сегменты в тех табличных
областях.
Поскольку эти файлы обрабатывают операции ввода-вывода, прежде сделанные в системной табличной области, мы расширяем определение системной табличной области, чтобы включать эти новые файлы.
Журналы отмены также известны как сегменты отката.
Эта функция включает следующие новые или переименованные параметры конфигурации:
innodb_rollback_segments
становится innodb_undo_logs
. Старое название все еще доступно для совместимости.
Чтобы использовать эту функцию, следуйте за этими шагами:
Выберите путь на быстром устройстве хранения, чтобы содержать журналы отмены.
Вы определите что путь как параметр innodb_undo_directory
опция в Вашем конфигурационном файле MySQL
или сценарии запуска.
Выберите ненулевое начальное значение для innodb_undo_logs
опция. Можно запустить с относительно низкая
стоимость и увеличить ее в течение долгого времени, чтобы исследовать эффект на производительность.
Выберите ненулевое значение для innodb_undo_tablespaces
опция. Многократные журналы отмены,
определенные innodb_undo_logs
значение делится между этим много
отдельных табличных областей (представленный .ibd
файлы). Это значение фиксируется для жизни экземпляра MySQL, так, если Вы не уверены в оптимальном
значении, оценке на высокой стороне.
Установите полностью новый экземпляр MySQL для того, чтобы протестировать, используя значения, которые Вы выбрали в конфигурационном файле или в Вашем сценарии запуска MySQL. Используйте реалистическую рабочую нагрузку с объемом данных, подобным Вашим производственным серверам.
Протестируйте производительности в сравнении с эталоном интенсивно использующих средства ввода-вывода рабочих нагрузок.
Периодически увеличивайте значение innodb_undo_logs
и восстановите тесты производительности. Найдите
значение, где Вы прекращаете испытывать усиления в производительности ввода-вывода.
Разверните новый производственный экземпляр, используя идеальные настройки для этих опций. Установите это как ведомый сервер в конфигурации репликации, или передайте данные от более раннего производственного экземпляра.
Хранение отмены входит в систему, отдельные файлы позволяют команде MySQL реализовывать ввод-вывод и
оптимизацию памяти, связанную с этими транзакционными данными. Например, потому что данные отмены пишутся
диску и затем редко используются (только в случае восстановления катастрофического отказа), это не должно
быть сохранено в кэш-памяти файловой системы, поочередно позволяя более высокий процент системной памяти
быть посвященным InnoDB
пул буферов.
Типичная передовая практика SSD хранения InnoDB
системная табличная область на
жестком диске и перемещении табличных областей на таблицу к SSD, помогается, перемещая информацию об отмене
в отдельные файлы табличной области.
Физические файлы табличной области называют undo
, где N
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 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 . |
После того, как Вы перезапускаете занятый сервер, обычно есть период разминки с
устойчиво увеличивающейся пропускной способностью как дисковые страницы, которые были в 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;
Новые параметры конфигурации 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
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_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
заставить MySQL перезагрузить обновленную статистику.tbl_name
В MySQL и InnoDB, многократных потоках доступа выполнения совместно использованные структуры данных. InnoDB синхронизирует эти доступы со своей собственной реализацией блокировок чтения-записи и взаимных исключений. InnoDB исторически защитил внутреннее состояние блокировки чтения-записи со взаимным исключением InnoDB. На платформах Unix и Linux внутреннее состояние взаимного исключения InnoDB защищается взаимным исключением Pthreads, как в Станд. IEEE 1003.1c (POSIX.1c).
На многих платформах есть более эффективный способ реализовать блокировки чтения-записи и взаимные исключения. Атомарные операции могут часто использоваться, чтобы синхронизировать действия многократных потоков более эффективно чем Pthreads. Каждая работа, чтобы получить или выпустить блокировку может быть сделана в меньшем количестве инструкций ЦП, и таким образом закончиться в менее напрасно потраченное время, когда потоки борются за доступ к совместно используемым структурам данных. Это поочередно означает большую масштабируемость на многожильных платформах.
InnoDB реализует взаимные исключения и блокировки чтения-записи со pthread_mutex_t
реализовывать взаимные исключения InnoDB и блокировки
чтения-записи.
На 32-разрядном Microsoft Windows InnoDB реализовал взаимные исключения (но не блокировки чтения-записи) с
рукописными инструкциями ассемблера. Начинание с Microsoft Windows 2000, функции для
Солярис 10 представленных библиотечных функций для атомарных операций, и InnoDB использует эти функции по
умолчанию. Когда MySQL компилируется на Солярисе 10 с компилятором, который не поддерживает
Это изменение улучшает масштабируемость 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 отключается, 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, "Буферизуя и Кэшируясь".
Когда 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".
Если таблица соответствует почти полностью в оперативной памяти, самый быстрый способ выполнить запросы на
этом состоит в том, чтобы использовать хеш, индексирует, а не поиски B-дерева. Поискы мониторов MySQL на
каждом индексируют определенный для таблицы InnoDB. Если это замечает, что бесспорный индексируют значения,
получаются доступ часто, это автоматически создает хэш-таблицу в памяти для этого, индексируют. См. Раздел 14.2.3.13.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
".
Таблица 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".
Запрос чтения вперед является запросом ввода-вывода, чтобы выбрать многократные страницы с упреждением в пуле буферов асинхронно в ожидании, что эти страницы скоро будут необходимы. Запросы вводят все страницы в одной степени. 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]
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
Пул буферов".
Много оптимизации ускоряют определенные шаги восстановления, которое происходит на следующем запуске после катастрофического отказа. В частности сканирование журнала отката и применение журнала отката являются быстрее чем в MySQL 5.1 и более ранними, из-за улучшенных алгоритмов для управления памятью. Вы не должны предпринять меры, чтобы использовать в своих интересах это улучшение производительности. Если Вы сохранили размер своих файлов журнала отката искусственно низко, потому что восстановление заняло много времени, можно рассмотреть увеличение размера файла.
Для получения дополнительной информации о восстановлении InnoDB, см. Раздел
14.2.3.14," InnoDB
Процесс восстановления".
Запускаясь с 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
таблицы, см. Раздел
20.9.2, "Таблицы Экземпляра Схемы Производительности". Для определений *_summary_*
таблицы, см. Раздел
20.9.8, "Сводные таблицы Схемы Производительности". Для определения thread
таблица, см. Раздел
20.9.9, "Таблицы Разного Схемы Производительности". Для определения *_current_*
и *_history_*
таблицы, см.
Раздел 20.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, см. Главу 20, 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 сегментов. С MySQL 5.7.2, 32 этих 128 сегментов резервируются для транзакций временной таблицы. Это листы 96 сегментов, каждый из которых может поддерживать до 1023 транзакций, которые выполняют записи для в общей сложности приблизительно 96 k параллельных транзакций. Исходный предел транзакции до InnoDB 1.1 с MySQL 5.5 был 1023.
Каждая транзакция присваивается одному из сегментов отката, и остается связанной к тому сегменту отката для продолжительности. Это улучшение улучшает обе масштабируемости (более высокое число параллельных транзакций) и производительность (меньше конкуренции, когда различные транзакции получают доступ к сегментам отката).
Чтобы использовать в своих интересах эту функцию, Вы не должны создать новую базу данных или таблицы, или реконфигурировать что-либо. Следует сделать медленное завершение работы прежде, чем обновить от MySQL 5.1 или ранее, или некоторое время позже. InnoDB производит необходимые изменения в системной табличной области автоматически, в первый раз, когда Вы перезапускаете после выполнения медленного завершения работы.
Если Ваша рабочая нагрузка не была ограничена исходным пределом 1023 параллельных транзакций, можно
сократить количество сегментов отката, используемых в пределах экземпляра MySQL или в пределах сеанса,
устанавливая параметр конфигурации innodb_rollback_segments
.
Для получения дополнительной информации о производительности InnoDB при высокой транзакционной загрузке, см.
Раздел 8.5.2, "Оптимизируя InnoDB
Управление транзакциями".
Операции чистки (тип сборки "мусора"), который InnoDB выполняет автоматически, теперь делаются в одном или более отдельных потоках, а не как часть основного потока. Это изменение улучшает масштабируемость, потому что основные операции базы данных, выполненные независимо от работы обслуживания, происходящей в фоновом режиме.
Чтобы управлять этой функцией, увеличьте значение параметра конфигурации innodb_purge_threads=
. Если действие DML концентрируется на единственной
таблице или нескольких таблицах, сохраните установку низкой так, чтобы потоки не боролись друг с другом за
доступ к занятым таблицам. Если операции DML распространяются через многие таблицы, увеличивают установку.
Его максимум 32. n
Есть другой связанный параметр конфигурации, 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 для надежности и непротиворечивости, кодируя логику приложения, которая использует базу данных в качестве быстрого хранилища значения ключа.
Эта функция комбинирует лучший из обоих миров:
Данные, которые пишутся, используя 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".
Эта функция является продолжением "Быстрого Создания индекса" функция, представленная в
Для полного изложения см. Раздел 5.5, "Онлайновый DDL для
InnoDB
Таблицы".
Операции DDL, улучшенные этой функцией, являются этими изменениями на ALTER TABLE
оператор:
Создайте вторичный, индексирует: CREATE INDEX
или name
ON table
(col_list
)ALTER TABLE
. (Создание первичного ключа или a
table
ADD INDEX name
(col_list
)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 TABLEtbl1
ADD CONSTRAINTfk_name
FOREIGN KEYindex
(col1
) REFERENCEStbl2
(col2
)referential_actions
;ALTER TABLEtbl
DROP FOREIGN KEYfk_name
;
Отбрасывание внешнего ключа может быть выполнено онлайн с foreign_key_checks
опция, включенная или отключенная. Создание
внешнего ключа онлайн требует foreign_key_checks
быть отключенным.
Если Вы не знаете имена об ограничениях внешнего ключа на определенную таблицу, делаете
следующее заявление и находите ограничительное имя в CONSTRAINT
пункт для каждого внешнего ключа:
show create table table
\G
Или, запросите information_schema.table_constraints
таблица и использование
constraint_name
и constraint_type
столбцы, чтобы идентифицировать имена внешнего ключа.
Как следствие этого улучшения можно теперь также отбросить внешний ключ, и его связанные индексируют в единственном операторе, который ранее потребовал отдельных операторов в строгом порядке:
ALTER TABLEtable
DROP FOREIGN KEYconstraint
, DROP INDEXindex
;
Переименование столбца: 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
это иногда добавляется негласно, и Вы могли бы иначе не учесть, клонируя таблицу на новой
системе или устанавливая столбцы внешнего ключа с идентичным типом.
Производительность DDL для временных таблиц InnoDB улучшается посредством оптимизации CREATE TABLE
, DROP
TABLE
, TRUNCATE TABLE
,
и ALTER TABLE
операторы. Оптимизация была достигнута, ограничивая действия,
выполняемые операторами DDL только необходимым для временных таблиц.
Память для экземпляров транзакции (trx_t
) теперь выделяется в конфигурируемых
размерных блоках, которые являются кратным числом размера экземпляра транзакции. Экземпляры транзакции также
помещаются в приоритетную очередь и упорядочиваются их адресом в памяти так, чтобы, когда экземпляры
выделяются от пула, они были близко друг к другу. Это улучшение уменьшает стоимость, понесенную, выполняя
итерации по экземплярам транзакций, выделяя экземпляры от пула.