MySQL Glossary

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

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

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

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

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

См. Также атомарный, фиксация, параллелизм, doublewrite буфер, уровень изоляции, блокировка, откат, транзакция.

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

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

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

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

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

См. Также B-дерево, пул буферов, хеш индексируют, memcached, страница, вторичный индексируют.

Акроним для адаптивного хеша индексирует.

См. Также, что адаптивный хеш индексирует.

Акроним для асинхронного ввода-вывода. Вы могли бы видеть этот акроним в сообщениях InnoDB или ключевых словах.

См. Также асинхронный ввод-вывод.

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

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

См. Также Барракуду, компактный формат строки, сжатый формат строки, динамический формат строки, формат файла, innodb_file_format, избыточный формат строки.

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

Когда резервное копирование, произведенное Резервным продуктом MySQL Enterprise, не включает новые изменения, которые произошли, в то время как резервное копирование было в стадии реализации, процесс обновления файлов резервных копий, чтобы включать те изменения известен как применять шаг. Это определяется apply-log опция mysqlbackup команда.

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

См. Также горячее резервное копирование, ibbackup_logfile, Резервное копирование MySQL Enterprise, подготовленное резервное копирование, необработанное резервное копирование.

Метаданные для таблиц АРХИВА. Контраст с.ARZ файлом. Файлы с этим расширением всегда включаются в резервные копии, произведенные mysqlbackup командой Резервного продукта MySQL Enterprise.

См. Также.ARZ файл, Резервное копирование MySQL Enterprise, mysqlbackup команда.

Данные для таблиц АРХИВА. Контраст с.ARM файлом. Файлы с этим расширением всегда включаются в резервные копии, произведенные mysqlbackup команда Резервного продукта MySQL Enterprise.

См. Также.ARM файл, Резервное копирование MySQL Enterprise, mysqlbackup команда.

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

Исторически, InnoDB использовал асинхронный ввод-вывод на системах Windows только. Запускаясь с Плагина InnoDB 1.1, InnoDB использует асинхронный ввод-вывод на системах Linux. Это изменение представляет зависимость от libaio. На других Подобных Unix системах InnoDB использует синхронный ввод-вывод только.

См. Также пул буферов, неблокируя ввод-вывод.

В контексте SQL транзакции являются единицами работы, за которыми любой следует полностью (когда фиксирующийся) или не имеет никакого эффекта вообще (когда откатывающийся). Неделимое ("атомарное") свойство транзакций является "A" в ACID акронима.

См. Также ACID, фиксацию, откат, транзакцию.

Специальные инструкции, обеспеченные ЦП, чтобы гарантировать, что критические низкоуровневые операции не могут быть прерваны.

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

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

Столбцы автоприращения могут быть проблематичными с основанной на операторе репликацией, потому что воспроизведение операторов на ведомом устройстве не могло бы произвести тот же самый набор значений столбцов как на ведущем устройстве, из-за проблем синхронизации. Когда у Вас есть автопостепенно увеличивающийся первичный ключ, можно использовать основанную на операторе репликацию только с установкой innodb_autoinc_lock_mode=1. Если Вы имеете innodb_autoinc_lock_mode=2, который позволяет более высокий параллелизм для операций вставки, используйте построчную репликацию, а не основанную на операторе репликацию. Установка innodb_autoinc_lock_mode=0 предыдущая (традиционная) настройка по умолчанию и не должна использоваться за исключением целей совместимости.

См. Также автоинкрементную блокировку, innodb_autoinc_lock_mode, первичный ключ, построчная репликация, основанная на операторе репликация.

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

См. Также автоинкремент, параллелизм, innodb_autoinc_lock_mode.

Установка, которая вызывает работу фиксации после каждого SQL-оператора. Этот режим не рекомендуется для того, чтобы работать с таблицами InnoDB с транзакциями тот промежуток несколько операторов. Может помочь производительности для транзакций только для чтения на таблицах InnoDB, где это минимизирует издержки от блокировки и генерации данных отмены, особенно в MySQL 5.6.4 и. Это также подходяще для работы с таблицами MyISAM, где транзакции не применимы.

См. Также фиксацию, блокировку, транзакцию только для чтения, SQL, транзакцию, отмену.

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

См. Также масштабируемость.

Древовидная структура данных, которая популярна для использования в базе данных, индексирует. Структура сохраняется сортированной всегда, включая быстрому поиску для точных совпадений (равняется оператору) и диапазоны (например, больше чем, меньше чем, и BETWEEN операторы). Этот тип индексирует, доступно для большинства механизмов хранения, таков как InnoDB и MyISAM.

Поскольку у узлов B-дерева может быть много дочерних элементов, B-дерево не является тем же самым как двоичным деревом, которое ограничивается 2 дочерними элементами на узел.

Контраст с хешем индексирует, который только доступен в механизме хранения ПАМЯТИ. Механизм хранения ПАМЯТИ может также использовать B-дерево, индексирует, и следует выбрать, B-дерево индексирует для таблиц ПАМЯТИ, если некоторые запросы используют операторы диапазона.

См. Также, что хеш индексирует.

