RussianLDP Рейтинг@Mail.ru
WebMoney: 
WMZ Z294115950220 
WMR R409981405661 
WME E134003968233 		 Visa 
4274 3200 2453 6495 

Глава 15. Словарь данных MySQL

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

Эта глава описывает основные особенности, выгоду, различия в использовании и ограничения словаря данных. Для информации о других возможностях словаря данных, обратитесь к разделу Data Dictionary Notes ресурса MySQL 8.0.0 Release Notes.

InnoDB продолжает использовать собственный словарь данных в MySQL 8.0.0.

Выгода словаря данных MySQL включает:

  • Простота централизованной схемы словаря данных, которая однородно хранит данные словаря. См. раздел 15.1.

  • Удаление основанного на файлах хранения метаданных. См. раздел 15.2.
  • Транзакционное, защищенное от катастрофического отказа хранение данных в словаре. См. раздел 15.3.
  • Централизованное кэширование для объектов словаря. См. раздел 15.4.
  • Более простое и улучшенное выполнение для некоторых таблиц INFORMATION_SCHEMA. См. раздел 15.5.

Данные, включенные сервером в словарь, влекут за собой некоторые общие операционные различия; см. раздел 15.6. Кроме того, для обновлений до MySQL 8.0 от MySQL 5.7, процедура обновления несколько отличается от предыдущего релиза и требует, чтобы Вы проверили готовность обновления своей установки, проверяя определенные предпосылки. Для получения дополнительной информации, см. раздел 2.10.1.

15.1. Схема словаря данных

Таблицы словаря данных невидимы и доступ к ним не может быть получен непосредственно. Однако, доступ к данным, хранящимся в таблицах словаря данных, поддержан через операторы INFORMATION_SCHEMA и SHOW.

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

15.2. Удаление основанного на файлах хранения метаданных

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

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

  • Файлы .frm: табличные метафайлы с данными. С удалением файлов .frm:

    • Предел размера определения 64 КБ, наложенный структурой файла .frm, удален.

    • Поле VERSION в INFORMATION_SCHEMA.TABLES теперь сообщает о значении 10, которое является последней версией файла frm, используемой в MySQL 5.7.

  • Файлы .par: файлы определения разделения. Файлы .par были удалены в MySQL 5.7.6 с введением нативного разделения для таблиц InnoDB.
  • Файлы .TRN: файлы пространства имен триггеров.
  • Файлы .TRG: файлы параметров триггеров.
  • Файлы .isl: символические ссылки InnoDB, содержащие местоположение файлов табличного пространства, созданных за пределами каталога данных MySQL. Записи журнала теперь используются, чтобы определить местонахождение отдаленных файлов табличного пространства.
  • Файлы db.opt: конфигурационные файлы базы данных. Эти файлы, по одному на каталог базы данных, содержали набор символов базы данных по умолчанию.

15.3. Транзакционное хранение данных словаря

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

15.4. Кэш объектов словаря

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

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

  • Раздел кэша определения табличного пространства : Хранит объекты определения табличного пространства. Опция tablespace_definition_cache устанавливает предел числа объектов определения табличного пространства, которые могут храниться в кэше объектов словаря. Значение по умолчанию 256.

  • Раздел кэша определения схемы: Хранит объекты определения схемы. Опция schema_definition_cache устанавливает предел числа объектов определения схемы, которые могут храниться в кэше объекта словаря. Значение по умолчанию 256.
  • Раздел кэша определения таблиц: Хранит табличные объекты определения. Предел установлен в значение max_connections, у которого есть значение по умолчанию 151.

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

  • Раздел кэша определения хранимых подпрограмм : Хранит сохраненные объекты определения программы. Опция stored_program_definition_cache устанавливает предел числа объектов определения программы, которые могут быть сохранены в кэше объекта словаря. Значение по умолчанию 256.

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

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

  • Раздел кэша определения набора символов: Хранит объекты определения набора символов и имеет предел объектов 256.
  • Раздел кэша определения сопоставления: Хранит объекты определения сопоставления и имеет предел объектов 256.

15.5. Интеграция INFORMATION_SCHEMA и словаря данных

С введением словаря данных следующие таблицы INFORMATION_SCHEMA осуществлены как представления таблиц словаря данных:

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

  • Больше не надо составлять временную таблицу для каждого запроса таблицы INFORMATION_SCHEMA.

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

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

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

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

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

