MySQL Server теперь включает транзакционный словарь данных, который хранит информацию об объектах базы данных. В предыдущих выпусках MySQL данные о словаре хранились в метафайлах с данными и нетранзакционных таблицах.
Эта глава описывает основные особенности, выгоду, различия в
использовании и ограничения словаря данных. Для информации о других
возможностях словаря данных, обратитесь к разделу
Data Dictionary Notes
ресурса
MySQL 8.0.0 Release Notes.
InnoDB
продолжает использовать собственный
словарь данных в MySQL 8.0.0.
Выгода словаря данных MySQL включает:
Простота централизованной схемы словаря данных, которая однородно хранит данные словаря. См. раздел 15.1.
INFORMATION_SCHEMA
. См.
раздел 15.5.
Данные, включенные сервером в словарь, влекут за собой некоторые общие операционные различия; см. раздел 15.6. Кроме того, для обновлений до MySQL 8.0 от MySQL 5.7, процедура обновления несколько отличается от предыдущего релиза и требует, чтобы Вы проверили готовность обновления своей установки, проверяя определенные предпосылки. Для получения дополнительной информации, см. раздел 2.10.1.
Таблицы словаря данных невидимы и доступ к ним не может быть получен
непосредственно. Однако, доступ к данным, хранящимся в таблицах словаря
данных, поддержан через операторы
INFORMATION_SCHEMA
и
SHOW
.
Системные таблицы MySQL все еще существуют в MySQL 8.0 и могут быть
просмотрены через SHOW TABLES
в системной базе данных mysql
. Вообще, различие между системными
таблицами MySQL и таблицами словаря данных в том, что системные таблицы
содержат вспомогательные данные, такие как часовой пояс и справочная
информация, в то время как таблицы словаря данных содержат данные, требуемые,
чтобы выполнять запросы SQL. Системные таблицы MySQL и таблицы словаря данных
также отличаются по тому, как они обновлены. Обновление системных таблиц
MySQL требует выполнения
mysql_upgrade. Обновлениями словаря данных
управляет сервер MySQL.
В предыдущих выпусках 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
: конфигурационные файлы базы данных. Эти файлы,
по одному на каталог базы данных, содержали набор символов базы
данных по умолчанию.Схема словаря данных хранит данные словаря в транзакционных
(InnoDB
) таблицах, созданных в виде файла на таблицу. Файлы
табличного пространства словаря данных расположены в каталоге базы данных
mysql
вместе с системными таблицами. Данные словаря теперь
защищены теми же способами, которые защищают пользовательские
данные в таблицах InnoDB
.
Кэш объектов словаря это совместно используемый глобальный кэш, который хранит объекты словаря данных, к которым ранее получали доступ, в памяти, чтобы включить повторное использование объекта и минимизировать дисковый ввод/вывод. Подобный другим механизмам кэша, используемым 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
устанавливает мягкий верхний предел для числа
кэшируемых хранимых процедур или функций на соединение, предел проверяется
каждый раз, когда соединение выполняет хранимую процедуру или функцию.
Раздел кэша определения программы, с другой стороны, является совместно
используемым кэшем, который хранит сохраненные объекты определения программы
в других целях. У существования объектов в кэше определения программы нет
никакой зависимости от существования объектов в кэше
хранимых процедур и наоборот.
С введением словаря данных следующие таблицы
INFORMATION_SCHEMA
осуществлены как представления
таблиц словаря данных:
COLLATIONS
COLLATION_CHARACTER_SET_APPLICABILITY
COLUMNS
KEY_COLUMN_USAGE
SCHEMATA
STATISTICS
TABLES
TABLE_CONSTRAINTS
VIEWS
Запросы на тех таблицах теперь более эффективны, потому что они получают
информацию из таблиц словаря данных, а не другими, более медленными,
средствами. В частности, для каждой таблицы
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
получали последние метаданные непосредственно
от механизма хранения, с такой скоростью, с какой не получают
кэшируемые табличные метаданные.
Использование данных, включенных в словарь сервером 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
.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;
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 не используются эти
таблицы, таким образом, невозможно вывести временные метки.
Этот раздел описывает временные ограничения словаря данных MySQL.
Ручное создание каталогов базы данных в соответствии с каталогом данных (например, через mkdir) более не поддерживается. Вручную создаваемые каталоги базы данных не будут признаны сервером MySQL.
MyISAM
более не поддерживается. Таблицы, перемещенные с
использованием этого метода не будут обнаружены сервером.MyISAM
посредством копирования файлов данных не поддерживается.
TRUNCATE TABLE
,
который отображен на DROP TABLE
и CREATE TABLE
в MySQL 8.0,
является временно неатомным. Выход сервера во время операции
TRUNCATE TABLE
может привести к повреждению таблицы. Это может также привести к неправильным
записям внешнего ключа в таблицах словаря SYS_FOREIGN
и
SYS_FOREIGN_COLS
в InnoDB
, если таблица содержит
ограничения внешнего ключа..frm
..frm
. Минимальный риск, введенный этим ограничением,
главным образом, относится к операциям восстановления и другим операциям,
которые загружают многочисленные новые таблицы..isl
в MySQL 8.0 офлайновое перемещение
табличных пространств, создаваемых за пределами каталога данных
MySQL, не поддерживается.