Идентификаторы в пределах SQL-операторов MySQL должны быть заключены в кавычки, используя символ обратной галочки (`) если они содержат специальные символы или зарезервированные слова. Например, чтобы обратиться к названной таблице FOO#BAR или столбец называют SELECT, Вы определили бы идентификаторы как `FOO#BAR` и `SELECT`. Так как обратные галочки обеспечивают дополнительный уровень безопасности, они используются экстенсивно в сгенерированных программой SQL-операторах, где имена идентификатора не могли бы быть известны заранее.

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

См. Также SQL.

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

С MySQL физические резервные копии выполняются Резервным продуктом MySQL Enterprise, и логические резервные копии выполняются mysqldump команда. У этих методов есть различные характеристики с точки зрения размера и представления резервных данных, и скорости (особенно скорость работы восстановления).

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

См. Также холодное резервное копирование, горячее резервное копирование, логическое резервное копирование, Резервное копирование MySQL Enterprise, mysqldump, физическое резервное копирование, теплое резервное копирование.

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

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

Резервная версия 3.5 продукта MySQL Enterprise и выше поддерживает поддержку табличных областей, которые используют формат файла Барракуды.

См. Также Антилопу, компактный формат строки, сжатый формат строки, динамический формат строки, формат файла, файл на таблицу, innodb_file_format, Резервное копирование MySQL Enterprise, формат строки, системная табличная область.

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

См. Также раннего последователя, GA.

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

Можно исследовать содержание двоичного журнала, или воспроизвести те операторы во время репликации или восстановления, при использовании mysqlbinlog команды. Для полной информации о двоичном журнале см. Раздел 5.2.4, "Двоичный Журнал". Для параметров конфигурации MySQL, связанных с двоичным журналом, см. Раздел 16.1.4.4, "Двоичные Опции Журнала и Переменные".

Для Резервного продукта MySQL Enterprise имя файла двоичного журнала и текущей позиции в пределах файла является важными деталями. Чтобы записать эту информацию для главного сервера, беря резервное копирование в контексте репликации, можно определить --slave-info опция.

До MySQL 5.0 подобная возможность была доступна, известна как журнал обновления. В MySQL 5.0 и выше, двоичный журнал заменяет журнал обновления.

См. Также binlog, Резервное копирование MySQL Enterprise, репликация.

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

См. Также двоичный журнал.

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

См. Также полнотекстовый поиск.

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

См. Также пул буферов, параллелизм.

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

См. Также завершение работы.

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

См. Также пул буферов, страницу, размер страницы.

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

См. Также пул буферов, катастрофический отказ, doublewrite буфер, вставьте буфер.

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

Несколько InnoDB переменные состояния, information_schema таблицы, и performance_schema таблицы помогают контролировать внутренние работы пула буферов. Запускаясь в MySQL 5.6, можно также вывести и восстановить содержание пула буферов, или автоматически во время завершения работы и перезапуска, или вручную в любое время, через ряд InnoDB переменные конфигурации такой как innodb_buffer_pool_dump_at_shutdown и innodb_buffer_pool_load_at_startup.

См. Также экземпляр пула буферов, LRU, страницу, нагреться.

Любая из многократных областей, на которые пул буферов может быть разделен, управляемый innodb_buffer_pool_instances параметр конфигурации. Размер общей памяти, определенный innodb_buffer_pool_size делится среди всех экземпляров. Как правило, многократные экземпляры пула буферов являются подходящими для систем, посвящающих многократные гигабайты пулу буферов InnoDB с каждым экземпляром 1 гигабайт или больше. На системной загрузке или поиске большие объемы данных в пуле буферов от многих параллельных сеансов, наличие многократных экземпляров уменьшает конкуренцию для эксклюзивного доступа к структурам данных, которые управляют пулом буферов.

См. Также пул буферов.

Встроенный механизм хранения InnoDB в пределах MySQL является исходной формой распределения для механизма хранения. Контраст с Плагином InnoDB. Запускаясь с MySQL 5.5, Плагин InnoDB объединяется назад в кодовую базу MySQL как встроенный механизм хранения InnoDB (известный как InnoDB 1.1).

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

См. Также InnoDB, плагин.

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

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

См. Также реляционный.

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

См. Также буфер, пул буферов.

Число различных значений в столбце таблицы. Когда запросы обращаются к столбцам, у которых есть связанное, индексируют, количество элементов каждого столбца влияния, какой метод доступа является самым эффективным. Например, для столбца с ограничением на уникальность данных, число различных значений равно числу строк в таблице. Если у таблицы есть миллион строк, но только 10 различных значений для определенного столбца, каждое значение происходит (в среднем) 100 000 раз. Запрос такой как SELECT c1 FROM t1 WHERE c1 = 50; таким образом мог бы возвратить 1 строку или огромное число строк, и сервер базы данных мог бы обработать запрос по-другому в зависимости от количества элементов c1.

Если у значений в столбце есть очень неравное распределение, количество элементов не могло бы быть хорошим способом определить лучший план запроса. Например, SELECT c1 FROM t1 WHERE c1 = x; мог бы возвратить 1 строку когда x=50 и миллион строк, когда x=30. В таком случае Вы, возможно, должны были бы использовать, индексируют подсказки, чтобы провести совет, о котором метод поиска более эффективен для определенного запроса.

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

Для InnoDB процесс оценки количества элементов для индексирует, под влиянием innodb_stats_sample_pages и innodb_stats_on_metadata параметры конфигурации. Ориентировочные стоимости более устойчивы, когда персистентная опция статистики активируется (в MySQL 5.6 и выше).

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

Файл метаданных, используемый с InnoDB мобильная функция табличной области. Это производится командой FLUSH TABLES ... FOR EXPORT, помещает одну или более таблиц в непротиворечивое состояние, которое может быть скопировано в другой сервер. .cfg файл копируется наряду с соответствующим.ibd файлом, и используется, чтобы скорректировать внутренние значения .ibd файл, такой как ID пространства, во время ALTER TABLE ... IMPORT TABLESPACE шаг.

См. Также.ibd файл, расположите с интервалами ID, мобильную табличную область.

Специальная структура данных, которая записывает изменения к страницам во вторичном, индексирует. Эти значения могли следовать из SQL INSERT, UPDATE, или DELETE операторы (DML). Набор функций, включающих буфер изменения, известен все вместе, поскольку буферизация изменения, состоя из буферизации вставки, удаляет буферизацию, и буферизацию чистки.

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

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

Видами и объемом данных, сохраненным в буфере изменения, управляют innodb_change_buffering и innodb_change_buffer_max_size параметры конфигурации. Чтобы видеть информацию о текущих данных в буфере изменения, выйдите SHOW ENGINE INNODB STATUS команда.

Прежде известный как буфер вставки.

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

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

См. Также буфер изменения, удалите буферизацию, вставьте буферизацию, буферизацию чистки.

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

См. Также пул буферов, файлы данных, сброс, нечеткую установку контрольных точек, LSN.

В InnoDB, механизм проверки допустимости, чтобы обнаружить повреждение, когда страница в табличной области читается из диска в пул буферов InnoDB. Эта функция включается и выключается innodb_checksums параметр конфигурации. В MySQL 5.6 можно включить более быстрому алгоритму контрольной суммы, также определяя параметр конфигурации innodb_checksum_algorithm=crc32.

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

MySQL также использует контрольные суммы в целях репликации. Для получения дополнительной информации см. параметры конфигурации binlog_checksum, master_verify_checksum, и slave_sql_verify_checksum.

См. Также пул буферов, страницу, табличную область.

В отношении внешнего ключа дочерняя таблица является той, строки которой относятся (или точка) к строкам в другой таблице с идентичным значением для определенного столбца. Это - таблица, которая содержит FOREIGN KEY ... REFERENCES пункт и дополнительно ON UPDATE и ON DELETE пункты. Соответствующая строка в родительской таблице должна существовать прежде, чем строка может быть создана в дочерней таблице. Значения в дочерней таблице могут предотвратить, удаляют или обновляют операции на родительской таблице, или может вызвать автоматическое удаление или обновления в дочерней таблице, основанной на ON CASCADE опция, используемая, создавая внешний ключ.

См. Также внешний ключ, родительскую таблицу.

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

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

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

См. Также катастрофический отказ, быстрое завершение работы, завершение работы, медленное завершение работы.

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

См. Также mysql, сервер.

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

В продукте Базы данных Oracle этот тип таблицы известен как индексирование - организованная таблица.

См. Также индексируют, первичный ключ, вторичный индексируют.

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

См. Также резервное копирование, горячее резервное копирование, теплое резервное копирование.

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

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

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

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

Индексирование на единственном столбце.

См. Также сводный индекс, индексировать.

Когда индексирование создается со спецификацией длины, такой как CREATE INDEX idx ON t1 (c1(N)), только первые символы N значения столбца сохранены в индексировании. Хранение индексировать маленький префикс делает индексирование компактного, и память и дисковая производительность справки сбережений ввода-вывода. (Хотя создание индексировать слишком маленького префикса может препятствовать оптимизации запросов, заставляя строки с различными значениями, казаться, к оптимизатору запросов быть копиями.)

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

См. Также индексируют.

SQL-оператор, который заканчивает транзакцию, делая постоянный любые изменения, произведенные транзакцией. Это - противоположность отката, который отменяет любые изменения, произведенные в транзакции.

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

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

См. Также автоматическую фиксацию, оптимистичную, откат, SQL, транзакция.

Значение по умолчанию формат строки InnoDB начиная с MySQL 5.0.3. Доступный для таблиц, которые используют формат файла Антилопы. У этого есть более компактное представление для нулей и полей переменной длины чем предшествующее значение по умолчанию (избыточный формат строки).

Из-за B-дерева индексирует, которые делают поиски строки столь быстро в InnoDB, есть немного если любой выигрыш в производительности к хранению всех строк тот же самый размер.

См. Также Антилопу, формат файла, избыточный формат строки, формат строки.

Индексирование, которое включает многократные столбцы.

См. Также индексируют, индексируют префикс.

Функция сжатия Резервного продукта MySQL Enterprise делает сжатую копию каждой табличной области, изменяя расширение от .ibd к .ibz. Сжатие резервных данных позволяет Вам держать больше резервных копий под рукой, и уменьшает время, чтобы передать резервные копии различному серверу. Данные являются несжатыми во время работы восстановления. Когда сжатая операция резервного копирования обрабатывает таблицу, которая уже сжимается, она пропускает шаг сжатия для той таблицы, потому что сжатие снова привело бы к небольшим или никаким сбережениям пространства.

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

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

См. Также применяются, двоичный журнал, сжатие, горячее резервное копирование, Резервное копирование MySQL Enterprise, табличная область.

Формат строки, который включает данным и индексирует сжатие для таблиц InnoDB. Это было представлено в Плагине InnoDB, доступном как часть формата файла Барракуды. Большие поля хранятся от страницы, которая содержит остальную часть данных строки, как в динамическом формате строки. Обе индексных страницы и большие поля сжимаются, приводя к памяти и дисковым сбережениям. В зависимости от структуры данных уменьшение в памяти и использование диска могли бы или не могли бы перевесить издержки производительности распаковки данных, поскольку это используется. См. Раздел 5.4.6, "Работающий с InnoDB Сжатые Таблицы" для деталей использования.

См. Также Барракуду, сжатие, динамический формат строки, формат строки.

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

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

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

Табличная функция сжатия требует MySQL 5.5 использования или выше, или Плагин InnoDB в MySQL 5.1 или ранее, и создание таблицы, используя формат файла Барракуды и сжатый формат строки, с включенной установкой innodb_file_per_table. Сжатие для каждой таблицы под влиянием KEY_BLOCK_SIZE пункт CREATE TABLE и ALTER TABLE операторы. В MySQL 5.6 и выше, на сжатие также влияют параметры конфигурации всего сервера innodb_compression_failure_threshold_pct, innodb_compression_level, и innodb_compression_pad_pct_max. См. Раздел 5.4.6, "Работающий с InnoDB Сжатые Таблицы" для деталей использования.

Другой тип сжатия является сжатой резервной функцией Резервного продукта MySQL Enterprise.

См. Также Барракуду, пул буферов, сжатый формат строки, DML, горячее резервное копирование, индексируйте, INFORMATION_SCHEMA, innodb_file_per_table, плагин, таблица, отмените буфер.

Не фактически ошибка, скорее дорогая работа, которая может произойти при использовании сжатия в комбинации с операциями DML. Это происходит когда: обновления к сжатой странице переполняют области на странице, зарезервированной для того, чтобы записать модификации; страница сжимается снова со всеми изменениями, которым применяются к табличные данные; пересжатые данные не соответствуют на исходной странице, требуя, чтобы MySQL разделил данные на две новых страницы и сжал каждого отдельно. Чтобы проверить частоту этого условия, запросите таблицу INFORMATION_SCHEMA.INNODB_CMP и проверьте сколько значения COMPRESS_OPS столбец превышает значение COMPRESS_OPS_OK столбец. Идеально, отказы сжатия часто не происходят; когда они делают, можно скорректировать параметры конфигурации innodb_compression_level, innodb_compression_failure_threshold_pct, и innodb_compression_pad_pct_max.

См. Также сжатие, DML, страницу.

См. сводный индекс.

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

См. Также ACID, блокировку, транзакцию.

Файл, который содержит значения опции, используемые MySQL при запуске. Традиционно, на Linux и UNIX этот файл называют my.cnf, и на Windows это называют my.ini. Можно установить много опций, связанных с InnoDB под [mysqld] раздел файла.

Как правило, этот файл разыскивается в расположениях /etc/my.cnf /etc/mysql/my.cnf /usr/local/mysql/etc/my.cnf и ~/.my.cnf. См. Раздел 4.2.3.3, "Используя Файлы Опции" для деталей о пути поиска для этого файла.

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

См. Также my.cnf, файл опции.

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

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

Непротиворечивое чтение является режимом по умолчанию, в котором InnoDB обрабатывает SELECT операторы в ЧТЕНИИ ФИКСИРОВАВШИЕ и ПОВТОРИМЫЕ уровни изоляции ЧТЕНИЯ. Поскольку непротиворечивое чтение не устанавливает, любой соединяет таблицы, к которым оно получает доступ, другие сеансы свободны изменить те таблицы, в то время как непротиворечивое чтение выполняется на таблице.

Для технических деталей о применимых уровнях изоляции см. Раздел 14.2.3.3, "Непротиворечивые Чтения Без блокировки".

См. Также ACID, параллелизм, уровень изоляции, блокировку, MVCC, ФИКСИРОВАВШЕЕ ЧТЕНИЕ, СЧИТАЙТЕ НЕЗАФИКСИРОВАННОЕ, ПОВТОРИМОЕ ЧТЕНИЕ, СЕРИАЛИЗУЕМОЕ, транзакция, отмените журнал.

Автоматический тест, который может блокировать изменения базы данных, чтобы препятствовать тому, чтобы данные стали непоследовательными. (В терминах информатики, своего рода утверждение, связанное с инвариантным условием.) Ограничения являются решающим компонентом философии ACID, чтобы поддержать непротиворечивость данных. Ограничения, поддерживаемые MySQL, включают ограничения FOREIGN KEY и ограничения на уникальность данных.

См. Также ACID, внешний ключ, реляционное, ограничение на уникальность данных.

Значение, которое постепенно увеличивается деталью отчасти InnoDB работа. Полезный для измерения, насколько занятый сервер, диагностируя источники проблем производительности, и тестируя, ли изменения (например, к параметрам конфигурации или индексирует используемый запросами) имеют требуемые низкоуровневые эффекты. Различные виды счетчиков доступны через performance_schema таблицы и information_schema таблицы, особенно information_schema.innodb_metrics.

См. Также INFORMATION_SCHEMA, метрический счетчик, Схему Производительности.

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

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

См., что столбец Also индексирует, сводный индекс, индексирует, вторичный индексируют.

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

См. Также восстановление катастрофического отказа, быстрое завершение работы, InnoDB, журнал отката, завершение работы.

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

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

См. Также буфер изменения, фиксацию, катастрофический отказ, файлы данных, doublewrite буфер, InnoDB, чистка, журнал отката.

Акроним для "создает, читал, обновляет, удаляет", общая последовательность операций в приложениях базы данных. Часто обозначает class приложений с относительно простым использованием базы данных (основной DDL, DML и операторы запроса в SQL), который может быть реализован быстро на любом языке.

См. Также DDL, DML, запрос, SQL.

Внутренняя структура данных, которая используется, чтобы представить набор результатов запроса, или другую работу, которая выполняет поиск, используя SQL WHERE пункт. Это работает как iterator в других высокоуровневых языках, производя каждое значение из набора результатов согласно просьбе.

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

См. Также запрос.

См. DDL.

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

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

См. столбец Also.frm файл, горячее резервное копирование, индексируйте, Резервное копирование MySQL Enterprise, системная табличная область, таблица.

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

См. Также файлы данных, экземпляр.

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

См. Также словарь данных, файл на таблицу, индексируйте, системная табличная область, таблица, табличная область.

См. DML.

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

См. Также денормализованный, OLTP, запрос, транзакция только для чтения.

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

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

См. Также файлы данных, файл на таблицу.ibd файл, экземпляр, схема, системная табличная область.

Язык управления данными, ряд SQL-операторов для того, чтобы управлять полномочиями. В MySQL, состоит из GRANT и REVOKE операторы. Контраст с DDL и DML.

См. Также DDL, DML, SQL.

Язык определения данных, ряд SQL-операторов для того, чтобы управлять базой данных непосредственно, а не отдельными строками таблицы. Включает все формы CREATE, ALTER, и DROP операторы. Также включает TRUNCATE оператор, потому что это работает по-другому чем a DELETE FROM table_name оператор, даже при том, что окончательный эффект подобен.

Операторы DDL автоматически фиксируют текущую транзакцию; они не могут откатываться.

InnoDB-связанные аспекты DDL включают улучшения скорости для CREATE INDEX и DROP INDEX операторы, и путь установка файла на таблицу влияют на поведение TRUNCATE TABLE оператор.

Контраст с DML и DCL.

См. Также фиксацию, DCL, DML, файл на таблицу, откат, SQL, транзакцию.

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

Мертвая блокировка может произойти, когда транзакции блокируют строки в многократных таблицах (через операторы такой как UPDATE или SELECT ... FOR UPDATE), но в противоположном порядке. Мертвая блокировка может также произойти, когда такие операторы блокируют диапазоны, индексируют записи и разрывы, с каждой транзакцией, получающей некоторые блокировки, но не других из-за проблемы синхронизации.

Чтобы уменьшить возможность мертвых блокировок, используйте транзакции, а не LOCK TABLE операторы; сохраните транзакции, которые вставляют или обновляют данные, достаточно маленькие, что они не остаются открытыми в течение долгих промежутков времени; когда различные транзакции обновляют многократные таблицы или большие спектры строк, используйте тот же самый порядок операций (такой как SELECT ... FOR UPDATE) в каждой транзакции; создайте индексирует на столбцах, используемых в SELECT ... FOR UPDATE и UPDATE ... WHERE операторы. На возможность мертвых блокировок не влияет уровень изоляции, потому что уровень изоляции изменяет поведение операций чтения, в то время как мертвые блокировки происходят из-за операций записи.

Если мертвая блокировка действительно происходит, InnoDB обнаруживает условие и откатывает одну из транзакций (жертва). Таким образом, даже если Ваша логика приложения совершенно корректна, следует все еще обработать случай, где транзакция должна быть повторена. Чтобы видеть последнюю мертвую блокировку в пользовательской транзакции InnoDB, используйте команду SHOW ENGINE INNODB STATUS. Если частые мертвые блокировки выделяют проблему со структурой транзакции или обработкой ошибки приложения, работают с innodb_print_all_deadlocks установка включала, чтобы напечатать информацию обо всех мертвых блокировках к mysqld журнал ошибок.

Для вводной информации о том, как мертвые блокировки автоматически обнаруживаются и обрабатываются, см. Раздел 14.2.3.9, "Обнаружение мертвой блокировки и Откат". Для подсказок относительно ухода от и восстановления с условий мертвой блокировки, см. Раздел 14.2.3.10, "Как Справиться с Мертвыми блокировками".

См. Также параллелизм, разрыв, уровень изоляции, блокировку, блокировку, откат, транзакцию, жертву.

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

См. Также мертвую блокировку, откат, транзакцию, жертву.

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

См. Также отбрасывание, чистку, усеченную.

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

См. Также буфер изменения, буферизацию изменения, вставьте буфер, вставьте буферизацию, буферизацию чистки.

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

См. Также хранилище данных, нормализованное.

Тип индексирует доступный с некоторыми системами баз данных, где индексируют хранение, оптимизируется, чтобы обработать ORDER BY column DESC пункты. В настоящий момент, хотя MySQL позволяет DESC ключевое слово в CREATE TABLE оператор, это не использует специального расположения хранения для получающегося, индексируют.

См. Также индексируют.

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

См. Также пул буферов, чистую страницу, файлы данных, сброс, страницу.

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

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

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

См. Также ACID, фиксацию, непротиворечивое чтение, уровень изоляции, ФИКСИРОВАВШЕЕ ЧТЕНИЕ, ЧИТАЙТЕ НЕЗАФИКСИРОВАННЫЙ, откат.

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

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

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

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

Тип рабочей нагрузки, где основное узкое место является дисковым вводом-выводом. (Также известный как I/O-bound.) Обычно включает частые записи к диску, или случайные чтения большего количества данных, чем может вписаться в пул буферов.

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

Язык манипулирования данными, ряд SQL-операторов для того, чтобы выполнить вставляет, обновляет, и удаляет операции. SELECT оператор иногда рассматривают как оператор DML, потому что SELECT ... FOR UPDATE форма подвергается тем же самым соображениям для того, чтобы заблокировать как INSERT, UPDATE, и DELETE.

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

Контраст с DDL и DCL.

См. Также фиксацию, DCL, DDL, блокировку, откат, SQL, транзакцию.

В InnoDB полнотекстовая функция поиска, специальный столбец в таблице, содержащей ПОЛНОТЕКСТОВЫЙ ИНДЕКС, чтобы однозначно определить документ, связанный с каждым значением ilist. Его имя FTS_DOC_ID (требуемый верхний регистр). Сам столбец должен иметь BIGINT UNSIGNED NOT NULL введите с названным уникальным индексом FTS_DOC_ID_INDEX. Предпочтительно, Вы определяете этот столбец, составляя таблицу. Если InnoDB должен добавить столбец к таблице, создавая a FULLTEXT индексируйте, работа индексации значительно более дорога.

См. Также полнотекстовый поиск, ПОЛНОТЕКСТОВЫЙ ИНДЕКС, ilist.

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

Хотя данные всегда пишутся дважды, буфер doublewrite не требует вдвое большего количества издержек ввода-вывода или вдвое большего количества операций ввода-вывода. Данные пишутся буферу непосредственно как большой последовательный блок с синглом fsync() призовите к операционной системе.

Чтобы выключить буфер doublewrite, определите опцию innodb_doublewrite=0.

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

Своего рода работа DDL, которая удаляет объект схемы через оператор такой как DROP TABLE или DROP INDEX. Это отображается внутренне на ALTER TABLE оператор. С точки зрения InnoDB соображения производительности таких операций включают время, когда словарь данных блокируется, чтобы гарантировать, что взаимосвязанные объекты все обновляются, и время, чтобы обновить структуры памяти, такие как пул буферов. Для таблицы у работы отбрасывания есть несколько различные характеристики чем усеченная работа (TRUNCATE TABLE оператор).

См. Также пул буферов, словарь данных, DDL, таблицу, усеченную.

Формат строки, представленный в Плагине InnoDB, доступном как часть формата файла Барракуды. Поскольку TEXT и BLOB поля сохранены за пределами остальной части страницы, которая содержит данные строки, это очень эффективно для строк, которые включают большие объекты. Так как к большим полям обычно не получают доступ, чтобы оценить условия запроса, они не приносятся в пул буферов как часто, приводя к меньшему количеству операций ввода-вывода и лучшего использования кэш-памяти.

См. Также Барракуду, пул буферов, формат файла, формат строки.

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

См. Также бету, GA.

Тип информации о показе журнала о MySQL запускается и критические ошибки периода выполнения и информация о катастрофическом отказе. Для получения дополнительной информации см. Раздел 5.2.2, "Журнал ошибок".

См. Также катастрофический отказ, журнал.

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

См. Также пул буферов, грязную страницу, сброс, LRU.

Своего рода блокировка, которая препятствует тому, чтобы любая другая транзакция блокировала ту же самую строку. В зависимости от уровня изоляции транзакции этот вид блокировки мог бы блокировать другие транзакции от записи до той же самой строки, или мог бы также блокировать другие транзакции от чтения той же самой строки. Уровень изоляции InnoDB значения по умолчанию, ПОВТОРИМОЕ ЧТЕНИЕ, включает более высокому параллелизму, позволяя транзакции считать строки, у которых есть монопольные блокировки, метод, известный как непротиворечивое чтение.

См. Также параллелизм, непротиворечивое чтение, уровень изоляции, блокировку, ПОВТОРИМОЕ ЧТЕНИЕ, коллективную блокировку, транзакцию.

Группа страниц в пределах табличной области всего 1 мегабайт. С размером страницы значения по умолчанию 16 Кбит степень содержит 64 страницы. В MySQL 5.6 размер страницы может также составить 4 Кбита или 8 Кбит, когда степень содержит больше страниц, все еще составляя в целом 1 МБ.

Функции InnoDB, такие как сегменты, запросы чтения вперед и буферные операции ввода-вывода использования doublewrite, которые читают, пишут, выделяют, или свободные данные одна степень за один раз.

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

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

Поскольку ведение индексов может добавить издержки производительности ко многим операциям передачи данных, считайте выполнение операций таким как ALTER TABLE ... ENGINE=INNODB или INSERT INTO ... SELECT * FROM ... без любого вторичного устройства индексирует на месте, и создание индексирования позже.

В MySQL 5.6 эта функция становится более общей: можно читать и записать в таблицы, в то время как индексирование создается, и еще много видов ALTER TABLE операции могут быть выполнены, не копируя таблицу, не блокируя операции DML, или обоих. Таким образом в MySQL 5.6 и выше, мы обычно именуем этот набор функций как онлайновый DDL, а не Быстрое Создание индекса.

См. Также DML, индексируйте, онлайновый DDL, вторичный индексируют.

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

См. Также восстановление катастрофического отказа, файлы данных, сброс, завершение работы, медленное завершение работы.

Формат, используемый InnoDB для каждой таблицы, обычно с установкой файла на таблицу, включенной так, чтобы каждая таблица была сохранена в отдельном .ibd файл. В настоящий момент форматы файлов, доступные в InnoDB, известны как Антилопа и Барракуда. Каждый формат файла поддерживает один или более форматов строки. Форматы строки, доступные для таблиц Барракуды, СЖАТЫХ и ДИНАМИЧНЫХ, активируют важные новые опции хранения для таблиц InnoDB.

См. Также Антилопу, Барракуду, файл на таблицу.ibd файл, ibdata файл, формат строки.

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

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

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

См. Также сжатый формат строки, сжатие, формат файла.ibd файл, ibdata файл, innodb_file_per_table, формат строки, системную табличную область.

В InnoDB индексируют, пропорция страницы, которая приводится в рабочее состояние, индексирует данные прежде, чем страница будет разделена. Неиспользуемое место, когда индексируют данные, сначала делится между страницами, учитывает строки, которые будут обновлены с более длинными строковыми значениями, не требуя дорогих операций ведения индексов. Если коэффициент заполнения слишком низок, индексирование занимает больше места чем необходимые, вызывающие дополнительные издержки ввода-вывода, читая индексирование. Если коэффициент заполнения слишком высок, любое обновление, которое увеличивает длину значений столбцов, может вызвать дополнительные издержки ввода-вывода для ведения индексов. См. Раздел 14.2.3.12.4, "Физическая Структура InnoDB Индексируйте" для получения дополнительной информации.

См. Также индексируют, страница.

Этот формат строки используется механизмом хранения MyISAM, не InnoDB. Если Вы составляете таблицу InnoDB с опцией row_format=fixed, InnoDB преобразовывает эту опцию, чтобы использовать компактный формат строки вместо этого, хотя fixed значение могло бы все еще разоблачить в выводе такой как SHOW TABLE STATUS отчеты.

См. Также компактный формат строки, формат строки.

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

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

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

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

См. Также пул буферов, грязную страницу, LRU, минитранзакцию, взаимное исключение, страницу, уборщика страницы.

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

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

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

См. Также дочернюю таблицу, ограничение FOREIGN KEY, соединение, нормализованное, НУЛЬ, родительская таблица, ссылочная целостность, реляционная.

Тип ограничения, которое поддерживает непротиворечивость базы данных через отношение внешнего ключа. Как другие виды ограничений, это может препятствовать тому, чтобы данные были вставлены или обновлены, если данные стали бы непоследовательными; в этом случае предотвращаемая несогласованность между данными в многократных таблицах. Альтернативно, когда работа DML выполняется, FOREIGN KEY ограничения могут заставить данные в дочерних строках быть удаленными, измененным на различные значения, или установить в NULL, основанный на ON CASCADE опция, определенная, создавая внешний ключ.

См. Также дочернюю таблицу, ограничение, DML, внешний ключ, НУЛЬ.

Файл, содержащий метаданные, такие как табличное определение, таблицы MySQL.

Хотя у каждой таблицы InnoDB есть a .frm файл, InnoDB поддерживает свои собственные табличные метаданные (словарь данных) в системной табличной области; .frm файлы не необходимы для InnoDB, чтобы работать на таблицах InnoDB. Проблемы могут произойти, если катастрофический отказ происходит в то время как .frm файл пишется, приводя к несогласованностям между .frm файл и словарь данных,

Для резервных копий следует всегда сохранять полный комплект .frm файлы наряду с резервными данными, чтобы быть в состоянии восстановить таблицы, которые изменяются или отбрасываются после резервного копирования. Файлы с этим расширением всегда включаются в резервные копии, произведенные mysqlbackup командой Резервного продукта MySQL Enterprise. Если Вы используете ibbackup команду вместо этого, следует скопировать .frm файлы самостоятельно.

Эти файлы поддерживаются Резервным продуктом MySQL Enterprise. Эти файлы не должны быть изменены ALTER TABLE работа, в то время как резервное копирование имеет место, который является, почему резервные копии, которые включают non-InnoDB таблицы, выполняют a FLUSH TABLES WITH READ LOCK работа, чтобы заморозить такое действие, поддерживая .frm файлы. Восстановление резервного копирования может привести к .frm файлы, создаваемые, измененные, или удаленный, чтобы соответствовать состояние базы данных во время резервного копирования.

См. Также катастрофический отказ, словарь данных, ibbackup команда, Резервное копирование MySQL Enterprise, mysqlbackup команда, системная табличная область.

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

См. Также полное сканирование таблицы, полнотекстовый поиск.

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

См. Также резервное копирование, базу данных, экземпляр, частичное резервное копирование, таблицу.

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

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

См. Также пул буферов, индексируйте, LRU.

Функция MySQL открытия слов, фраз, Булевых комбинаций слов, и так далее в пределах табличных данных, более быстрым, более удобным, и более гибким способом чем использование SQL LIKE оператор или запись Вашего собственного алгоритма поиска уровня приложения. Это использует функцию SQL MATCH() и Полнотекстовые индексы.

См. Также ПОЛНОТЕКСТОВЫЙ ИНДЕКС.

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

См. Также полнотекстовый поиск, индексируйте, InnoDB, поиск индексирует, stopword.

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

См. Также пул буферов, грязную страницу, сброс.

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

См. Также бету, раннего последователя.

Место в индексной структуре данных InnoDB, где новые значения могли быть вставлены. Когда Вы блокируете ряд строк с оператором такой как SELECT ... FOR UPDATE, InnoDB может создать блокировки, которые применяются к разрывам так же как фактическим значениям в индексировании. Например, если Вы выбираете все значения, больше чем 10 для обновления, блокировка разрыва препятствует тому, чтобы другая транзакция вставила новое значение, которое больше чем 10. Запись supremum и запись нижней грани представляют разрывы, содержащие все значения, больше чем или меньше, чем весь ток индексирует значения.

См. Также параллелизм, разорвите блокировку, индексируйте, запись нижней грани, уровень изоляции, supremum запись.

Блокировка на разрыве между индексирует записи, или блокировку на разрыве перед первым или после того, как последние индексируют запись. Например, SELECT c1 FOR UPDATE FROM t WHERE c1 BETWEEN 10 and 20; препятствует тому, чтобы другие транзакции вставили значение 15 в столбец t.c1, было ли уже какое-либо такое значение в столбце, потому что разрывы между всеми существующими значениями в диапазоне блокируются. Контраст с блокировкой записи и следующей блокировкой ключа.

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

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

См. общий журнал запросов.

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

Записывает более широкий диапазон запросов чем медленный журнал запросов. В отличие от двоичного журнала, который используется для репликации, общий журнал запросов содержит SELECT операторы и не поддерживают строгое упорядочивание. Для получения дополнительной информации см. Раздел 5.2.3, "Общий Журнал запросов".

См. Также двоичный журнал, общий журнал запросов, журнал.

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

См. Также ACID, СЕРИАЛИЗУЕМЫЙ, транзакция, XA.

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

Когда binlog включается, Вы обычно также устанавливаете параметр конфигурации sync_binlog=0, потому что групповая фиксация для двоичного журнала только поддерживается, если это устанавливается в 0.

См. Также фиксацию, плагин, XA.

Тип индексирует предназначенный для запросов, которые используют операторы равенства, вместо того, чтобы расположиться операторы такой как больше - чем или BETWEEN. Это доступно для таблиц ПАМЯТИ. Хотя хеш индексирует, значение по умолчанию для таблиц ПАМЯТИ по историческим причинам, тот механизм хранения также поддерживает B-дерево, индексирует, которые часто являются лучшим выбором для запросов общего назначения.

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

См. Также, что адаптивный хеш индексирует, B-дерево, индексирует, InnoDB.

Акроним для "жесткого диска". Обращается к дискам вращения использования носителей, обычно сравниваясь и контрастируя с SSD. Его показатели производительности могут влиять на пропускную способность находящейся на диске рабочей нагрузки.

См. Также находящийся на диске, SSD.

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

См. Также репликацию.

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

См. Также низкий водяной знак.

Список транзакций с удаляет - отмеченные записи, которые, как запланировали, будут обработаны InnoDB работа чистки. Записанный в журнале отмены. О длине списка предыстории сообщает команда SHOW ENGINE INNODB STATUS. Если список предыстории становится более длинным чем значение innodb_max_purge_lag параметр конфигурации, каждая работа DML задерживается немного, чтобы позволить работе чистки заканчивать сбрасывать удаленные записи.

Также известный как задержка чистки.

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

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

Хотя "горячий" обычно указывает на нежелательное условие, горячее резервное копирование является привилегированным типом резервного копирования.

См. Также горячее резервное копирование.

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

Продукт Oracle, который выполняет горячие резервные копии таблиц InnoDB особенно, но также и таблиц от MyISAM и других механизмов хранения, известен как Резервное копирование MySQL Enterprise.

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

См. Также применяются, Резервное копирование MySQL Enterprise, подготовленное резервное копирование, необработанное резервное копирование.

См. ограниченный диском.

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

См. Также базу данных, файл на таблицу, журнал отката, системную табличную область.

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

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

См. Также двоичный журнал, зарегистрируйте группу, журнал отката.

Фундаментальный инструмент командной строки Резервного продукта MySQL Enterprise. Это выполняет горячую операцию резервного копирования для таблиц InnoDB. Вы используете эту команду непосредственно, если все Ваши данные находятся в таблицах InnoDB, если все важные данные, которые Вы должны поддержать, находятся в таблицах InnoDB, или если Вы работаете на платформе Windows. Если Вы также должны поддержать таблицы от MyISAM или других механизмов хранения, Вы используете mysqlbackup команду вместо этого (доступный на UNIX и системах Linux только).

См. Также горячее резервное копирование, Резервное копирование MySQL Enterprise, mysqlbackup команда.

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

См. Также применяются, горячее резервное копирование, Резервное копирование MySQL Enterprise, подготовленное резервное копирование, необработанное резервное копирование.

Создаваемое использование таблицы каждого InnoDB режима файла на таблицу входит в свой собственный файл табличной области с a .ibd расширение, в каталоге базы данных. Этот файл содержит табличные данные, и любой индексирует для таблицы. Режим файла на таблицу, которым управляет innodb_file_per_table опция, влияет на многие аспекты использования хранения InnoDB и производительности, и включается по умолчанию в MySQL 5.6.7 и выше.

Это расширение не применяется к системной табличной области, которая состоит из ibdata файлов.

Когда a .ibd файл включается в сжатое резервное копирование Резервным продуктом MySQL Enterprise, сжатый эквивалент является a .ibz файл.

Если таблица, создают с DATA DIRECTORY = пункт в MySQL 5.6 и выше, .ibd файл располагается вне нормального каталога базы данных, и указывается.isl файлом.

См. Также базу данных, файл на таблицу, ibdata файл.ibz файл, индексируйте, innodb_file_per_table.isl файл, Резервное копирование MySQL Enterprise, системная табличная область, таблица, табличная область.

Ряд файлов с именами такой как ibdata1, ibdata2, и так далее это составляет системную табличную область InnoDB. Эти файлы содержат метаданные о таблицах InnoDB, (словарь данных), и области хранения для журнала отмены, буфера изменения, и буфера doublewrite. Они также могут содержать некоторых или все табличные данные также (в зависимости от того, является ли режим файла на таблицу в действительности, когда каждая таблица составляется). Когда innodb_file_per_table опция включается, данные и индексирует для недавно составленных таблиц, сохранены в отдельных.ibd файлах, а не в системной табличной области.

Рост ibdata файлы под влиянием innodb_autoextend_increment параметр конфигурации.

См. Также буфер изменения, словарь данных, doublewrite буфер, файл на таблицу.ibd файл, innodb_file_per_table, системная табличная область, отмените журнал.

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

См. Также временную табличную область.

Когда Резервный продукт MySQL Enterprise выполняет сжатое резервное копирование, он преобразовывает каждый файл табличной области, который создается, используя файл на таблицу, сходящий a .ibd расширение a .ibz расширение.

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

См. Также сжатое резервное копирование, сжатый формат строки, файл на таблицу.ibd файл, Резервное копирование MySQL Enterprise, табличная область.

В пределах ПОЛНОТЕКСТОВОГО ИНДЕКСА InnoDB, структура данных, состоящая из ID документа и информации о местонахождении для маркера (то есть, определенное слово).

См. Также ПОЛНОТЕКСТОВЫЙ ИНДЕКС.

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

См. Также блокировку строки.

Тип системы баз данных, которая поддерживает данные в памяти, чтобы избежать издержек из-за дискового ввода-вывода и преобразования между дисковыми блоками и областями памяти. Некоторые базы данных в памяти жертвуют длительностью ("D" в принципах проектирования ACID) и уязвимы для аппаратных средств, питания, и других типов отказов, делая их более подходящий для операций только для чтения. Другие базы данных в памяти действительно используют механизмы длительности, такие как журналирование изменений к диску или использованию энергонезависимой памяти.

Функции MySQL, которые являются адресом те же самые виды интенсивно использующей память обработки, включают пул буферов InnoDB, адаптивный хеш индексируют, и оптимизация транзакции только для чтения, механизм хранения ПАМЯТИ, кэш ключа MyISAM, и кэш запроса MySQL.

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

Тип горячего резервного копирования, выполняемого Резервным продуктом MySQL Enterprise, это только сохраняет данные, измененные начиная с некоторого момента времени. Наличие полного резервного копирования и последовательности инкрементных резервных копий позволяет Вам восстанавливать резервные данные за длительный период без издержек хранения держания под рукой нескольких полных резервных копий. Можно восстановить полное резервное копирование и затем применить каждые из инкрементных резервных копий по очереди, или можно сохранить полное резервное копирование актуальным, применяя каждое инкрементное резервное копирование в это, затем выполнить единственную работу восстановления.

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

См. Также горячее резервное копирование, Резервное копирование MySQL Enterprise, страницу.

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

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

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

Хотя B-дерево индексирует, наиболее распространено, различный вид структуры данных используется для хеша, индексирует, как в MEMORY механизм хранения и InnoDB адаптивный хеш индексируют.

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

Область памяти, которая содержит маркерные данные для InnoDB полнотекстовый поиск. Это буферизует данные, чтобы минимизировать дисковый ввод-вывод, когда данные вставляются или обновляются в столбцах, которые являются частью ПОЛНОТЕКСТОВОГО ИНДЕКСА. Маркерные данные пишутся диску, когда индексировать кэш становится полным. Каждый InnoDB FULLTEXT индексируйте имеет его собственное отдельное, индексируют кэш, размером которого управляет параметр конфигурации innodb_ft_cache_size.

См. Также полнотекстовый поиск, ПОЛНОТЕКСТОВЫЙ ИНДЕКС.

Расширенный синтаксис SQL для того, чтобы переопределить индексирование рекомендуемого оптимизатором. Например, FORCE INDEX, USE INDEX, и IGNORE INDEX пункты. Обычно используемый, когда индексированные столбцы неравно распределили значения, приводящие к неточным оценкам количества элементов.

См. Также количество элементов, индексировать.

В индексировании, которое применяется к многократным столбцам (известный как сводный индекс), начальная буква или ведущие столбцы индексирования. Запрос, который ссылается на первый 1, 2, 3, и так далее столбцы сводного индекса, может использовать индексирование, даже если запрос не ссылается на все столбцы в индексировании.

См. Также сводный индекс, индексировать.

См. статистику.

Псевдозапись в индексировании, представляя разрыв ниже самого маленького значения в этом индексирует. Если у транзакции есть оператор такой как SELECT ... FOR UPDATE ... WHERE col < 10;, и самое маленькое значение в столбце 5, это - блокировка на записи нижней грани, которая препятствует тому, чтобы другие транзакции вставили еще меньшие значения такой как 0,-10, и так далее.

См. Также разрыв, индексируйте, псевдозапишите, supremum запись.

Имя базы данных, которая обеспечивает интерфейс запроса для словаря данных MySQL. (Это имя определяется стандартом ANSI SQL.) Чтобы исследовать информацию (метаданные) о базе данных, можно запросить таблицы такой как INFORMATION_SCHEMA.TABLES и INFORMATION_SCHEMA.COLUMNS, вместо использования SHOW команды, которые производят неструктурированный вывод.

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

См. Также сжатие, словарь данных, базу данных, InnoDB, блокировку, транзакцию.

Резервное копирование от прежнего InnoDB Горячий Резервный продукт. Это заменяется mysqlbackup команда в Резервном продукте MySQL Enterprise.

См. Также резервное копирование, InnoDB Горячее Резервное копирование, Резервное копирование MySQL Enterprise, mysqlbackup команда.

Компонент MySQL, который комбинирует высокую производительность с транзакционной возможностью надежности, устойчивости, и параллельного доступа. Это воплощает принципы проектирования ACID. Представленный как механизм хранения; это обрабатывает таблицы, создаваемые или измененные с ENGINE=INNODB пункт. См. Раздел 14.2," InnoDB Механизм хранения" для архитектурных деталей и процедур администрирования, и Раздела 8.5, "Оптимизируя для InnoDB Таблицы" для совета производительности.

В MySQL 5.5 и выше, InnoDB является механизмом хранения значения по умолчанию для новых таблиц и ENGINE=INNODB пункт не требуется. В MySQL 5.1 только, многие из усовершенствованных функций InnoDB требуют включения компоненту, известному как Плагин InnoDB. См. Раздел 14.2.1.1,"InnoDB как Механизм Хранения MySQL Default" для соображений, включенных в переход к недавним выпускам, где таблицы InnoDB являются значением по умолчанию.

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

См. Также ACID, горячее резервное копирование, механизм хранения, транзакцию.

Лицензируемый резервный продукт, замененный в MySQL 5.1 и выше Резервным копированием MySQL Enterprise.

Резервное копирование See Also MySQL Enterprise.

innodb_autoinc_lock_mode опция управляет алгоритмом, используемым для автоинкрементной блокировки. Когда у Вас есть автопостепенно увеличивающийся первичный ключ, можно использовать основанную на операторе репликацию только с установкой innodb_autoinc_lock_mode=1. Эта установка известна как последовательный режим блокировки, потому что мультистрока вставляет в пределах транзакции, получают последовательные автоинкрементные значения. Если Вы имеете innodb_autoinc_lock_mode=2, который позволяет более высокий параллелизм для операций вставки, используйте построчную репликацию, а не основанную на операторе репликацию. Эта установка известна как чередованный режим блокировки, потому что многократная мультистрока вставляет операторы, работающие, одновременно может получить автоинкрементные значения, которые чередуются. Установка innodb_autoinc_lock_mode=0 предыдущая (традиционная) настройка по умолчанию и не должна использоваться за исключением целей совместимости.

См. Также автоинкрементную блокировку, смешанный режим вставляют, первичный ключ.

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

См. Также Антилопу, Барракуду, формат файла, файл на таблицу, innodb_file_per_table, системная табличная область, табличная область.

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

Эта опция влияет на производительность и соображения хранения для многих SQL-операторов, такой как DROP TABLE и TRUNCATE TABLE.

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

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

Для информации о ссылке см. innodb_file_per_table. Для информации об использовании см. Раздел 5.4.1, "Управляя Табличными областями InnoDB".

См. Также сжатие, файл на таблицу.ibd файл, Резервное копирование MySQL Enterprise, системная табличная область.

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

См. Также мертвую блокировку, обнаружение мертвой блокировки, блокировку, ожидать.

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

Этот режим является настройкой по умолчанию в MySQL 5.5.5 и выше.

См. Также строгий режим.

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

См. Также автоинкремент, буферизацию изменения, хранилище данных, DML, InnoDB, вставьте буфер, OLTP, SQL.

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

См. Также буфер изменения, буферизацию изменения.

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

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

См. Также буфер изменения, буферизацию изменения, удалите буферизацию, вставьте буфер, буферизацию чистки, уникальный индекс.

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

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

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

См. Также INFORMATION_SCHEMA, Схему Производительности.

См. блокировку намерения.

Своего рода блокировка, которая применяется к табличному уровню, имела обыкновение указывать, какую блокировку транзакция намеревается получить на строках в таблице. Различные транзакции могут получить различные виды намерения, соединяет ту же самую таблицу, но первая транзакция, которая получит намерение, монопольное (IX), соединяются, таблица препятствует тому, чтобы другие транзакции получили любой S, или X соединяет таблицу. Наоборот, первая транзакция, которая получит намерение, совместно использованное (IS), соединяется, таблица препятствует тому, чтобы другие транзакции получили любой X, соединяет таблицу. Двухфазный процесс позволяет запросам блокировки быть разрешенными в порядке, не блокируя блокировки и соответствующие операции, которые являются совместимыми. Для получения дополнительной информации на этом механизме блокировки, см. Раздел 14.2.3.2,"InnoDB Режимы блокировки".

См. Также блокировку, заблокируйте режим, блокируя.

См. блокировку намерения.

Структура данных, оптимизированная для систем поиска документов, используемых в реализации InnoDB полнотекстовый поиск. ПОЛНОТЕКСТОВЫЙ ИНДЕКС InnoDB, реализованный как инвертированный индекс, записывает позицию каждого слова в пределах документа, а не расположение строки таблицы. Единственное значение столбца (документ, хранивший как текстовая строка), представляется многими записями в инвертированном индексе.

См. Также полнотекстовый поиск, ПОЛНОТЕКСТОВЫЙ ИНДЕКС, ilist.

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

См. Также ограниченный диском, OLTP, масштабируемость.

Файл, который определяет расположение.ibd файла для таблицы InnoDB, составленной с DATA DIRECTORY = пункт в MySQL 5.6 и выше. Это функционирует как символьная ссылка без ограничений платформы фактического механизма символьной ссылки. Можно сохранить табличные области InnoDB вне каталога базы данных, например, на особенно большом или быстром устройстве хранения в зависимости от использования таблицы. Для получения дополнительной информации см. Раздел 5.4.1.2, "Определение Расположения Табличной области".

См. Также базу данных.ibd файл, таблица, табличная область.

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

От самого высокого количества непротиворечивости и защиты к наименее, уровни изоляции, поддерживаемые InnoDB: СЕРИАЛИЗУЕМОЕ, ПОВТОРИМОЕ ЧТЕНИЕ, ЧИТАЙТЕ ФИКСИРОВАВШИЙ, и ЧИТАЙТЕ НЕЗАФИКСИРОВАННЫЙ.

С таблицами InnoDB много пользователей могут сохранить уровень изоляции значения по умолчанию (ПОВТОРИМОЕ ЧТЕНИЕ) для всех операций. Опытные пользователи могли бы выбрать чтение фиксировавший уровень, поскольку они продвигают границы масштабируемости с обработкой OLTP, или во время операций организации хранилищ данных, где незначительные несогласованности не влияют на совокупные результаты больших объемов данных. Уровни на краях (СЕРИАЛИЗУЕМЫЙ и ЧИТАЮТ НЕЗАФИКСИРОВАННЫЙ) изменяют поведение обработки до такой степени, что они редко используются.

См. Также ACID, СЧИТАЙТЕ ФИКСИРОВАВШИЙ, СЧИТАЙТЕ НЕЗАФИКСИРОВАННОЕ, ПОВТОРИМОЕ ЧТЕНИЕ, СЕРИАЛИЗУЕМОЕ, транзакция.

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

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

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

См. Также сжатый формат строки.

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

См. Также словарь данных, блокировку, блокировку, взаимное исключение, Схему Производительности, rw-блокировку.

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

См. Также пул буферов, замещение, LRU, подсписок.

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

См. Также фиксатор, заблокируйте режим, блокировку, взаимное исключение.

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

См. Также блокировку, блокировку строки, блокировку таблицы.

Совместно используемое (S) блокировка позволяет транзакции читать строку. Многократные транзакции могут получить блокировку S на той же самой строке одновременно.

Монопольное (X) блокировка позволяет транзакции обновлять или удалять строку. Никакая другая транзакция не может получить вид, соединяют ту же самую строку одновременно.

Блокировки намерения применяются к табличному уровню, и используются, чтобы указать, какую блокировку транзакция намеревается получить на строках в таблице. Различные транзакции могут получить различные виды намерения, соединяет ту же самую таблицу, но первая транзакция, которая получит намерение, монопольное (IX), соединяются, таблица препятствует тому, чтобы другие транзакции получили любой S, или X соединяет таблицу. Наоборот, первая транзакция, которая получит намерение, совместно использованное (IS), соединяется, таблица препятствует тому, чтобы другие транзакции получили любой X, соединяет таблицу. Двухфазный процесс позволяет запросам блокировки быть разрешенными в порядке, не блокируя блокировки и соответствующие операции, которые являются совместимыми.

См. Также блокировку намерения, блокировку, блокируя.

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

См. Также ACID, параллелизм, уровень изоляции, фиксатор, блокировку, взаимное исключение, транзакцию.

A SELECT оператор, который также выполняет работу блокировки на InnoDB таблица. Также SELECT ... FOR UPDATE или SELECT ... LOCK IN SHARE MODE. У этого есть потенциал, чтобы произвести мертвую блокировку, в зависимости от уровня изоляции транзакции. Противоположность чтения без блокировки. Не учитывал глобальные таблицы в транзакции только для чтения.

См. Также мертвую блокировку, уровень изоляции, блокировку, чтение без блокировки, транзакцию только для чтения.

В контексте InnoDB "журнал" или "файлы журнала" обычно ссылаются на журнал отката, представленный ib_logfile* файлами. Другой областью журнала, которая является физически частью системной табличной области, является журнал отмены.

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

См. Также двоичный журнал, журнал ошибок, общий журнал запросов, ib_logfile, журнал отката, медленный журнал запросов, системная табличная область, отмените журнал.

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

См. Также файл журнала, журнал отката.

Один из ib_logfileN файлы, которые составляют журнал отката. Данные пишутся этим файлам от области буферной памяти журнала.

См. Также ib_logfile, зарегистрируйте буфер, журнал отката.

Набор файлов, которые составляют журнал отката, обычно называемый ib_logfile0 и ib_logfile1. (По этой причине, иногда упоминаемый все вместе как ib_logfile.)

См. Также ib_logfile, журнал отката.

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

См. Также логическое резервное копирование, физическое.

Резервное копирование, которое воспроизводит структуру таблицы и данные, не копируя фактические файлы данных. Например, mysqldump команда производит логическое резервное копирование, потому что его вывод содержит операторы такой как CREATE TABLE и INSERT это может воссоздать данные. Контраст с физическим резервным копированием. Логическое резервное копирование предлагает гибкость (например, Вы могли отредактировать табличные определения или вставить операторы прежде, чем восстановить), но может взять существенно дольше, чтобы восстановить чем физическое резервное копирование.

См. Также резервное копирование, mysqldump, физическое резервное копирование, восстановление.

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

См. Также плагин.

Значение, представляющее более низкий предел, обычно пороговое значение, в котором некоторое корректирующее действие начинается или становится более агрессивным. Контраст с высшей точкой.

См. Также высшую точку.

Акроним для "последнего использованного", общепринятая методика для того, чтобы управлять областями хранения. Элементы, которые не использовались недавно, были выселены, когда пространство необходимо, чтобы кэшировать более новые элементы. InnoDB использует механизм LRU по умолчанию, чтобы управлять страницами в пределах пула буферов, но делает исключения в случаях, где страница могла бы быть только для чтения единственное время, такой как во время полного сканирования таблицы. Это изменение алгоритма LRU вызывают стратегией вставки средней точки. Пути, которыми управление пулом буферов отличается от традиционного алгоритма LRU, подстраиваются опциями innodb_old_blocks_pct, innodb_old_blocks_time, и новые опции MySQL 5.6 innodb_lru_scan_depth и innodb_flush_neighbors.

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

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

В Резервном продукте MySQL Enterprise можно определить LSN, чтобы представить момент времени, от которого можно взять инкрементное резервное копирование. Соответствующий LSN выводится на экран выводом ibbackup команда. Как только у Вас есть соответствие LSN времени полного резервного копирования, можно определить, что значение, чтобы взять последующее инкрементное резервное копирование, вывод которого содержит другой LSN для следующего инкрементного резервного копирования.

См. Также восстановление катастрофического отказа, инкрементное резервное копирование, Резервное копирование MySQL Enterprise, журнал отката, транзакцию.

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

См. Также репликацию, ведомый сервер.

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

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

См. Также пул буферов, грязную страницу, сброс, вставьте буфер, уборщика страницы, поток.

Акроним для "метаданных блокирует".

См. Также блокировку метаданных.

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

Интерфейс memcached к таблицам InnoDB доступен в MySQL 5.6 и выше; см. Раздел 14.2.9, "Интеграция InnoDB с memcached" для деталей. Интерфейс memcached к таблицам MySQL Cluster доступен в MySQL Cluster 7.2; см. http://dev.mysql.com/doc/ndbapi/en/ndbmemcache.html для деталей.

См. Также InnoDB, NoSQL.

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

См. Также пул буферов, буфер изменения, сброс, табличную область.

Тип блокировки, которая предотвращает операции DDL на таблице, которая используется одновременно другой транзакцией. Для получения дополнительной информации см. Раздел 8.10.4, "Блокировка Метаданных".

Улучшения к онлайновым операциям, особенно в MySQL 5.6 и выше, фокусируются на сокращении количества блокировки метаданных. Цель для операций DDL, которые не изменяют структуру таблицы (такой как CREATE INDEX и DROP INDEX для InnoDB таблицы) продолжиться, в то время как таблица запрашивается, обновило, и так далее другими транзакциями.

См. Также DDL, блокировку, онлайн, транзакцию.

Опция, реализованная innodb_metrics таблица в information_schema, в MySQL 5.6 и выше. Можно запросить количества и общие количества для низкого уровня операции InnoDB, и использовать результаты для производительности, настраивающей комбинацию с данными от performance_schema.

См. Также счетчик, INFORMATION_SCHEMA, Схему Производительности.

Метод начального обеспечения страниц в пул буферов InnoDB не в "новейшем" конце списка, но вместо этого где-нибудь в середине. Точное расположение этой точки может измениться, основанный на установке innodb_old_blocks_pct опция. Намерение состоит в том, который блокирует, которые только читаются, как только, такой как во время полного сканирования таблицы, может быть в возрасте из пула буферов скорее чем со строгим алгоритмом LRU.

См. Также пул буферов, полное сканирование таблицы, LRU, страницу.

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

См. Также фиксацию, восстановление катастрофического отказа, DML, физический, чистка, журнал отката, откат, транзакция.

INSERT оператор, где автоинкрементные значения определяются для некоторых, но не всех новых строк. Например, мультизначение INSERT мог определить значение для столбца автоприращения в некоторых случаях и NULL в других случаях. InnoDB генерирует автоинкрементные значения для строк, где значение столбца было определено как NULL. Другой пример INSERT ... ON DUPLICATE KEY UPDATE оператор, где автоинкрементные значения могли бы быть сгенерированы, но не использоваться для любых дублирующихся строк, которые обрабатываются как UPDATE вместо INSERT операторы.

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

См. Также автоинкремент, innodb_autoinc_lock_mode, главный сервер, репликация, ведомый сервер.

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

Резервное копирование See Also MySQL Enterprise, mysqlbackup команда.

Тип процессора, который может использовать в своих интересах многопоточные программы, такие как сервер MySQL.

См. MVCC.

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

См. Также фиксатор, блокировку, Схему Производительности, Pthreads, rw-блокировку.

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

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

См. Также ACID, параллелизм, непротиворечивое чтение, уровень изоляции, блокировку, транзакцию.

Имя, на UNIX или системах Linux, файла опции MySQL.

См. Также my.ini, файл опции.

Имя, на системах Windows, файла опции MySQL.

См. Также my.cnf, файл опции.

Файл, что использование MySQL, чтобы хранить данные для таблицы MyISAM. Файлы с этим расширением всегда включаются в резервные копии, произведенные mysqlbackup команда Резервного продукта MySQL Enterprise.

См. Также.MYI файл, Резервное копирование MySQL Enterprise, mysqlbackup команда.

Файл, который MySQL использует для хранилища, индексирует для таблицы MyISAM. Файлы с этим расширением всегда включаются в резервные копии, произведенные mysqlbackup команда Резервного продукта MySQL Enterprise.

См. Также.MYD файл, Резервное копирование MySQL Enterprise, mysqlbackup команда.

mysql программа является интерпретатором командной строки для базы данных MySQL. Это обрабатывает SQL-операторы, и также специфичные для MySQL команды такой как SHOW TABLES, передавая запросы к mysqld демон.

См. Также mysqld, SQL.

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

См. Также горячее резервное копирование, InnoDB.

Инструмент командной строки Резервного продукта MySQL Enterprise. Это выполняет горячую операцию резервного копирования для таблиц InnoDB, и теплое резервное копирование для MyISAM и других видов таблиц. См. Раздел 24.2, "Резервное копирование MySQL Enterprise" для получения дополнительной информации об этой команде.

См. Также горячее резервное копирование, ibbackup команда, Резервное копирование MySQL Enterprise, теплое резервное копирование.

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

См. Также mysql.

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

См. Также логическое резервное копирование, Резервное копирование MySQL Enterprise, физическое резервное копирование, восстановление.

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

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

См. Также автоинкремент, первичный ключ, вторичный индексируют, синтетический ключ.

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

См. Также грязную страницу, степень, сброс, страницу.

Комбинация записи соединяет индексировать запись, и разрыв соединяют разрыв перед индексировать записью.

См. Также блокировку разрыва, блокировку, запишите блокировку.

Отраслевой термин, который означает то же самое как асинхронный ввод-вывод.

См. Также асинхронный ввод-вывод.

Запрос, который не использует SELECT ... FOR UPDATE или SELECT ... LOCK IN SHARE MODE пункты. Единственный вид запроса, учтенного глобальные таблицы в транзакции только для чтения. Противоположность блокировки читала.

См. Также чтение блокировки, запрос, транзакцию только для чтения.

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

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

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

См. Также ACID, непротиворечивое чтение, уровень изоляции, ЧТЕНИЕ НЕЗАФИКСИРОВАННОЕ, ПОВТОРИМОЕ ЧТЕНИЕ, СЕРИАЛИЗУЕМОЕ, транзакция.

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

Например, адресу можно было бы дать уникальный ID, так, чтобы база данных переписи могла представить жизни отношения в этом адресе, связывая тот ID с каждым элементом семейства, вместо того, чтобы хранить многократные копии сложного значения, такие как 123 Мэйн-Стрит, Anytown, США.

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

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

См. Также денормализованный, внешний ключ, OLTP, реляционный.

Широкий термин для ряда технологий доступа к данным, которые не используют язык SQL в качестве их основного механизма для чтения и записи данных. Некоторое технологическое действие NoSQL как значение ключа хранит, только принимая чтения единственного значения и записи; некоторые ослабляют ограничения методологии ACID; все еще другие не требуют предварительно запланированной схемы. Пользователи MySQL могут объединить обработку NoSQL-стиля для скорости и простоты с операциями SQL для гибкости и удобства, при использовании memcached API, чтобы непосредственно получить доступ к некоторым видам таблиц MySQL. Интерфейс memcached к таблицам InnoDB доступен в MySQL 5.6 и выше; см. Раздел 14.2.9, "Интеграция InnoDB с memcached" для деталей. Интерфейс memcached к таблицам MySQL Cluster доступен в MySQL Cluster 7.2; см. http://dev.mysql.com/doc/ndbapi/en/ndbmemcache.html для деталей.

См. Также ACID, InnoDB, memcached, схему, SQL.

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

См. столбец Also, ограничение, НУЛЬ, первичный ключ, ссылочную целостность.

Специальное значение в SQL, указывая на отсутствие данных. Любая арифметическая работа или тест равенства, включающий a NULL значение, поочередно производит a NULL результат. (Таким образом это подобно IEEE понятие с плавающей точкой о НЭН, "не число".) Любое совокупное вычисление такой как AVG() игнорирует строки с NULL значения, определяя, сколько строк, чтобы разделиться на. Единственный тест, который работает с NULL значения используют идиомы SQL IS NULL или IS NOT NULL.

NULL значения играют роль в, индексируют операции, потому что для производительности база данных должна минимизировать издержки отслеживания без вести пропавших значений данных. Как правило, NULL значения не сохранены в индексировании, потому что запрос, который тестирует индексированный столбец, используя стандартный оператор сравнения, никогда не мог соответствовать строку с a NULL значение для того столбца. По той же самой причине уникальные индексы не предотвращают NULL значения; те значения просто не представляются в индексировании. Объявление a NOT NULL ограничение на столбец обеспечивает заверение, что нет никаких строк, покинутых из индексирования, учитывая лучшую оптимизацию запросов (точный подсчет строк и оценка того, использовать ли индексирование).

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

Хотя база данных Oracle позволяет a NULL значение, которое будет связано со строкой, InnoDB обрабатывает результат такой работы как NULL.

См. Также индексируют, первичный ключ, SQL.

Столбец, содержащий данные переменной длины (такой как BLOB и VARCHAR) это является слишком длинным, чтобы соответствовать на странице B-дерева. Данные хранятся в страницах переполнения. DYNAMIC формат строки в формате файла Барракуды InnoDB более эффективен для такого хранения чем более старое COMPACT формат строки.

См. Также B-дерево, Барракуду, страницу переполнения.

Акроним для "Оперативной обработки транзакций". Система баз данных, или приложение базы данных, которое выполняет рабочую нагрузку со многими транзакциями, с частыми записями так же как чтениями, обычно влияя на небольшие количества данных за один раз. Например, система резервирования авиалинии или приложение, которое обрабатывает вклады в банк. Данные могли бы быть организованы в нормализованной форме для баланса между DML (вставляют/обновляют/удаляют) эффективность и запрашивают эффективность. Контраст с хранилищем данных.

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

См. Также хранилище данных, DML, InnoDB, запрос, блокировку строки, транзакцию.

Тип работы, которая не включает времени простоя, блокирования, или ограниченной работы для базы данных. Обычно примененный к DDL. Операции, которые сокращают периоды ограниченной работы, такие как быстрое создание индекса, развились в более широкий набор онлайновых операций DDL в MySQL 5.6.

В контексте резервных копий горячее резервное копирование является онлайновой работой, и теплое резервное копирование является частично онлайновой работой.

См. Также DDL, Быстрое Создание индекса, горячее резервное копирование, онлайновый DDL, теплое резервное копирование.

Функция, которая улучшает производительность, параллелизм, и доступность таблиц InnoDB во время DDL (прежде всего ALTER TABLE) операции. См. Раздел 5.5, "Онлайновый DDL для InnoDB Таблицы" для деталей.

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

Эта функция является улучшением Быстрой функции Создания индекса в MySQL 5.5 и Плагине InnoDB для MySQL 5.1.

См. Также DDL, Быстрое Создание индекса, онлайн.

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

Резервное копирование See Also MySQL Enterprise, mysqlbackup команда.

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

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

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

См. Также фиксацию, параллелизм, DML, блокировку, пессимистичную.

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

См. Также индексируют, присоединяются, запрашивают, таблица.

Параметр конфигурации для MySQL, или сохраненного в файле опции или переданный командная строка.

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

См. Также InnoDB, файл опции.

Файл, который содержит параметры конфигурации для экземпляра MySQL. Традиционно, на Linux и UNIX этот файл называют my.cnf, и на Windows это называют my.ini.

См. Также конфигурационный файл, my.cnf, опцию.

Отдельно выделенные дисковые страницы, которые содержат столбцы переменной длины (такой как BLOB и VARCHAR) это является слишком длинным, чтобы соответствовать на странице B-дерева. Связанные столбцы известны как столбцы вне страницы.

См. Также B-дерево, столбец вне страницы, страницу.

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

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

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

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

См. Также пул буферов, компактный формат строки, сжатый формат строки, файлы данных, степень, размер страницы, строку.

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

См. Также пул буферов, грязную страницу, сброс, основной поток, поток.

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

Запускаясь в MySQL 5.6, размер страницы для экземпляра InnoDB может составить или 4 Кбита, 8 Кбит, или 16 Кбит, которыми управляют innodb_page_size параметр конфигурации. Вы устанавливаете размер, создавая экземпляр MySQL, и это остается постоянным впоследствии. Тот же самый размер страницы применяется ко всем табличным областям InnoDB, и системная табличная область и любые отдельные табличные области, создаваемые в режиме файла на таблицу.

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

См. Также ограниченный диском, файл на таблицу, экземпляр, OLTP, страница, SSD, системная табличная область, табличная область.

Файл, содержащий определения раздела. Файлы с этим расширением всегда включаются в резервные копии, произведенные mysqlbackup команда Резервного продукта MySQL Enterprise.

Резервное копирование See Also MySQL Enterprise, mysqlbackup команда.

Таблица в отношении внешнего ключа, которое содержит начальные значения столбцов, на которые указывают из дочерней таблицы. Последствия удаления, или обновления строк в родительской таблице зависят от ON UPDATE и ON DELETE пункты в определении внешнего ключа. Строки с соответствующими значениями в дочерней таблице могли быть автоматически удалены или обновлены поочередно, или те столбцы могли быть установлены в NULL, или работа могла быть предотвращена.

См. Также дочернюю таблицу, внешний ключ.

Резервное копирование, которое содержит некоторые из таблиц в базе данных MySQL, или некоторые из баз данных в экземпляре MySQL. Контраст с полным резервным копированием.

См. Также резервное копирование, полное резервное копирование, таблицу.

Индексирование, которое представляет только часть значения столбца, обычно первые символы N (префикс) длинного VARCHAR значение.

См. Также индексируют, индексируют префикс.

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

См. Также фиксатор, взаимное исключение, rw-блокировку.

Функция в MySQL 5.6, который хранилища индексируют статистику для таблиц InnoDB на диске, обеспечивая лучше, планирует устойчивость запросы.

См. Также индексируют, оптимизатор, устойчивость плана, запрос, таблица.

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

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

См. Также мертвую блокировку, блокировку, оптимистичную.

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

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

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

См. Также непротиворечивое чтение, уровень изоляции, неповторяемое чтение, ЧТЕНИЕ НЕЗАФИКСИРОВАННОЕ, ПОВТОРИМОЕ ЧТЕНИЕ, СЕРИАЛИЗУЕМОЕ, транзакция.

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

См. Также логическое, физическое резервное копирование.

Резервное копирование, которое копирует фактические файлы данных. Например, mysqlbackup команда Резервного продукта MySQL Enterprise производит физическое резервное копирование, потому что его вывод содержит файлы данных, которые могут использоваться непосредственно mysqld сервер, приводящий к более быстрой работе восстановления. Контраст с логическим резервным копированием.

См. Также резервное копирование, логическое резервное копирование, Резервное копирование MySQL Enterprise, восстановление.

Акроним для восстановления момента времени.

См. Также восстановление момента времени.

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

См. Также запрос, запросите план выполнения.

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

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

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

См. Также встроенный, InnoDB.

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

См. Также резервное копирование, логическое резервное копирование, Резервное копирование MySQL Enterprise, физическое резервное копирование, PITR.

См. индексируют префикс.

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

См. Также двоичный журнал, горячее резервное копирование, инкрементное резервное копирование, Резервное копирование MySQL Enterprise, необработанное резервное копирование, восстановление.

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

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

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

См. Также кластерный индекс, индексируйте, естественный ключевой, синтетический ключ.

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

См. Также параллелизм, поток.

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

См. Также запись нижней грани, блокировку, supremum запись.

POSIX распараллеливает стандарт, который определяет API для поточной обработки и блокировки операций на системах Linux и UNIX. На UNIX и системах Linux, InnoDB использует эту реализацию для взаимных исключений.

См. Также взаимное исключение.

Тип сборки "мусора", выполняемой отдельным потоком, работая на периодическом расписании. Чистка включает эти действия: удаление устаревших значений от индексирует; физически удаляющие строки, которые были отмечены для удаления предыдущим DELETE операторы.

См. Также восстановление катастрофического отказа, удалите, doublewrite буфер.

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

См. Также буфер изменения, буферизацию изменения, удалите буферизацию, вставьте буфер, вставьте буферизацию.

Другое имя для InnoDB список предыстории. Связанный с innodb_max_purge_lag параметр конфигурации.

См. Также список предыстории, чистку.

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

См. Также чистку, поток.

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

По историческим причинам иногда обсуждения внутренней обработки для операторов используют "запрос" в более широком смысле, включая другие типы операторов MySQL, такие как операторы DML и DDL.

См. Также DDL, DML, индексируйте, присоединитесь, SQL, таблица.

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

См. Также индексируют, присоединяются, устойчивость плана, запрос.

См. общий журнал запросов.

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

В MySQL 5.6 и выше, синтаксис FLUSH TABLES ... FOR EXPORT записи некоторые данные к диску для InnoDB таблицы, которые делают более простым поддержать те таблицы, копируя файлы данных.

См. Также резервное копирование, сброс, InnoDB, завершение работы.

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

См. Также параллелизм.

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

Первоначально, число выбранных страниц было фиксировано в 8; теперь, это определяется установкой innodb_stats_sample_pages параметр.

Путем случайные страницы выбираются, зависит от установки innodb_use_legacy_cardinality_algorithm параметра. У настройки по умолчанию (ПРОЧЬ) есть лучшая случайность чем в более старых выпусках.

См. Также количество элементов.

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

См. Также двоичный журнал, горячее резервное копирование, ibbackup_logfile, инкрементное резервное копирование, Резервное копирование MySQL Enterprise, подготовленное резервное копирование, восстановление.

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

Когда транзакция с этим уровнем изоляции выполняет UPDATE ... WHERE или DELETE ... WHERE операции, другим транзакциям, возможно, придется ожидать. Транзакция может выполнить SELECT ... FOR UPDATE, и LOCK IN SHARE MODE операции, не заставляя другие транзакции ожидать.

См. Также ACID, уровень изоляции, блокировку, ПОВТОРИМОЕ ЧТЕНИЕ, СЕРИАЛИЗУЕМОЕ, транзакция.

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

См. Также ACID, грязное чтение, уровень изоляции, блокировку, транзакцию.

Внутренний снимок используется механизмом MVCC InnoDB. Определенные транзакции, в зависимости от их уровня изоляции, см. значения данных, как они были в то время, когда транзакция (или в некоторых случаях, оператор) запускалась. Уровни изоляции, которые используют представление чтения, являются ПОВТОРИМЫМ ЧТЕНИЕМ, ЧИТАЮТ ФИКСИРОВАВШИЙ, и ЧИТАЮТ НЕЗАФИКСИРОВАННЫЙ.

См. Также уровень изоляции, MVCC, ФИКСИРОВАВШЕЕ ЧТЕНИЕ, СЧИТАЙТЕ НЕЗАФИКСИРОВАННОЕ, ПОВТОРИМОЕ ЧТЕНИЕ, транзакцию.

Тип ввода-вывода запрашивает, чтобы выбрал группу с упреждением страниц (вся степень) в пул буферов асинхронно, в ожидании, что эти страницы скоро будут необходимы. Линейный метод чтения вперед выбирает все страницы с упреждением одной степени, основанной на схемах доступа для страниц в предыдущей степени, и является частью всех версий MySQL, запускающихся с Плагина InnoDB для MySQL 5.1. Случайный метод чтения вперед выбирает все страницы с упреждением для степени, как только определенное число страниц от той же самой степени находится в пуле буферов. Случайное чтение вперед не является частью MySQL 5.5, но повторно представляется в MySQL 5.6 под управлением innodb_random_read_ahead параметр конфигурации.

См. Также пул буферов, степень, страницу.

Тип транзакции, которая может быть оптимизирована для InnoDB таблицы, устраняя часть бухгалтерии, связанной с созданием чтения, просматривают для каждой транзакции. Может только выполнить запросы чтения без блокировки. Это может быть запущено явно с синтаксисом START TRANSACTION READ ONLY, или автоматически при определенных условиях. См. Раздел 14.2.4.2.3, "Оптимизация для Транзакций Только для чтения" для деталей.

См. Также чтение без блокировки, считайте представление, транзакцию.

Блокировка на индексировать записи. Например, SELECT c1 FOR UPDATE FROM t WHERE c1 = 10; препятствует тому, чтобы любая другая транзакция вставила, обновила, или удалила строки где значение t.c1 10. Контраст с блокировкой разрыва и следующей блокировкой ключа.

См. Также блокировку разрыва, блокировку, следующую блокировку ключа.

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

См. Также восстановление катастрофического отказа, DML, LSN, журнал отката, транзакцию.

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

Журнал отката физически представляется как ряд файлов, обычно называемых ib_logfile0 и ib_logfile1. Данные в журнале отката кодируются с точки зрения записей, на которые влияют; эти данные все вместе упоминаются как восстановление. Проход данных через журналы отката представляется постоянно увеличивающимся значением LSN. Исходный предел на 4 Гбайт на максимальном размере для журнала отката повышается до 512 Гбайт в MySQL 5.6.

Дисковое расположение журнала отката под влиянием параметров конфигурации innodb_log_file_size, innodb_log_group_home_dir, и (редко) innodb_log_files_in_group. На производительность операций журнала отката также влияет буфер журнала, которым управляют innodb_log_buffer_size параметр конфигурации.

См. Также восстановление катастрофического отказа, файлы данных, ib_logfile, зарегистрируйте буфер, LSN, восстановление, завершение работы, транзакцию.

Самый старый формат строки InnoDB, доступный для таблиц, используя формат файла Антилопы. До MySQL 5.0.3 это был единственный формат строки, доступный в InnoDB. В Моем SQL 5.0.3 и позже, значение по умолчанию является компактным форматом строки. Можно все еще определить избыточный формат строки для совместимости с более старыми таблицами InnoDB.

См. Также Антилопу, компактный формат строки, формат файла, формат строки.

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

См. Также ACID, ограничение FOREIGN KEY, ограничение NOT NULL, ограничение на уникальность данных.

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

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

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

В математическом контексте отношения в пределах базы данных получаются из теории множеств. Например, OR и AND операторы a WHERE пункт представляет понятия объединения и пересечения.

См. Также ACID, ограничение, внешний ключ, нормализованный.

В полнотекстовой функции поиска, число, показывающее подобие между строкой поиска и данными в ПОЛНОТЕКСТОВОМ ИНДЕКСЕ. Например, когда Вы ищете отдельное слово, то слово обычно более важно для строки где, если происходит несколько раз в тексте чем строка, где это появляется только однажды.

См. Также полнотекстовый поиск, ПОЛНОТЕКСТОВЫЙ ИНДЕКС.

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

Когда транзакция с этим уровнем изоляции выполняет UPDATE ... WHERE, DELETE ... WHERE, SELECT ... FOR UPDATE, и LOCK IN SHARE MODE операции, другим транзакциям, возможно, придется ожидать.

См. Также ACID, непротиворечивое чтение, уровень изоляции, блокировку, фантом, СЕРИАЛИЗУЕМЫЙ, транзакция.

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

См. Также построчную репликацию, основанную на операторе репликацию.

Процесс помещения ряда файлов резервных копий от Резервного продукта MySQL Enterprise на месте для использования MySQL. Эта работа может быть выполнена, чтобы фиксировать поврежденную базу данных, возвратиться к некоторому более раннему моменту времени, или (в контексте репликации), чтобы установить новую ведомую базу данных. В Резервном продукте MySQL Enterprise эта работа выполняется copy-back опция mysqlbackup команда.

См. Также горячее резервное копирование, Резервное копирование MySQL Enterprise, mysqlbackup команда, подготовленное резервное копирование, репликация.

SQL-оператор, который заканчивает транзакцию, отменяя любые изменения, произведенные транзакцией. Это - противоположность фиксации, которая делает постоянным любые изменения сделанный в транзакции.

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

См. Также ACID, фиксацию, транзакцию.

Область хранения, содержащая журнал отмены, часть системной табличной области.

См. Также системную табличную область, отмените журнал.

Логическая структура данных определяется рядом столбцов. Ряд строк составляет таблицу. В пределах файлов данных InnoDB каждая страница может содержать одну или более строк.

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

См. столбец Also, файлы данных, страницу, формат строки, таблицу.

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

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

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

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

Контраст с блокировками таблицы, используемыми MyISAM, или во время операций DDL на таблицах InnoDB, которые не могут быть сделаны с онлайновым DDL; те блокировки блокируют параллельный доступ к таблице.

См. Также DDL, DML, InnoDB, блокировку, блокировку, онлайновый DDL, блокировку таблицы, транзакцию.

Форма репликации, где события распространяются от главного сервера, определяющего, как изменить отдельные строки на ведомом сервере. Безопасно использовать для всех настроек innodb_autoinc_lock_mode опция.

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

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

См. Также InnoDB, блокировку, блокировку строки, блокировку таблицы, транзакцию.

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

См. Также фиксатор, блокировку, взаимное исключение, Схему Производительности.

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

См. Также откат, транзакцию.

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

См. Также доступность, масштабируйтесь, увеличьтесь.

Метод для того, чтобы увеличить масштабируемость, добавляя новые серверы и больше экземпляров MySQL. Например, устанавливая репликацию, MySQL Cluster, объединение в пул соединения, или другие функции, которые распространяют работу через группу серверов. Контраст с увеличивается.

См. Также масштабируемость, увеличиться.

Метод для того, чтобы увеличить масштабируемость, увеличивая емкость существующих аппаратных средств или программного обеспечения. Например, увеличивая память на сервере и корректируя связанные с памятью параметры такой как innodb_buffer_pool_size и innodb_buffer_pool_instances. Контраст с масштабом.

См. Также масштабируемость, масштабируйтесь.

Концептуально, схема является рядом взаимосвязанных объектов базы данных, таких как таблицы, столбцы таблицы, типы данных столбцов, индексирует, внешние ключи, и так далее. Эти объекты соединяются через синтаксис SQL, потому что столбцы составляют таблицы, внешние ключи обращаются к таблицам и столбцам и так далее. Идеально, они также соединяются логически, сотрудничая как часть объединенного приложения или гибкой платформы. Например, information_schema и performance_schema базы данных используют "схему" на их имена, чтобы подчеркнуть тесные отношения между таблицами и столбцами, которые они содержат.

В MySQL, физически, схема синонимична с базой данных. Можно заменить ключевым словом SCHEMA вместо DATABASE в синтаксисе SQL MySQL, например используя CREATE SCHEMA вместо CREATE DATABASE.

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

См. Также базу данных, набор ib-файла, INFORMATION_SCHEMA, Схему Производительности.

В MySQL полнотекстовые запросы поиска используют специальное предложение, отчасти индексируют, ПОЛНОТЕКСТОВЫЙ ИНДЕКС. В MySQL 5.6.4 и, InnoDB и MyISAM таблицы обе поддержки FULLTEXT индексирует; прежде, они индексируют, были только доступны для MyISAM таблицы.

См. Также полнотекстовый поиск, ПОЛНОТЕКСТОВЫЙ ИНДЕКС.

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

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

Создание и отбрасывание вторичного индексируют, традиционно включил существенные издержки от копирования всех данных в таблице InnoDB. Быстрая функция создания индекса Плагина InnoDB делает обоих CREATE INDEX и DROP INDEX операторы намного быстрее для вторичного InnoDB индексируют.

См. Также кластерный индекс, Быстрое Создание индекса, индексировать.

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

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

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

См. Также степень, файл на таблицу, откатывайте сегмент, системную табличную область, табличную область, отмените журнал.

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

См. Также количество элементов, запрос.

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

См. Также непротиворечивое чтение, уровень изоляции, ФИКСИРОВАВШЕЕ ЧТЕНИЕ.

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

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

См. Также ACID, непротиворечивое чтение, уровень изоляции, блокировку, ПОВТОРИМОЕ ЧТЕНИЕ, транзакцию.

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

См. Также клиент, mysqld.

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

См. Также монопольную блокировку, блокировку, транзакцию.

Другой способ обратиться к системной табличной области.

См. Также системную табличную область.

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

См. Также грязную страницу, сброс, журнал отката, рабочую нагрузку.

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

Режимом завершения работы управляют innodb_fast_shutdown опция.

См. Также быстрое завершение работы, InnoDB, медленное завершение работы, запуск.

Часто сокращаемый к "ведомому устройству". Машина сервера базы данных в сценарии репликации, который получает изменения от другого сервера (ведущее устройство) и применяет те те же самые изменения. Таким образом это поддерживает то же самое содержание как ведущее устройство, хотя это могло бы отстать несколько позади.

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

У ведомых серверов обычно есть высокие рабочие нагрузки, потому что они обрабатывают весь DML (запись) операции, переданные от ведущего устройства, так же как пользовательских запросов. Чтобы гарантировать, что ведомые серверы могут применить изменения от ведущего устройства достаточно быстро, у них часто есть быстрые устройства ввода-вывода и достаточный ЦП и память, чтобы выполнить многократные экземпляры базы данных на том же самом ведомом сервере. Например, главный сервер мог бы использовать хранение жесткого диска, в то время как ведомые серверы используют SSD.

См. Также DML, репликацию, сервер, SSD.

Тип журнала, используемого для настройки производительности SQL-операторов, обрабатывается сервером MySQL. Информация журнала хранится в файле. Следует активировать эту опцию, чтобы использовать это. Вы управляете, какие категории "медленных" SQL-операторов регистрируются. Для получения дополнительной информации см. Раздел 5.2.5, "Медленный Журнал запросов".

См. Также общий журнал запросов, журнал.

Тип завершения работы, которое делает дополнительный InnoDB сбрасывание операций перед завершением. Также известный как чистое завершение работы. Определенный параметром конфигурации innodb_fast_shutdown=0 или команда SET GLOBAL innodb_fast_shutdown=0;. Хотя само завершение работы может занять больше времени, то время будет сэкономлено на последующем запуске.

См. Также чистое завершение работы, быстрое завершение работы, завершение работы.

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

См. Также фиксацию, непротиворечивое чтение, уровень изоляции, транзакцию.

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

До MySQL 5.6 этот hardcoded оценивает представленные трудности в перемещении InnoDB файлы табличной области между экземплярами MySQL. Запускаясь в MySQL 5.6, можно скопировать файлы табличной области между экземплярами при использовании мобильной функции табличной области, включающей операторы FLUSH TABLES ... FOR EXPORT, ALTER TABLE ... DISCARD TABLESPACE, и ALTER TABLE ... IMPORT TABLESPACE. Информация должна была корректироваться, ID пространства передается в.cfg файле, который Вы копируете наряду с табличной областью. См. Раздел 14.2.4.2.34, "Улучшенное управление Табличной областью" для деталей.

См. Также.cfg файл, файл на таблицу.ibd файл, системная табличная область, табличная область, мобильная табличная область.

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

См. Также фиксатор, блокировку, взаимное исключение, ожидать.

Язык структурированных запросов, который является стандартным для того, чтобы выполнить операции базы данных. Часто разделенный на DDL категорий, DML, и запросы. MySQL включает некоторые дополнительные категории оператора, такие как репликация. См. Главу 9, Структуру Языка для стандартных блоков синтаксиса SQL, Главы 11, Типов данных для типов данных, чтобы использовать для столбцов таблицы MySQL, Главы 13, Синтаксиса SQL-оператора для деталей о SQL-операторах и их связанных категориях, и Главе 12, Функциях и Операторах для стандартных и специфичных для MySQL функций, чтобы использовать в запросах.

См. Также DDL, DML, запрос, репликацию.

Акроним для "твердотельного диска". Тип устройства хранения с различными показателями производительности чем традиционный жесткий диск (HDD): меньшая емкость хранения, быстрее для случайных чтений, никаких подвижных частей, и со многими соображениями, влияющими на производительность записи. Его показатели производительности могут влиять на пропускную способность ограниченной диском рабочей нагрузки.

См. Также ограниченный диском, SSD.

Процесс запуска сервера MySQL. Обычно сделанный одной из программ, перечисленных в Разделе 4.3, "MySQL Server и Server-Startup Programs". Противоположность завершения работы.

См. Также завершение работы.

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

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

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

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

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

Другие типы статистики доступны для объектов базы данных и действия базы данных через INFORMATION_SCHEMA и таблицы PERFORMANCE_SCHEMA.

См. Также количество элементов, индексируйте, INFORMATION_SCHEMA, НУЛЬ, Схема Производительности, персистентная статистика, первичный ключ, запросите план выполнения, вторичный индексируют, представляют в виде таблицы, транзакция.

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

См. Также полнотекстовый поиск, ПОЛНОТЕКСТОВЫЙ ИНДЕКС.

В ПОЛНОТЕКСТОВОМ ИНДЕКСЕ слово, которое считают распространенным или достаточно тривиальным, что оно опускается от поиска, индексирует и проигнорированный в запросах поиска. Различные параметры конфигурации управляют stopword, обрабатывающим для InnoDB и MyISAM таблицы. См. Раздел 12.9.4, "Полнотекстовый Stopwords" для деталей.

См. Также ПОЛНОТЕКСТОВЫЙ ИНДЕКС, поиск индексируют.

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

Резервный продукт MySQL Enterprise оптимизируется для того, чтобы поддержать таблицы InnoDB. Это может также поддержать таблицы, обработанные MyISAM и другими механизмами хранения.

См. Также InnoDB, Резервное копирование MySQL Enterprise, табличный тип.

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

У MySQL также есть что-то названное строгим режимом.

См. Также формат файла, innodb_strict_mode, формат строки.

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

См. Также пул буферов, замещение, список, LRU.

Псевдозапись в индексировании, представляя разрыв выше самого большого значения в этом индексирует. Если у транзакции есть оператор такой как SELECT ... FOR UPDATE ... WHERE col > 10;, и самое большое значение в столбце 20, это - блокировка на записи supremum, которая препятствует тому, чтобы другие транзакции вставили еще большие значения такой как 50, 100, и так далее.

См. Также разрыв, запись нижней грани, псевдозапись.

Имя синонима для синтетического ключа.

См. Также синтетический ключ.

Индексированный столбец, обычно первичный ключ, где значения присваиваются произвольно. Часто сделанное использование столбца автоприращения. Обрабатывая значение как абсолютно произвольный, можно избежать чрезмерно рестриктивных правил и дефектных предположений приложения. Например, у числовой последовательности, представляющей числа сотрудника, мог бы быть разрыв, если бы сотрудник был одобрен для того, чтобы нанять, но никогда фактически присоединен. Или у сотрудника номер 100 могла бы быть более поздняя дата найма чем сотрудник номер 500, если бы они покинули компанию и позже возразили. Числовые значения также производят более короткие значения предсказуемой длины. Например, храня числовые коды, означающие "Дорогу", "Бульвар", "Скоростная автомагистраль", и так далее более эффективен пространством чем повторение тех строк много раз.

Также известный как суррогатный ключ. Контраст с естественным ключом.

См. Также автоинкремент, естественный ключ, первичный ключ, суррогатный ключ.

Маленький набор файлов данных (ibdata файлы) содержащий метаданные для InnoDB-связанных объектов (словарь данных), и области хранения для журнала отмены, буфера изменения, и буфера doublewrite. В зависимости от установки innodb_file_per_table, когда таблицы составляются, это могло бы также содержать таблицу и индексировать данные для некоторых или всех таблиц InnoDB. Данные и метаданные в системной табличной области применяются ко всем базам данных в экземпляре MySQL.

До MySQL 5.6.7 значение по умолчанию должно было сохранить все таблицы InnoDB и индексирует в системной табличной области, часто заставляя этот файл стать очень большим. Поскольку системная табличная область никогда не уменьшается, проблемы хранения могли возникнуть, если бы большое количество временных данных было загружено и затем удалено. В MySQL 5.6.7 и выше, значение по умолчанию является режимом файла на таблицу, где каждая таблица и его связанное индексируют, сохранены в отдельном.ibd файле. Это новое значение по умолчанию облегчает использовать функции InnoDB, которые полагаются на формат файла Барракуды, такой как табличное сжатие и ДИНАМИЧЕСКИЙ формат строки.

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

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

См. Также Барракуду, буфер изменения, сжатие, словарь данных, базу данных, doublewrite буферный, динамический формат строки, файл на таблицу.ibd файл, ibdata файл, innodb_file_per_table, экземпляр, Резервное копирование MySQL Enterprise, табличная область, отмените журнал.

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

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

Таблицы InnoDB, составленные в режиме файла на таблицу, могут использовать формат файла Барракуды. Таблицы барракуды могут использовать ДИНАМИЧЕСКИЙ формат строки или СЖАТЫЙ формат строки. Эти относительно новые настройки активируют много опций InnoDB, таких как сжатие, быстрое создание индекса, и столбцы вне страницы

Для обратной совместимости с MySQL 5.1 и ранее, таблицы InnoDB в системной табличной области должны использовать формат файла Антилопы, который поддерживает компактный формат строки и избыточный формат строки.

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

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

Блокировка, которая препятствует тому, чтобы любая другая транзакция получила доступ к таблице. InnoDB прилагает значительное усилие, чтобы сделать такие блокировки ненужными, при использовании методов, таких как онлайновый DDL, блокировки строки и непротиворечивые чтения для того, чтобы обработать операторы DML и запросы. Можно создать такую блокировку через SQL, используя LOCK TABLE оператор; один из шагов в переходе от других систем баз данных или механизмов хранения MySQL должен удалить такие операторы везде, где практичный.

См. Также непротиворечивое чтение, DML, блокировку, блокировку, онлайновый DDL, запрос, блокировку строки, таблицу, транзакцию.

См. полное сканирование таблицы.

См. статистику.

Устаревший синоним для механизма хранения. Мы обращаемся к InnoDB таблицы, MyISAM таблицы, и так далее.

См. Также InnoDB, механизм хранения.

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

Используя многократные табличные области, включая innodb_file_per_table опция, жизненно важно для использования многих функций MySQL, таких как табличное сжатие и мобильные табличные области, и управление использованием диска. См. Раздел 5.4.1, "Управляя Табличными областями InnoDB" и Разделом 14.2.4.2.34, "Улучшенное управление Табличной областью" для деталей.

Табличные области, создаваемые встроенным механизмом хранения InnoDB, совместимы снизу вверх с Плагином InnoDB. Табличные области, создаваемые Плагином InnoDB, совместимы сверху вниз со встроенным механизмом хранения InnoDB, если они используют формат файла Антилопы.

MySQL Cluster также группирует свои таблицы в табличные области. См. Раздел 17.5.12.1, "MySQL Cluster Disk Data Objects" для деталей.

См. Также Антилопу, Барракуду, сжатый формат строки, словарь данных, файлы данных, файл на таблицу, индексируйте, innodb_file_per_table, системная табличная область, таблица.

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

См. Также словарь данных, файл на таблицу.frm файл.ibd файл, системная табличная область, табличная область.

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

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

См. Также таблицу.

Табличная область для несжатого InnoDB временные таблицы и связанные объекты. Эта табличная область была представлена в MySQL 5.7.1. Опция конфигурационного файла, innodb_temp_data_file_path, позволяет пользователям определять относительный путь для временного файла данных. Если innodb_temp_data_file_path не определяется, поведение значения по умолчанию должно создать единственный авторасширяющийся названный файл данных 12 МБ ibtmp1 в каталоге данных, рядом ibdata1. Временная табличная область воссоздается на каждом сервере, запускаются, и получает динамически сгенерированный идентификатор пространства, который помогает избежать конфликтов с существующими идентификаторами пространства. Временная табличная область не может находиться на необработанном устройстве. Неспособность или ошибка, создающая временную таблицу, обрабатываются как фатальные, и запуску сервера откажут.

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

См. Также ibtmp файл.

Набор столбцов включается в ПОЛНОТЕКСТОВЫЙ ИНДЕКС.

См. Также ПОЛНОТЕКСТОВЫЙ ИНДЕКС.

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

См. Также параллелизм, основной поток, процесс, Pthreads.

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

См. Также doublewrite буфер.

Акроним для "транзакций в секунду", модуль измерения иногда используется в сравнительных тестах. Его значение зависит от рабочей нагрузки, представленной определенным эталонным тестированием, объединенным с факторами, которыми Вы управляете, такие как аппаратная емкость и конфигурация базы данных.

См. Также транзакцию, рабочую нагрузку.

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

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

См. Также ACID, фиксацию, уровень изоляции, блокировку, откат.

Внутреннее поле связалось с каждой строкой. Это поле физически изменяется ВСТАВКОЙ, ОБНОВЛЕНИЕМ, и УДАЛИТЕ операции, чтобы записать, какая транзакция заблокировала строку.

См. Также неявную блокировку строки.

Функция, которая позволяет табличной области быть перемещенной от одного экземпляра до другого. Традиционно, это не было возможно для табличных областей InnoDB, потому что все табличные данные были частью системной табличной области. В MySQL 5.6 и выше, FLUSH TABLES ... FOR EXPORT синтаксис готовит таблицу InnoDB к тому, что она скопировала в другой сервер; выполнение ALTER TABLE ... DISCARD TABLESPACE и ALTER TABLE ... IMPORT TABLESPACE на другом сервере приносит скопированный файл данных в другой экземпляр. Отдельное .cfg файл, скопированный наряду с.ibd файлом, используется, чтобы обновить табличные метаданные (например ID пространства), поскольку табличная область импортируется. См. Раздел 14.2.4.2.34, "Улучшенное управление Табличной областью" для информации об использовании.

См. Также.ibd файл, расположите с интервалами ID, системную табличную область, табличную область.

Файл, содержащий триггерные параметры. Файлы с этим расширением всегда включаются в резервные копии, произведенные mysqlbackup команда Резервного продукта MySQL Enterprise.

Резервное копирование See Also MySQL Enterprise, mysqlbackup команда.TRN файл.

Файл, содержащий триггерную информацию о пространстве имен. Файлы с этим расширением всегда включаются в резервные копии, произведенные mysqlbackup команда Резервного продукта MySQL Enterprise.

Резервное копирование See Also MySQL Enterprise, mysqlbackup команда.TRG файл.

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

Работа DDL, которая удаляет все содержание таблицы, вставая из-за стола и связанный, индексирует неповрежденный. Контраст с отбрасыванием. Хотя концептуально у этого есть тот же самый результат как a DELETE оператор без WHERE пункт, это работает по-другому негласно: InnoDB составляет новую пустую таблицу, отбрасывает старую таблицу, затем переименовывает новую таблицу, чтобы взять место старого. Поскольку это - работа DDL, она не может откатываться.

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

См. Также DDL, отбрасывание, внешний ключ, откат.

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

См. Также курсор.

Работа, которая является частью распределенной транзакции под спецификацией XA. (Иногда сокращаемый как 2PC.), Когда многократные базы данных участвуют в транзакции, или все базы данных фиксируют изменения, или все базы данных откатывают изменения.

См. Также фиксацию, откат, транзакцию, XA.

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

См. Также откат, откатывайте сегмент, системную табличную область, транзакцию, отмените журнал, отмените табличную область.

См. журнал отмены.

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

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

Журнал отмены разделяется на отдельные части, буфер отмены вставки и буфер отмены обновления. Все вместе эти части также известны как сегмент отката, знакомый термин для DBA Oracle.

См. Также непротиворечивое чтение, откатывайте сегмент, SSD, системную табличную область, транзакцию, отмените табличную область.

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

См. Также системную табличную область, отмените журнал.

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

См. Также ограничение, реляционный, уникальный индекс.

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

Оптимизация буферизации вставки не применяется к уникальным индексам. Как обходное решение, можно временно установить unique_checks=0 в то время как выполнение объемных данных загружается в таблицу InnoDB.

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

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

См. Также количество элементов, ограничение на уникальность данных, уникальный индекс.

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

См. Также мертвую блокировку, обнаружение мертвой блокировки, innodb_lock_wait_timeout.

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

На системах с тяжелым грузом и многими транзакциями, Вы могли бы использовать вывод от SHOW INNODB STATUS команда, чтобы определить, проводят ли потоки слишком много времени, ожидая, и если так, как можно улучшить параллелизм.

См. Также параллелизм, фиксатор, блокировку, взаимное исключение, вращение.

Резервное копирование, взятое, в то время как база данных работает, но это ограничивает некоторые операции базы данных во время процесса резервного копирования. Например, таблицы могли бы стать только для чтения. Для занятых приложений и веб-сайтов, Вы могли бы предпочесть горячее резервное копирование.

См. Также резервное копирование, холодное резервное копирование, горячее резервное копирование.

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

Этот процесс происходит естественно в течение долгого времени, когда сервер MySQL перезапускается или подвергается новой рабочей нагрузке. Запускаясь в MySQL 5.6, можно ускорить процесс разминки, устанавливая переменные конфигурации innodb_buffer_pool_dump_at_shutdown=ON и innodb_buffer_pool_load_at_startup=ON, возвращать содержание пула буферов в память после перезапуска. Как правило, Вы выполняете рабочую нагрузку в течение некоторого времени, чтобы нагреть пул буферов прежде, чем выполнить тесты производительности, гарантировать непротиворечивые результаты через многократные выполнения; иначе, производительность могла бы быть искусственно низкой во время первого показа.

См. Также пул буферов, рабочую нагрузку.

Встроенный механизм хранения InnoDB и Плагин InnoDB поддерживаются на всем одинаковом версии Microsoft Windows как сервер MySQL. У Резервного продукта MySQL Enterprise есть более всесторонняя поддержка систем Windows чем InnoDB Горячий Резервный продукт, который это заменяет.

См. Также InnoDB, InnoDB Горячее Резервное копирование, Резервное копирование MySQL Enterprise, плагин.

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

См. Также узкое место, ограниченное диском, ограниченное диском, SQL.

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

См. Также пул буферов, грязную страницу, сброс.

Стандартный интерфейс для того, чтобы скоординировать распределенные транзакции, позволяя многократные базы данных участвовать в транзакции, поддерживая соответствие ACID. Для полного изложения см. Раздел 13.3.7, "Транзакции XA".

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

См. Также фиксацию, транзакцию, двухфазную фиксацию.

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

См. Также пул буферов, сброс, INFORMATION_SCHEMA, LRU, страницу.