15.6. Различия в использовании словаря данных

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

  • Ранее, включение системной переменной innodb_read_only блокировало создание и удаление таблиц только для InnoDB. С MySQL 8.0, включение innodb_read_only закроет эти операции для всех механизмов хранения. Создание и удаление таблиц изменяют таблицы словаря данных в системной базе данных mysql, но те таблицы используют механизм хранения InnoDB и не могут быть изменены, когда включен innodb_read_only . Тот же самый принцип относится к другим табличным операциям, которые требуют изменения таблиц словаря данных. Примеры:

    • ANALYZE TABLE терпит неудачу, потому что это обновляет табличные статистические данные, которые сохранены в словаре данных.

    • ALTER TABLE tbl_name ENGINE=engine_name терпит неудачу, потому что это обновляет обозначение механизма хранения, которое сохранено в словаре данных.

    Включение innodb_read_only также имеет важные значения для таблиц словаря не с данными в системной базе данных mysql. Для деталей см. описание innodb_read_only в разделе 16.13 .

  • Ранее таблицы в системной базе данных mysql были видимы DML и заявлениям DDL. С MySQL 8.0 таблицы словаря данных невидимы и не могут быть изменены или запрошены непосредственно. Однако, в большинстве случаев они соответствуют таблицам INFORMATION_SCHEMA, которые могут быть запрошены. Это позволяет основным таблицам словаря данных быть измененными, в то время как развитие сервера продолжается, поддерживая интерфейс INFORMATION_SCHEMA для использования приложениями.

  • Таблицы INFORMATION_SCHEMA в MySQL 8.0 близко связаны со словарем данных, что приводит к нескольким различиям в использовании:

    • Раньше запросы для табличной статистики INFORMATION_SCHEMA в таблицах STATISTICS и TABLES получали статистику непосредственно от механизмов хранения. С MySQL 8.0 значение по умолчанию должно использовать кэшируемую табличную статистику, которая более эффективна. Однако, когда сервер запускается, кэшируемые статистические данные NULL и не обновлены для данной таблицы до выполнения ANALYZE TABLE. Чтобы использовать последнюю табличную статистику, полученную из механизмов хранения (логика до версии 8.0), измените системную переменную information_schema_stats с CACHED на LATEST.

    • Несколько таблиц INFORMATION_SCHEMA представления таблиц словаря данных, что позволяет оптимизатору использовать индексы основных таблиц. Следовательно, в зависимости от выбора оптимизатора, порядок строк результатов для запросов INFORMATION_SCHEMA может отличаться от предыдущих результатов. Если у результата запроса должны быть определенные характеристики упорядочивания строки, включайте предложение ORDER BY.
    • mysqldump и mysqlpump больше не выводят базу данных INFORMATION_SCHEMA, даже если она явно названа в командной строке.
    • CREATE TABLE dst_tbl LIKE src_tbl требует, чтобы src_tbl была базовой таблицей и терпит неудачу, если это таблица INFORMATION_SCHEMA, которая является представлением таблицы словаря данных.
    • Ранее заголовки набора результатов столбцов, выбранных из таблицы INFORMATION_SCHEMA использовали написание прописными буквами, определенное в запросе. Этот запрос производит набор результатов с заголовком table_name: 
      SELECT table_name FROM INFORMATION_SCHEMA.TABLES;
      С MySQL 8.0 эти заголовки приведены к верхнему регистру: предыдущий запрос производит набор результатов с заголовком TABLE_NAME. В случае необходимости псевдоним столбца может использоваться, чтобы достигнуть различного регистра символов. Например: 
      SELECT table_name AS 'table_name' FROM INFORMATION_SCHEMA.TABLES;
  • Каталог данных затрагивает mysqldump и mysqlpump для вывода информации из системной базы данных mysql:

    • Ранее было возможно вывести все таблицы в mysql. Теперь mysqldump и mysqlpump выводят только несловарные таблицы в этой базе данных.

    • Ранее опции --routines и --events не требовались для включения событий и сохраненных процедур, используя опцию --all-databases : дамп включал всю системную базу данных mysql, а поэтому таблицы proc и event также выводились. Теперь таблицы event и proc не используются. Определения для соответствующих объектов сохранены в таблицах словаря данных, но те таблицы не выведены. Включить их в дамп, изготовленный с опцией --all-databases, можно, применив явно опции --routines и --events.
    • Ранее опция --routines требовала привилегию SELECT для таблицы proc. Теперь эта таблица не используется, --routines требует глобальной привилегии SELECT.
    • Ранее было возможно вывести сохраненные процедуры и определения событий вместе с временной меткой их создания и модификации, выводя таблицы proc и event. В MySQL 8.0 не используются эти таблицы, таким образом, невозможно вывести временные метки.

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

15.7. Ограничения словаря данных

Этот раздел описывает временные ограничения словаря данных MySQL.

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

  • Перенос данных в таблицах копированием и переносом файлов данных таблиц MyISAM более не поддерживается. Таблицы, перемещенные с использованием этого метода не будут обнаружены сервером.
  • Простое резервное копирование и восстановление отдельных таблиц MyISAM посредством копирования файлов данных не поддерживается.
  • TRUNCATE TABLE, который отображен на DROP TABLE и CREATE TABLE в MySQL 8.0, является временно неатомным. Выход сервера во время операции TRUNCATE TABLE может привести к повреждению таблицы. Это может также привести к неправильным записям внешнего ключа в таблицах словаря SYS_FOREIGN и SYS_FOREIGN_COLS в InnoDB, если таблица содержит ограничения внешнего ключа.
  • Операции DDL занимают больше времени из-за записи в транзакционное хранилище вместо файлов .frm.
  • Промежуток времени, в течение которого операции DDL уязвимы для выхода сервера, больше из-за записи в транзакционное хранилище вместо файлов .frm. Минимальный риск, введенный этим ограничением, главным образом, относится к операциям восстановления и другим операциям, которые загружают многочисленные новые таблицы.
  • С удалением файлов .isl в MySQL 8.0 офлайновое перемещение табличных пространств, создаваемых за пределами каталога данных MySQL, не поддерживается.

Поиск

  

Найди своих коллег!

Вы можете направить письмо администратору этой странички, Алексею Паутову. mailto:alexey.v.pautov@mail.ru