WebMoney:  WMZ Z294115950220  WMR R409981405661  WME E134003968233	Visa  4274 3200 2453 6495

Глоссарий MySQL Эти термины обычно используются в информации о сервере базы данных MySQL. Этот глоссарий порожден как ссылка для терминологии о механизме хранения InnoDB и большинстве определений в MySQL. A Файл .ARM Метаданные для таблиц ARCHIVE. Файлы с этим расширением всегда включаются в резервные копии, произведенные командой mysqlbackup пакета MySQL Enterprise Backup. Не путать с файлами .ARZ. См. Файлы .ARZ, MySQL Enterprise Backup , mysqlbackup. Файл .ARZ Не путать с файлами .ARM. Данные для таблиц ARCHIVE. Файлы с этим расширением всегда включаются в резервные копии, произведенные командой mysqlbackup пакета MySQL Enterprise Backup. См. Файлы .ARM, MySQL Enterprise Backup , mysqlbackup. ACID Сокращение для atomicity, consistency, isolation и durability. Эти свойства все желательны в системе базы данных и близко связаны с понятием транзакции. Транзакционые особенности InnoDB придерживаются принципов ACID. Транзакции это атомные единицы работы, которые могут быть переданы или отменены. Когда транзакция производит многократные изменения в базе данных, все изменения преуспевают, когда транзакция передана, или все изменения отменены, когда транзакция оменена. База данных остается в последовательном состоянии всегда после каждой передачи или отмены и в то время, как транзакции происходят. Если связанные данные обновляются через многократные таблицы, запросы видят или все старые значения или все новые значения, но не соединение старых и новых значений. Транзакции защищены (изолированы) друг от друга в то время, как они происходят: они не могут вмешаться друг в друга или видеть нейтральные данные друг друга. Эта изоляция достигнута через механизм блокировки. Опытные пользователи могут скорректировать уровень изоляции, балансируя между меньшим количеством защиты в пользу увеличенной работы и параллелизма, когда они могут убедиться, что транзакции действительно не вмешиваются друг в друга. Результаты транзакций длительны: как только транзакция передана, произведенные изменения защищены от перебоев в питании, системных катастрофических отказов или других потенциальных опасностей. Длительность, как правило, вовлекает запись на диск с определенным количеством избыточности, чтобы защитить от перебоев в питании или катастрофических отказов программного обеспечения. В InnoDB этому способствует буфер doublewrite. См. atomic, commit, concurrency, doublewrite buffer, isolation level, locking, rollback, transaction. Адаптивный сброс Алгоритм для InnoDB, который сглаживает скачки ввода/вывода из-за контрольных точек. Вместо того, чтобы сбросить все измененные страницы из буферного пула в файлы данных сразу, MySQL периодически сбрасывает маленькие наборы измененных страниц. Адаптивный алгоритм расширяет этот процесс, оценивая оптимальный уровень этих периодических сбросов, основанный на уровне сброса вообще и том, как быстро произведена информация redo. См. buffer pool, checkpoint, data files, flush, InnoDB, page, redo log. Адаптивный хеш-индекс Оптимизация для InnoDB, которая может ускорить использование поисков = и IN, создавая хеш-индекс в памяти. MySQL отслеживает индексные поиски для InnoDB и если запросы могли бы извлечь выгоду из хеш-индекса, создает его автоматически для индексных страниц, к которым часто получают доступ. В некотором смысле адаптивный хеш конфигурирует MySQL во время выполнения, чтобы использовать в своих интересах вполне достаточную основную память. Этой особенностью управляет опция innodb_adaptive_hash_index. Поскольку эта особенность приносит пользу лишь некоторым рабочим нагрузкам, но не другим, а память, используемая для хеша, индексирует, сохранена в буферном пуле , как правило, Вы должны определить эффективность с этой опцией, включенной и отключенной. Хеш-индекс всегда создается основанный на существующем вторичном индексе InnoDB, который организован как B-tree. MySQL может создать хеш-индекс на префиксе любой длины ключа, определенного для B-дерева, в зависимости от образца поисков по индексу. Хеш-индекс может быть частичным: целое B-дерево не должно кэшироваться в буферном пуле. В MySQL 5.6 и выше другой способ использовать в своих интересах быстрые поиски единственного значения с InnoDB это использовать плагин InnoDB memcached, см. раздел 16.19. См. B-tree, buffer pool, hash index, memcached, page, secondary index. AHI Сокращение от adaptive hash index. См. adaptive hash index . AIO Сокращение от asynchronous I/O. Вы могли бы видеть этот акроним в сообщениях или ключевых словах InnoDB. См. asynchronous I/O. application programming interface (API) Ряд функций или процедур. API обеспечивает устойчивый набор имен и типов для функций, процедур, параметров и возвращаемых значений. Применение Когда резервное копирование, произведенное MySQL Enterprise Backup, не включает новые изменения, которые произошли, в то время как резервное копирование было в стадии реализации, процесс обновления резервных файлов, чтобы включить те изменения, известен как применение. Это определено опцией apply-log команды mysqlbackup. Прежде, чем изменения применены, мы именуем файлы как сырое резервное копирование. После того, как изменения применены, мы именуем файлы как готовое резервное копирование. Изменения зарегистрированы в файле ibbackup_logfile , как только шаг применения закончен, этот файл больше не необходим. См. hot backup, ibbackup_logfile, MySQL Enterprise Backup , prepared backup, raw backup. асинхронный ввод/вывод Тип работы ввода/вывода, которая позволяет другой обработке продолжаться перед завершением ввода/вывода. Также известный как неблокирующий ввод/вывод и AIO. InnoDB использует этот тип ввода/вывода для определенных операций, которые могут работать параллельно, не затрагивая надежность базы данных, таких как чтение страниц в буферный пул, которые фактически не требуются, но могут скоро быть необходимы. Исторически InnoDB использует асинхронный ввод/вывод только в системах Windows. Начиная с InnoDB Plugin 1.1 и MySQL 5.5 InnoDB использует асинхронный ввод/вывод на системах Linux. Это изменение вводит зависимость от libaio. Асинхронный ввод/вывод на системах Linux сконфигурирован, используя опцию innodb_use_native_aio , которая включена по умолчанию. На других Unix-системах InnoDB использует только синхронный ввод/вывод. См. buffer pool, non-blocking I/O. Атомный В SQL транзакции это единицы работы, которые сделаны полностью (когда переданы ) или не имеют никакого эффекта вообще (когда отменены). Неделимое ("атомное") свойство транзакций это "A" в сокращении ACID. См. ACID, commit, rollback, transaction. Атомная инструкция Специальные инструкции, обеспеченные центральным процессором, чтобы гарантировать, что критические низкоуровневые операции не могут быть прерваны. auto-increment Свойство столбца таблицы (определенное ключевым словом AUTO_INCREMENT), которое автоматически добавляет последовательность возрастания значений в столбце. InnoDB поддерживает auto-increment только для столбцов primary key. Это экономит работу разработчика, чтобы не надо было произвести новые уникальные значения, вставляя новые строки. Это обеспечивает полезную информацию для оптимизатора запроса, потому что столбец, как известно, является не нулем и с уникальными значениями. Значения такого столбца могут использоваться в качестве ключей поиска в различных контекстах, и потому что они самозарождены нет никакой причины когда-либо изменить их, по этой причине столбцы первичного ключа часто определяются как auto-increment. Auto-increment могут быть проблематичными с основанной на запросе репликацией, потому что переигрывание запросов на ведомом устройстве не могло бы произвести тот же самый набор значений столбцов, как на ведущем устройстве, из-за проблем синхронизации. Когда у Вас есть auto-increment первичный ключ, Вы можете использовать основанную на запросе репликацию только с установкой innodb_autoinc_lock_mode=1. Если innodb_autoinc_lock_mode=2, что позволяет более высокий параллелизм для операций вставки, используйте основанную на строке репликацию вместо основанной на запросе. innodb_autoinc_lock_mode=0 это предыдущая (традиционная) настройка по умолчанию и не должна использоваться за исключением целей совместимости. См. auto-increment locking, innodb_autoinc_lock_mode , primary key, row-based replication, statement-based replication. Блокировка auto-increment Удобство первичного ключа auto-increment вовлекает некоторые пргоблемы с параллелизмом. В самом простом случае, если одна транзакция вставляет значения в таблицу, любые другие транзакции должны ждать, чтобы сделать их собственные вставки в ту таблицу так, чтобы строки, вставленные первой транзакцией, получили последовательные значения первичного ключа. InnoDB включает оптимизацию и опцию innodb_autoinc_lock_mode, чтобы Вы могли выбрать, как балансировать между предсказуемыми последовательностями значений автоинкремента и максимального параллелизма для операций вставки. См. auto-increment, concurrency, innodb_autoinc_lock_mode . autocommit Установка, которая вызывает передачу после каждого запроса SQL. Этот режим не рекомендуется для того, чтобы работать с InnoDB с транзакциями из нескольких запросов. Это может помочь работе для транзакций только для чтения в InnoDB, где это минимизирует издержки блокировки и производства данных об отмене, особенно в MySQL 5.6.4 и выше. Это также подходяще для работы с MyISAM, где транзакции неприменимы. См. commit, locking, read-only transaction, SQL, transaction, undo. Доступность Способность справиться и в случае необходимости оправиться от отказа на узле, включая отказы MySQL, операционной системы или аппаратных средств и деятельности обслуживания, которая может иначе вызвать время простоя. Часто соединяемая с масштабируемостью, как критические аспекты крупномасштабного развертывания. См. scalability. B B-tree Структура данных дерева, которая популярна для использования в базе данных. Структура сохранена сортированной всегда, включая быстрый поиск для точных совпадений (равняется оператору) и диапазона (например, больше чем, меньше чем и BETWEEN). Этот тип индекса доступен для большинства механизмов хранения, например, InnoDB и MyISAM. Поскольку у узлов B-дерева может быть много дочерних элементов, B-дерево не то же самое, как двоичное дерево, которое ограничено 2 дочерними элементами на узел. Отличается hash index, который доступен только в MEMORY. Механизм хранения MEMORY может также использовать B-дерево, и Вы должны выбрать B-дерево для таблицы MEMORY, если некоторые запросы используют операторы диапазона. Использование термина B-дерево предназначено как ссылка на общий класс индексов. B-древовидные-структуры, используемые механизмами хранения MySQL, могут быть расценены как разновидности из-за изощренности, не существующей в классическом проекте B-дерева. Для соответствующей информации обратитесь к разделу InnoDB Page Structure Fil Header в MySQL Internals Manual. См. hash index. Обратные кавычки Идентификаторы в пределах запроса SQL должны быть заключены в кавычки, используя символ обратной кавычки (`), если они содержат специальные символы или зарезервированные слова. Например, чтобы обратиться к таблице FOO#BAR или столбцу SELECT, Вы определили бы идентификаторы как `FOO#BAR` и `SELECT`. Так как обратные кавычки обеспечивают дополнительный уровень безопасности, они используются в произведенных программой запросах SQL, где имена идентификатора не могли бы быть известны заранее. Много других систем базы данных используют двойные кавычки (") вокруг таких специальных имен. Для мобильности Вы можете включить режим ANSI_QUOTES в MySQL и использовать двойные кавычки вместо обратных, чтобы квалифицировать имена идентификатора. См. SQL. Резервное копирование Процесс копирования некоторых или всех табличных данных и метаданных от экземпляра MySQL для сохранности. Может также обратиться к набору скопированных файлов. Это решающая задача для DBA. В MySQL физические резервные копии выполнены MySQL Enterprise Backup и логические резервные копии командой mysqldump. У этих методов есть различные характеристики с точки зрения размера и представления резервных данных и скорости (особенно скорости работы восстановления). Резервные копии далее классифицированы как горячие, теплые или холодные в зависимости от того, насколько они вмешиваются в нормальную работу базы данных. У горячих резервных копий есть наименьшее количество вмешательства. См. cold backup, hot backup, logical backup, MySQL Enterprise Backup , mysqldump, physical backup, warm backup. Основной столбец Непроизведенный столбец таблицы, на котором базируется произведенный сохраненный столбец или произведенный виртуальный столбец. Другими словами, основной столбец это непроизведенный столбец таблицы, который является частью определения произведенного столбца. См. generated column, generated stored column , generated virtual column. beta Ранняя стадия в жизни программного продукта, когда это доступно только для оценки, как правило, без определенного номера выпуска или числа меньше 1. InnoDB не использует бета обозначение, предпочитая фазу раннего последователя, которая может расширить более, чем несколько доработанных версий, приводя к выпуску GA. См. early adopter, GA. Двоичный журнал Файл, содержащий отчет всех запросов, которые пытаются изменить табличные данные. Эти запросы могут быть переиграны, чтобы осовременить ведомые серверы в репликации или осовременить базу данных после восстановления табличных данных из резервной копии. Двоичное журналирование может быть выключено, хотя Oracle всегда рекомендует включать, если Вы используете репликацию или выполняете резервные копии. Вы можете исследовать содержание журнала или переиграть те запросы при использовании mysqlbinlog. См. раздел 6.4.4. Для полной информации о журнале см. раздел 19.1.6.4. Для MySQL Enterprise Backup имя файла двоичного журнала и текущяя позиция в пределах файла это важные детали. Чтобы сделать запись этой информации для главного сервера, беря резервное копирование в контексте репликации, Вы можете определить опцию --slave-info. До MySQL 5.0 подобная способность была известна как журнал обновления. В MySQL 5.0 и выше двоичный журнал заменяет журнал обновления. См. binlog, MySQL Enterprise Backup , replication. binlog Неофициальное название файла двоичного журнала . Например, Вы могли бы видеть это сокращение, используемое в обсуждениях на форуме или электронных письмах. См. binary log. Расширение запроса Специальный режим полнотекстового поиска, включенного WITH QUERY EXPANSION. Это выполняет поиск дважды, где фраза поиска для второго поиска это оригинальная фраза поиска, связанная с немногими наиболее очень соответствующими документами от первого поиска. Этот метод главным образом применим для коротких фраз поиска, возможно, только отдельное слово. Это может раскрыть соответствия, где точный критерий поиска не происходит в документе. См. full-text search. Узкое место Часть системы, которая ограничена в размере или способности, которая имеет эффект ограничения полной пропускной способности. Например, область памяти могла бы быть меньшей, чем необходимо, доступ к единственному необходимому ресурсу мог бы препятствовать тому, чтобы многие ядра центрального процессора работали одновременно или ожидание дискового ввода/вывода могло бы препятствовать тому, чтобы центральный процессор работал на полную мощность. Удаление узких мест имеет тенденцию улучшать параллелизм. Например, способность иметь много копий буферного пула в InnoDB уменьшает проблемы, когда многократные сеансы читают и пишут одновременно. См. buffer pool, concurrency. Возврат Операция shutdown немедленно вызывает перезапуск. Идеально с относительно коротким периодом разминки так, чтобы работа и пропускная способность быстро возвратились к высокому уровню. См. shutdown. Распределитель Механизм для того, чтобы управлять разного размера страницами в буферном пуле InnoDB. См. buffer pool, page, page size. Буфер Память или дисковая область для временного хранения. Данные буферизованы в памяти так, чтобы это могло быть написано на диск эффективно, несколькими большими операциями ввода/вывода, а не многими маленькими. Данные буферизованы на диске для большей надежности, чтобы это могло быть восстановлено, даже когда катастрофический отказ или другой отказ происходят в худшее время. Основные типы буферов, используемых InnoDB, это буферный пул, буфер doublewrite и буфер изменения. См. buffer pool, change buffer, crash, doublewrite buffer. Буферный пул Область памяти, которая хранит кэшируемые InnoDB данные для таблиц и индексов. Для эффективности большого объема операций чтения буферный пул разделен на страницы, которые могут потенциально содержать много строк. Для эффективности управления кэшем буферный пул осуществлен как связанный список страниц, данные, которые редко используются, удалены из кэша, используя версию алгоритма LRU. На системах с большой памятью Вы можете улучшить параллелизм, деля буферный пул на много экземпляров. Несколько переменных состояния InnoDB, таблиц information_schema и performance_schema помогают контролировать внутренние работы буферного пула. Начиная с MySQL 5.6, Вы можете избежать длинного периода разминки после перезапуска сервера, особенно для случаев с большими буферными пулами, сохраняя состояние буферного пула при завершении работы сервера и восстанавливая буферный пул в то же самое состояние при запуске сервера. См. раздел 16.6.3.8. См. buffer pool instance , LRU, page, warm up. Экземпляр буферного пула Любая из многих областей, на которые буферный пул может быть разделен, управляя параметром конфигурации innodb_buffer_pool_instances. Полный размер памяти, определенный innodb_buffer_pool_size разделен среди всех буферных экземпляров. Как правило, наличие многократных буферных пулов является подходящим для систем, которые выделяют много гигабайт для буферного пула InnoDB. При системной загрузке или поиске больших объемов данных в буферном бассейне от многих параллельных сеансов, наличие многократных буферных пулов уменьшает издержки для эксклюзивного доступа к структурам данных, которые управляют буферным пулом. См. buffer pool. Встроенный Встроенный механизм хранения InnoDB в пределах MySQL это оригинальная форма распределения для механизма хранения. Не путать с InnoDB Plugin. Начиная с MySQL 5.5, InnoDB Plugin слит назад в кодовую базу MySQL как встроенный механизм хранения (известный как InnoDB 1.1). Это различие важно, главным образом, в MySQL 5.1, где особенность или исправление ошибки могли бы относиться к InnoDB Plugin, но не к встроенному InnoDB. См. InnoDB, plugin. Транзакционные правила Отношения и последовательности действий, которые формируют основание программного обеспечения для бизнеса, чтобы выполнять коммерческую компанию. Иногда эти правила диктует закон, другие определены политикой компании. Осторожное планирование гарантирует, что отношения, закодированные и проведенные в жизнь базой данных, и действиями, выполненными через логику приложения, точно отражают реальную политику компании и могут обработать реальные ситуации. Например, служащий, покидающий компанию, мог бы вызвать последовательность действий отдела человеческих ресурсов. Базе данных человеческих ресурсов, возможно, также понадобилась бы гибкость, чтобы представить данные о человеке, который был нанят, но еще не начал работу. Закрытие учетной записи в службе онлайн могло бы привести к данным, удаляемым из базы данных, или данные могли бы быть перемещены или отмечены так, чтобы это могло быть восстановлено, если учетная запись вновь открыта. Компания могла бы установить политику относительно максимумов зарплаты, минимумов и корректировок, в дополнение к основным проверкам, таким как зарплата, не являющаяся отрицательным числом. Розничная база данных не могла бы позволить покупке с тем же самым порядковым номером быть возвращенной не раз, или не могла бы позволить покупки по кредитной карте выше определенного значения в то время, как база данных, используемая, чтобы обнаружить мошенничество, могла бы позволить эти виды вещей. См. relational. C Файл .cfg Метафайл с данными, используемый с InnoDB переносным табличным пространством. Это произведено командой FLUSH TABLES ... FOR EXPORT, которая помещает одну или более таблиц в последовательное состояние, которое может быть скопировано к другому серверу. Файл .cfg скопирован наряду с соответствующим файлом .ibd и используется, чтобы скорректировать внутренние значения файла .ibd, например, space ID, во время ALTER TABLE ... IMPORT TABLESPACE. См. .ibd file, space ID, transportable tablespace . Кэш Общий термин для любой области памяти, которая хранит копии данных для частого или высокоскоростного извлечения. В InnoDB основной вид структуры кэша это буферный пул. См. buffer, buffer pool. Количество элементов Число различных значений в столбце таблицы. Когда запросы обращаются к столбцам, у которых есть связанный индекс, количество элементов каждого столбца влияет на то, какой метод доступа является самым эффективным. Например, для столбца с уникальным ограничением, число различных значений равно числу строк в таблице. Если у таблицы есть миллион строк, но только 10 различных значений для особого столбца, каждое значение происходит (в среднем) 100000 раз. Такой запрос, как SELECT c1 FROM t1 WHERE c1 = 50;, мог бы возвратить 1 строку или огромное число строк, и сервер базы данных мог бы обработать запрос по-другому в зависимости от количества элементов c1. Если у значений в столбце есть очень неравное распределение, количество элементов не могло бы быть хорошим способом определить лучший план запроса. Например, SELECT c1 FROM t1 WHERE c1 = x; мог бы возвратить 1 строку, когда x=50, и миллион строк, когда x=30. В таком случае Вы, возможно, должны были бы использовать индексные подсказки, чтобы провести совет, который метод поиска более эффективен для особого запроса. Количество элементов может также относиться к числу отличных значений, существующих в многих столбцах, как в сводном индексе. См. column, composite index, index, index hint, persistent statistics, random dive, selectivity, unique constraint. Буфер изменения Специальная структура данных, которая делает запись изменений страниц во вторичных индексах. Эти значения могли следовать из SQL-запросов INSERT, UPDATE или DELETE (DML). Набор особенностей, вовлекающих буфер изменения, известен как буферизация изменения, состоящая из буферизации вставки, буферизации удаления и буферизации очистки. Изменения зарегистрированы в буфере изменения, только когда соответствующая страница от вторичного индекса не находится в буферном пуле. Когда соответствующая индексная страница принесена в буферный пул в то время, как связанные изменения находятся все еще в буфере изменения, изменения для той страницы применены в буферном пуле, используя данные от буфера изменения. Периодически работа очистки, которая работает в течение времени, когда система главным образом неактивна, или во время медленного завершения работы, пишет новые индексные страницы на диск. Работа чистки может написать дисковые блоки для серии индексных значений более эффективно, чем если бы каждое значение было немедленно написано на диск. Физически, буфер изменения это часть системного табличного пространства, так что индексные изменения остаются буферизованными через перезапуски базы данных. Изменения применены, только когда страницы принесены в буферный пул из-за некоторой другой работы чтения. Видами и объемом данных, сохраненных в буфере изменения, управляют опции innodb_change_buffering и innodb_change_buffer_max_size. Чтобы видеть информацию о текущих данных в буфере изменения, используйте SHOW ENGINE INNODB STATUS. Прежде известен как буфер вставки. См. buffer pool, change buffering, delete buffering, DML, insert buffer, insert buffering, merge, page, purge, purge buffering, secondary index, system tablespace. Буферизация изменения Общий термин для особенностей, вовлекающих буфер изменения, состоящих из буферизации вставки, буферизации удаления и буферизации очистки. Индексные изменения, следующие из запросов SQL, которые могли обычно вовлекать случайные операции ввода/вывода, задержаны и периодически выполняются фоновым потоком. Эта последовательность операций может написать дисковые блоки для серии индексных значений более эффективно, чем если бы каждое значение было немедленно написано. Управляется опциями innodb_change_buffering и innodb_change_buffer_max_size. См. change buffer, delete buffering, insert buffering, purge buffering. Контрольная точка Поскольку изменения произведены в страницах данных, которые кэшируются в буферном пуле, те изменения написаны в файлы данных когда-то позже, выполняется процесс, известный как сброс. Контрольная точка это отчет последних изменений (представленный значением LSN) которые были успешно записаны в файлы с данными. См. buffer pool, data files, flush, fuzzy checkpointing, LSN. Контрольная сумма В InnoDB механизм проверки допустимости, чтобы обнаружить повреждение, когда страница в табличном пространстве считана с диска в буферный пул InnoDB. Этой особенностью управляет опция innodb_checksums в MySQL 5.5. innodb_checksums устарела в MySQL 5.6.3 и заменена innodb_checksum_algorithm. innochecksum помогает диагностировать проблемы повреждения, проверяя значения контрольной суммы указанного файла табличного пространства в то время, как сервер MySQL закрыт. MySQL также использует контрольные суммы в целях репликации, см. опции binlog_checksum , master_verify_checksum и slave_sql_verify_checksum. См. buffer pool, page, tablespace. Дочерняя таблица В отношениях внешнего ключа дочерняя таблица это та, строки которой относятся к строкам в другой таблице с идентичным значением для определенного столбца. Это таблица, которая содержит FOREIGN KEY ... REFERENCES и опционально ON UPDATE и ON DELETE. Соответствующая строка в родительской таблице должна существовать прежде, чем строка может быть создана в дочерней таблице. Значения в дочерней таблице могут предотвратить операции удаления или обновления на родительской таблице или может вызвать автоматическое удаление или обновления в дочерней таблице, основанной на опции ON CASCADE, создавая внешний ключ. См. foreign key, parent table. Чистая страница Страница в буферном пуле InnoDB, где все изменения, произведенные в памяти, были также написаны в файлы данных. Противоположность грязной страницы. См. buffer pool, data files, dirty page, flush, page. Чистое завершение работы Завершение работы, которое завершается без ошибок и применяет все изменения таблиц InnoDB перед окончанием, в противоположность катастрофическому отказу или быстрому завершению работы . Синоним для медленного завершения работы . См. crash, fast shutdown, shutdown, slow shutdown. Клиент Тип программы, которая посылает запросы в сервер и интерпретирует или обрабатывает результаты. Клиентское программное обеспечение могло бы выполняться только часть времени (например, почта или программа чата) или работать в интерактивном режиме (например, процессор команд mysql). См. mysql, server. Кластеризуемый индекс Термин InnoDB для индекса primary key . InnoDB организован на значениях столбцов первичного ключа, чтобы ускорить запросы и сортировки, вовлекающие столбцы первичного ключа. Для лучшей работы выберите столбцы первичного ключа, основанные на самых критических по отношению к работе запросах. Поскольку изменение столбцов кластеризируемого индекса дорогая работа, выберите основные столбцы, которые редко или никогда не обновляются. В Oracle Database этот тип таблицы известен как index-organized table. См. index, primary key, secondary index. Холодное резервное копирование Резервное копирование в то время, как база данных закрыта. Для занятых приложений и веб-сайтов это не могло бы быть практично, и Вы могли бы предпочесть теплое резервное копирование или горячее резервное копирование . См. backup, hot backup, warm backup. Столбец Элемент данных в строке, хранение которого и семантика определены типом данных. Каждая таблица и индекс в значительной степени определены набором столбцов, которые это содержит. У каждого столбца есть значение количества элементов . Столбец может быть первичным ключом для своей таблицы или частью первичного ключа. Столбец может подвергнуться уникальному ограничению, ограничению NOT NULL или обоим. Значения в различных столбцах, даже через различные таблицы, могут быть соединены отношениями внешнего ключа. В обсуждениях внутренних операций MySQL иногда область используется в качестве синонима. См. cardinality, foreign key, index, NOT NULL constraint, primary key, row, table, unique constraint. Столбец индекса Индекс на единственном столбце. См. composite index, index. Префикс столбца Когда индекс создается со спецификацией длины, такой как CREATE INDEX idx ON t1 (c1(N)), только первые N символов значения столбца сохранены в индексе. Хранение маленького префикса индекса делает индексирование компактным. Хотя создание слишком маленького префикса может препятствовать оптимизации запроса, заставляя строки с различными значениями быть дубликатами. Для столбцов, содержащих двоичные значения или длинные текстовые строки, где сортировка не главное соображение и хранение всего значения в индексе потратило бы впустую пространство, индекс автоматически использует первые N (как правило, 768) символов значения, чтобы сделать поиски и сортировки. См. index. commit Команда SQL, которая заканчивает транзакцию, делая постоянными любые изменения, произведенные транзакцией. Это противоположность rollback, которая отменяет любые изменения, произведенные в транзакции. InnoDB использует оптимистический механизм для передачи, чтобы изменения могли быть написаны файлам с данными прежде, чем передача фактически произойдет. Этот метод делает передачу быстрее, хотя больше работы требуется в случае отмены. По умолчанию MySQL использует autocommit, которая автоматически передает после каждого запроса SQL. См. autocommit, optimistic, rollback, SQL, transaction. Компактный формат строки Формат строки для InnoDB. Это был формат строки по умолчанию от MySQL 5.0.3 до MySQL 5.7.8. В MySQL 8.0 формат строки по умолчанию определен опцией innodb_default_row_format, у которой есть настройка по умолчанию DYNAMIC. Формат строки COMPACT обеспечивает более компактное представление для нулей и столбцов переменной длины, чем REDUNDANT. См. раздел 16.10.4. См. dynamic row format, file format, redundant row format, row format. Композитный индекс Индекс, который включает много столбцов. См. index. Сжатое резервное копирование Особенность сжатия MySQL Enterprise Backup делает сжатую копию каждого табличного пространства, изменяя расширение с .ibd на .ibz. Сжатие резервных данных позволяет Вам держать больше резервных копий под рукой и уменьшает время, чтобы передать резервные копии серверу. Данные несжаты во время работы восстановления. Когда сжатая резервная работа обрабатывает таблицу, которая уже сжата, она пропускает шаг сжатия для той таблицы, потому что сжатие снова привело бы к небольшим или никаким сбережениям пространства. Ряд файлов, произведенных MySQL Enterprise Backup , где каждое табличное пространство сжато. Сжатые файлы переименованы с расширением файла .ibz. Применение сжатия в начале резервного процесса помогает избежать издержек хранения во время процесса сжатия и передавая резервные файлы другому серверу. Процесс применения двоичного журнала занимает больше времени и требует несжатых резервных файлов. См. apply, binary log, compression, hot backup, MySQL Enterprise Backup , tablespace. Сжатый формат строки Формат строки, который включает данным и индексам сжатие для InnoDB. Большие области хранятся отдельно от страницы, которая содержит остальную часть данных о строке, как в динамическом формате строки . Обе индексных страницы и большие области сжаты. См. раздел 16.9. См. раздел 16.10.3. См. compression, dynamic row format, row format. Сжатая таблица Таблица, для которой данные хранятся в сжатой форме. Для InnoDB это таблица, составленная с ROW_FORMAT=COMPRESSED. См. раздел 16.9. См. compressed row format, compression. Сжатие Особенность со всесторонней выгодой от использования меньшего количества дискового пространства, выполнения меньшего количества ввода/вывода и использования меньшей памяти для того, чтобы кэшировать. InnoDB допускает сжатие на уровне страницы и на уровне таблицы. Сжатие страницы InnoDB также упоминается как page прозрачное сжатие страницы. См. раздел 16.9. Другой тип сжатия это сжатая резервная копия в MySQL Enterprise Backup. См. buffer pool, compressed backup, compressed row format, DML, transparent page compression. Отказ сжатия Не ошибка, скорее дорогая работа, которая может произойти, используя сжатие в комбинации с операциями DML. Это происходит, когда обновления сжатой страницы переполняют области на странице, для того, чтобы сделать запись модификаций, страница сжата снова, со всеми изменениями, к которым относятся табличные данные, пересжатые данные не помещаются на оригинальной странице, требуя, чтобы MySQL разделил данные на две новых страницы и сжал каждую отдельно. Чтобы проверить частоту этого условия, запросите таблицу INFORMATION_SCHEMA.INNODB_CMP и проверьте насколько значение столбца COMPRESS_OPS превышает значение столбца COMPRESS_OPS_OK. Идеально отказы сжатия часто не происходят, когда они есть, Вы можете корректировать опции innodb_compression_level, innodb_compression_failure_threshold_pct и innodb_compression_pad_pct_max. См. compression, DML, page. Связанный индекс См. composite index. Параллелизм Способность многократных операций (в терминологии базы данных, транзакций) работать одновременно, не вмешиваясь друг в друга. Параллелизм также связан с работой, потому что идеально защита для многократных одновременных транзакций работает с минимумом работы, используя эффективные механизмы для того, чтобы заблокировать. См. ACID, locking, transaction. Конфигурационный файл Файл, который хранит значения опций, используемых MySQL при запуске. Традиционно, в Linux и Unix этот файл называют my.cnf, а в Windows my.ini. Вы можете установить много опций, связанных с InnoDB, в разделе [mysqld]. См. раздел 5.2.6. Когда Вы используете MySQL Enterprise Backup, Вы как правило используете два конфигурационных файла: тот, который определяет, куда данные прибывают и как это структурировано (который мог быть оригинальным конфигурационным файлом для Вашего сервера), и упрощенный, содержащий только маленький набор опций, которые определяют, куда резервные данные идут и как это структурировано. Конфигурационные файлы, используемые с MySQL Enterprise Backup, должны содержать определенные опции, которые как правило упускаются из регулярных конфигурационных файлов, таким образом, Вы, возможно, должны были бы добавить опции к своему существующему конфигурационному файлу для использования с MySQL Enterprise Backup. См. my.cnf, MySQL Enterprise Backup , option, option file. Последовательное чтение Работа чтения, которая использует информацию снимка, чтобы представить результаты запроса, основанные на моменте времени, независимо от изменений, выполненных другими транзакциями, работающими в то же самое время. Если запрашиваемые данные были изменены другой транзакцией, оригинальные данные восстановлены, основываясь на содержании журнала отмены. Этот метод избегает некоторых из проблем блокировки, которые могут уменьшить параллелизм, вынуждая транзакции ждать завершения других транзакций. С уровнем изоляции REPEATABLE READ снимок основан на времени, когда первая работа чтения выполнена. С уровнем изоляции READ COMMITTED снимок сброшен ко времени каждой последовательной работы чтения. Последовательное чтение это режим по умолчанию, в котором InnoDB обрабатывает SELECT в уровне изоляции READ COMMITTED и REPEATABLE READ. Поскольку последовательное чтение не устанавливает никаких блокировок на таблицы, к которым оно получает доступ, другие сеансы свободны изменить те таблицы в то время, как последовательное чтение выполняется на таблице. См. раздел 16.5.2.3. См. concurrency, isolation level, locking, READ COMMITTED, REPEATABLE READ, snapshot, transaction, undo log. Ограничение Автоматический тест, который может заблокировать изменения базы данных, чтобы препятствовать тому, чтобы данные стали непоследовательными. В терминах информатики, своего рода утверждение, связанное с инвариантным условием. Ограничения это решающий компонент ACID , чтобы поддержать последовательность данных. Ограничения, поддержанные MySQL, включают ограничения FOREIGN KEY и уникальные ограничения. См. ACID, foreign key, unique constraint. Счетчик Значение, которое постепенно увеличено действием InnoDB. Полезен для измерения, насколько занят сервер, исследуя источники исполнительных проблем и проверяя изменения (например, настройки конфигурации или индекс, используемый запросами) имеют желаемые низкоуровневые эффекты. Различные виды счетчиков доступны через таблицы Performance Schema и INFORMATION_SCHEMA, особенно INFORMATION_SCHEMA.INNODB_METRICS. См. INFORMATION_SCHEMA, metrics counter, Performance Schema. Покрывающий индекс Индекс, который включает все столбцы, полученные запросом. Вместо того, чтобы использовать индексные значения в качестве указателей, чтобы найти полные строки таблицы, запрос возвращает значения из индексной структуры, сохраняя дисковый ввод/вывод. InnoDB может применить этот метод оптимизации к большему индексу, чем MyISAM, потому что вторичные индексы InnoDB также включают столбцы первичного ключа. InnoDB не может применить этот метод для запросов для таблиц, измененных транзакцией, пока та транзакция не заканчивается. Любой столбец индекса или сводный индекс может действовать как покрывающий индекс, учитывая правильный запрос. См. column index, composite index, index, primary key, secondary index. CPU-bound Тип нагрузки, где основное узкое место это операции центрального процессора с памятью. Как правило, вовлекает интенсивные действия чтения, где все результаты могут кэшироваться в буферном пуле . См. bottleneck, buffer pool, workload. Катастрофический отказ MySQL использует термин "катастрофический отказ", чтобы обратиться вообще к любой неожиданной ситуации завершения работы, где сервер не может сделать своей нормальной уборки. Например, катастрофический отказ мог произойти из-за ошибки аппаратных средств на машине сервера базы данных или устройстве хранения данных, перебоя в питании, потенциального несоответствия данных, которое заставляет сервер MySQL останавливаться, быстрого завершения работы , начатого DBA, или многих других причин. Автоматическое восстановление катастрофического отказа для таблиц InnoDB гарантирует, что данные сделаны последовательными, когда сервер перезапущен, без любой дополнительной работы DBA. См. crash recovery, fast shutdown, InnoDB, shutdown. Восстановление катастрофического отказа Действия уборки, которые происходят, когда MySQL запущен снова после катастрофического отказа. Для таблиц InnoDB изменения от неполных транзакций переигрываются, используя данные журнала redo. Изменения, которые были переданы перед катастрофическим отказом, но еще не написаны в файлы с данными , восстановлены от буфера doublewrite . Когда база данных обычно закрывается, этот тип деятельности выполнен во время завершения работы чистки. Во время нормального функционирования переданные данные могут храниться в буфере изменения прежде, чем быть написанными в файлы с данными. Всегда есть проблема между хранением современных файлов с данными, что вводит издежрки во время нормального функционирования, и буферизации данных, которые могут сделать завершение работы и восстановление занимающими больше времени. См. change buffer, commit, crash, data files, doublewrite buffer, InnoDB, purge, redo log. CRUD Сокращение от "create, read, update, delete", общая последовательность операций в приложениях базы данных. Часто обозначает класс приложений с относительно простым использованием базы данных (основной DDL, DML и запросы SQL), который может быть осуществлен быстро на любом языке. См. DDL, DML, query, SQL. Курсор Внутренняя структура данных, которая используется, чтобы представить набор результатов запроса или другую работу, которая выполняет поиск, используя параметр SQL WHERE. Это работает как итератор на других высокоуровневых языках, производя каждое значение из набора результатов согласно запросу. Хотя SQL обычно обрабатывает обработку курсоров для Вас, Вы могли бы копаться во внутренних работах, имея дело с критическим по отношению к работе кодом. См. query. D Язык определения данных См. DDL. Словарь данных Метаданные, которые отслеживают объекты базы данных, такие как таблицы, индексы и столбцы. Для словаря данных MySQL, введенного в MySQL 8.0, метаданные физически расположены в файлах табличного пространства InnoDB file-per-table в каталоге базы данных mysql. Для словаря данных InnoDB метаданные физически расположены в системном табличном пространстве InnoDB. Поскольку MySQL Enterprise Backup всегда поддерживает системное табличное пространство InnoDB, все резервные копии включают содержание словаря данных InnoDB. См. column, file-per-table, .frm file, index, MySQL Enterprise Backup , system tablespace, table. Каталог данных Каталог, в соответствии с которым каждый экземпляр MySQL сохраняет файлы с данными для InnoDB и каталоги, представляющие отдельные базы данных. Управляется опцией datadir. См. data files, instance. Файлы с данными Файлы, которые физически содержат данные таблицы и индекса. Системное табличное пространство InnoDB, которое содержит словарь данных и способно хранить данные для многих таблиц InnoDB, представлено одним или больше файлами .ibdata. Табличные пространства File-per-table, которые содержат данные для одной таблицы InnoDB, представлены файлом .ibd. Общие табличные пространства (введенные в MySQL 5.7.6), которые могут содержать данные для многих таблиц InnoDB, также представлены файлом .ibd. См. data dictionary, file-per-table, general tablespace, .ibd file, ibdata file, index, system tablespace, table, tablespace. Язык манипуляции данных См. DML. Хранилище данных Система базы данных или приложение, которое прежде всего выполняет большие запросы. Данные только для чтения или для чтения главным образом могли бы быть организованы в форме denormalized для эффективности запроса. Может извлечь выгоду из оптимизации для транзакций только для чтения в MySQL 5.6 или выше. См. denormalized, OLTP, query, read-only transaction . База данных В пределах каталога данных MySQL каждая база данных представлена отдельным каталогом. Системное табличное пространство, которое может содержать табличные данные многих баз данных в пределах экземпляра MySQL, сохранено в файлах с данными, которые находятся за пределами отдельных каталогов базы данных. Когда режим file-per-table включен, файлы .ibd, представляющие таблицы InnoDB, хранятся в каталогах базы данных если не создаются в другом месте использованием DATA DIRECTORY. Общие табличные пространства, введенные в MySQL 5.7.6, также содержат табличные данные в файлах .ibd. В отличие от file-per-table файлов .ibd, файлы .ibd общего табличного пространства могут содержать табличные данные многих баз данных в пределах экземпляра MySQL и быть назначены на каталоги относительно или независимо от каталога данных MySQL. Для давних пользователей MySQL база данных знакомое понятие. Пользователи, происходящие из среды базы данных Oracle Database, найдут, что значение базы данных MySQL ближе к тому, что Oracle Database называет schema. См. data files, file-per-table, .ibd file, instance, schema, system tablespace. DCL Язык управления данных, ряд запросов SQL для руководящих привилегий. В MySQL состоит из GRANT и REVOKE. См. DDL, DML, SQL. DDL Язык определения данных, ряд запросов SQL для того, чтобы управлять базой данных непосредственно, а не отдельными строками таблицы. Включает все формы CREATE, ALTER и DROP. Также включает TRUNCATE, потому что это работает по-другому, чем DELETE FROM table_name даже при том, что окончательный эффект подобен. DDL автоматически передает текущую транзакцию, запрос нельзя отменить. InnoDB online DDL улучшает работу для CREATE INDEX , DROP INDEX и многих типов ALTER TABLE, см. раздел 16.12. Кроме того, InnoDB file-per-table может затронуть поведение DROP TABLE и TRUNCATE TABLE . См. commit, DCL, DML, file-per-table, rollback, SQL, transaction. Тупик Ситуация, где различные транзакции неспособны продолжиться, потому что каждая держит блокировку , нужную другой. Поскольку обе транзакции ждут ресурса, ни одна никогда не будет выпускать блокировки, которые это держит. Тупик может произойти, когда транзакции блокируют строки в многократных таблицах (через запрос вроде UPDATE или SELECT ... FOR UPDATE), но в противоположном порядке. Тупик может также произойти, когда такие запросы блокируют диапазоны индексных записей и промежутки, с каждой транзакцией, приобретающей некоторые блокировки, но не другие из-за проблемы синхронизации. Для вводной информации о том, как тупики автоматически обнаружены и обработаны см. раздел 16.5.5.2 . Для подсказок относительно ухода от тупика и восстановления от условий тупика см. раздел 16.5.5.3 . См. gap, lock, transaction. Обнаружение тупиков Механизм, который автоматически обнаруживает, когда тупик происходит, и автоматически отменяет одну из вовлеченных транзакций (жертву). Обнаружение тупика может быть отключено, используя innodb_deadlock_detect. См. deadlock, rollback, transaction, victim. delete Когда InnoDB выполняет запрос DELETE, строки были немедленно отмечены для удаления и больше не возвращены запросами. Хранение исправлено когда-то позже, во время периодической уборки мусора, известной как очистка. Для того, чтобы удалить большие количества данных, связанные операции с их собственными техническими характеристиками являются TRUNCATE и DROP. См. drop, purge, truncate. Буфер удаления Метод хранения изменений вторичных индексных страниц по результатам DELETE в буфере изменения вместо того, чтобы немедленно писать изменения, чтобы физические записи могли быть выполнены, чтобы минимизировать случайный ввод/вывод. Поскольку операции удаления это двухступенчатый процесс, эта работа буферизует записи, которые обычно отмечают индексную запись для удаления. Это один из типов буферизации изменения, другие это буферизация insert и буферизация очистки. См. change buffer, change buffering, insert buffer, insert buffering, purge buffering. denormalized Стратегия хранения данных, которая дублирует данные через различные таблицы, вместо того, чтобы соединить таблицы с запросами внешними ключами join. Как правило, используется в приложениях хранилища данных, где данные не обновлены после загрузки. В таких приложениях работа запроса более важна, чем поддержка последовательных данных во время обновлений. См. data warehouse, foreign key, join, normalized. Убывание индекса Тип индекса доступный с некоторыми системами базы данных, где хранение оптимизировано, чтобы обработать ORDER BY column DESC. В настоящее время, хотя MySQL позволяет ключевое слово DESC в CREATE TABLE, это не использует специального расположения хранения для получающегося индекса. См. index. Кэш объекта словаря Кэш объекта словаря хранит объекты словаря данных , к которым ранее получали доступ, в памяти, чтобы позволить повторное использование объекта и минимизировать дисковый ввод/вывод. LRU-стратегия используется, чтобы вычеркнуть последние использованные объекты из памяти. Кэш состоит из нескольких разделов, которое хранят различные типы объектов. См. раздел 15.4. См. data dictionary, LRU. Грязная страница Страница в буферном пуле InnoDB которая была обновлена в памяти, но изменения еще не написаны в файлы данных. См. buffer pool, clean page, data files, flush, page. Грязное чтение Работа, которая получает ненадежные данные, которые были обновлены другой транзакцией, но еще не переданы. Это возможно только с уровнем изоляции, известным как read uncommitted. Этот вид работы не придерживается ACID. Это считают очень опасным, потому что данные могли быть отменены или обновлены далее прежде, чем быть переданными, тогда транзакция, делающая грязное чтение, использовала бы данные, которые никогда не подтверждались как точные. См. ACID, commit, consistent read, isolation level, READ UNCOMMITTED, rollback. disk-based Своего рода база данных, которая прежде всего организует данные по дисковому хранению (жесткие диски или эквивалент). Данные переданы между диском и памятью, которая будет управляться на. Это противоположность in-memory database. Хотя InnoDB основано на диске, это также содержит такие особенности, как буферный пул, многократные буферные пулы и адаптивный хеш-индекс, которые позволяют определенным видам рабочих нагрузок работать прежде всего в памяти. См. adaptive hash index , buffer pool, in-memory database. disk-bound Тип нагрузки, где основное узкое место это дисковый ввод/вывод. Также известный как I/O-bound. Как правило, вовлекает частые записи на диск или случайные чтения большого количества данных, чем может вписаться в буферный пул. См. bottleneck, buffer pool, workload. DML Язык манипуляции данными, ряд запросов SQL для того, чтобы выполнить операторы INSERT, UPDATE и DELETE. SELECT иногда рассматривают как запрос DML, потому что форма SELECT ... FOR UPDATE подвергается тем же самым соображениям для того, чтобы заблокировать, как INSERT, UPDATE и DELETE. Запросы DML для таблицы InnoDB работают в контексте транзакций, таким образом, их эффекты могут быть переданы или отменены как единственный модуль. См. commit, DCL, DDL, locking, rollback, SQL, transaction. document id В полнотекстовом поиске InnoDB специальный столбец в таблице, содержащей индекс FULLTEXT, чтобы уникально идентифицировать документ, связанный с каждым значением ilist. Его имя FTS_DOC_ID (верхний регистр обязателен!). Сам столбец должен иметь тип BIGINT UNSIGNED NOT NULL с уникальным индексом FTS_DOC_ID_INDEX. Предпочтительно, Вы определяете этот столбец, составляя таблицу. Если InnoDB должен добавить столбец к таблице, создавая индекс FULLTEXT, работа индексации значительно более дорога. См. full-text search, FULLTEXT index, ilist. Буфер doublewrite InnoDB использует метод потока файла, названный doublewrite. Перед записью страниц в файлы данных InnoDB сначала пишет их в непрерывную область, названную буфером doublewrite. Только после того, как запись и сброс к буферу doublewrite завершились, InnoDB пишет страницы к их надлежащим позициям в файле с данными. Если есть катастрофический отказ операционной системы, подсистемы хранения или процесса mysqld в середине записи страницы, InnoDB может позже найти хорошую копию страницы из буфера doublewrite во время восстановления катастрофического отказа. Хотя данные всегда пишутся дважды, буфер doublewrite не требует вдвое большего количества ввода/вывода. Данные написаны в буфер непосредственно как большой последовательный кусок одним вызовом fsync(). Чтобы выключить буфер doublewrite, определите опцию innodb_doublewrite=0 . См. crash recovery, data files, page, purge. drop Своего рода работа DDL, которая удаляет объект схемы через такой запрос, как DROP TABLE или DROP INDEX. Это отображается внутренне на ALTER TABLE . Для InnoDB исполнительное рассмотрение таких операций вовлекает время, когда словарь данных заблокирован, чтобы гарантировать, что взаимосвязанные объекты все обновлены, и время, чтобы обновить структуры памяти, такие как буферный пул. Для таблицы у задачи drop есть несколько иные характеристики, чем у truncate (TRUNCATE TABLE). См. buffer pool, data dictionary, DDL, table, truncate. Динамический формат строки Формат строки InnoDB. Поскольку длинные значения столбцов переменной длины сохранены за пределами страницы, которая содержит данные о строке, это очень эффективно для строк, которые включают большие объекты. Так как к большим областям, как правило, не получают доступ, чтобы оценить условия запроса, они не принесены в буферный пул , приводя к меньшему количеству операций ввода/вывода и лучшему использованию кэш-памяти. С MySQL 5.7.9 формат строки по умолчанию определен опцией innodb_default_row_format, у которой есть значение по умолчанию DYNAMIC. См. раздел 16.10.3. См. buffer pool, file format, row format. E early adopter Этап, подобный бете, когда программный продукт оценивается для работы, функциональности и совместимости в установке. См. beta. Журнал ошибок Тип журнала о запуске MySQL и критических ошибках во время выполнения и информации о катастрофическом отказе. Для деталей см. раздел 6.4.2. См. crash, log. Вычеркивание Процесс удаления элемента из кэша или другой временной области хранения, такой как буферный пул. Часто, но не всегда, использует алгоритм LRU, чтобы определить, который элемент удалить. Когда грязная страница вычеркнута, ее содержание сброшено на диск, и любые грязные соседние страницы могли бы сброситься также. См. buffer pool, dirty page, flush, LRU, neighbor page. Исключительная блокировка Своего рода блокировка, которая препятствует тому, чтобы любая другая транзакция блокировала ту же самую строку. В зависимости от операционного уровня изоляции этот вид блокировки мог бы заблокировать другие транзакции на запись той же самой строки или заблокировать другие транзакции от чтения той же самой строки. Значение по умолчанию уровень изоляции InnoDB REPEATABLE READ включает более высокий параллелизм, позволяя транзакции считать строки, у которых есть исключительные блокировки, метод, известный как последовательное чтение. См. concurrency, consistent read, isolation level, lock, REPEATABLE READ, shared lock, transaction. Экстент Группа страниц в пределах табличного пространства. Для размера страницы по умолчанию в 16 КБ экстент содержит 64 страницы. В MySQL 5.6 размер страницы для InnoDB может составить 4 КБ, 8 КБ, или 16 КБ, этим управляет опция innodb_page_size . Для размеров страниц 4KB, 8KB и 16KB размер экстента всегда 1 МБ (или 1048576 байтов). Поддержка размеров страниц 32 КБ и 64 КБ была добавлена в MySQL 5.7.6. Для размера страницы 32 КБ размер экстента составляет 2 МБ. Для размера страницы 64 КБ размер экстента составляет 4 МБ. Такие особенности InnoDB, как сегменты, запросы чтения вперед и буферные операции ввода/вывода с использованием буфера doublewrite, которые читают, пишут, выделяют или освобождают данные, применяют экстент за раз. См. doublewrite buffer, page, page size, read-ahead, segment, tablespace. F Файл .frm Файл, содержащий метаданные, такие как табличное определение, таблицы MySQL. Файлы .frm были удалены в MySQL 8.0, но все еще используются в более ранних выпусках MySQL. В MySQL 8.0 данные, ранее хранившиеся в файлах .frm, хранятся в таблицах словаря данных. См. data dictionary, MySQL Enterprise Backup , system tablespace. Fast Index Creation Способность сначала появилась в InnoDB Plugin, теперь это часть MySQL 5.5 и выше, которая ускоряет создание вторичных индексов InnoDB избегая потребности полностью переписать связанную таблицу. Ускорение относится также к удалению вторичного индекса. Поскольку обслуживание индекса может добавить работу ко многим операциям передачи данных, выполнение таких операций, как ALTER TABLE ... ENGINE=INNODB или INSERT INTO ... SELECT * FROM ... без вторичного индекса существенно ускоряет процесс. В MySQL 5.6 эта особенность становится более общей. Вы можете читать и писать таблицы в то время, как индексирование создается, и делать еще много видов ALTER TABLE, не копируя таблицу, не блокируя операции DML или то и другое. Таким образом в MySQL 5.6 и выше, этот набор особенностей упоминается как online DDL вместо Fast Index Creation. См. InnoDB Fast Index Creation и раздел 16.12. См. DML, index, online DDL, secondary index. Быстрое завершение работы Процедура завершения работы по умолчанию для InnoDB основана на установке опции innodb_fast_shutdown=1 . Чтобы сэкономить время, определенные операции сброса пропущены. Этот тип завершения работы безопасен во время нормального использования, потому что операции сброса выполнены во время следующего запуска, используя тот же самый механизм в качестве восстановлении катастрофического отказа . В случаях, где база данных закрывается для обновления, сделайте медленное завершение работы вместо этого, чтобы гарантировать, что все соответствующие изменения применены к файлам с данными во время завершения работы. См. crash recovery, data files, flush, shutdown, slow shutdown. Формат файла Формат, используемый InnoDB для каждой таблицы, как правило, с установкой file-per-table включенной так, чтобы каждая таблица была сохранена в отдельном файле .ibd. См. file-per-table, .ibd file, ibdata file, row format. file-per-table Общее название установки, которой управляет опция innodb_file_per_table , которая является важным параметром конфигурации, который затрагивает аспекты хранения файла, доступность особенностей и характеристики ввода/вывода. С MySQL MySQL 5.6.7 innodb_file_per_table включена по умолчанию. При включении innodb_file_per_table Вы можете составить таблицу в ее собственном файле .ibd вместо совместно используемых файлов ibdata системного табличного пространства. Когда табличные данные хранятся в отдельном файле .ibd, у Вас есть больше гибкости, чтобы выбрать форматы строки, требуемые для таких особенностей, как сжатие. TRUNCATE TABLE также быстрее, и пустое пространство, может использоваться операционной системой вместо того, чтобы остаться сохраненным для InnoDB. MySQL Enterprise Backup более гибок для таблиц, которые находятся в их собственных файлах. Например, таблицы могут быть исключены из резервного копирования, но только если они находятся в отдельных файлах. Таким образом, эта установка является подходящей для таблиц, которые поддерживаются менее часто или в различном графике. См. compressed row format, compression, file format, .ibd file, ibdata file, innodb_file_per_table, MySQL Enterprise Backup , row format, system tablespace. Коэффициент заполнения В индексе InnoDB пропорция страницы, которая заполнена данными прежде, чем страница будет разделена. Неиспользуемое место, когда индексные данные разделены между страницами, учитывает строки, которые будут обновлены с более длинными строковыми значениями, не требуя дорогого обслуживания индекса. Если коэффициент заполнения слишком низок, индексирование занимает больше места, чем необходимо, вызывая дополнительный ввод/вывод, читая индексирование. Если коэффициент заполнения слишком высок, любое обновление, которое увеличивает длину значений столбцов, может вызвать дополнительный ввод/вывод для обслуживания индекса, см. раздел 16.8.10. См. index, page. Фиксированный формат строки Этот формат строки используется MyISAM, а не InnoDB. Если Вы создаете InnoDB с опцией ROW_FORMAT=FIXED в MySQL 5.7.6 или раньше, InnoDB использует компактный формат строки, вместо этого, хотя значение FIXED все еще может быть в выводе SHOW TABLE STATUS. С MySQL 5.7.7 InnoDB возвращает ошибку, если определен ROW_FORMAT=FIXED. См. compact row format, row format. Сброс Запись изменения файлов базы данных, которые были буферизованы в области памяти или временной дисковой области хранения. Структуры хранения InnoDB, которые периодически сбрасываются, включают журнал redo, журнал отмены и буферный пул. Сброс может произойти, потому что область памяти становится полной и система должна освободить некоторое пространство, потому что передача означает, что изменения от транзакции могут быть завершены, или потому что медленное завершение работы означает, что вся невыполненная работа должна быть завершена. Когда не важно сбросить все буферизованные данные сразу, InnoDB может использовать метод, названный нечеткой установкой контрольных точек, чтобы сбросить маленькие пакеты страниц. См. buffer pool, commit, fuzzy checkpointing, redo log, slow shutdown, undo log. Список сброса Внутренняя структура данных InnoDB, которая отслеживает грязные страницы в буферном пуле : то есть, страницы, которые были изменены и должны быть записаны на диск. Эта структура данных часто обновляется внутренними минитранзакциями и защищена собственным mutex, чтобы позволить параллельный доступ к буферному пулу. См. buffer pool, dirty page, LRU, mini-transaction, mutex, page, page cleaner. Внешний ключ Тип отношений указателя, между строками в отдельных таблицах InnoDB. Отношения внешнего ключа определены на одном столбце в родительской таблице и в дочерней таблице. В дополнение к включению быстрого поиска соответствующей информации, внешние ключи помогают провести в жизнь ссылочную целостность , препятствуя любому из этих указателей стать недопустимым, когда данные вставлены, обновлены и удалены. Этот механизм осуществления тип ограничения. Строка, которая указывает на другую таблицу, не может быть вставлена, если связанное значение внешнего ключа не существует в другой таблице. Если строка удалена, или ее значение внешнего ключа изменилось, и строки в другой таблице указывают на то значение внешнего ключа, внешний ключ может быть настроен, чтобы предотвратить удаление, заставить соответствующие значения столбцов в другой таблице становиться null или автоматически удалять соответствующие строки в другой таблице. Один из этапов в разработке нормализованной базы данных должен идентифицировать данные, которые дублированы, выделить те данные в новую таблицу и настроить отношения внешнего ключа так, чтобы многократные таблицы могли быть запрошены как единственная таблица, используя работу соединения. См. child table, FOREIGN KEY constraint, join, normalized, NULL, parent table, referential integrity, relational. Ограничение FOREIGN KEY Тип ограничения, которое поддерживает последовательность базы данных через отношения внешнего ключа . Как другие виды ограничений, это может препятствовать тому, чтобы данные были вставлены или обновлены, если данные стали бы непоследовательными, в этом случае предотвращается несогласованность между данными в многократных таблицах. Альтернативно, когда работа DML выполнена, ограничения FOREIGN KEY могут удалить данные в дочерних строках , изменить на различные значения или установить в null, исходя из опции ON CASCADE, которая была определена, создавая внешний ключ. См. child table, constraint, DML, foreign key, NULL. FTS В большинстве контекстов сокращение от full-text search. Иногда в исполнительных обсуждениях сокращение для full table scan. См. full table scan, full-text search. Полное резервное копирование Резервное копирование, которое включает все таблицы в каждой базе данных MySQL и все базы данных в экземпляре MySQL. См. backup, database, instance, partial backup, table. Полное сканирование таблицы Работа, которая требует чтения всего содержания таблицы, а не только выбранных частей, используя индекс. Как правило, выполняется с маленькими таблицами поиска или в ситуациях со складированием данных в больших таблицах, где все доступные данные соединены и проанализированы. Как часто эти операции происходят и размеры таблиц относительно доступной памяти, имеет значение для алгоритмов, используемых в оптимизации запроса и управлении буферным пулом . Цель индексов это позволить поиски для определенных значений или диапазонов значений в пределах большой таблицы, таким образом избегая полного сканирования таблицы. См. buffer pool, index. Полнотекстовый поиск Возможность для того, чтобы найти слова, фразы, булевы комбинации слов и так далее в пределах табличных данных более быстрым, удобным и гибким способом, чем использование SQL LIKE. Это использует функцию SQL MATCH() и индексы FULLTEXT. См. FULLTEXT index. Индекс FULLTEXT Спецвид индекса, который хранит поисковый индекс в механизме полнотекстового поиска MySQL. Представляет слова от значений столбца, опуская любые, которые определены как стоп-слова. Первоначально доступен только для MyISAM. Начиная с MySQL 5.6.4, это также доступно для таблиц InnoDB. См. full-text search, index, InnoDB, search index, stopword. Нечеткая установка контрольных точек Метод, который сбрасывает маленькие пакеты грязных страниц из буферного пула, вместо того, чтобы сбросить все грязные страницы сразу, что разрушило бы обработку базы данных. См. buffer pool, dirty page, flush. G GA "Generally available", этап, когда программный продукт оставляет статус beta и доступен для продажи, официальной поддержки и производственного использования. См. beta. Промежуток Место в структуре данных индекса, где новые значения могли быть вставлены. Когда Вы блокируете ряд строк таким запросом, как SELECT ... FOR UPDATE, InnoDB может создать блокировки, которые относятся к промежуткам так же, как к фактическим значениям в индексировании. Например, если Вы выбираете все значения, больше 10 для обновления, блокировка промежутка препятствует тому, чтобы другая транзакция вставила новое значение, которое больше 10. Запись supremum и запись infimum представляют промежутки, содержащие все значения, больше или меньше, чем все текущие значения индекса. См. concurrency, gap lock, index, infimum record, isolation level, supremum record. Блокировка промежутка Блокировка на промежутке между индексными записями или блокировка на промежутке перед первой или после последней записи. Например, SELECT c1 FOR UPDATE FROM t WHERE c1 BETWEEN 10 and 20; препятствует тому, чтобы другие транзакции вставили значение 15 в столбец t.c1, неважно, было ли уже какое-либо такое значение в столбце, потому что промежутки между всеми существующими значениями в диапазоне заблокированы. Блокировки промежутка используются в некоторых операционных уровнях изоляции. См. gap, infimum record, lock, next-key lock, record lock, supremum record. Общий журнал См. Общий журнал запросов. Общий журнал запросов Тип журнала, используемого для диагностики и поиска неисправностей запросов SQL, обработан сервером MySQL. Может быть сохранен в файле или в таблице базы данных. Вы должны активировать это через опцию general_log. Вы можете отключить это для определенного соединения через опцию sql_log_off. Делает запись более широкого диапазона запросов, чем медленный журнал запроса. В отличие от двоичного журнала, который используется для репликации, общий журнал запроса содержит запросы SELECT и не поддерживает строгое упорядочивание. Для получения дополнительной информации см. раздел 6.4.3. См. binary log, log, slow query log. Общее табличное пространство Совместно используемое InnoDB табличное пространство, созданное CREATE TABLESPACE. Общие табличные пространства могут быть созданы за пределами каталога данных MySQL, способны к хранению многих таблиц и поддерживают таблицы всех форматов строки. Общие табличные пространства были введены в MySQL 5.7.6. Таблицы добавлены к общему табличному пространству через CREATE TABLE tbl_name ... TABLESPACE [=] tablespace_name или ALTER TABLE tbl_name TABLESPACE [=] tablespace_name. См. раздел 16.7.9. См. file-per-table, system tablespace, table, tablespace. Произведенный столбец Столбец, значения которого вычислены от выражения, включенного в определение столбца. Произведенный столбец может быть виртуальным или сохраненным. См. base column, generated stored column , generated virtual column. Произведенный сохраненный столбец Столбец, значения которого вычислены от выражения, включенного в определение столбца. Значения столбцов оценены и сохранены, когда строки вставлены или обновлены. Сохраненный столбец требует места для хранения и может быть индексирован. См. base column, generated column, generated virtual column . Произведенный виртуальный столбец Столбец, значения которого вычислены от выражения, включенного в определение столбца. Значения столбцов не сохранены, но оценены, когда строки считаны, немедленно после любого триггера BEFORE. Виртуальный столбец не занимает места. InnoDB допускает вторичные индексы на произведенных виртуальных столбцах. См. base column, generated column, generated stored column . Глобальная транзакция Тип транзакции, вовлеченной в операции XA. Это состоит из нескольких действий, которые являются транзакционными, но все должны завершиться успешно как группа, или все быть отменены. В основном, это расширяет свойства ACID так, чтобы многократные транзакции ACID могли быть выполнены как компоненты глобальной работы, у которой также есть свойства ACID. См. ACID, transaction, XA. Групповая передача В оптимизации InnoDB, которая выполняет некоторые низкоуровневые операции ввода/вывода однажды для ряда передач вместо того, чтобы синхронизировать отдельно для каждой. Когда двоичный журнал включен, Вы, как правило, также устанавливаете параметр конфигурации sync_binlog=0, потому что групповая передача для двоичного журнала, поддержана только, если это установлено в 0. См. binary log, commit. H Хэш-индекс Тип индекса предназначенный для запросов, которые используют операторы равенства вместо таких операторов, как больше чем или BETWEEN. Это доступно для таблиц MEMORY. Хотя хеш-индекс это индекс по умолчанию для MEMORY по историческим причинам, этот механизм хранения также поддерживает индексы B-tree, которые часто являются лучшим выбором для запросов общего назначения. MySQL включает разновидность этого индекса адаптивный хеш-индекс, который создан автоматически для InnoDB , если нужно во время выполнения. См. adaptive hash index , B-tree, index, InnoDB. HDD Сокращение для "hard disk drive". Относится к жестким дискам обычно сравниваясь и контрастируя с SSD. Его технические характеристики могут влиять на пропускную способность. См. disk-based, SSD. Биение Периодическое сообщение, которое посылают, чтобы указать, что система функционирует должным образом. В контексте репликации, если ведущее устройство прекращает посылать такие сообщения, одно из ведомых устройств может занять его место. Подобные методы могут использоваться между серверами в окружающей среде кластера, чтобы подтвердить, что все они действуют должным образом. См. master server, replication. Верхняя метка Значение, представляющее верхний предел или жесткий предел, который не должен быть превышен во время выполнения, или максимальное значение, которое было фактически достигнуто. См. low-water mark. Список истории Список транзакций с записями, отмеченными как удаленные, для работы InnoDB очистки. Зарегистрирован в журнале отмены. О длине списка истории сообщает команда SHOW ENGINE INNODB STATUS. Если список истории становится более длинным, чем значение innodb_max_purge_lag , каждый запрос DML отсрочен немного, чтобы позволить работе чистки заканчивать сброс удаленных записей. Также известно как задержка чистки. См. DML, flush, purge, purge lag, rollback segment, transaction, undo log. hole punching Выпуск пустых блоков страницы. InnoDB прозрачное сжатие страницы полагается на поддержку hole punching. См. раздел 16.9.2. См. sparse file, transparent page compression. Горячий Условие, где к строке, таблице или внутренней структуре данных получают доступ так часто, требуя некоторой формы блокировки или взаимного исключения, что это приводит к проблеме масштабируемости или работы. Хотя "горячий" как правило указывает на нежелательное условие, горячее резервное копирование это привилегированный тип резервного копирования. См. hot backup. Горячее резервное копирование Резервное копирование в то время, как база данных работает, и приложения читают и пишут ее. Резервное копирование вовлекает больше, чем простое копирование файлов с данными: это должно включать любые данные, которые были вставлены или обновлены, в то время как резервное копирование было в процессе, это должно исключить любые данные, которые были удалены, в то время как резервное копирование было в процессе, и это должно проигнорировать любые изменения, которые не были переданы. Продукт Oracle, который выполняет горячие резервные копии, ориентирован на InnoDB, но также и на таблицы MyISAM и другие механизмы хранения. Это MySQL Enterprise Backup . Горячий резервный процесс состоит из двух этапов. Копирование файлов с данными производит сырое резервное копирование . Шаг применения включает любые изменения базы данных, которые произошли в то время, как резервное копирование работало. Применение изменений производит готовое резервное копирование: эти файлы готовы быть восстановленными всякий раз, когда необходимо. См. apply, MySQL Enterprise Backup , prepared backup, raw backup. I Файл .ibd Файл с данными для табличных пространств file-per-table и общих табличных пространств. Табличное пространство File-per-table содержит единственную таблицу и связанный индексные данные. Общее табличное пространство может содержать таблицу и индексные данные для многих таблиц. Файл .ibd не относится к системному табличному пространству, которое состоит из одного или более файлов ibdata. Если табличное пространство file-per-table или общее табличное пространство создаются с DATA DIRECTORY =, файл .ibd расположен в указанном пути вне нормального каталога данных. Когда файл .ibd включен в сжатое резервное копирование MySQL Enterprise Backup, сжатый эквивалент это файл .ibz. См. database, file-per-table, general tablespace, ibdata file, .ibz file, innodb_file_per_table, MySQL Enterprise Backup, system tablespace. Файл .ibz Когда MySQL Enterprise Backup выполняет сжатое резервное копирование, он преобразовывает каждый файл табличного пространства , который создается, используя file-per-table из .ibd в .ibz. Сжатие, примененное во время резервного копирования, отлично от сжатого формата строки, который сохраняет табличные данные сжатыми во время нормального функционирования. Сжатая резервная работа пропускает шаг сжатия для табличного пространства, которое уже находится в сжатом формате строки, поскольку сжатие во второй раз замедлило бы резервное копирование, но произвело бы небольшие или никакие сбережения пространства. См. compressed backup, compressed row format, file-per-table, .ibd file, MySQL Enterprise Backup , tablespace. I/O-bound См. disk-bound . Набор файлов ib Набор файлов, которыми управляет InnoDB в пределах базы данных MySQL: системное табличное пространство , файлы табличного пространства file-per-table и файлы журнала redo. В зависимости от версии MySQL и InnoDB конфигурация, может также включать общее табличное пространство, временное табличное пространство и табличное пространство отмены. Этот термин иногда используется в детальных обсуждениях структуры файла и форматов, чтобы обратиться к набору файлов, которыми управляет InnoDB в пределах базы данных MySQL. См. database, file-per-table, general tablespace, redo log, system tablespace, temporary tablespace, undo tablespace. ibbackup_logfile Дополнительный резервный файл создан MySQL Enterprise Backup во время горячей резервной копии. Это содержит информацию о любых изменениях данных, которые произошли в то время, как резервное копирование работало. Начальные резервные файлы, включая ibbackup_logfile, известны как сырое резервное копирование, потому что изменения, которые произошли во время резервной работы, еще не включены. После того, как Вы выполняете шаг применения к сырым резервным файлам, получающиеся файлы действительно включают те заключительные изменения данных, и известны как готовое резервное копирование. На данном этапе файл ibbackup_logfile больше не необходим. См. apply, hot backup, MySQL Enterprise Backup , prepared backup, raw backup. Файл ibdata Ряд файлов с именами вроде ibdata1, ibdata2 и т.д., которые составляет системное табличное пространство InnoDB. Эти файлы содержат метаданные о InnoDB (словарь данных InnoDB) и области хранения для одного или более журналов отмены, буфера изменения и буфера doublewrite. Они также могут содержать некоторые или все табличные данные (в зависимости от того, включен ли режим file-per-table, когда каждая таблица составлена). Когда включена опция innodb_file_per_table, данные и индексы для составленных таблиц сохранены в отдельных файлах .ibd , а не в системном табличном пространстве. Рост файлов ibdata управляется опцией innodb_autoextend_increment. См. change buffer, data dictionary, doublewrite buffer, file-per-table, .ibd file, innodb_file_per_table, system tablespace, undo log. Файл ibtmp Файл временного табличного пространства для несжатых временных таблиц InnoDB и связанных объектов. Опция конфигурационного файла innodb_temp_data_file_path позволяет пользователям определять относительный путь для временного файла с данными табличного пространства. Если innodb_temp_data_file_path не определена, поведение по умолчанию должно создать единственный автомасштабируемый файл ibtmp1 в 12MB в каталоге данных рядом с ibdata1. См. data files, temporary table, temporary tablespace. ib_logfile Ряд файлов, как правило называемых ib_logfile0 и ib_logfile1, форма журнала redo. Также иногда называется группой журнала. Эти файлы делают запись запросов, которые пытаются изменить данные в InnoDB. Эти запросы переигрываются автоматически, чтобы исправить данные, написанные неполными транзакциями, при запуске после катастрофического отказа. Эти данные не могут использоваться для ручного восстановления, для этого типа работы, используйте двоичный журнал. См. binary log, log group, redo log. ilist В пределах индекса FULLTEXT структура данных, состоящая из ID документа и информации о местонахождении для маркера (то есть, особого слова). См. FULLTEXT index. Неявная блокировка строки Блокировка строки, приобретенная InnoDB, чтобы гарантировать последовательность. См. row lock. База данных в памяти Тип системы базы данных, которая поддерживает данные в памяти, чтобы избежать издержек из-за дискового ввода/вывода и перевода между дисковыми блоками и областями памяти. Некоторые базы данных в памяти жертвуют длительностью ("D" в ACID) и уязвимы для аппаратных средств и других типов отказов, делая их более подходящими для операций только для чтения. Другие базы данных в памяти действительно используют механизмы длительности, такие как журналирование изменений диска или использования энергонезависимой памяти. Особенности MySQL, которые обращаются к тем же самым видам интенсивной обработки памяти, включают буферный пул, адаптивный хеш-индекс и оптимизация только для чтения, механизм хранения MEMORY, ключевой кэш MyISAM и кэш запросов MySQL. См. ACID, adaptive hash index, buffer pool, disk-based, read-only transaction. incremental backup Тип горячего резервного копирования, выполненного MySQL Enterprise Backup, который сохраняет только данные, измененные начиная с некоторого момента времени. Наличие полного резервного копирования и последовательности возрастающих резервных копий позволяет Вам восстанавливать резервные данные за длительный период без издержек хранения нескольких полных резервных копий. Вы можете восстановить полное резервное копирование и затем применить каждую из возрастающих резервных копий по очереди, или Вы можете сохранить полное резервное копирование современным, применяя каждое возрастающее резервное копирование к этому, а затем выполнить единственную работу восстановления. Степень детализации измененных данных на уровне страницы . Страница могла бы фактически покрыть больше, чем одну строку. Каждая измененная страница включена в резервное копирование. См. hot backup, MySQL Enterprise Backup , page. Индекс Структура данных, которая обеспечивает быструю способность поиска строк таблицы, как правило, формируя древовидную структуру (B-дерево) , представляющее все значения особого столбца или набора столбцов. У таблицы InnoDB всегда есть кластеризируемый индекс, представление первичного ключа . Они могут также иметь один или более вторичных индексов, определенных на одном или более столбцах. В зависимости от структуры, вторичный индекс может быть классифицирован как частичный, столбцовый или составной. Индекс это решающий аспект работы запроса. Архитекторы базы данных разрабатывают таблицы, запросы и индексы, чтобы позволить быстрые поиски для данных, необходимых приложениям. Идеальное проектирование баз данных использует покрывающий индекс, результаты запроса вычислены полностью от индекса, не читая фактические табличные данные. Каждое ограничение внешнего ключа также требует индексирования, чтобы эффективно проверить, существуют ли значения в родительских и дочерних таблицах. Хотя B-дерево индекса наиболее распространено, иной вид структуры данных используется для хэш-индексов, как в механизме хранения MEMORY и адаптивном хэш-индексе InnoDB. Индексы R-tree используются для пространственной индексации многомерной информации. См. adaptive hash index , B-tree, child table, clustered index, column index, composite index, covering index, foreign key, hash index, parent table, partial index, primary key, query, R-tree, row, secondary index, table. Кэш индекса Область памяти, которая содержит маркерные данные для полнотекстового поиска. Это буферизует данные, чтобы минимизировать дисковый ввод/вывод, когда данные вставлены или обновлены в столбцах, которые являются частью индекса FULLTEXT . Маркерные данные написаны на диск, когда индексный кэш становится полным. Каждый индекс FULLTEXT имеет его собственный отдельный индексный кэш, размером которого управляет параметр конфигурации innodb_ft_cache_size. См. full-text search, FULLTEXT index. index condition pushdown Index condition pushdown (ICP) это оптимизация, которая продвигает часть выражения WHERE вниз к механизму хранения, если части условия могут быть оценены, используя области индекса . ICP может уменьшить число раз, которое механизм хранения должен получить доступ к базовой таблице и число раз, которое сервер MySQL должен получить доступ к механизму хранения. Для получения дополнительной информации см. раздел 9.2.1.6 . См. index, storage engine. Индексные подсказки Расширенный синтаксис SQL для того, чтобы переопределить индексы, рекомендуемые оптимизатором. Например, FORCE INDEX, USE INDEX и IGNORE INDEX. Как правило, использутся, когда индексированные столбцы неравно распределили значения, приводящие к неточным оценкам количества элементов. См. cardinality, index. Префикс индекса В индексе, который относится к многим столбцам (известен как сводный индекс), ведущие столбцы индекса. Запрос, который ссылается на первые 1, 2, 3 и т.д. столбцы сводного индекса, может использовать индексирование, даже если запрос не ссылается на все столбцы в индексе. См. composite index, index. Индексная статистика См. statistics. Запись infimum Псевдозапись в индексе, представляющая промежуток ниже самого маленького значения в этом индексе. Если у транзакции есть такой запрос, как SELECT ... FOR UPDATE ... WHERE col < 10;, и самое маленькое значение в столбце 5, это блокировка на infimum, которая препятствует тому, чтобы другие транзакции вставили еще меньшие значения, такие как 0, -10 и так далее. См. gap, index, pseudo-record, supremum record. INFORMATION_SCHEMA Название базы данных, которая обеспечивает интерфейс запроса к словарю данных MySQL. Это имя определено стандартом ANSI SQL. Чтобы исследовать информацию (метаданные) о базе данных, Вы можете запросить такие таблицы, как INFORMATION_SCHEMA.TABLES и INFORMATION_SCHEMA.COLUMNS вместо использования команды SHOW, которая производит неструктурированный вывод. Информационная схема содержит некоторые таблицы, которые являются определенными для InnoDB, например, INNODB_LOCKS и INNODB_TRX. Вы используете эти таблицы, чтобы не видеть, как база данных структурирована, но получить информацию в реальном времени о работах таблиц InnoDB, чтобы помочь с исполнительным контролем, настройкой и поиском неисправностей. В частности, эти таблицы предоставляют информацию об особенностях MySQL, связанных с сжатием, транзакциями и их связанными блокировками. См. compression, data dictionary, database, InnoDB, lock, transaction. InnoDB Компонент MySQL, который комбинирует высокую производительность с транзакционными возможностями. Это воплощает ACID. Представлен как механизм хранения, это обрабатывает таблицы, создаваемые или измененные с ENGINE=INNODB, см. главу 16 и раздел 9.5. В MySQL 5.5 и выше InnoDB механизм хранения значения по умолчанию для новых таблиц и ENGINE=INNODB не требуется. В MySQL 5.1 многие из усовершенствованных особенностей InnoDB требуют включения компонента InnoDB Plugin. См. раздел 16.1. Таблицы InnoDB идеально удовлетворяют требования для горячих резервных копий. См. раздел 27.2. См. ACID, hot backup, storage engine, transaction. innodb_autoinc_lock_mode Опция innodb_autoinc_lock_mode управляет алгоритмом, используемым для блокировки auto-increment. Когда у Вас есть постепенно увеличивающийся первичный ключ , Вы можете использовать основанную на запросе репликацию только с установкой innodb_autoinc_lock_mode=1. Эта установка известна как последовательный режим блокировки, потому что мультистрочная вставка в пределах транзакции, получает последовательные значения auto-increment. Если Вы имеете innodb_autoinc_lock_mode=2, который позволяет более высокий параллелизм для операций вставки, используйте основанную на строке репликацию, а не основанную на запросе. Эта установка известна как чередованный режим блокировки, потому что мультистрочные вставки, работающие в то же самое время, могут получить значения autoincrement, которые чередованы. Установка innodb_autoinc_lock_mode=0 это предыдущая (традиционная) настройка по умолчанию и не должна использоваться за исключением целей совместимости. См. auto-increment locking, mixed-mode insert, primary key. innodb_file_per_table Важный параметр конфигурации, который затрагивает много аспектов хранения файла InnoDB, доступности особенностей и характеристик ввода/вывода. В MySQL 5.6.7 и выше это включено по умолчанию. До MySQL 5.6.7 это отключено по умолчанию. innodb_file_per_table включает режим file-per-table. С этим включенным режимом недавно составленная таблица InnoDB и связанный индекс могут быть сохранены в отдельном файле .ibd вне системного табличного пространства. Эта опция затрагивает соображения работы и хранения для многих запросов SQL, например, DROP TABLE и TRUNCATE TABLE. Включение innodb_file_per_table позволяет Вам использовать в своих интересах другие особенности, такие как табличное сжатие и резервные копии названных таблиц в MySQL Enterprise Backup. innodb_file_per_table была статичной, но теперь может быть установлена, используя SET GLOBAL . Для информации см. раздел 16.7.4. См. compression, file-per-table, .ibd file, MySQL Enterprise Backup , system tablespace. innodb_lock_wait_timeout Опция innodb_lock_wait_timeout устанавливает баланс между ожиданием совместно используемых ресурсов или отказом и обработкой ошибки, повторением или выполнением альтернативы в Вашем приложении. Отменяет любую транзакцию InnoDB, которая ждет больше, чем требуемое время, чтобы приобрести блокировку. Особенно полезно, если тупики вызваны обновлениями многих таблиц, которыми управляют различные механизмы хранения, такие тупики не обнаружены автоматически. См. deadlock, deadlock detection, lock, wait. innodb_strict_mode Опция innodb_strict_mode управляет, работает ли InnoDB в строгом режиме, где условия, которые обычно обрабатываются как предупреждения, вызывают ошибки вместо этого (и основные запросы терпят неудачу). Этот режим настройка по умолчанию в MySQL 5.5.5 и выше. См. strict mode. insert Одна из основных операций DML в SQL. Исполнение вставок это ключевой фактор в системах хранилищ данных, которые загружают миллионы строк в таблицы, и систем OLTP, где много параллельных соединений могли бы вставить строки в ту же самую таблицу в произвольном порядке. Если вставка важна для Вас, Вы должны узнать об особенностях InnoDB, таких как буфер вставки, используемый в буферизации изменения, и столбцах auto-increment. См. auto-increment, change buffering, data warehouse, DML, InnoDB, insert buffer, OLTP, SQL. Буфер вставки Прежнее название буфера изменения. В MySQL 5.5 была добавлена поддержка, чтобы буферизовать изменения вторичных индексных страниц для DELETE и UPDATE. Ранее только изменения, следующие из INSERT , были буферизованы. Привилегированный термин теперь буфер изменения. См. change buffer, change buffering. Буферизация вставки Метод хранения изменений вторичных индексных страниц из INSERT в буфере изменения вместо того, чтобы немедленно записать изменения, чтобы минимизировать случайный ввод/вывод. Это один из типов буферизации изменения. Буферизация не используется, если вторичные индексы уникальны, потому что уникальность новых значений не может быть проверена прежде, чем новые записи записаны. Другие виды буферизации изменения действительно работают на уникальных индексах. См. change buffer, change buffering, delete buffering, insert buffer, purge buffering, unique index. Блокировка намерения вставки Тип блокировки промежутка, которая установлена INSERT до вставки строки. Этот тип блокировки сигнализирует намерение вставить таким способом, которым многократные транзакции, вставляющие в тот же самый индексный промежуток, не должны ждать друг друга, если они не вставляют в ту же самую позицию в пределах промежутка. Для получения дополнительной информации см. раздел 16.5.1. См. gap lock, lock, next-key lock. Экземпляр Один демон mysqld управляющий каталогом данных, представляющим одну или более баз данных с рядом таблиц . Распространено в развитии, тестировании и некоторых сценариях репликации иметь многократные экземпляры на той же самой машине, каждый управляющий собственным каталогом данных и слушающий на собственном порту или сокете. С одним экземпляром, выполняющим disk-bound нагрузку, у сервера могли бы все еще быть дополнительные ресурсы центральныого процессора и объем памяти, чтобы выполнить дополнительные экземпляры. См. data directory, database, disk-bound, mysqld, replication, server. Инструментовка Модификации на уровне исходного кода, чтобы собрать характеристики для настройки и отладки. В MySQL данные, собранные инструментовкой, выставлены через интерфейс SQL, используя базы данных INFORMATION_SCHEMA и PERFORMANCE_SCHEMA. См. INFORMATION_SCHEMA, Performance Schema. Исключительная блокировка намерения См. intention lock. Блокировка намерения Подвид блокировки, которая относится к табличному уровню, чтобы указывать, какую блокировку транзакция намеревается приобрести на строках в таблице. Различные транзакции могут приобрести различные виды намерения на ту же самую таблицу, но первая транзакция, которая приобретет исключительную блокировку намерения (IX) препятствует тому, чтобы другие транзакции приобрели любые S или X блокировки на таблице. Наоборот, первая транзакция, которая приобретет совместно использованное намерение (IS), препятствует тому, чтобы другие транзакции приобрели любую блокировку X. Двухфазовый процесс позволяет запросам блокировки быть решенными в порядке, не блокируя блокировки и соответствующие операции, которые совместимы. Для большего количества деталей об этом механизме блокировки см. раздел 16.5.1. См. lock, lock mode, locking. Совместно использованная блокировка намерения См. intention lock. Инвертированный индекс Структура данных, оптимизированная для систем извлечения документа, используемых в выполнении InnoDB полнотекстового поиска . InnoDB индекс FULLTEXT, осуществленный как инвертированный индекс, делает запись позиции каждого слова в пределах документа, а не местоположения строки таблицы. Единственное значение столбца (документ, хранимый как текстовая строка), представлено многими записями в инвертированном индексе. См. full-text search, FULLTEXT index, ilist. IOPS Сокращение от I/O operations per second. Общее измерение для занятых систем, особенно приложений OLTP. Если это значение около максимума, который могут обработать устройства хранения данных, приложение может стать disk-bound, ограничивая масштабируемость. См. disk-bound, OLTP, scalability. Уровень изоляции Один из фондов обработки базы данных. Изоляция это I в ACID, уровень изоляции это установка, которая точно настраивает баланс между работой и надежностью, последовательностью и воспроизводимостью результатов, когда многократные транзакции производят изменения и выполняют запросы в то же самое время. От самого высокого количества последовательности и защиты к наименьшей, уровни изоляции, поддержанные InnoDB: SERIALIZABLE, REPEATABLE READ, READ COMMITTED и READ UNCOMMITTED. С InnoDB много пользователей могут сохранить уровень изоляции по умолчанию (REPEATABLE READ) для всех операций. Опытные пользователи могли бы выбрать read committed, поскольку они продвигают границы масштабируемости с обработкой OLTP, или во время операций складирования данных, где незначительные несогласованности не затрагивают совокупные результаты больших объемов данных. Уровни на краях (SERIALIZABLE и READ UNCOMMITTED) изменяют поведение обработки до такой степени, что они редко используются. См. ACID, READ COMMITTED, READ UNCOMMITTED, REPEATABLE READ, SERIALIZABLE, transaction. J join Запрос, который получает данные больше, чем от одной таблицы, ссылаясь на столбцы в таблицах, которые содержат идентичные значения. Идеально, эти столбцы часть отношений внешнего ключа InnoDB, которые гарантируют ссылочную целостность и что столбцы соединения индексированы. Часто используется, чтобы оставить свободное место и улучшить работу запроса, заменяя повторенные строки числовыми ID в нормализованном проекте данных. См. foreign key, index, normalized, query, referential integrity. K KEY_BLOCK_SIZE Опция, чтобы определить размер страниц данных в пределах таблицы InnoDB, которая использует сжатый формат строки. Значение по умолчанию составляет 8 килобайт. Нижние значения рискуют поражать внутренние пределы, которые зависят от комбинации размера строки и процента сжатия. См. compressed row format. L latch Легкая структура, используемая InnoDB, чтобы осуществить блокировку для ее собственных внутренних структур памяти, как правило проводимых в течение краткого времени, измеренного в миллисекундах или микросекундах. Общий термин, который включает mutexes (для эксклюзивного доступа) и rw-блокировки (для совместно используемого доступа). Определенные структуры центр исполнительной настройки InnoDB, такой как словарь данных mutex. Статистические данные об использовании доступны через интерфейс Performance Schema . См. data dictionary, lock, locking, mutex, Performance Schema, rw-lock. Список Буферный пул представлен как список страниц в памяти. Список переупорядочен по мере работы со страницами. Буферный пул фактически разделен на подсписки, и политика замены это изменение знакомого метода LRU. См. buffer pool, eviction, LRU, sublist. Блокировка Высокоуровневое понятие объекта, который управляет доступом к ресурсу, такому как таблица, строка или внутренняя структура данных, как часть стратегии блокировки. Для интенсивной исполнительной настройки Вы могли бы копаться в фактических структурах, которые осуществляют блокировки, например, mutexes и latches. См. latch, lock mode, locking, mutex. Подъем блокировки Работа в некоторых системах базы данных, которая преобразовывает много блокировок строки в единственную табличную блокировку, сохраняя место в памяти, но уменьшая параллельный доступ к таблице. InnoDB использует эффективное представление для блокировок строки, чтобы подъем блокировки не был необходим. См. locking, row lock, table lock. Режим блокировки Совместно используемая блокировка (S) позволяет транзакции читать строку. Многократные транзакции могут приобрести блокировку S на ту же самую строку в то же самое время. Исключительная блокировка (X) позволяет транзакции обновлять или удалять строку. Никакая другая транзакция не может приобрести такую блокировку на ту же самую строку в то же самое время. Блокировки намерения относятся к табличному уровню и используются, чтобы указать, какую блокировку транзакция намеревается приобрести на строках в таблице. Различные транзакции могут приобрести различные виды намерения на ту же самую таблицу, но первая транзакция, которая приобретет исключительное намерение (IX) препятствует тому, чтобы другие транзакции приобрели любую S или X на таблице. Наоборот, первая транзакция, которая приобретет совместно использованное намерение (IS) препятствует тому, чтобы другие транзакции приобрели любую блокировку X на таблицу. Двухфазовый процесс позволяет запросам блокировки быть решенными в порядке, не блокируя блокировки и соответствующие операции, которые совместимы. См. intention lock, lock, locking. Блокировка Система защиты транзакции от наблюдения или изменения данных, которые запрашиваются или изменяются другими транзакциями. Стратегия блокировки должна сбалансировать надежность и последовательность операций базы данных (принципы ACID). Точная настройка стратегии блокировки часто вовлекает выбор уровня изоляции и обеспечение того, что все Ваши операции базы данных безопасны и надежны для этого уровня изоляции. См. ACID, concurrency, isolation level, latch, lock, mutex, transaction. Блокировка чтения SELECT, который также выполняет работу блокировки на таблице InnoDB. Также SELECT ... FOR UPDATE или SELECT ... LOCK IN SHARE MODE. У этого есть потенциал, чтобы произвести тупик, в зависимости от уровня изоляции транзакции. Противоположность чтения без блокировки. Не позволяет глобальные таблицы в транзакции только для чтения . См. deadlock, isolation level, locking, non-locking read, read-only transaction. Журнал В контексте InnoDB журнал или файлы журнала как правило обращается к журналу redo представленному файлами ib_logfile*. Другой областью журнала, которая может быть физически частью системного табличного пространства, является журнал отмены. Другие виды журналов, которые важны в MySQL, являются журналом ошибок (для того, чтобы диагностировать запуск и проблемы во время выполнения), двоичный журнал (для того, чтобы работать с репликацией и выполнить восстановления момента времени), общий журнал запроса (для того, чтобы диагностировать проблемы приложения) и медленный журнал запроса (для того, чтобы диагностировать исполнительные проблемы). См. binary log, error log, general query log, ib_logfile, redo log, slow query log, system tablespace, undo log. Буфер журнала Область памяти, которая хранит данные, которые будут написаны в файлы системного журнала, которые составляют журнал redo. Этим управляется опцией innodb_log_buffer_size. См. log file, redo log. Файл системного журнала Один из файлов ib_logfileN, которые составляют журнал redo. Данные записаны в эти файлам из буферной области памяти журнала. См. ib_logfile, log buffer, redo log. Группа журнала Набор файлов, которые составляют журнал redo , обычно ib_logfile0 и ib_logfile1. По этой причине иногда упоминаемые все вместе как ib_logfile. См. ib_logfile, redo log. Логический Тип работы, которая вовлекает высокий уровень, абстрактные аспекты, такие как таблицы, запросы, индексы и другие понятия SQL. Как правило, логические аспекты важны, чтобы сделать управление базами данных и разработку приложений удобными и применимыми. См. logical backup, physical. Логическое резервное копирование Резервное копирование, которое воспроизводит структуру таблицы и данные, не копируя фактические файлы с данными. Например, mysqldump производит логическое резервное копирование, потому что его вывод содержит такой запрос, как CREATE TABLE или INSERT, а это может обновить данные. Логическое резервное копирование предлагает гибкость (например, Вы могли отредактировать табличные определения или вставить запрос прежде, чем восстановить), но может занять существенно больше времени, чтобы восстановить, чем физическое резервное копирование. См. backup, mysqldump, physical backup, restore. loose_ В MySQL 5.1 префикс, добавленный к параметрам конфигурации InnoDB, устанавливая Plugin после запуска сервера, таким образом, любые новые параметры конфигурации, не признанные текущим уровнем MySQL, не вызывают отказ запуска. MySQL обрабатывает параметры конфигурации, которые запускаются с этого префикса, но дает предупреждение, а не отказ, если часть после префикса это не признанная опция. См. plugin. Нижняя метка Значение, представляющее низкий предел, как правило, пороговое значение, в котором некоторое корректирующее действие начинается или становится более агрессивным. См. high-water mark. LRU Сокращение от "least recently used", общепринятая методика для того, чтобы управлять областями хранения. Элементы, которые не использовались недавно, вычеркнуты, когда пространство необходимо, чтобы кэшировать более новые элементы. InnoDB использует механизм LRU по умолчанию, чтобы управлять страницами в буферном пуле, но делает исключения в случаях, где страница могла бы быть только для чтения, как во время полного сканирования таблицы. Это изменение алгоритма LRU называют стратегией вставки середины . Пути, которыми буферное управление пула отличается от традиционного алгоритма LRU, точно настроены опциями innodb_old_blocks_pct , innodb_old_blocks_time и новыми в MySQL 5.6 innodb_lru_scan_depth и innodb_flush_neighbors. См. buffer pool, eviction, full table scan, midpoint insertion strategy, page. LSN Сокращение от "log sequence number". Это произвольное, постоянно увеличивающееся, значение представляет момент времени, соответствующий операциям, зарегистрированным в журнале redo. Этот момент времени независим от операционных границ, это может упасть в середине одной или более транзакций. Это используется внутренне InnoDB во время восстановления катастрофического отказа и для того, чтобы управлять буферным пулом. До MySQL 5.6.3 LSN был 4-байтным unsigned integer. LSN стал 8-байтовым unsigned integer в MySQL 5.6.3, когда предел размера файла системного журнала увеличился с 4GB до 512GB, поскольку дополнительные байты были обязаны хранить дополнительную информацию размера. Приложения, основанные на MySQL 5.6.3 или позже, которые используют значения LSN, должны теперь использовать 64-битовые, а не 32-битовые переменные, чтобы сохранить и сравнить значения LSN. В MySQL Enterprise Backup Вы можете определить LSN, чтобы представить момент времени, от которого можно взять возрастающее резервное копирование. Соответствующий LSN выведен на экран выводом mysqlbackup. Как только у Вас есть соответствие LSN времени полного резервного копирования, Вы можете определить значение, чтобы взять последующее возрастающее резервное копирование, вывод которого содержит другой LSN для следующего возрастающего резервного копирования. См. crash recovery, incremental backup, MySQL Enterprise Backup , redo log, transaction. M Файл .MRG Файл, содержащий ссылки на другие таблицы, используемые механизмом хранения MERGE. Файлы с этим расширением всегда включаются в резервные копии, произведенные mysqlbackup из MySQL Enterprise Backup. См. MySQL Enterprise Backup, mysqlbackup command. Файл .MYD Файл, чтобы хранить данные для таблицы MyISAM. См. .MYI file, MySQL Enterprise Backup, mysqlbackup command. Файл .MYI Файл, чтобы хранить индексы для таблицы MyISAM. См. .MYD file, MySQL Enterprise Backup, mysqlbackup command. Главный сервер Часто "ведущее устройство". Машина сервера базы данных в сценарии репликации, который обрабатывает начальные запросы вставки, обновления и удаления данных. Эти изменения размножены и повторены на других серверах, известных как ведомые серверы. См. replication, slave server. Основной поток Поток, который выполняет различные задачи в фоне. Большинство этих задач связаны с вводом/выводом, например, запись буфера изменения в соответствующие вторичные индексы. Чтобы улучшить параллелизм, иногда действия перемещены из основного потока, чтобы отделить фоновые потоки. Например, в MySQL 5.6 и выше грязные страницы сбрасываются из буферного пула потоком уборщика страницы, а не основным потоком. См. buffer pool, dirty page, flush, insert buffer, page cleaner, thread. MDL Сокращение от metadata lock. См. metadata lock. memcached Популярный компонент многих стеков программного обеспечения MySQL и NoSQL, позволяя быстро читать и писать единственные значения и кэширование результатов полностью в памяти. Традиционно, приложения требовали, чтобы дополнительная логика писала те же самые данные в базу данных MySQL для постоянного хранения или читала данные из базы данных MySQL, когда это еще не кэшировалось в памяти. Теперь приложения могут использовать простой протокол memcached, поддержанный библиотеками клиента для многих языков, чтобы работать непосредственно с использованием серверов MySQL или MySQL Cluster. Эти интерфейсы NoSQL к таблицам MySQL позволяют приложениям достигать больших скоростей, чем выпуская запросы SQL непосредственно, и могут упростить логику приложения и конфигурации развертывания для систем, которые уже включили memcached для кэширования в памяти. Интерфейс memcached к таблицам InnoDB доступен в MySQL 5.6 и выше, см. раздел 16.19. Интерфейс memcached к MySQL Cluster доступен в MySQL Cluster 7.2, см. http://dev.mysql.com/doc/ndbapi/en/ndbmemcache.html. См. InnoDB, NoSQL. Слияние Применяет изменения данных в памяти как тогда, когда страница принесена в буферный пул, и любые применимые изменения, зарегистрированные в буфере изменения. Обновленные данные в конечном счете написаны в табличное пространство механизмом сброса данных. См. buffer pool, change buffer, flush, tablespace. Блокировка метаданных Тип блокировки, которая предотвращает операции DDL на таблице, которая используется в то же самое время другой транзакцией . Для деталей см. раздел 9.11.4 . Улучшения операций онлайн, особенно в MySQL 5.6 и выше, сосредоточены на сокращении количества блокировки метаданных. Цель для операций DDL, которые не изменяют структуру таблицы, например, CREATE INDEX и DROP INDEX для InnoDB: продолжиться в то время, как таблица запрашивается, обновляется и так далее другими транзакциями. См. DDL, lock, online, transaction. Счетчик метрик Опция, реализованная таблицей innodb_metrics в information_schema в MySQL 5.6 и выше. Вы можете запросить counts и общие количества для низкого уровня операции InnoDB, и использовать результаты для работы, настраивающей комбинацию с данными от performance_schema. См. counter, INFORMATION_SCHEMA, Performance Schema. Стратегия вставки середины Метод начального обеспечения страниц в буферном пуле InnoDB не в "новейшем" конце списка, а вместо этого где-нибудь в середине. Точное местоположение этого пункта может измениться, основанное на установке innodb_old_blocks_pct. Намерение состоит в том, чтобы блоки, которые только считаны, как во время полного сканирования таблицы, могли быть удалены из буферного пула скорее, чем со строгим алгоритмом LRU. См. buffer pool, full table scan, LRU, page. Минитранзакция Внутренняя фаза обработки InnoDB, производящая изменения на физическом уровне внутренних структур данных во время операций DML. У минитранзакции (mtr) нет никакого понятия отмены, многократные минитранзакции могут произойти в пределах единственной транзакции. Минитранзакции пишут информацию в журнал redo, который используется во время восстановления катастрофического отказа. Минитранзакция может также произойти вне контекста регулярной транзакции, например во время обработки чистки фоновыми потоками. См. commit, crash recovery, DML, physical, purge, redo log, rollback, transaction. Смешанный режим вставки INSERT, где auto-increment определены для некоторых, но не всех новых строк. Например, INSERT может определить значение для столбца auto-increment в некоторых случаях и NULL в других случаях. InnoDB производит значения auto-increment для строк, где значение столбца было определено как NULL. Другой пример INSERT ... ON DUPLICATE KEY UPDATE, где значения auto-increment могли бы быть произведены, но не использоваться, для любых дублирующихся строк, которые обработаны как UPDATE вместо INSERT. Может вызвать проблемы последовательности между основными и ведомыми серверами в конфигурации репликации. Может потребовать корректировки значения опции innodb_autoinc_lock_mode. См. auto-increment, innodb_autoinc_lock_mode , master server, replication, slave server. mtr См. mini-transaction. multi-core Тип процессора, который может использовать в своих интересах мультипоточные программы, такие как сервер MySQL. multiversion concurrency control См. MVCC. mutex Сокращение от "mutex variable". Mutex сам по себе сокращение от "mutual exclusion". Низкоуровневый объект, используемый InnoDB, чтобы представить и провести в жизнь блокировки эксклюзивного доступа к внутренним структурам данных в памяти. Как только блокировка приобретена, любому другому процессу, потоку и так далее препятствуют приобрести ту же самую блокировку. Mutexes и rw-блокировки известны все вместе как latches. См. latch, lock, Performance Schema, Pthreads, rw-lock. MVCC Сокращение от "multiversion concurrency control". Этот метод позволяет транзакциям InnoDB с определенными уровнями изоляции выполнить последовательные операции чтения, то есть, чтобы запросить строки, которые обновляются другими транзакциями, и видеть значения до тех обновлений. Это сильный метод увеличить параллелизм , позволяя запросам продолжиться, не ожидая из-за блокировок, проводимых другими транзакциями. Этот метод не универсален в мире баз данных. Некоторые другие продукты базы данных и некоторые другие механизмы хранения MySQL не поддерживают это. См. ACID, concurrency, consistent read, isolation level, lock, transaction. my.cnf Имя файла опции MySQL в системах Unix или Linux. См. my.ini, option file. my.ini Имя файла опции MySQL в системах Windows. См. my.cnf, option file. mysql Интерпретатор командной строки для базы данных MySQL. Это обрабатывает запросы SQL, а также команды MySQL, например, SHOW TABLES, передавая запросы к mysqld. См. mysqld, SQL. MySQL Enterprise Backup Имеющий лицензию продукт, который выполняет горячие резервные копии баз данных MySQL. Это предлагает больше эффективности и гибкости, поддерживая таблицы InnoDB, но может также поддержать MyISAM и другие виды таблиц. См. hot backup, InnoDB. mysqlbackup Инструмент командной строки MySQL Enterprise Backup. Это выполняет горячее резервирование для таблиц InnoDB и теплое резервирование для MyISAM и других видов таблиц. См. раздел 27.2. См. hot backup, MySQL Enterprise Backup , warm backup. mysqld Это собственно механизм базы данных MySQL. Это работает как демон Unix или служба Windows, постоянно ждущая запросов и выполняющая работу обслуживания в фоне. См. mysql. mysqldump Команда, которая выполняет логическое резервное копирование некоторой комбинации баз данных, таблиц и табличных данных. Результаты это запросы SQL, которые воспроизводят оригинальные объекты схемы, данные или то и другое. Для значительного количества данных физическое резервное копирование , например, MySQL Enterprise Backup быстрее, особенно для работы восстановления. См. logical backup, MySQL Enterprise Backup , physical backup, restore. N Естественный ключ Индексированный столбец, как правило, primary key , где у значений есть некоторое значение реального мира. Если значение должно когда-либо изменяться, есть потенциально много индексного обслуживания, чтобы изменить кластеризируемый индекс и обновить копии значения первичного ключа, которые повторены в каждом вторичном индексе. Даже на вид устойчивые значения могут измениться непредсказуемыми способами, которые трудно представить правильно в базе данных. Например, одна страна может измениться на две или несколько, делая оригинальный код страны устаревшим. Или у правил об уникальных значениях могли бы быть исключения. Например, даже если удостоверения личности налогоплательщика предназначены, чтобы быть уникальными для единственного человека, базе данных, возможно, придется обработать отчеты, которые нарушают это правило, как в случаях хищения личных данных. Удостоверения личности налогоплательщика и другие чувствительные идентификационные номера также делают бесполезными первичные ключи, потому что они, возможно, должны быть обеспечены в зашифрованном виде и обработаны по-другому, чем другие столбцы. Таким образом, как правило лучше использовать произвольные числовые значения, чтобы сформировать синтетический ключ , например, используя столбец auto-increment . См. auto-increment, primary key, secondary index, synthetic key. Соседняя страница Любая страница в том же самом экстенте, как особая страница. Когда страница выбрана, чтобы сбросить, любые соседние страницы, которые грязные, как правило, также сбрасываются, как оптимизация ввода/вывода для традиционных жестких дисков. В MySQL 5.6 и выше этим поведением может управлять переменная конфигурации innodb_flush_neighbors: Вы могли бы выключить ту установку для дисков SSD, у которых нет таких издержек для того, чтобы написать меньшие пакеты данных. См. dirty page, extent, flush, page. Блокировка следующего ключа Комбинация блокировки записи индекса и блокировки промежутка на промежутке перед индексной записью. См. gap lock, locking, record lock. Неблокирующий ввод/вывод Промышленный термин, который означает то же самое, что и asynchronous I/O. См. asynchronous I/O. Чтение без блокировки Запрос, который не использует SELECT ... FOR UPDATE или SELECT ... LOCK IN SHARE MODE . Единственный вид запроса, который позволяет глобальные таблицы в транзакции только для чтения. См. locking read, query, read-only transaction. Неповторимое чтение Ситуация, когда запрос получает данные, и более поздний запрос в пределах той же самой транзакции получает то, что должно быть теми же самыми данными, но запросы возвращают различные результаты (изменены другой транзакцией, переданной тем временем). Этот вид работы идет вразрез с ACID. В пределах транзакции данные должны быть последовательными, с предсказуемыми и устойчивыми отношениями. Среди различных уровней изоляции неповторимые чтения предотвращены уровнями serializable read и repeatable read, но разрешены на уровнях consistent read и read uncommitted. См. ACID, consistent read, isolation level, READ UNCOMMITTED, REPEATABLE READ, SERIALIZABLE, transaction. normalized Стратегия проектирования баз данных, где данные разделены на многократные таблицы и двойные значения, сжатые в единственные строки, представленные ID, чтобы избежать хранить, запрашивать и обновлять избыточные или длинные значения. Это как правило используется в приложениях OLTP. Например, адресу можно было бы дать уникальный ID, чтобы база данных переписи могла представить жизни отношений в этом адресе, связывая ID с каждым членом семьи, вместо того, чтобы хранить многократные копии сложного значения, такие как 123 Main Street, Anytown, USA . Для другого примера, хотя простое приложение адресной книги могло бы сохранить каждый номер телефона в той же самой таблице как имя человека и адрес, база данных телефонной компании могла бы дать каждому номеру телефона специальный ID и сохранить числа и ID в отдельной таблице. Это нормализованное представление могло упростить крупномасштабные обновления, когда коды области разделяли обособленно. Нормализация не всегда рекомендуется. Данные, которые прежде всего запрошены и только обновлены, часто сохраняются в больших таблицах с избыточными копиями двойных значений. Это представление данных упоминается как denormalized и часто находится в приложениях складирования данных. См. denormalized, foreign key, OLTP, relational. NoSQL Широкий термин для ряда технологий доступа к данным, которые не используют язык SQL в качестве их основного механизма для чтения и записи данных. Некоторый технологический акт NoSQL как значение ключа хранит только единственное значение, что не требует предварительно запланированной схемы. Пользователи MySQL могут объединить обработку NoSQL-стиля для скорости и простоты с операциями SQL для гибкости и удобства при использовании memcached API, чтобы непосредственно получить доступ к некоторым видам таблиц MySQL. Интерфейс memcached к таблицам InnoDB доступен в MySQL 5.6 и выше, см. раздел 16.19. Интерфейс memcached к MySQL Cluster доступен в MySQL Cluster 7.2, см. http://dev.mysql.com/doc/ndbapi/en/ndbmemcache.html. См. ACID, InnoDB, memcached, schema, SQL. Ограничение NOT NULL Тип ограничения, которое определяет, что столбец не может содержать NULL. Это помогает сохранить ссылочную целостность, поскольку сервер базы данных может идентифицировать данные с ошибочными недостающими значениями. Это также помогает в арифметике, вовлеченной в оптимизацию запроса, позволяя оптимизатору предсказать число записей в индексе на этом столбце. См. column, constraint, NULL, primary key, referential integrity. NULL Специальное значение в SQL указывает на отсутствие данных. Любая арифметическая работа или тест равенства, вовлекающий NULL, вернет NULL. Таким образом это подобно понятию IEEE с плавающей запятой NaN, "not a number". Любое совокупное вычисление, такое как AVG(), игнорирует строки с NULL. Единственный тест, который работает с NULL, использует идиомы SQL IS NULL или IS NOT NULL. NULL играют роль в индексе, потому что для работы база данных должна минимизировать издержки отслеживания недостающих значений данных. Как правило, NULL не сохранены в индексировании, потому что запрос, который проверяет индексированный столбец, используя стандартный оператор сравнения, никогда не мог соответствовать строке с NULL для того столбца. По той же самой причине уникальный индекс не предотвращает NULL, эти значения просто не представлены в индексе. Объявление NOT NULL ограничение на столбец обеспечивает, что нет никаких строк вне индекса, что упрощает оптимизацию (точный подсчет строк и оценка того, использовать ли индекс). Поскольку первичный ключ должен быть в состоянии уникально идентифицировать каждую строку в таблице, первичный ключ единственного столбца не может содержать NULL и многостолбцовый первичный ключ не может содержать строки с NULL во всех столбцах. Хотя база данных Oracle позволяет NULL, которое будет связано со строкой, InnoDB обрабатывает результат такой работы как NULL. См. index, primary key, SQL. O Файл .OPT Файл, содержащий информацию о конфигурации базы данных. Файлы с этим расширением всегда включаются в резервные копии, произведенные mysqlbackup в MySQL Enterprise Backup . См. MySQL Enterprise Backup, mysqlbackup command. Столбец вне страницы Столбец, содержащий данные переменной длины (BLOB и VARCHAR), которые слишком длинные, чтобы разместить на странице B-tree. Данные хранятся в страницах переполнения. DYNAMIC формат строки в формате файла Barracuda InnoDB более эффективен для такого хранения, чем более старый формат строки COMPACT. См. B-tree, overflow page. OLTP Сокращение для "Online Transaction Processing". Система базы данных или приложение базы данных, которое выполняет рабочую нагрузку со многими транзакциями, частыми чтениями и записями, как правило затрагивая небольшие количества данных за один раз. Например, система резервирования авиалинии или приложение, которое обрабатывает вклады в банке. Данные могли бы быть организованы в нормализованной форме для баланса между эффективностью DML (вставки/обновления/удаления) и запросов. С блокировкой на уровне строки и транзакционной способностью InnoDB это идеальный механизм хранения для таблиц MySQL, используемых в приложениях OLTP. См. data warehouse, DML, InnoDB, query, row lock, transaction. online Тип работы, которая не вовлекает времени простоя, блокирования или ограниченной работы для базы данных. Как правило, применяется к DDL. Операции, которые сокращают периоды ограниченной работы, такие как быстрое создание индекса , развились в более широкий набор операций DDL онлайн в MySQL 5.6. В контексте резервных копий горячее резервное копирование это работа онлайн, а теплое резервное копирование частично работа онлайн. См. DDL, Fast Index Creation, hot backup, online DDL, warm backup. online DDL Особенность, которая улучшает работу, параллелизм и доступность таблиц InnoDB во время DDL (прежде всего ALTER TABLE), см. раздел 16.12. Детали изменяются согласно типу работы. В некоторых случаях таблица может быть изменена одновременно в то время, как работает ALTER TABLE. Работа могла быть выполнена, не делая табличную копию, или используя особенно оптимизированный тип табличной копии. Использованием места управляет опция innodb_online_alter_log_max_size. Эта особенность улучшение Fast Index Creation в MySQL 5.5 и InnoDB Plugin в MySQL 5.1. См. DDL, Fast Index Creation, online. Оптимистичный Методология, которая ведет низкоуровневые решения выполнения для системы реляционной базы данных. Требования работы и параллелизма в реляционной базе данных означают, что операции должны быть запущены или посланы быстро. Требования последовательности и ссылочной целостности означают, что любая работа могла потерпеть неудачу: транзакция могла быть отменена, работа DML могла нарушить ограничение, запрос о блокировке мог вызвать тупик, сетевая ошибка могла вызвать тайм-аут. Оптимистическая стратегия принимает, что большинство запросов преуспеют, чтобы относительно маленькая работа была сделана, чтобы подготовиться к случаю отказа. Когда это предположение истина, база данных делает небольшую ненужную работу, когда запросы действительно терпят неудачу, дополнительная работа должна быть сделана, чтобы отменить изменения. InnoDB использует оптимистические стратегии операций, таких как locking и commits. Например, данные, измененные транзакцией, могут быть написаны файлам с данными прежде, чем передача произойдет, делая передачу очень быстро, но требуя больше работы, чтобы отменить изменения, если транзакция отменилась Противоположность оптимистической стратегии это пессимистическая, где система оптимизирована, чтобы иметь дело с операциями, которые ненадежны и часто неудачны. Эта методология редка в системе базы данных, потому что такая большая забота входит в выбор надежных аппаратных средств, сетей и алгоритмов. См. commit, concurrency, DML, locking, pessimistic. Оптимизатор Компонент MySQL, который определяет лучший порядок использования индексов и join для запроса, основанного на характеристиках и распределении данных соответствующих таблиц. См. index, join, query, table. Опция Параметр конфигурации для MySQL, сохраненный в файле опций или переданный в командной строке. Для опций, которые относятся к таблицам InnoDB , каждое имя опции начинается с innodb_. См. InnoDB, option file. Файл опций Файл, который содержит параметры конфигурации MySQL. Традиционно в Linux и Unix этот файл называют my.cnf, а в Windows my.ini. См. configuration file, my.cnf, option. Страница переполнения Отдельно выделенные дисковые страницы, которые содержат столбцы переменной длины (такие как BLOB и VARCHAR), которые слишком длинные, чтобы поместиться на странице B-tree. Связанные столбцы известны как столбцы вне страницы . См. B-tree, off-page column, page. P Файл .PAR Файл, содержащий определения разделения. Файлы с этим расширением всегда включаются в резервные копии, произведенные mysqlbackup в MySQL Enterprise Backup. С введением родного разделения для InnoDB в MySQL 5.7.6 файлы .PAR больше не создаются для разделенных таблиц InnoDB. См. MySQL Enterprise Backup, mysqlbackup command. Страница Представление сколько данных InnoDB переходит в любой момент между диском (файлы с данными) и памятью (буферный пул). Страница может содержать одну или более строк, в зависимости от того, сколько данных находится в каждой строке. Если строка не соответствует полностью единственной странице, InnoDB настраивает дополнительные структуры данных указателя так, чтобы информация о строке могла храниться в одной странице. Один способ разместить больше данных на каждой странице состоит в том, чтобы использовать сжатый формат строки. Для таблиц, которые используют BLOB или большие текстовые поля, компактный формат строки позволяет большим столбцам быть сохраненными отдельно от остальной части строки, уменьшая ввод/вывод и использование памяти для запросов, которые не ссылаются на те столбцы. Когда InnoDB читает или пишет наборы страниц как пакет, чтобы увеличить пропускную способность ввода/вывода, он читает или пишет экстент за один раз. All the InnoDB disk data structures within a MySQL instance share the same page size. См. buffer pool, compact row format, compressed row format, data files, extent, page size, row. Уборщик страницы Фоновый поток InnoDB, который сбрасывает грязные страницы из буферного пула. До MySQL 5.6 эта деятельность была выполнена основным потоком. См. buffer pool, dirty page, flush, master thread, thread. Размер страницы Для выпусков до и включая MySQL 5.5, размер каждой страницы InnoDB установлен в 16 килобайт. Это значение представляет баланс: достаточно большой, чтобы хранить данные для большинства строк, но все же достаточно маленький, чтобы минимизировать издержки передачи ненужных данных к памяти. Другие значения не проверены или поддержаны. С MySQL 5.6 размер страницы для экземпляра может составить 4 КБ, 8 КБ или 16 КБ, чем управляет опция innodb_page_size . С MySQL 5.7.6 InnoDB также оказывает поддержку для размеров страницы 32KB и 64KB. Для размеров страницы 32KB и 64KB ROW_FORMAT=COMPRESSED не поддержан и максимальный размер записи составляет 16 КБ. Вы устанавливаете размер, создавая экземпляр MySQL, и это остается постоянным позже. Тот же самый размер страницы относится ко всем табличным пространствам InnoDB, системному табличному пространству и любымм отдельным табличным пространствам, создаваемым в режиме file-per-table. Меньшие размеры страницы могут помочь работе с устройствами хранения данных, которые используют маленькие размеры блока, особенно для устройств SSD в рабочих нагрузках disk-bound, например, OLTP. Поскольку отдельные строки обновлены, меньше данных скопировано в память, написано на диск, реорганизовано, заблокировано и так далее. См. disk-bound, file-per-table, instance, OLTP, page, SSD, system tablespace, tablespace. Родительская таблица Таблица в отношениях внешнего ключа, которые содержат начальные значения столбцов от дочерней таблицы. Последствия удаления или обновления строк в родительской таблице зависят от определений ON UPDATE и ON DELETE в определении внешнего ключа. Строки с соответствующими значениями в дочерней таблице могли быть автоматически удалены или обновлены в свою очередь, те столбцы могли быть установлены в NULL, или работа могла быть предотвращена. См. child table, foreign key. Частичное резервное копирование Резервное копирование, которое содержит некоторые из таблиц в базе данных MySQL или некоторые из баз данных в экземпляре MySQL. См. backup, full backup, table. Частичный индекс Индекс, который представляет только часть значения столбца, как правило, первые N символов (префикс ) длинного значения VARCHAR. См. index, index prefix. Performance Schema performance_schema в MySQL 5.5 и выше представляет ряд таблиц, которые Вы можете запросить, чтобы получить подробную информацию о технических характеристиках многих внутренних деталей сервера MySQL. См. latch, mutex, rw-lock. Постоянная статистика В MySQL 5.6 хранит индексную статистику для таблиц InnoDB на диске, обеспечивая лучший план для запросов , см. раздел 16.6.10.1 . См. index, optimizer, plan stability, query, table. Пессимистичный Методология, которая жертвует работой или параллелизмом в пользу безопасности. Уместно, если высокий процент запросов или попыток мог бы потерпеть неудачу, или если последствия неудавшегося запроса серьезны. InnoDB использует то, что известно, как пессимистическая стратегия блокировки, что минимизирует шанс тупиков. На уровне приложения Вы могли бы избежать тупиков при использовании пессимистической стратегии приобретения всех блокировок, необходимых транзакции в самом начале. Много встроенных механизмов базы данных используют противоположную оптимистическую методологию. См. deadlock, locking, optimistic. Фантом Строка, которая появляется в наборе результатов запроса, но не в наборе результатов более раннего запроса. Например, если запрос выполнен дважды в пределах транзакции, а тем временем другая транзакция передает после вставки новой строки или обновления строки так, чтобы это соответствовало WHERE. Это возникновение известно как призрачное чтение. Более трудно принять меры, чем неповторимое чтение, потому что блокировка всех строк от первого набора результатов запроса не предотвращает изменения, которые заставляют фантом появляться. Среди различных уровней изоляции призрачные чтения предотвращены уровнем serializable read, но позволены repeatable read, consistent read и read uncommitted. См. consistent read, isolation level, non-repeatable read, READ UNCOMMITTED, REPEATABLE READ, SERIALIZABLE, transaction. Физический Тип работы, которая вовлекает связанные с аппаратными средствами аспекты такие, как диск, блокировка, страницы памяти, файлы, биты, дисковые чтения и так далее. Как правило, физические аспекты важны во время исполнительной настройки на опытном уровне и поиска проблем. См. logical, physical backup. Физическое резервное копирование Резервное копирование, которое копирует фактические файлы с данными. Например, mysqlbackup из MySQL Enterprise Backup производит физическое резервное копирование, потому что его вывод содержит файлы с данными, которые могут использоваться непосредственно mysqld, приводя к более быстрой работе восстановления. См. backup, logical backup, MySQL Enterprise Backup , restore. PITR Сокращение от point-in-time recovery. См. point-in-time recovery. План стабильности Свойство плана выполнения запроса, где оптимизатор делает тот же самый выбор каждый раз для данного запроса, чтобы работа была последовательна и предсказуема. См. query, query execution plan. Плагин В MySQL 5.1 и ранее отдельно устанавливаемая форма механизма хранения InnoDB, который включает особенности и исполнительные улучшения, не включенные во встроенный InnoDB. Для MySQL 5.5 и выше дистрибутивы MySQL включают последние особенности InnoDB и исполнительные улучшения, известные как InnoDB 1.1, и больше нет отдельного InnoDB Plugin. Это различие важно, главным образом, в MySQL 5.1, где особенность или исправление ошибки могли бы относиться к InnoDB Plugin, но не ко встроенному InnoDB. См. built-in, InnoDB. Восстановление момента времени Процесс восстановления резервного копирования , чтобы обновить состояние базы данных к определенной дате и время. Обычно обозначается как PITR. Поскольку маловероятно, что требуемое время соответствует точно времени резервного копирования, этот метод обычно требует комбинации физического резервного копирования и логического резервного копирования. Например, с MySQL Enterprise Backup Вы восстанавливаете последнее резервное копирование, которое Вы взяли перед указанным моментом времени, затем переиграть изменения от двоичного журнала между временем резервного копирования и временем PITR. См. backup, logical backup, MySQL Enterprise Backup , physical backup, PITR. Префикс См. index prefix. Готовое резервное копирование Ряд резервных файлов, произведенных MySQL Enterprise Backup после всех этапов применения двоичных журналов и возрастающих резервных копий. Получающиеся файлы готовы быть восстановленными. До шага применения файлы известны как сырое резервное копирование. См. binary log, hot backup, incremental backup, MySQL Enterprise Backup , raw backup, restore. primary key Ряд столбцов и косвенно индекс, основанный на этом наборе столбцов, который может уникально идентифицировать каждую строку в таблице. Также это должен быть уникальный индекс, который не содержит NULL. InnoDB требует, чтобы у каждой таблицы был такой индекс (также названный кластеризируемым индексом или кластерным индексом) и организует табличное хранение, основанное на значениях столбцов первичного ключа. Выбирая значения первичного ключа, рассмотрите использование произвольных значений (синтетический ключ) вместо того, чтобы положиться на некоторый другой источник (естественный ключ). См. clustered index, index, natural key, synthetic key. Процесс Экземпляр программы выполнения. Операционная система переключается между многими рабочими процессами, учитывая определенную степень параллелизма. На большинстве операционных систем процессы могут содержать многократные потоки . Переключение контекста между потоками быстрее чем эквивалентное переключение между процессами. См. concurrency, thread. Псевдоотчет Искусственный отчет в индексе, используемый для того, чтобы заблокировать значения ключа или диапазоны, которые в настоящее время не существуют. См. infimum record, locking, supremum record. Pthreads Стандарт POSIX threads, который определяет API для поточной обработки и блокировки операций на системах Unix и Linux. На системах Unix и Linux InnoDB использует это для mutexes. См. mutex. Чистка Тип сбора мусора, выполненного одним или более отдельными фоновыми потоками (управляется innodb_purge_threads), это работает в периодическом графике. Чистка обарабывает страницы журнала отмены из списка истории с целью удаления кластеризируемых и вторичных индексных записей, которые были отмечены для удаления (предыдущим DELETE) и больше не требуются для MVCC или отмены. Чистка освобождает страницы журнала отмены от списка истории после обработки. См. history list, MVCC, rollback, undo log. Буферизация чистки Метод хранения изменений вторичных индексных страниц после операции DELETE в буфере изменения вместо того, чтобы немедленно писать изменения, чтобы минимизировать случайный ввод/вывод. Поскольку удаления двухступенчатый процесс, эта работа буферизует запись, которая обычно производит чистку индексного отчета, который был ранее отмечен для удаления. Это один из типов буферизации изменения . См. change buffer, change buffering, delete buffering, insert buffer, insert buffering. Задержка чистки Другое название список истории InnoDB. Связан с опцией innodb_max_purge_lag . См. history list, purge. Поток чистки Поток в пределах процесса InnoDB, который посвящен выполнению периодической работы чистки. В MySQL 5.6 и выше многократные потоки чистки включены опцией innodb_purge_threads. См. purge, thread. Q Запрос В SQL работа, которая читает информацию из одной или более таблиц. В зависимости от организации данных и параметров запроса, поиск мог бы быть оптимизирован, консультируясь с индексом. Если многократные таблицы вовлечены, запрос известен как join. По историческим причинам иногда обсуждения внутренней обработки для запросов используют понятие "запрос" в более широком смысле, включая другие типы запросов MySQL, такие как DDL и DML. См. DDL, DML, index, join, SQL, table. План выполнения запроса Набор решений, принятых оптимизатором относительно того, как выполнить запрос наиболее эффективно, включая индекс или индексы и порядок, в который можно присоединиться к таблицам. Стабильность плана вовлекает тот же самый выбор, сделанный последовательно для данного запроса. См. index, join, plan stability, query. Журнал запросов См. general query log. quiesce Уменьшение количества деятельности базы данных, часто в подготовке к такой работе, как ALTER TABLE, резервирование или завершение работы. Может вовлечь выполнение такого большого сброса, как возможно, чтобы InnoDB не продолжил делать фоновый ввод/вывод. В MySQL 5.6 и выше FLUSH TABLES ... FOR EXPORT пишет некоторые данные на диск для таблиц InnoDB, что делает проще поддержку таблиц, копируя файлы с данными. См. backup, flush, InnoDB, shutdown. R R-tree Структура данных дерева для пространственной индексирующей многомерной информации, такой как географические координаты, прямоугольники или многоугольники. См. B-tree. RAID Сокращение от "Redundant Array of Inexpensive Drives". Распространение операций ввода/вывода на многие диски включает больший параллелизму на уровне аппаратных средств и улучшает эффективность низкого уровня операций, которые иначе были бы выполнены в последовательности. См. concurrency. Случайное погружение Метод для того, чтобы быстро оценить число различных значений в столбце (количество элементов столбца). Эта работа происходит, когда каждая таблица открыта. См. cardinality. Сырое резервное копирование Начальный набор резервных файлов, произведенных MySQL Enterprise Backup перед изменениями, отраженными в двоичном журнале и любых возрастающих резервных копиях. На данном этапе файлы не готовы к восстановлению . После того, как эти изменения применены, файлы известны как готовое резервное копирование. См. binary log, hot backup, ibbackup_logfile, incremental backup, MySQL Enterprise Backup , prepared backup, restore. READ COMMITTED Уровень изоляции, который использует стратегию блокировки, которая ослабляет часть защиты между транзакциями в интересах работы. Транзакции не могут видеть нейтральные данные от других транзакций, но они могут видеть данные, которые переданы другой транзакцией после того, как текущая транзакция запускалась. Таким образом, транзакция никогда не видит неправильных данных, но данные, которые она действительно видит, могут зависеть до некоторой степени от синхронизации других транзакций. Когда транзакция с этим уровнем изоляции запускает UPDATE ... WHERE или DELETE ... WHERE, другим транзакциям, возможно, придется ждать. Транзакция может запустить SELECT ... FOR UPDATE и LOCK IN SHARE MODE, не заставляя другие транзакции ждать. См. ACID, isolation level, locking, REPEATABLE READ, SERIALIZABLE, transaction. read phenomena Явления, такие как грязные чтения, неповторимые чтения и призрачные чтения, которые могут произойти, когда транзакция читает данные, которые изменила другая транзакция. См. dirty read, non-repeatable read, phantom. READ UNCOMMITTED Уровень изоляции, который обеспечивает наименьшее количество защиты между транзакциями. Запросы используют стратегию блокировки, которая позволяет им продолжаться в ситуациях, где они обычно ждали бы другой транзакции. Однако, эта дополнительная работа идет за счет менее надежных результатов, включая данные, которые были изменены другими транзакциями и не переданы все же (известны как грязное чтение). Используйте этот уровень изоляции только очень осторожно и знайте, что результаты не могли бы быть последовательными или восстанавливаемыми, в зависимости от того, что другие транзакции делают в то же самое время. Как правило, транзакции с этим уровнем изоляции делают только запросы, не вставляют, обновляют или удаляют данные. См. ACID, dirty read, isolation level, locking, transaction. Чтение представления Внутренний снимок используется механизмом MVCC InnoDB. Определенные транзакции, в зависимости от их уровня изоляции видят значения данных, как они были в то время, когда транзакция (или в некоторых случаях, запрос) запускалась. Уровни изоляции, которые используют представление чтения: REPEATABLE READ, READ COMMITTED и READ UNCOMMITTED. См. isolation level, MVCC, READ COMMITTED, READ UNCOMMITTED, REPEATABLE READ, transaction. read-ahead Тип ввода/вывода, чтобы предварительно забрать группу страниц в буферный пул асинхронно, в ожидании, что эти страницы скоро будут необходимы. Линейный метод чтения вперед предварительно приносит все страницы одного экстента, основываясь на образцах доступа для страниц в предыдущем экстенте и является частью всех версий MySQL, начиная с InnoDB Plugin в MySQL 5.1. Случайный метод чтения вперед предварительно приносит все страницы для экстента, как только определенное число страниц от того же самого экстента находится в буферном пуле. Случайное чтение вперед не часть MySQL 5.5, но повторно введено в MySQL 5.6 под управлением опции innodb_random_read_ahead. См. buffer pool, extent, page. Транзакция только для чтения Тип транзакции, которая может быть оптимизирована для таблицы, устраняя часть расчетов, связанных с созданием чтения представления для каждой транзакции. Может только выполнить запросы чтения без блокировки. Это может быть запущено явно с синтаксисом START TRANSACTION READ ONLY или автоматически при определенных условиях. См. раздел 9.5.3. См. non-locking read, read view, transaction. Блокировка записи Блокировка на индексной записи. Например, SELECT c1 FOR UPDATE FROM t WHERE c1 = 10; препятствует тому, чтобы любая другая транзакция вставила, обновила или удалила строки, где значение t.c1 = 10. См. gap lock, lock, next-key lock. redo Данные, в модулях отчетов, зарегистрированных в журнале redo, когда запросы DML производят изменения в таблицах InnoDB. Это используется во время восстановления катастрофического отказа, чтобы исправить данные, написанные неполными транзакциями. Постоянно увеличивающееся значение LSN представляет совокупное количество данных, которые прошли через журнал. См. crash recovery, DML, LSN, redo log, transaction. Журнал redo Основанная на диске структура данных, используемая во время восстановления катастрофического отказа, чтобы исправить данные, написанные неполными транзакциями . Во время нормального функционирования это кодирует просьбы изменить табличные данные InnoDB, которые следуют из запросов SQL или низкого уровня требования API через интерфейсы NoSQL. Модификации, которые не закончили обновлять файлы с данными перед неожиданным завершением работы , переигрываются автоматически. Журнал физически представлен как ряд файлов, как правило, называемых ib_logfile0 и ib_logfile1. Данные в журнале закодированы с точки зрения затронутых записей, эти данные все вместе упоминаются как redo. Проход данных через журналы представлен постоянно увеличивающимся значением LSN . Оригинальный предел в 4GB на максимальный размер для журнала redo поднят до 512GB в MySQL 5.6.3. Дисковое расположение журнала под влиянием параметров конфигурации innodb_log_file_size , innodb_log_group_home_dir и (редко) innodb_log_files_in_group. Исполнение операций журнала затронуто буфером журнала, которым управляет опция innodb_log_buffer_size. См. crash recovery, data files, ib_logfile, log buffer, LSN, redo, shutdown, transaction. Избыточный формат строки Самый старый формат строки. До MySQL 5.0.3 это был единственный формат строки, доступный в InnoDB. С MySQL 5.0.3 до MySQL 5.7.8 формат строки по умолчанию COMPACT. С MySQL 5.7.9 формат строки по умолчанию определен опцией innodb_default_row_format, у которого есть настройка по умолчанию DYNAMIC. Вы можете все еще определить формат строки REDUNDANT для совместимости с более старым таблицами InnoDB. См. раздел 16.10.4. См. compact row format, file format, row format. Ссылочная целостность Метод поддержания данных всегда в последовательном формате, части ACID. В частности, данные в различных таблицах сохранены последовательными с помощью ограничений внешнего ключа, которые могут предотвратить изменения или автоматически размножить те изменения на все связанные таблицы. Связанные механизмы включают уникальное ограничение, которое препятствует тому, чтобы двойные значения были вставлены по ошибке, и ограничение NOT NULL, которое препятствует тому, чтобы пустые значения были вставлены по ошибке. См. ACID, FOREIGN KEY constraint, NOT NULL constraint, unique constraint. Относительный Важный аспект современных систем базы данных. Сервер базы данных кодирует и проводит в жизнь такие отношения, как непосредственные, "один ко многим", "многие к один" и уникальность. Например, у человека мог бы быть ноль, один или много номеров телефонов в базе данных адреса, единственный номер телефона мог бы быть связан с несколькими членами семьи. В финансовой базе данных человек мог бы быть обязан иметь точно одно удостоверение личности налогоплательщика, и любое удостоверение личности налогоплательщика могло быть связано только с одним человеком. Сервер базы данных может использовать эти отношения, чтобы препятствовать тому, чтобы неправильные данные были вставлены. Например, если значение, как объявляют, уникально, сервер может прекратить искать, как только первое соответствие найдено, и это может отклонить попытки вставить вторую копию того же самого значения. На уровне базы данных эти отношения выражены через особенности SQL, такие как столбцы в пределах таблицы, уникальное и NOT NULL ограничения, внешние ключи и различные виды операций соединения. Сложные отношения, как правило, вовлекают разделение данных больше, чем между одной таблицей. Часто данные нормализованы , чтобы двойные значения в отношениях "один ко многим" были сохранены только однажды. В математическом контексте отношения в пределах базы данных получены из теории множеств. Например, операторы OR и AND в WHERE представляют понятия союза и пересечения. См. ACID, constraint, foreign key, normalized. Тема В полнотекстовой функции поиска число, показывающее подобие между строкой поиска и данными в индексе FULLTEXT. Например, когда Вы ищете отдельное слово, то слово, как правило, более важно для строки, где происходит несколько раз в тексте, чем для строки, где это появляется только однажды. См. full-text search, FULLTEXT index. REPEATABLE READ Уровень изоляции по умолчанию для InnoDB. Это предотвращает любые строки, которые запрошены от изменения другими транзакциями, таким образом блокируя неповторимые чтения, но не призрачные чтения. Это использует умеренно строгую стратегию блокировки так, чтобы все запросы в пределах транзакции видели данные от того же самого снимка, то есть, данные, как это было в то время, когда транзакция запускалась. Когда транзакция с этим уровнем изоляции выполняет UPDATE ... WHERE, DELETE ... WHERE, SELECT ... FOR UPDATE и LOCK IN SHARE MODE, другим транзакциям, возможно, придется ждать. См. ACID, consistent read, isolation level, locking, phantom, SERIALIZABLE, transaction. Репликация Практика посылки изменений от основной базы данных одной или более ведомым базам данных , чтобы у всех баз данных были те же самые данные. У этого метода есть широкий диапазон использования, например, балансирование загрузки для лучшей масштабируемости, аварийное восстановление и обновления программного обеспечения тестирования и изменения конфигурации. Изменения могут послать между базой данных методами, названными основанная на строке и основанная на запросе репликация. См. row-based replication, statement-based replication. Восстановление Процесс помещения ряда резервных файлов от MySQL Enterprise Backup в место для использования MySQL. Эта работа может быть выполнена, чтобы установить поврежденную базу данных, возвратиться к некоторому более раннему моменту времени или (в контексте репликации), чтобы настроить новую ведомую базу данных. В MySQL Enterprise Backup эта работа выполнена опцией copy-back команды mysqlbackup. См. hot backup, MySQL Enterprise Backup , mysqlbackup command, prepared backup, replication. Отмена Команда SQL, которая заканчивает транзакцию, отменяя любые изменения, произведенные транзакцией. Это противоположность commit, которая делает постоянными любые изменения, сделанные в транзакции. По умолчанию MySQL использует опцию autocommit , которая автоматически передает после каждого запроса SQL. Вы должны изменить эти настройки прежде, чем Вы сможете использовать метод отмены. См. ACID, commit, transaction. Сегмент отмены Область хранения, содержащая журнал отмены , часть системного табличного пространства . См. system tablespace, undo log. Строка Логическая структура данных определена рядом столбцов . Ряд строк составляет таблицу. В пределах файлов с данными InnoDB каждая страница может содержать одну или более строк. Хотя InnoDB использует формат строки для последовательности с синтаксисом MySQL, формат строки это свойство каждой таблицы и относится ко всем строкам в той таблице. См. column, data files, page, row format, table. Формат строки Дисковый формат хранения для строк таблицы InnoDB. Поскольку InnoDB получает новые способности, такие как сжатие, новые форматы строки введены, чтобы поддержать получающиеся усовершенствования эффективности хранения и работы. Формат строки таблицы InnoDB определен опцией ROW_FORMAT или innodb_default_row_format (с MySQL 5.7.9). Форматы строки включают REDUNDANT, COMPACT, COMPRESSED и DYNAMIC. Чтобы просмотреть формат строки таблицы InnoDB, Вы можете скомандовать SHOW TABLE STATUS или запросить INFORMATION_SCHEMA.INNODB_SYS_TABLES (в MySQL 5.6 или выше). См. compact row format, compressed row format, dynamic row format, file-per-table, fixed row format, general tablespace, redundant row format, row, system tablespace, table. Блокировка строки Блокировка, которая препятствует тому, чтобы строка была получена несовместимым способом другой транзакцией. Другие строки в той же самой таблице могут быть свободно написаны другими транзакциями. Это тип блокировки операциями DML на таблицах InnoDB. Контраст с табличными блокировками, используемыми MyISAM, или во время операций DDL на таблицах InnoDB, которые не могут быть сделаны с DDL онлайн : те блокировки блокируют параллельный доступ к таблице. См. DDL, DML, InnoDB, lock, locking, online DDL, table lock, transaction. Основанная на строке репликация Форма репликации, где события размножены от главного сервера, определяющего, как изменить отдельные строки на ведомом сервере. Безопасно использовать для всех настроек опции innodb_autoinc_lock_mode. См. auto-increment locking, innodb_autoinc_lock_mode , master server, replication, slave server, statement-based replication. Блокировка на уровне строки Механизм блокировки, используемый для таблиц InnoDB, полагаясь на блокировки строки, а не табличные блокировки. Многократные транзакции могут изменить ту же самую таблицу одновременно. Только если две операционных попытки изменить ту же самую строку предприняты, одна из транзакций ждет завершения другой (и снятия ее блокировки строки). См. InnoDB, locking, row lock, table lock, transaction. rw-lock Низкоуровневый объект, чтобы представить и провести в жизнь блокировки совместно используемого доступа к внутренним структурам данных в памяти после определенных правил. Контраст с mutexes, который нужен, чтобы представить и провести в жизнь эксклюзивный доступ к внутренним структурам данных в памяти. Mutexes и rw-блокировки известны все вместе как latches. Типы rw-lock включают s-locks (совместно используемые блокировки), x-locks (исключительные блокировки) и sx-locks (совместно используемо-исключительные блокировки). s-lock обеспечивает доступ чтения к общему ресурсу. x-lock обеспечивает доступ на запись к общему ресурсу, не разрешая непоследовательные чтения другими потоками. sx-lock обеспечивает доступ на запись к общему ресурсу, разрешая непоследовательные чтения другими потоками. sx-locks были введены в MySQL 5.7, чтобы оптимизировать параллелизм и улучшить масштабируемость. Следующая матрица суммирует совместимость типов rw-блокировок. S SX X S Совместимы Совместимы Конфликтуют SX Совместимы Конфликтуют Конфликтуют X Конфликтуют Конфликтуют Конфликтуют См. latch, lock, mutex, Performance Schema. S savepoint Savepoint помогают осуществить вложенные транзакции . Они могут использоваться, чтобы обеспечить контекст операциям на таблицах, которые являются частью большей транзакции. Например, планирование поездки в системе резервирования могло бы вовлечь заказ нескольких различных полетов, если желаемый полет недоступен, Вы могли бы отменить изменения, вовлеченные в заказ, не отменяя более ранние полеты, которые были успешно заказаны. См. rollback, transaction. Масштабируемость Способность добавить больше работы и выпустить больше одновременных запросов к системе, без внезапного понижения работы из-за превышения пределов системных ресурсов. Архитектура программного обеспечения, конфигурация аппаратных средств, кодирование приложения и тип рабочей нагрузки играют роль в масштабируемости. Когда система достигает своей максимальной мощности, популярные методы для того, чтобы увеличить масштабируемость это увеличение существующих аппаратных средств или программного обеспечения и добавить новые серверы и больше экземпляров MySQL. Часто соединяется с доступностью как критические аспекты крупномасштабного развертывания. См. availability, scale out, scale up. Масштаб Метод для того, чтобы увеличить масштабируемость , добавляя новые серверы и больше экземпляров MySQL. Например, настраивая репликацию, MySQL Cluster, объединение соединения или другие особенности, которые распространяют работу на группу серверов. См. scalability, scale up. Расширение Метод для того, чтобы увеличить масштабируемость , увеличивая возможности существующих аппаратных средств или программного обеспечения. Например, увеличивая память на сервере и корректируя связанные с памятью параметры innodb_buffer_pool_size и innodb_buffer_pool_instances. См. scalability, scale out. Схема Концептуально схема это ряд взаимосвязанных объектов базы данных, таких как таблицы, столбцы таблицы, типы данных столбцов, индекы, внешние ключи и так далее. Эти объекты соединены через синтаксис SQL, потому что столбцы составляют таблицы, внешние ключи обращаются к таблицам и столбцам и так далее. Идеально они также соединены логически, сотрудничая как часть объединенного приложения или гибкой структуры. Например, базы данных information_schema и performance_schema используют "схему" с их именами, чтобы подчеркнуть тесные отношения между таблицами и столбцами, которые они содержат. В MySQL, физически, схема это синоним базы данных. Вы можете заменить ключевое слово SCHEMA на DATABASE в MySQL-синтаксисе SQL, например, используя CREATE SCHEMA вместо CREATE DATABASE . Некоторые другие продукты базы данных проводят различия. Например, в продукте базы данных Oracle Database schema представляет только часть базы данных: таблицы и другие объекты принадлежат единственному пользователю. См. database, ib-file set, INFORMATION_SCHEMA, Performance Schema. SDI Сокращение от serialized dictionary information . См. Serialized Dictionary Information (SDI). Поисковый индекс В MySQL запросы полнотекстового поиска используют специальный индекс FULLTEXT. В MySQL 5.6.4 и выше InnoDB и MyISAM поддерживают индексы FULLTEXT, ранее они были доступны только для таблиц MyISAM. См. full-text search, FULLTEXT index. Вторичный индекс Тип индекса InnoDB, который представляет подмножество столбцов таблицы. У таблицы InnoDB может быть ноль, один или много вторичных индексов. Контраст с кластеризируемым индексом, который требуется для каждой таблицы InnoDB и хранит данные для всех столбцов таблицы. Вторичный индекс может использоваться, чтобы удовлетворить запросы, которые только требуют значений от индексированных столбцов. Для более сложных запросов это может использоваться, чтобы идентифицировать соответствующие строки в таблице, которые тогда получены посредством поисков, используя кластеризируемый индекс. Создание и удаление вторичного индекса традиционно вовлекает существенные издержки от копирования всех данных в таблице InnoDB. fast index creation в InnoDB Plugin делает CREATE INDEX и DROP INDEX намного быстрее для вторичных индексов. См. clustered index, Fast Index Creation, index. Сегмент Подразделение в пределах табличного пространства InnoDB. Если табличное пространство походит на каталог, сегменты походят на файлы в пределах того каталога. Сегмент может вырасти. Могут быть созданы новые сегменты. Например, в пределах табличного пространства file-per-table табличные данные находятся в одном сегменте, и каждый связанный индекс находится в его собственном сегменте. Системное табличное пространство содержит много различных сегментов, потому что оно может содержать много таблиц и их связанных индексов. Системное табличное пространство также включает один или более сегментов отмены, используемых для журналов отмены. Сегменты растут и сжимаются, поскольку данные вставлены и удалены. Когда сегмент нуждается в большем количестве места, он расширен на экстент (1 мегабайт) за один раз. Точно так же сегмент освобождает один экстент, когда все данные в том экстенте больше не необходимы. См. extent, file-per-table, rollback segment, system tablespace, tablespace, undo log. Селективность Свойство распределения данных, число отличных значений в столбце (его количество элементов), разделенное на число записей в таблице. Высокая селективность означает, что значения столбцов относительно уникальны и могут быть эффективно получены посредством индекса. Если Вы (или оптимизатор запросов) можете предсказать, что WHERE соответствует только небольшое число (или пропорция) строк в таблице, полный запрос имеет тенденцию быть эффективным, если это оценивает тот тест сначала, используя индекс. См. cardinality, query. Полупоследовательное чтение Тип работы чтения, используемой для запроса UPDATE, который является комбинацией read committed и consistent read. Когда UPDATE исследует строку, которая уже заблокирована, InnoDB возвращает последнюю переданную версию в MySQL так, чтобы MySQL мог определить, соответствует ли строка WHERE условию UPDATE. Если строка соответствует (должна быть обновлена), MySQL читает строку снова, и на сей раз InnoDB или блокирует ее или ждет блокировки на ней. Этот тип работы чтения может произойти только, когда у транзакции есть уровень изоляции read committed, или когда включена опция innodb_locks_unsafe_for_binlog, которая удалена в MySQL 8.0. См. consistent read, isolation level, READ COMMITTED. SERIALIZABLE Уровень изоляции, который использует самую консервативную стратегию блокировки, чтобы препятствовать тому, чтобы любые другие транзакции вставили или изменили данные, которые были считаны этой транзакцией, пока это не закончено. Этим путем тот же самый запрос может быть выполнен много раз в пределах транзакции и быть уверен, что получил тот же самый набор результатов каждый раз. Любая попытка изменить данные, которые были переданы другой транзакцией, начиная с запуска текущей транзакции, заставляет текущую транзакцию ждать. Это уровень изоляции по умолчанию, определенный стандартом SQL. Практически, эта степень строгости редко необходима, таким образом, уровень изоляции по умолчанию для InnoDB следующее самое строгое значение, repeatable read. См. ACID, consistent read, isolation level, locking, REPEATABLE READ, transaction. Serialized Dictionary Information (SDI) Метаданные об объекте словаря в преобразованном в последовательную форму BLOB. См. file-per-table, general tablespace, system tablespace, tablespace. Сервер Тип программы, которая работает непрерывно, ожидая запросы из другой программы (клиента). Поскольку часто весь компьютер посвящен выполнению разных серверов (таких как сервер базы данных, веб-сервер, сервер приложений или некоторая их комбинация), термин сервер может также отнестись к компьютеру, который выполняет программное обеспечение сервера. См. client, mysqld. Совместно используемая блокировка Своего рода блокировка, которая позволяет другим транзакциям читать заблокированный объект, и также приобретать другие совместно используемые блокировки, но не писать этот объект. Противоположность исключительной блокировки. См. exclusive lock, lock, transaction. Совместно используемое табличное пространство Другой способ обратиться к системному табличному пространству. См. system tablespace. Контрольная точка Процесс сбрасывает на диск все грязные буферные страницы пула, чьи записи содержатся в определенной части журнала redo. Происходит прежде, чем InnoDB снова использует часть файла системного журнала, файлы системного журнала используются круговым способом. Как правило, происходит в рабочих нагрузках с интенсивной записью. См. dirty page, flush, redo log, workload. Завершение работы Процесс остановки сервера MySQL. По умолчанию этот процесс делает операции уборки для таблиц InnoDB, таким образом, он может замедлить закрытие, но быстро запустить позже. Если Вы пропускаете операции уборки, это быстро, но должно сделать уборку во время следующего перезапуска. Режимом завершения работы управляет опция innodb_fast_shutdown . См. fast shutdown, InnoDB, slow shutdown, startup. Ведомый сервер Часто сокращаемый к "ведомому устройству". Машина сервера базы данных в сценарии репликации, который получает изменения от другого сервера (ведущее устройство) и применяет те же самые изменения. Таким образом, это поддерживает то же самое содержание как ведущее устройство, хотя это могло бы несколько отстать. В MySQL ведомые серверы обычно используются в аварийном восстановлении, чтобы взять место главного сервера, который терпит неудачу. Они также обычно используются для того, чтобы проверить обновления программного обеспечения и новые настройки, чтобы гарантировать, что изменения конфигурации базы данных не вызывают проблемы с работой или надежностью. У ведомых серверов, как правило, есть высокие рабочие нагрузки, потому что они обрабатывают все операции DML, переданные от ведущего устройства, так же как пользовательские запросы. Чтобы гарантировать, что ведомые серверы могут применить изменения от ведущего устройства достаточно быстро, у них часто есть быстрые устройства ввода/вывода, достаточный центральный процессор и память, чтобы выполнить многократные экземпляры базы данных на том же самом ведомом сервере. Например, главный сервер мог бы использовать жесткий диск в то время, как ведомые серверы используют SSD. См. DML, replication, server, SSD. Медленный журнал запроса Тип журнала, используемого для исполнительной настройки запросов SQL, обработан сервером MySQL. Информация журнала хранится в файле. Вы должны активировать эту опцию, чтобы использовать это. Вы управляете, какие категории медленных запросов SQL зарегистрированы. Для получения дополнительной информации см. раздел 6.4.5. См. general query log, log. Медленное завершение работы Тип завершения работы, которое делает дополнительный сброс InnoDB перед завершением. Также известный как чистое завершение работы. Определен параметром конфигурации innodb_fast_shutdown=0 или командой SET GLOBAL innodb_fast_shutdown=0;. Хотя само завершение работы может занять больше времени, это время будет сэкономлено при последующем запуске. См. clean shutdown, fast shutdown, shutdown. Снимок Представление данных в определённое время, которое остается тем же самым, когда изменения переданы другими транзакциями. Используется определенными уровнями изоляции, чтобы позволить последовательные чтения. См. commit, consistent read, isolation level, transaction. Буфер сортировки Буфер, используемый для того, чтобы сортировать данные во время создания индекса InnoDB. Размер настроен опцией innodb_sort_buffer_size. ID пространства Идентификатор, используемый, чтобы уникально идентифицировать табличное пространство InnoDB в пределах экземпляра MySQL. ID для системного табличного пространства всегда ноль, это же самое ID относится ко всем таблицам в пределах системного табличного пространства или в пределах общего табличного пространства. У каждого табличного пространства file-per-table и общего табличного пространства есть свой собственный ID. С MySQL 5.6 Вы можете скопировать файлы табличного пространства между экземплярами при использовании мобильной особенности табличного пространства, используя FLUSH TABLES ... FOR EXPORT, ALTER TABLE ... DISCARD TABLESPACE и ALTER TABLE ... IMPORT TABLESPACE. Информация должна была корректировать ID в файле .cfg , который Вы копируете наряду с табличным пространством. См. раздел 16.7.6. См. .cfg file, file-per-table, general tablespace, .ibd file, system tablespace, tablespace, transportable tablespace. Редкий файл Тип файла, который использует пространство файловой системы более эффективно при записи метаданных, представляющих пустые блоки вместо того, чтобы писать фактическое пустое место. InnoDB прозрачная особенность сжатия страницы полагается на эту поддержку, см. раздел 16.9.2. См. hole punching, transparent page compression. spin Тип ожидания, которая непрерывно проверяет, становится ли ресурс доступным. Этот метод используется для ресурсов, которые, как правило, проводятся только в течение кратких периодов, где более эффективно ждать, чем поместить поток в спячку и выполнить переключение контекста. Если ресурс не становится доступным в пределах короткого времени, цикл прекращается, и используется другой метод ожидания. См. latch, lock, mutex, wait. SQL Structured Query Language, который является стандартным для того, чтобы выполнить операции базы данных. Часто разделен на категории DDL, DML и запросы. MySQL включает некоторые дополнительные категории запроса, такие как репликация . См. DDL, DML, query, replication. SSD Сокращение от "solid-state drive". Тип устройства хранения данных с различными техническими характеристиками, чем традиционный жесткий диск (HDD): меньшая емкость хранения, быстрее для случайных чтений, никаких движущихся частей. Его технические характеристики могут влиять на пропускную способность нагрузок disk-bound. См. disk-bound, SSD. Запуск Процесс запуска сервера MySQL. Как правило, сделан одной из программ, перечисленных в разделе 5.3. См. shutdown. Основанная на запросе репликация Форма репликации, где запросы SQL посылают из главного сервера и переиграны на ведомом сервере. Требуется некоторая работа с установкой для опции innodb_autoinc_lock_mode, чтобы избежать потенциальных проблем синхронизации с блокировкой auto-increment . См. auto-increment locking, innodb_autoinc_lock_mode , master server, replication, row-based replication, slave server. Статистика Ориентировочные стоимости, касающиеся каждой таблицы и индекса InnoDB, используемые, чтобы создать эффективный план выполнения запроса. Основные значения это количество элементов (число отличных значений) и общее количество строк таблицы или индексных записей. Статистические данные для таблицы представляют данные в индексе primary key . Статистические данные для вторичного индекса представляют строки, покрытые этим индексом. Значения оценены, а не посчитаны точно, потому что в любой момент различные транзакции могут вставлять и удалять строки из той же самой таблицы. Чтобы препятствовать частому повторному вычислению значений, Вы можете включить постоянную статистику , где значения сохранены в системные таблицы InnoDB и освежены только, когда Вы командуете ANALYZE TABLE. Вы можете управлять, как обработаны NULL, вычисляя статистику через опцию innodb_stats_method. Другие типы статистики доступны для объектов базы данных и деятельности базы данных через таблицы INFORMATION_SCHEMA и PERFORMANCE_SCHEMA. См. cardinality, index, INFORMATION_SCHEMA, NULL, Performance Schema, persistent statistics, primary key, query execution plan, secondary index, table, transaction. Происхождение Способность искать различные изменения слова, основанного на общем слове корня, такие как исключительный, множественный и будущее время глагола. Эта функция в настоящее время поддерживается в MyISAM с фнукцией full-text search, но не в индексах FULLTEXT для InnoDB. См. full-text search, FULLTEXT index. stopword В индексе FULLTEXT слово, которое считают настольуо распространенным или тривиальным, что оно опущено в поисковом индексе и проигнорировано в запросах поиска. Различные настройки конфигурации управляют stopword для таблиц InnoDB и MyISAM, см. раздел 13.9.4. См. FULLTEXT index, search index. Механизм хранения Компонент базы данных MySQL, который выполняет низкоуровневую работу хранения, обновления и запросов данных. В MySQL 5.5 и выше InnoDB механизм хранения по умолчанию для новых таблиц вместо MyISAM. Различные механизмы хранения разработаны с различными факторами. Каждый механизм хранения управляет определенными таблицами, таким образом, мы обращаемся к таблицам InnoDB , MyISAM и т.д. MySQL Enterprise Backup оптимизирован для того, чтобы поддержать таблицы InnoDB. Это может также поддержать таблицы, обработанные MyISAM и другими механизмами хранения. См. InnoDB, MySQL Enterprise Backup , table type. Строгий режим Общее название установки, которой управляет опция innodb_strict_mode . Включение этой установки вызывает определенные условия, которые обычно обрабатываются как предупреждения, чтобы считаться ошибками. Например, определенные недопустимые комбинации опций, связанных с форматом файла и форматом строки, которые обычно производят предупреждение и продолжаются со значениями по умолчанию, теперь вызывают ошибку в CREATE TABLE. У MySQL также есть что-то названное строгим режимом. См. file format, innodb_strict_mode, row format. Подсписок В пределах структуры списка, которая представляет буферный пул, страницы, которые относительно стары и относительно новые, представлены различными частями списка. Ряд параметров управляет размером этих частей и точкой раздела между новыми и старыми страницами. См. buffer pool, eviction, list, LRU. supremum Псевдозапись в индексе, представляет промежуток выше самого большого значения в этом индексе. Если у транзакции есть такой запрос, как SELECT ... FOR UPDATE ... WHERE col > 10; и самое большое значение в столбце 20, блокировка на записи supremum препятствует тому, чтобы другие транзакции вставили еще большие значения, такие как 50, 100 и так далее. См. gap, infimum record, pseudo-record. Суррогатный ключ Синоним для synthetic key. См. synthetic key. Синтетический ключ Индексированный столбец, как правило первичный ключ , где значения назначены произвольно. Часто использует auto-increment. Обрабатывая значение как абсолютно произвольное, Вы можете избежать чрезмерно рестриктивных правил и дефектных предположений приложения. Числовые значения также производят более короткие значения предсказуемой длины. Например, хранить числовые коды, означающие "Road", "Boulevard", "Expressway" и так далее более эффективно с точки зрения места, чем повторение тех строк много раз. Также известный как surrogate key. См. auto-increment, natural key, primary key, surrogate key. Системное табличное пространство Один или более файлов с данными (файлы ibdata), содержащий метаданные для InnoDB-связанных объектов, и области хранения для одного или более журналов отмены, буфера изменения и буфера doublewrite. Это может также содержать таблицу и индексные данные для таблиц InnoDB, если таблицы были составлены в системном табличном пространстве вместо file-per-table или общих табличных пространствах. Данные и метаданные в системном табличном пространстве относятся ко всем базам данных в экземпляре MySQL. До MySQL 5.6.7 значение по умолчанию должно было сохранить все таблицы InnoDB и индексы в системном табличном пространстве, часто заставляя этот файл стать очень большим. Поскольку системное табличное пространство никогда не сжимается, проблемы хранения могли возникнуть, если бы большое количество временных данных было загружено и затем удалено. В MySQL 8.0 значение по умолчанию это режим file-per-table, где каждая таблица и его связанный индекс сохранены в отдельном файле .ibd. Это новое значение по умолчанию облегчает использовать функции InnoDB, которые полагаются на форматы строки DYNAMIC и COMPRESSED, например, сжатие, хранение вне страницы длинных значений столбцов переменной длины и большие индексные ключевые префиксы (innodb_large_prefix). Опция innodb_undo_tablespaces позволяет Вам конфигурировать отдельные файлы табличного пространства для журналов отмены. Эти файлы все еще считаются частью системного табличного пространства. Хранение всех табличных данных в системном табличном пространстве или в отдельном .ibd имеет значение для управления хранением вообще. MySQL Enterprise Backup мог бы поддержать маленький набор больших файлов или много меньших файлов. На системах с тысячами таблиц, операции файловой системы для тысяч файлов .ibd могут вызвать узкие места. InnoDB добавил общие табличные пространства в MySQL 5.7.6, которые также представлены файлами .ibd. Общие табличные пространства это совместно используемые табличные пространства, создаваемые CREATE TABLESPACE. Они могут быть созданы за пределами каталога данных MySQL, способны к хранению многих таблиц и поддерживают таблицы всех форматов строки. См. change buffer, compression, data dictionary, database, doublewrite buffer, dynamic row format, file-per-table, .ibd file, ibdata file, innodb_file_per_table, instance, MySQL Enterprise Backup , tablespace, undo log. T Таблица Каждая таблица MySQL связана с особым механизмом хранения. У таблиц InnoDB есть особые физические и логические характеристики, которые затрагивают работу, масштабируемость, резервное копирование и разработку приложений. С точки зрения хранения файла таблица InnoDB принадлежит к одному из следующих типов табличного пространства: Совместно используемое системное табличное пространство InnoDB, которое состоит из одного или больше файлов .ibdata. Табличное пространство file-per-table, состоявшее из отдельных файлов .ibd. Совместно используемое общее табличное пространство, состоявшее из отдельных файлов .ibd. Добавлены в MySQL 5.7.6. Файлы с данными .ibd содержат таблицу и индексные данные. Таблицы InnoDB, составленные в табличных пространствах file-per-table, могут использовать формат строки DYNAMIC или COMPRESSED. Эти форматы строки активируют такие опции InnoDB, как сжатие, столбцы вне страницы и префиксы индексного ключа (см. innodb_large_prefix). Общие табличные пространства поддерживают все форматы строки. Системное табличное пространство поддерживает таблицы, которые используют форматы строки REDUNDANT, COMPACT и DYNAMIC. Системная поддержка табличного пространства для формата строки DYNAMIC была добавлена в MySQL 5.7.6. Строки таблицы InnoDB организованы в индексированную структуру, известную как кластеризируемый индекс, с записями, сортированными основываясь на столбцах primary key. Доступ к данным оптимизирован для запросов, которые фильтруют и сортируют на столбцах первичного ключа, и каждый индекс содержит копию связанных столбцов первичного ключа для каждой записи. Изменение значений для любого из столбцов первичного ключа является дорогой работой. Таким образом важный аспект табличного проекта InnoDB это выбрать первичный ключ со столбцами, которые используются в самых важных запросах, и хранение короткого первичного ключа с редким изменением значений. См. backup, clustered index, compact row format, compressed row format, compression, dynamic row format, Fast Index Creation, file-per-table, .ibd file, index, off-page column, primary key, redundant row format, row, system tablespace, tablespace. Табличная блокировка Блокировка, которая препятствует тому, чтобы любая другая транзакция получила доступ к таблице. InnoDB прилагает значительное усилие, чтобы сделать такие блокировки ненужными, при использовании таких методов, как online DDL, блокировки строки и последовательные чтения для того, чтобы обработать запросы и DML. Вы можете создать такую блокировку через SQL использованием LOCK TABLE, один из шагов в перемещении от других систем базы данных или механизмов хранения MySQL должен удалить такие запросы везде, где можно. См. consistent read, DML, lock, locking, online DDL, query, row lock, table, transaction. table scan См. full table scan. table statistics См. statistics. Табличный тип Синоним для механизма хранения. Мы обращаемся к таблицам InnoDB, MyISAM и т.д. См. InnoDB, storage engine. Табличное пространство Файл с данными, который может содержать данные для одной или более таблиц с индексами . Системное табличное пространство содержит таблицы, которые составляют словарь данных и до MySQL 5.6 все другие таблицы InnoDB по умолчанию. Опция innodb_file_per_table, которая включена по умолчанию в MySQL 5.6 и выше, позволяет таблицам создаваться в табличных пространствах file-per-table с отдельным файлом данных для каждой таблицы. Включение innodb_file_per_table делает доступными другие особенности MySQL, такие как табличное сжатие и мобильные табличные пространства. См. раздел 16.7.4. MySQL Cluster также группирует свои таблицы в табличные пространства. См. MySQL Cluster Disk Data Objects. См. compressed row format, data dictionary, data files, file-per-table, general tablespace, index, innodb_file_per_table, system tablespace, table. Словарь табличного пространства Словарь табличного пространства существует в постоянном табличном пространстве InnoDB. Это хранит Serialized Dictionary Information (SDI) для объектов в пределах табличного пространства. См. data dictionary, file-per-table, .frm file, general tablespace, .ibd file, system tablespace, tablespace. Временная таблица Таблица, данные которой не должны быть действительно постоянными. Например, временные таблицы могли бы использоваться в качестве областей хранения для промежуточных результатов в сложных вычислениях или преобразованиях, эти промежуточные данные не должны быть восстановлены после катастрофического отказа. Продукты базы данных могут взять различные ярлыки, чтобы улучшить исполнение операций на временных таблицах, будучи менее скрупулезными в плане записи данных на диск и других мер, чтобы защитить данные через перезапуски. Иногда сами данные удалены автоматически в установленное время, например, когда транзакция или сеанс заканчивается. С некоторыми продуктами базы данных сама таблица удалена автоматически также. См. table. Временное табличное пространство Табличное пространство для несжатых временных таблиц и связанных объектов InnoDB, введенное в MySQL 5.7.1. Опция конфигурационного файла innodb_temp_data_file_path позволяет пользователям определять относительный путь для временного файла с данными табличного пространства. Если innodb_temp_data_file_path не определена, поведение по умолчанию должно создать единственный автомасштабируемый файл в 12MB с именем ibtmp1 в каталоге данных, рядом с системными файлами табличного пространства ibdata. Временное табличное пространство обновлено при каждом запуске сервере и получает динамически произведенное ID, которое помогает избежать конфликтов с существующими ID. Временное табличное пространство не может находиться на сыром устройстве. В запуске отказывают, если временное табличное пространство не может быть создано. Временное табличное пространство удалено при нормальном завершении работы или прерванной инициализации. Временное табличное пространство не удалено, когда катастрофический отказ происходит. В этом случае администратор базы данных может удалить временное табличное пространство вручную или перезапустить сервер с той же самой конфигурацией, которая удаляет и обновляет временное табличное пространство. См. ibtmp file. Текстовый набор Набор столбцов, включенных в индекс FULLTEXT . См. FULLTEXT index. Поток Модуль обработки, которая, как правило, более легка, чем процесс, учитывая больший параллелизм. См. concurrency, master thread, process, Pthreads. Порванная страница Состояние ошибки, которое может произойти из-за комбинации конфигурации устройства ввода/вывода и отказа аппаратных средств. Если данные выписаны в кусках, меньших чем размер страницы InnoDB (по умолчанию 16KB), отказ аппаратных средств в момент записи мог привести к только части страницы, сохраненной на диск. Буфер doublewrite принимает меры против этой возможности. См. doublewrite buffer. TPS Сокращение от "transactions per second", модуль измерения, иногда используется в точках отсчета. Его значение зависит от рабочей нагрузки, представленной особым оценочным испытанием, объединенным с факторами, которыми Вы управляете, такие как пропускная способность аппаратных средств и конфигурация базы данных. См. transaction, workload. Транзакция Транзакции это атомные единицы работы, которые могут быть переданы или отменены. Когда транзакция производит многократные изменения в базе данных, или все изменения преуспевают, когда транзакция передана, или все изменения отменены, когда транзакция отменена. У транзакций базы данных, как осуществлено InnoDB, есть свойства, которые все вместе известны как ACID. См. ACID, commit, isolation level, lock, rollback. ID транзакции Внутренняя область, связанная с каждой строкой. Эта область физически изменена INSERT, UPDATE и DELETE, чтобы сделать запись, какая транзакция заблокировала строку. См. implicit row lock. Прозрачное сжатие страницы Особенность в MySQL 5.7.8 и выше, которая разрешает сжатие на уровне страницы для таблиц InnoDB, которые находятся в табличных пространствах file-per-table. Сжатие страницы включено, определяя признак COMPRESSION в CREATE TABLE или ALTER TABLE. См. раздел 16.9.2. См. file-per-table, hole punching, sparse file. Мобильное табличное пространство Особенность, которая позволяет табличному пространству быть перемещенным от одного экземпляра в другой. Традиционно это не было возможно для табличных пространств InnoDB, потому что все табличные данные были частью системного табличного пространства. В MySQL 5.6 и выше FLUSH TABLES ... FOR EXPORT готовит таблицу InnoDB к тому, что она будет скопирована на другой сервер, выполнение ALTER TABLE ... DISCARD TABLESPACE и ALTER TABLE ... IMPORT TABLESPACE на другом сервере приносит скопированный файл с данными. Отдельный файл .cfg, скопированный наряду с файлом .ibd, используется, чтобы обновить табличные метаданные (например, space ID), см. раздел 16.7.6. См. .ibd file, space ID, system tablespace, tablespace. Поиск неисправностей Ресурсы для того, чтобы расследовать надежность InnoDB и исполнительные проблемы включают таблицы Information Schema. truncate Операция DDL, которая удаляет все содержание таблицы и связанный индекс. Хотя концептуально у этого есть тот же самый результат, как у DELETE без WHERE, это работает по-другому негласно: InnoDB составляет новую пустую таблицу, удаляет старую таблицу, затем переименовывает новую таблицу. Поскольку это работа DDL, это не может быть отменено. Если таблица, являющаяся усеченной, содержит внешние ключи, которые ссылаются на другую таблицу, работа усечения использует более медленный метод работы, удаляя одну строку за один раз так, чтобы соответствующие строки в таблице, на которую ссылаются, могли быть удалены как необходимо любым параметром ON DELETE CASCADE. MySQL 5.5 и выше не позволяют эту более медленную форму и возвращают ошибку вместо этого, если внешние ключи вовлечены. В этом случае используйте DELETE. См. DDL, drop, foreign key, rollback. tuple Технический термин, определяющий упорядоченный набор элементов. Это абстрактное понятие, используемое в формальных обсуждениях теории базы данных. В области базы данных кортежи обычно представляются столбцами строки таблицы. Они могли также быть представлены наборами результатов запросов, например, запросы, которые получали только некоторые столбцы таблицы, или столбцы от таблиц, к которым присоединяются. См. cursor. Двухфазовая передача Работа, которая является частью распределенной транзакции под спецификацией XA . Иногда сокращаемая как 2PC. Когда многократные базы данных участвуют в транзакции, или все базы данных передают изменения, или все базы данных отменяют изменения. См. commit, rollback, transaction, XA. U Отмена Данные, которые поддержаны в течение жизни транзакции , делая запись всех изменений так, чтобы они могли быть отменены в случае работы операции отмены. Это сохранено в журнале отмены в пределах системного табличного пространства или в отдельных табличных пространствах отмены. См. rollback, rollback segment, system tablespace, transaction, undo log, undo tablespace. Буфер отмены См. undo log . Журнал отмены Область хранения, которая хранит копии данных, измененные активными транзакциями. Если другая транзакция должна видеть оригинальные данные (как часть последовательной работы чтения), неизмененные данные получены от этой области хранения. По умолчанию эта область физически часть системного табличного пространства. В MySQL 5.6 и выше Вы можете использовать опции innodb_undo_tablespaces и innodb_undo_directory , чтобы разделить это на один или более отдельных файлов табличного пространства, табличные пространства отмены произвольно сохранены на другом устройстве хранения данных, таком как SSD. Журнал отмены разделен на отдельные части: буфер отмены вставки и буфер отмены обновления. См. consistent read, rollback segment, SSD, system tablespace, transaction, undo tablespace. Табличное пространство отмены Один из ряда файлов, содержащих журнал отмены , когда журнал отмены отделен от системного табличного пространства, используя опции innodb_undo_tablespaces и innodb_undo_directory. Только для MySQL 5.6 и выше. См. system tablespace, undo log. Уникальное ограничение Своего рода ограничение, которое утверждает, что столбец не может содержать двойные значения. С точки зрения относительной алгебры это используется, чтобы определить отношения 1 к 1. Для эффективности в проверке, может ли значение быть вставлено (то есть, значение не существует в столбце), уникальное ограничение поддержано основным уникальным индексом . См. constraint, relational, unique index. Уникальный индекс Индекс на столбце или наборе столбцов, у которых есть уникальное ограничение. Поскольку индексирование, как известно, не содержит любые двойные значения, определенные виды поисков и операций более эффективны, чем в нормальном индексе. Большинство поисков для этого типа индекса должны просто определить, существует ли определенное значение или нет. Число значений в индексе является тем же самым, как число строк в таблице, или по крайней мере число строк с ненулевыми значениями для связанных столбцов. Оптимизация буферизации изменения не относится к уникальному индексу. Как обходное решение, Вы можете временно установить unique_checks=0 в то время, как выполняется оптовая загрузка данных в таблицу InnoDB. См. cardinality, change buffering, unique constraint, unique key. Уникальный ключ Набор столбцов (один или больше) уникального индекса. Когда Вы можете определить WHERE, которое соответствует точно одной строке, и запрос может использовать связанный уникальный индекс, поиск и обработка ошибок могут быть выполнены очень эффективно. См. cardinality, unique constraint, unique index. V Тип переменной длины Тип данных переменной длины. Типы VARCHAR, VARBINARY, BLOB и TEXT переменной длины. См. раздел 12.8. InnoDB рассматривает CHAR как тип переменной длины, если таблица составлена, используя формат строки COMPACT, DYNAMIC или COMPRESSED, и значение столбца CHAR больше чем или равно 768 байтам, которые могут произойти, если максимальная длина байта набора символов больше 3, как это с обстоит с utf8mb4. См. row format. Жертва Транзакция, которая автоматически выбрана, чтобы быть отмененной, когда тупик обнаружен. InnoDB отменяет транзакцию, которая обновила наименьшее количество строк. См. deadlock, deadlock detection, innodb_lock_wait_timeout. Виртуальный столбец См. generated virtual column. Виртуальный индекс Виртуальный индекс, вторичный индекс на одном или более произведенных виртуальных столбцов или на комбинации произведенных виртуальных столбцов и непроизведенных виртуальных столбцов. Для получения дополнительной информации см. раздел 14.1.15.6. См. base column, generated stored column , generated virtual column. W Ожидание Когда работа, такая как приобретение блокировки , mutex или latch , не может быть немедленно завершена, InnoDB ждет и пробует снова. Механизм для того, чтобы сделать паузу достаточно тщательно продуман, так что у этой работы есть свое собственное имя, wait. Отдельные потоки делают паузу, используя комбинацию внутреннего планирования InnoDB, вызова операционной системы wait(), и короткой продолжительности циклов spin. На системах с тяжелой нагрузкой и многими транзакциями, Вы могли бы использовать вывод SHOW INNODB STATUS, чтобы определить, проводят ли потоки слишком много времени ожидая, и если это так, как Вы можете улучшить параллелизм. См. concurrency, latch, lock, mutex, spin. Теплое резервное копирование Резервное копирование в то время, как база данных работает, но это ограничивает некоторые операции базы данных во время резервного процесса. Например, таблицы могли бы стать только для чтения. Для занятых приложений и веб-сайтов, Вы могли бы предпочесть горячее резервное копирование. См. backup, cold backup, hot backup. Разогрев Выполнение системы при типичной рабочей нагрузке в течение некоторого времени после запуска, чтобы буферный пул и другие области памяти были заполнены, поскольку они находились бы в нормальнымх условиях. Этот процесс происходит естественно в течение долгого времени, когда сервер MySQL перезапущен или подвергнут новой рабочей нагрузке. Начиная с MySQL 5.6, Вы можете ускорить процесс разминки, устанавливая переменные конфигурации innodb_buffer_pool_dump_at_shutdown=ON и innodb_buffer_pool_load_at_startup=ON, чтобы возвращать содержание буферного пула в память после перезапуска. Как правило, Вы выполняете рабочую нагрузку в течение некоторого времени, чтобы нагреть буферный пул прежде, чем выполнить тесты производительности и гарантировать последовательные результаты, иначе работа могла бы быть искусственно низкой во время первого показа. См. buffer pool, workload. Windows Встроенный механизм хранения InnoDB и InnoDB Plugin поддержаны на всех версиях Microsoft Windows как сервер MySQL. У MySQL Enterprise Backup есть более всесторонняя поддержка систем Windows, чем у InnoDB Hot Backup, который это заменяет. См. InnoDB, MySQL Enterprise Backup , plugin. Рабочая нагрузка Комбинация и объем SQL и других операций базы данных, выполненных приложением базы данных во время типичного или пикового использования. Вы можете подвергнуть базу данных особой рабочей нагрузке во время исполнительного тестирования, чтобы идентифицировать узкие места или во время планирования мощностей. См. bottleneck, CPU-bound, disk-bound, SQL. Объединение записи Метод оптимизации, который уменьшает операции записи, когда грязные страницы сбрасываются из буферного пула InnoDB. Если строка в странице обновлена многократно или многие строки на той же самой странице обновлены, все те изменения сохранены к файлам с данными в одном запросе на запись, а не для каждого изменения. См. buffer pool, dirty page, flush. X XA Стандартный интерфейс для того, чтобы скоординировать распределенные транзакции, позволяя многократным базам данных участвовать в транзакции, поддерживая ACID. См. раздел 14.3.7. XA Distributed Transaction support включена по умолчанию. Если Вы не используете эту функцию, Вы можете отключить опцию innodb_support_xa, избегая исполнения дополнительного fsync для каждой транзакции. См. commit, transaction, two-phase commit. Y Свежие Характеристика страницы в буферном пуле InnoDB, имеющяя в виду, что к это недавно был получен доступ, и страница перемещена в пределах буферной структуры данных пула, чтобы это скоро не сбросилось алгоритмом LRU. Этот термин использован в некоторых информационных именах столбцов схемы таблиц, связанных с буферным пулом. См. buffer pool, flush, INFORMATION_SCHEMA, LRU, page.

Поиск На сайте В Яндексе

Вы можете направить письмо администратору этой странички, Алексею Паутову.