Команда разработчиков СУБД MySQL недавно анонсировала свой основной релиз как MySQL 8 Development Milestone Release (DMR) со значительными обновлениями и исправлениями проблем, которые были очень необходимы в изменениях больших данных.
Вам может быть интересно, почему номер версии 8 сразу после 5.7! Разве не пропущены промежуточные версии, то есть номера 6 и 7? Конечно, нет; фактически номер 6.0 был сохранен в рамках перехода к более частому и своевременному выпуску, в то время как номер 7.0 оставлен для кластерной версии MySQL.
Давайте посмотрим на некоторые интересные функциональные возможности, представленные в этой последней версии, показанные на следующей ниже схеме:
Самое время подробно рассмотреть функциональные возможности MySQL 8, которые вдохновляют и убеждают в необходимости крупного обновления версии MySQL.
Транзакционный словарь данных
В предыдущей версии словарь данных СУБД MySQL хранился в разных файлах метаданных и нетранзакционных таблицах, но начиная с этой версии она будет иметь транзакционный словарь данных для хранения информации о базе данных. Больше нет файлов .frm
, .trg
или .par
. Вся информация будет храниться в базе данных, что снимает затраты на выполнение тяжелых файловых операций. Были многочисленные проблемы с хранением метаданных файловой системы, такие как уязвимость файловой системы, непомерные файловые операции, которые с трудом справляются с восстановлением после аварийного завершения работы или репликацией; было также трудно добавлять новые метаданные, связанные с каким-то функциональным средством. Теперь это обновление упрощает централизованное хранение информации и повышает производительность, поскольку этот объект-словарь данных может кешироваться в памяти, как и другие объекты базы данных.
Этот словарь данных будет содержать данные, необходимые для выполнения SQL-запроса, в частности каталожную информацию, наборы символов, параметры сортировки, типы столбцов, индексы, сведения о базе данных, таблицы, процедуры хранения, функции и триггеры и т. д.
Роли
В MySQL 8 модуль привилегий был улучшен путем введения ролей, то есть коллекции разрешений. Теперь мы можем создавать роли с несколькими привилегиями и назначать их нескольким пользователям.
Проблема предыдущей версии была в том, что мы не могли определять общие разрешения для группы пользователей и каждый пользователь имел индивидуальные привилегии. Предположим, что если уже существует 1000 пользователей с общими привилегиями и вы хотите удалить разрешения на запись для всех этих 1000 пользователей, то что бы вы сделали в предыдущей версии? Вы бы предприняли длительный подход к обновлению каждого пользователя, не так ли? Брр... трудоемкая задача.
Теперь с MySQL 8 любое изменение привилегий легко обновляется. Роли будут определять все необходимые привилегии, и эта роль будет назначена этим 1000 пользователям. Нам просто нужно внести какие-либо изменения привилегий в роли, и все пользователи будут автоматически наследовать соответствующие привилегии.
Роли можно создавать, удалять, предоставлять или отзывать разрешения, предоставлять или отзывать из учетной записи пользователя, а также указывать роль по умолчанию в текущем сеансе.
Автоинкремент InnoDB
СУБД MySQL 8 изменила механизм хранения значения автоинкрементного счетчика. Ранее он хранился в памяти, что приводило к значительным сложностям в управлении во время перезапуска или сбоев сервера. Однако теперь значение автоинкрементного счетчика записывается в журнал повтора при каждом изменении его значения, и на каждой контрольной точке оно сохраняется в системной таблице, что делает его непрерывным при перезапуске сервера.
В предыдущей версии обновление значения автоинкрементного счетчика могло вызвать ошибки дублирования при вводе. Предположим, если вы обновили значение автоинкремента в середине последовательности большим значением, чем текущее максимальное значение, тогда только последующие операции вставки смогут определить неиспользуемые значения, что может вызвать проблему повторяющейся записи. Это было предотвращено путем обеспечения непрерывности автоинкрементного значения, поэтому последующие операции вставки могут получить новое значение и правильно его назначить.
Если происходил перезапуск сервера, то в предыдущей версии автоинкрементное значение терялось, поскольку оно хранилось в памяти, и InnoDB должен был выполнить запрос, чтобы узнать максимальное используемое значение. Это было изменено, поскольку более новая версия имеет возможность поддерживать его значение непрерывным во всех перезапусках сервера. Во время перезапуска сервера InnoDB инициализирует значение счетчика в памяти, используя максимальное значение, сохраненное в таблице словаря данных. В случае сбоев сервера In- noDB инициализирует значение автоинкрементного счетчика, которое больше, чем в таблице словаря данных и журнале повтора/отката.
Поддержка невидимых индексов
СУБД MySQL 8 предоставляет возможность делать индексы невидимыми. Такие индексы не могут использоваться оптимизатором. В случае, если вы хотите проверить производительность запросов без индексов, используя это функциональное средство, это можно выполнить, сделав их невидимыми, а не отбрасывая и повторно добавляя индекс. Это довольно удобное функциональное средство, когда индексирование должно отбрасываться и воссоздаваться на огромных наборах данных.
По умолчанию все индексы являются видимыми. Чтобы сделать их невидимыми или видимыми, используются ключевые слова соответственно INVISIBLE
и VISIBLE
, как описано в следующем ниже фрагменте кода:
ALTER TABLE таблица1 ALTER INDEX ix_столбца1_таблицы1 INVISIBLE; ALTER TABLE таблица1 ALTER INDEX ix_столбца1_таблицы1 VISIBLE;
Улучшение индексов, отсортированных по убыванию
Нисходящие индексы существовали и в версии 5.7, но они сканировались в обратном порядке, что создавало барьеры производительности. Чтобы улучшить производительность, СУБД MySQL 8 это оптимизирует и сканирует нисходящие индексы в прямом порядке, что резко улучшило производительность. Она также передает в оптимизатор многостолбцовые индексы, когда наиболее эффективный порядок сканирования для некоторых столбцов возрастающий и для других столбцов убывающий.
SET PERSIST
Серверные переменные могут быть настроены глобально и динамически во время работы сервера. Существует множество системных переменных, которые можно установить с помощью SET GLOBAL
:
SET GLOBAL max_connections = 1000;
Однако такие настройки будут потеряны после перезапуска сервера. Чтобы избежать этого, MySQL 8 ввел параметр SET PERSIST
, который сохраняет переменные во всех перезапусках сервера:
SET PERSIST max_connections = 1000;
Расширенная поддержка ГИС
В предыдущей версии СУБД поддерживала только одну систему координат, безразмерное двумерное положение, которое не было привязано к положению на земле. Теперь СУБД MySQL 8 добавила поддержку для системы пространственной привязки Spatial Reference System (SRS) с геопривязанными эллипсоидами и двумерными проекциями. SRS помогает назначать местоположению координаты и устанавливает связи между наборами таких координат. Этими пространственными данными можно управлять в хранилище словаря данных в виде таблицы ST_SPATIAL_REFERENCE_SYSTEMS
.
Кодировка символов по умолчанию
Кодировка символов по умолчанию была изменена с latin1
на UTF8. UTF8 является доминирующим набором символов, хотя это не было по умолчанию в предыдущих версиях MySQL. Наряду с кодировкой символов по умолчанию, параметры сортировки были изменены с latin1_swedish_ci
на utf8mb4_800_ci_ai
. С этими глобально принятыми изменениями наборы символов и параметры сортировки теперь основаны на UTF8; одна из распространенных причин заключается в том, что UTF8 поддерживает около 21 различных языков, что позволяет системам обеспечивать многоязычную поддержку.
Улучшение побитовых операций
В MySQL 5.7 побитовые операции и функции работали только для типов данных Bigint (64-разрядных целых чисел). Нам нужно было передавать BIGINT
в качестве аргумента, и она возвращала результат как BIGINT
. Короче говоря, для выполнения операций он имел максимальный диапазон до 64 разрядов. Если пользователь хотел выполнить их для других типов данных, то ему нужно было выполнять преобразование в тип данных BIGINT
. Такая типизация невозможна для типов данных, размер которых превышает 64 разряда, так как она приведет к усечению фактического значения и в конечном счете к неточности в данных.
В СУБД MySQL 8 усовершенствованы побитовые операции путем включения поддержки других двоичных типов данных, таких как Binary
, VarBinary
и BLOB
. Это позволяет выполнять побитовые операции с большей, чем 64-разрядные данные, длиной. Типизация больше не требуется! Это позволяет принимать аргументы и возвращать результаты размером более 64 разрядов.
InnoDB Memcached
Множественные операции чтения сейчас возможны с плагином InnoDB Memcached, который действительно помогает в улучшении их производительности. Теперь множественные пары ключ-значение могут выбираться в одиночном запросе Memcached. Кроме того, был минимизирован частый коммуникационный трафик, так как мы можем получать многочисленные данные за один раз.
Плагин InnoDB Memcached также поддерживает диапазонные запросы. Это упрощает поиск по диапазону, позволяя задавать определенный диапазон и извлекать значения в этом диапазоне.
NOWAIT и SKIP LOCKED
Когда строки блокируются другими транзакциями, к которым вы пытаетесь получить доступ, вам нужно дождаться, пока эта транзакция освободит блокировку данной строки, чтобы вы могли получить к ней соответствующий доступ. Чтобы избежать ожидания другой транзакции, InnoDB добавил поддержку параметров NOWAIT
и SKIP LOCKED
. Параметр NOWAIT
немедленно возвращается с ошибкой, в случае если запрошенная строка заблокирована, а не переходит в режим ожидания, а параметр SKIP LOCKED
пропускает заблокированную строку и не ждет получения блокированной строки. Следовательно, SKIP LOCKED
не будет учитывать блокированную строку в результирующем наборе:
SELECT * FROM таблица1 WHERE id = 5 FOR UPDATE NOWAIT;
SELECT * FROM таблица1 FOR UPDATE SKIP LOCKED;