Что нового в MySQL 8.0?

Sunday, May 13, 2018 6:26:51 PM

Недавно MySQL 8.0 стала общедоступной. MySQL 8.0 - чрезвычайно захватывающая новая версия самой популярной в мире базы данных с открытым исходным кодом с улучшениями по всем направлениям. Некоторые ключевые усовершенствования включают:

SQL Window, Common Table Expressions, NOWAIT и SKIP LOCKED, Descending Indexes, Grouping, Regular Expressions, Character Sets, Cost Model и Histograms.
Синтаксис JSON Extended, новые функции, улучшенная сортировка и частичные обновления. С помощью функций таблицы JSON вы можете использовать механизм SQL для данных JSON.
Поддержка географии ГИС. Пространственные справочные системы (SRS), а также пространственные типы данных SRS, пространственные индексы и пространственные функции.
Надежность. Операторы DDL стали быстрыми и аварийно безопасными, метаданные хранятся в одном словаре транзакционных данных. Работает на InnoDB!
Наблюдаемость. Значительные улучшения в схеме производительности, информационной схеме, конфигурационных переменных и регистрации ошибок.
Управляемость. Удаленное управление, Отмена управления табличным пространством и новый мгновенный DDL.
Улучшения безопасности. OpenSSL, новая аутентификация по умолчанию, роли SQL, разбивка супер-привилегий, надежность пароля и многое другое.
Производительность. Представление. InnoDB значительно лучше работает с рабочими нагрузками на чтение / запись, загруженными IO рабочими нагрузками и высокими конкурирующими «горячими» рабочими нагрузками. Добавлена функция группы ресурсов, которая дает пользователям возможность оптимизировать определенные рабочие нагрузки на конкретном оборудовании путем сопоставления пользовательских потоков с процессорами.

Вышеперечисленные улучшения представляют собой лишь часть из основных моментов. Вы можете также посмотреть исходный код на github.com/mysql.

Возможности для разработчиков

Разработчики MySQL хотят новых функций, а MySQL 8.0 предоставляет множество новых и многократно запрашиваемых функций в таких областях, как SQL, JSON, регулярные выражения и ГИС. Разработчики также хотят иметь возможность хранить Emojis, поэтому UTF8MB4 теперь является стандартным набором символов в 8.0. Наконец, в Datatypes есть улучшения, с битовыми операциями с типами данными BINARY и улучшенными функциями IPv6 и UUID.

SQL

Оконные функции

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

Оконные функции имеют две разновидности: агрегированные функции SQL, используемые в качестве оконных функций и специализированные оконные функции. Это набор агрегированных функций в MySQL, которые поддерживают работу с окнами: COUNT, SUM, AVG, MIN, MAX, BIT_OR, BIT_AND, BIT_XOR, STDDEV_POP (и его синонимы STD, STDDEV), STDDEV_SAMP, VAR_POP (и его синоним VARIANCE) и VAR_SAMP . Набор специализированных оконных функций: RANK, DENSE_RANK, PERCENT_RANK, CUME_DIST, NTILE, ROW_NUMBER, FIRST_VALUE, LAST_VALUE, NTH_VALUE, LEAD и LAG

Поддержка оконных функций (аналитические функции a.k.a.) является частым пользовательским запросом. Оконные функции уже давно являются частью стандартного SQL (SQL 2003).

Обобщенное табличное выражение

MySQL 8.0 предоставляет [рекурсивные] обобщенные выражения таблиц (CTE). Нерекурсивные CTE можно объяснить как «улучшенные производные таблицы», поскольку он позволяет ссылаться на производную таблицу более одного раза. Рекурсивный CTE представляет собой набор строк, который строится итеративно: из исходного набора строк процесс получает новые строки, которые вырабатывают набор, и эти новые строки снова загружаются в процесс, производя больше строк и т. д. до тех пор, пока процесс не создаст больше строк. CTE является часто запрашиваемой функцией SQL, например, запрос функции 16244 и 32174.

NOWAIT и SKIP LOCKED

MySQL 8.0 предоставляет альтернативы NOWAIT и SKIP LOCKED в операторе SQL-блокировки. Обычно, когда строка заблокирована из-за UPDATE или SELECT ... FOR UPDATE, любая другая транзакция должна будет ждать, чтобы получить доступ к этой заблокированной строке. В некоторых случаях использования необходимо либо немедленно вернуться, если строка заблокирована, либо игнорировать заблокированные строки. Оператор блокировки с использованием NOWAIT никогда не ждет, чтобы получить блокировку строк. Вместо этого запрос завершится с ошибкой. Оператор блокировки с использованием SKIP LOCKED никогда не будет ждать, чтобы получить блокировку строк в перечисленных таблицах. Вместо этого заблокированные строки пропускаются и не читаются вообще. NOWAIT и SKIP LOCKED часто запрашивают функции SQL. например, запрос функции 49763.

Убывающие индексы

MySQL 8.0 обеспечивает поддержку индексов в порядке убывания. Значения в таком индексе располагаются в порядке убывания, и мы сканируем его сверху вниз. До 8.0, когда пользователь создавал нисходящий индекс, мы создали восходящий индекс и отсканировали его снизу вверх. Одно из преимуществ заключается в том, что сканирование индекса сверху вниз происходит быстрее, чем обратно. Еще одно преимущество реального убывающего индекса заключается в том, что он позволяет использовать индексы вместо filesort для оператора ORDER BY со смешанными элементами сортировки ASC / DESC. Убывающие индексы - это часто запрашиваемая функция SQL, например, запрос функции 13375.

GROUPING

MySQL 8.0 поставляет GROUPING (), SQL_FEATURE T433. Функция GROUPING () отличает суперагрегатные строки от регулярных сгруппированных строк. Расширения GROUP BY, такие как ROLLUP, производят суперагрегатные строки, где набор всех значений представлен нулем. Используя функцию GROUPING (), вы можете отличить нуль, представляющий набор всех значений в суперагрегационной строке от NULL в регулярной строке. GROUPING - часто запрашиваемая функция SQL. Смотрите запросы функций 3156 и 46053.

Советы оптимизатора

В 5.7 мы ввели новый синтаксис подсказок для подсказок оптимизатора. С помощью нового синтаксиса подсказки могут быть указаны непосредственно после ключевых слов SELECT | INSERT | REPLACE | UPDATE | DELETE в инструкции SQL, заключенные в комментарии / * + * / style. . В MySQL 8.0 мы завершаем изображение, полностью используя этот новый стиль:

MySQL 8.0 добавляет подсказки для INDEX_MERGE и NO_INDEX_MERGE. Это позволяет пользователю контролировать поведение слияния индекса для отдельного запроса без изменения переключателя оптимизатора.
MySQL 8.0 добавляет подсказки для JOIN_FIXED_ORDER, JOIN_ORDER, JOIN_PREFIX и JOIN_SUFFIX. Это позволяет пользователю управлять порядком таблицы для выполнения соединения.
MySQL 8.0 добавляет подсказку SET_VAR, которая установит значение для данной системной переменной только для следующего оператора. Таким образом, после завершения операции значение будет сброшено до предыдущего значения.

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

JSON

MySQL 8.0 добавляет новые функции JSON и повышает производительность для сортировки и группировки значений JSON.

Расширенный синтаксис для диапазонов в выражениях маршрута JSON

MySQL 8.0 расширяет синтаксис для диапазонов в выражениях маршрута JSON. Например, SELECT JSON_EXTRACT ('[1, 2, 3, 4, 5]', '$ [1-3]'); приводит к [2, 3, 4]. Введен новый синтаксис - это подмножество синтаксиса SQL-стандарта, описанного в SQL: 2016, 9.39. Язык языка SQL / JSON: синтаксис и семантика.

Функции таблицы JSON

MySQL 8.0 добавляет функции таблицы JSON, которые позволяют использовать SQL-механизмы для данных JSON. JSON_TABLE () создает реляционное представление данных JSON. Он отображает результат оценки данных JSON в реляционные строки и столбцы. Пользователь может запросить результат, возвращаемый функцией, как обычную реляционную таблицу с использованием SQL, например. объединение, проект и совокупность.

Функции агрегирования JSON

MySQL 8.0 добавляет функции агрегирования JSON_ARRAYAGG () для генерации массивов JSON и JSON_OBJECTAGG () для генерации объектов JSON. Это позволяет объединить документы JSON в несколько строк в массив JSON или объект JSON.

Функции слияния JSON

Функция JSON_MERGE_PATCH () реализует семантику JavaScript (и других языков сценариев), определенных RFC7396, то есть удаляет дубликаты по приоритету второго документа. Например, JSON_MERGE ('{"a": 1, "b": 2}', '{"a": 3, "c": 4}'); # возвращает {"a": 3, "b": 2, "c": 4}.

Функция JSON_MERGE_PRESERVE () имеет семантику JSON_MERGE (), реализованную в MySQL 5.7, которая сохраняет все значения, например JSON_MERGE ('{"a": 1, "b": 2}', '{"a": 3, " с ": 4} '); # возвращает {"a": [1,3], "b": 2, "c": 4}.

Существующая функция JSON_MERGE () исключена из MySQL 8.0 с целью устранения неоднозначности для операции слияния.

JSON Pretty Function

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

Функции размера JSON

MySQL 8.0 добавляет функции JSON, связанные с использованием пространства для данного объекта JSON. JSON_STORAGE_SIZE () возвращает фактический размер в байтах для типа данных JSON. JSON_STORAGE_FREE () возвращает свободное пространство двоичного типа JSON в байтах, включая фрагментацию и отступы, сохраненные для обновления inplace.

Улучшенная сортировка JSON

MySQL 8.0 обеспечивает лучшую производительность для сортировки / группировки значений JSON с помощью ключей сортировки переменной длины. Предварительные контрольные показатели показывают улучшение в сортировке в 1,2-18 раз, в зависимости от варианта использования.

Частичное обновление JSON

MySQL 8.0 добавляет поддержку частичного обновления функций JSON_REMOVE (), JSON_SET () и JSON_REPLACE (). Если обновлены только некоторые части документа JSON, мы хотим предоставить информацию обработчику о том, что было изменено, чтобы механизм хранения и репликация не нуждались в написании полного документа. В реплицированной среде не может быть гарантировано, что макет документа JSON точно совпадает на главном и подчиненном устройстве, поэтому физические различия не могут использоваться для уменьшения сетевого ввода-вывода для репликации на основе строк. Таким образом, MySQL 8.0 обеспечивает логические различия, которые репликация на основе строк может отправлять по каналу и повторно использовать на подчиненном устройстве.

GIS

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

Пространственная справочная система (SRS)

Информационная схема ST_SPATIAL_REFERENCE_SYSTEMS предоставляет информацию о доступных пространственных системах отсчета для пространственных данных. Это представление основано на стандарте SQL / MM (ISO / IEC 13249-3). Каждая пространственная система отсчета идентифицируется номером SRID. MySQL 8.0 поставляется с около 5000 SRID из набора геодезических параметров EPSG, охватывая эллипсоиды с привязкой и 2d проекции (т. Е. Все двумерные пространственные системы отсчета).

Совместимые с SRID пространственные типы данных

Пространственные типы данных могут быть приписаны к определению пространственной системы отсчета, например, к SRID 4326 следующим образом: CREATE TABLE t1 (г GEOMETRY SRID 4326); SRID здесь является модификатором типа SQL для типа данных GEOMETRY. Значения, вставленные в столбец с свойством SRID, должны находиться в этом SRID. Попытки вставить значения с другими SRID приводят к возникновению условия исключения. Немодифицированные типы, т. е. типы без спецификации SRID, будут продолжать принимать все SRID, как и раньше.

MySQL 8.0 добавляет представление INFORMATION_SCHEMA.ST_GEOMETRY_COLUMNS, как указано в SQL / MM Part 3, Sect. 19,2. В этом представлении будут перечислены все столбцы GEOMETRY в экземпляре MySQL, и для каждого столбца он будет отображать стандартные SRS_NAME, SRS_ID и GEOMETRY_TYPE_NAME.

Совместимые с SRID пространственные индексы

Пространственные индексы могут быть созданы на пространственных типах данных. Столбцы в пространственных индексах должны быть заявлены как NOT NULL. Например, например: CREATE TABLE t1 (g GEOMETRY SRID 4326 NOT NULL, ПРОСТРАНСТВЕННЫЙ ИНДЕКС (g));

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

Совместимые с SRID пространственные функции

MySQL 8.0 расширяет пространственные функции, такие как ST_Distance () и ST_Length (), чтобы обнаружить, что его параметры находятся в географическом (эллипсоидальном) SRS и вычислять расстояние на эллипсоиде. В данное время ST_Distance и пространственные отношения, такие как ST_Within, ST_Intersects, ST_Contains, ST_Crosses и т. д. поддерживают географические вычисления. Поведение каждой функции ST определено в SQL / MM Part 3 Spatial.

Наборы символов

MySQL 8.0 делает UTF8MB4 набором символов по умолчанию. Производительность SQL, такая как сортировка строк UTF8MB4, была улучшена в 20 раз в 8,0 по сравнению с 5.7. UTF8MB4 является доминирующей кодировкой символов для Интернета, и этот шаг облегчит жизнь большинству пользователей MySQL.

Набор символов по умолчанию изменился с latin1 на utf8mb4, и сортировка по умолчанию изменилась с latin1_swedish_ci на utf8mb4_800_ci_ai.
Изменения по умолчанию применяются к командам командной строки libmysql и сервера, а также к самому серверу.
Изменения также отражаются в тестах MTR, работающих с новой кодировкой по умолчанию.
Масштаб сортировки и отображение случаев основаны на Unicode 9.0.0, объявленном комитетом Unicode 21 июня 2016 года.
Для совпадений utf8mb4 были реализованы нечеткие коллизии, специфичные для 21 языка, доступные для latin1 (наследие MySQL), например, чешская сортировка стала utf8mb4_cs_800_ai_ci.
Добавлена поддержка тематических и диакритических сортировок. MySQL 8.0 поддерживает все 3 уровня веса сортировки, определенные DUCET (таблица ввода столбцов Unicode по умолчанию).
Японская утилита utf8mb4_ja_0900_as_cs для utf8mb4, которая сортирует символы, используя вес трех уровней. Это задает правильный порядок сортировки для японцев.
Японский с дополнительной чувствительной к кане функцией, utf8mb4_ja_0900_as_cs_ks, где «ks» означает «kana sensitive».
Изменены все новые сопоставления, начиная с Unicode 9.0.0 forward, чтобы быть NO PAD вместо PAD STRING, т. е. обрабатывать пробелы в конце строки, как и любой другой символ. Это делается для улучшения согласованности и производительности. Старые сопоставления остаются на месте.

Типы данных

Битовые операции с бинарными типами данных

MySQL 8.0 расширяет битовые операции (поразрядный AND и др.) чтобы также работать с [VAR] BINARY / [TINY | MEDIUM | LONG] BLOB. Поразрядные операции до версии 8.0 поддерживались только для целых чисел. Если вы использовали битовые операции над двоичными файлами, аргументы были неявно переданы BIGINT (64 бит) перед операцией, что, возможно, привело к потере бит. Начиная с версии 8.0 поразрядные операции работают для всех типов данных BINARY и BLOB, применяя аргументы таким образом, чтобы бит не терялся.

IPV6-манипуляция

MySQL 8.0 улучшает удобство работы с IPv6, поддерживая битовые операции с типами данных BINARY. В MySQL 5.6 были внедрены функции INET6_ATON () и INET6_NTOA (), которые конвертируют адреса IPv6 между текстовой формой типа «fe80 :: 226: b9ff: fe77: eb17» и VARBINARY (16). Однако до сих пор эти функции IPv6 не могли быть объединены с битовыми операциями, так как такие операции - ошибочно - преобразовали вывод в BIGINT. Например, если у нас есть адрес IPv6 и вы хотите его протестировать против сетевой маски, мы можем теперь использовать INET6_ATON (адрес) & INET6_ATON (сеть), потому что INET6_ATON () корректно возвращает тип данных VARBINARY (16) (128 бит).

UUID-манипуляции

MySQL 8.0 улучшает удобство манипуляций UUID, реализуя три новые функции SQL: UUID_TO_BIN (), BIN_TO_UUID () и IS_UUID (). Первая преобразует UUID форматированный текст в VARBINARY (16), вторая из VARBINARY (16) в текст в формате UUID, а последняя проверяет достоверность текста в формате UUID. UUID, хранящийся как VARBINARY (16), может быть проиндексирован с использованием функциональных индексов. Функции UUID_TO_BIN () и UUID_TO_BIN () также могут перемешивать связанные с временем биты и перемещать их в начало, делая его дружественным к индексу и избегая случайных вставок в Б-дереве, таким образом уменьшая время вставки. Отсутствие такой функциональности упоминалось как один из недостатков использования UUID.

Модель стоимости

Оптимизатор запросов учитывает буферизацию данных

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

Гистограммы оптимизатора

MySQL 8.0 реализует статистику гистограммы. С помощью гистограмм пользователь может создавать статистику распределения данных для столбца в таблице, как правило, для неиндексированных столбцов, которые затем будут использоваться оптимизатором запросов при поиске оптимального плана запроса. Основным вариантом использования статистики гистограмм является вычисление селективности (эффекта фильтра) предикатов формы “COLUMN operator CONSTANT”.

Пользователь создает гистограмму с помощью синтаксиса ANALYZE TABLE, который был расширен, чтобы принять два новых условия: UPDATE HISTOGRAM ON столбец [, столбец] [WITH n BUCKETS] и DROP HISTOGRAM ON column [, column]. Количество бакетов не является обязательным, по умолчанию равно 100. Статистика гистограмм хранится в таблице словаря «column_statistics» и доступна через view information_schema.COLUMN_STATISTICS. Гистограмма хранится как объект JSON из-за гибкости типа данных JSON. ANALYZE TABLE автоматически определяет, следует ли выбирать базовую таблицу или нет, исходя из размера таблицы. Он также примет решение о том, следует ли строить синглтон или гистограмму эквидистанта на основе распределения данных и количества указанных бакетов.

Регулярные выражения

MySQL 8.0 поддерживает регулярные выражения для UTF8MB4, а также новые функции, такие как REGEXP_INSTR (), REGEXP_LIKE (), REGEXP_REPLACE () и REGEXP_SUBSTR (). Для управления выполнением были добавлены системные переменные regexp_stack_limit (по умолчанию 8000000 байт) и regexp_time_limit (по умолчанию 32 шага). Функция REGEXP_REPLACE () является одной из наиболее востребованных функций сообщества MySQL, например, см. запрос функции, сообщенный Гангом Гинзелем как ошибка № 27389.

Возможности Dev Ops

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

Надежность

MySQL 8.0 повышает общую надежность MySQL, потому что:

MySQL 8.0 хранит метаданные в InnoDB - проверенном транзакционном хранилище. Системные таблицы, такие как пользователи и привилегии, а также таблицы словаря данных теперь находятся в InnoDB.
MySQL 8.0 устраняет один источник потенциальной несогласованности. В 5.7 и более ранних версиях существуют по существу два словаря данных: один для уровня сервера и один для уровня InnoDB, и они могут выйти из синхронизации в некоторых сценариях сбоя. В 8.0 есть только один словарь данных.
MySQL 8.0 обеспечивает атомный, аварийный DDL. При этом пользователю гарантируется, что любой оператор DDL будет либо выполнен полностью, либо вообще отсутствует. Это особенно важно в реплицируемой среде, иначе могут быть сценарии, в которых мастера и подчиненные устройства (узлы) не синхронизируются, что приводит к дрейфу данных.

Эта работа выполняется в контексте нового словаря транзакционных данных.

Наблюдаемость

Информационная схема (ускорение)

MySQL 8.0 обновляет Информационную схему. В новой реализации таблицы Information Schema представляют собой простые представления таблиц словаря данных, хранящихся в InnoDB. Это намного эффективнее старой реализации с ускорением в 100 раз. Это делает Информационную схему практически применимой с помощью внешнего инструментария.

Схема производительности (ускорение)

MySQL 8.0 ускоряет выполнение запросов схемы производительности, добавляя более 100 индексов таблиц схемы производительности. Индексы таблиц схемы производительности предопределены. Они не могут быть удалены, добавлены или изменены. Индекс схемы производительности реализуется как отфильтрованное сканирование по существующим табличным данным, а не обход через отдельную структуру данных. Нет Б-деревьев или хеш-таблиц, которые должны быть сконструированы, обновлены или управляться иным образом. Индексы таблиц производительности ведут себя как хэш-индексы в отношении быстрого извлечения нужных строк и того, что они не обеспечивают упорядочивание строк, оставляя сервер сортировать результирующий набор, если это необходимо. Однако, в зависимости от запроса, индексы устраняют необходимость полного сканирования таблицы и возвращают значительно меньший набор результатов. Показатели схемы производительности видимы благодаря SHOW INDEXES и представлены в выводе EXPLAIN для запросов, которые ссылаются на индексированные столбцы.

Переменные конфигурации

MySQL 8.0 добавляет полезную информацию о переменных конфигурации, таких как имя переменной, значения min / max, откуда поступило текущее значение, кто внес изменения и когда оно был сделано. Эта информация содержится в новой таблице схем производительности, называемой variable_info.

Отчеты об ошибках клиента - количество сообщений

MySQL 8.0 позволяет просматривать агрегированные количества сообщений об ошибках клиента, отправляемых сервером. Пользователь может просматривать статистику из 5 разных таблиц: глобальный подсчет, сводку по потоку, сводную информацию для каждого пользователя, сводку на хост или сводку для каждой учетной записи. Для каждого сообщения об ошибке пользователь может увидеть количество поднятых ошибок, количество ошибок, исправленных обработчиком исключений SQL, отметки времени «first seen» и «last seen». Учитывая правильные привилегии, пользователь может выбрать SELECT из этих таблиц или TRUNCATE для сброса статистики.

Гистограммы времени ожидания

MySQL 8.0 предоставляет гистограммы схемы производительности времени ожидания с целью лучшего отслеживания времени ответа на запрос. Эта работа также вычисляет процентили «P95», «P99» и «P999» из собранных гистограмм. Эти процентили могут использоваться в качестве показателей качества обслуживания.

График зависимости блокировки данных
MySQL 8.0 предоставляет инструментарий блокировки данных в схеме производительности. Когда транзакция A является блокировкой строки R, а транзакция B ожидает в этой самой строке, B фактически блокируется A. Добавленный инструментарий раскрывает, какие данные заблокированы (R), кто владеет блокировкой (A), и кто ждет данные (B).

Пример запроса Digest

В MySQL 8.0 внесены некоторые изменения в таблицу схем показателей events_statements_summary_by_digest, чтобы получить полный примерный запрос и некоторую ключевую информацию об этом примере запроса. Столбец QUERY_SAMPLE_TEXT добавлен для захвата образца запроса, чтобы пользователи могли запускать EXPLAIN в реальном запросе и получать план запроса. Добавлен столбец QUERY_SAMPLE_SEEN для захвата временной метки образца запроса. Добавлен столбец QUERY_SAMPLE_TIMER_WAIT для захвата времени выполнения выборки запроса. Колонки FIRST_SEEN и LAST_SEEN были изменены для использования дробных секунд.

Метаданные о инструментах

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

Регистрация ошибок

MySQL 8.0 обеспечивает тщательную обработку журнала ошибок MySQL. С точки зрения архитектуры программного обеспечения, журнал ошибок становится компонентом новой инфраструктуры сервиса. Это означает, что продвинутые пользователи могут при необходимости создать собственную версию журнала ошибок. Большинство пользователей не хотят писать собственную версию журнала ошибок, но все же хотят иметь некоторую свободу относительно того, что и где писать. Следовательно, 8.0 предлагает пользователям возможность добавлять емкости (где) и фильтры (что). MySQL 8.0 реализует службу фильтрации (API) и реализацию (компонент) службы фильтрации по умолчанию. Фильтрация здесь означает подавление определенных сообщений журнала (выбор) и / или полей в пределах данного сообщения журнала (проецирования). MySQL 8.0 реализует службу записи журнала (API) и реализацию (компонент) службы записи журнала по умолчанию. Утилиты записи журналов принимают событие журнала и записывают его в журнал. Этот журнал может быть классическим файлом, syslog, EventLog и новой утилитой записи журнала JSON.

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

Нумерация ошибок: формат представляет собой номер в серии 10000, которому предшествует «MY-», например «MY-10001». Номера ошибок будут стабильными в версии GA, но соответствующие тексты ошибок могут меняться (то есть улучшаются) в версиях обслуживания.
Системные сообщения. Системные сообщения записываются в журнал ошибок как [System] вместо [Error], [Warning], [Note]. Сообщения [System] и [Error] печатаются независимо от подробностей и не могут быть подавлены. Сообщения [System] используются только в нескольких местах, в основном связанных с основными переходами состояния, такими как запуск или остановка сервера.
Уменьшенная детализация: значение по умолчанию log_error_verbosity изменяется от 3 (примечаний) до 2 (предупреждение). Это делает журнал ошибок MySQL 8.0 менее подробным по умолчанию.
Компонент источника. Каждое сообщение аннотируется одним из трех значений [Server], [InnoDB], [Replic], в котором представлена подсистема, из которой поступает сообщение.

Это то, что записывается в журнал ошибок в 8.0 GA после запуска:

2018-03-08T10:14:29.289863Z 0 [System] [MY-010116] [Server] /usr/sbin/mysqld (mysqld 8.0.5) starting as process 8063

2018-03-08T10:14:29.745356Z 0 [Warning] [MY-010068] [Server] CA certificate ca.pem is self signed.

2018-03-08T10:14:29.765159Z 0 [System] [MY-010931] [Server] /usr/sbin/mysqld: ready for connections. Version: '8.0.5' socket: '/tmp/mysql.sock' port: 3306 Source distribution.

2018-03-08T10:16:51.343979Z 0 [System] [MY-010910] [Server] /usr/sbin/mysqld: Shutdown complete (mysqld 8.0.5) Source distribution.

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

Управляемость

Невидимые индексы

MySQL 8.0 добавляет возможность переключения видимости индекса (видимый / невидимый). Оптимизатор не учитывает невидимый индекс при выполнении плана выполнения запроса. Тем не менее, индекс по-прежнему поддерживается в фоновом режиме, поэтому выгодно сделать его видимым снова. Цель этого заключается в том, чтобы DBA / DevOp определял, можно ли отменить индекс или нет. Если вы подозреваете, что индекс не используется, вы сначала делаете его невидимым, затем контролируете производительность запросов и, наконец, удаляете индекс, если не происходит замедление запросов. Эта функция была предложена многими пользователями, например, с помощью Bug # 70299.

Гибкое управление табличными пространствами Undo

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

Больше нет журнала Undo в системном табличном пространстве. Журнал Undo переносится из табличного пространства System и в табличные пространства Undo во время обновления. Это дает путь обновления для существующей установки 5.7 с использованием системного табличного пространства для журналов отмены.
Табличными пространствами Undo можно управлять отдельно от системного табличного пространства. Например, табличные пространства Undo можно разместить на быстрой памяти.
Извлеките пространство, сделанное необычно крупными транзакциями (онлайн). Создано не менее двух табличных пространств Undo для усечения табличного пространства. Это позволяет InnoDB сокращать табличное пространство Undo, поскольку одно табличное пространство Undo может быть активным, а другое - усеченным.
Больше сегментов отката приводит к меньшему количеству конкурентов. Пользователь может выбрать до 127 таблиц Undo, каждая из которых имеет до 128 сегментов отката. Дополнительные сегменты отката означают, что параллельные транзакции с большей вероятностью будут использовать отдельные сегменты отката для своих журналов отмены, что приводит к меньшему конфликту за одни и те же ресурсы.

SET PERSIST для глобальных переменных

MySQL 8.0 позволяет сохранять глобальные динамические переменные сервера. Многие серверные переменные являются GLOBAL и DYNAMIC и могут быть переконфигурированы во время работы сервера. Например: SET GLOBAL sql_mode = 'STRICT_TRANS_TABLES'; Однако такие параметры теряются при перезагрузке сервера.

Эта работа позволяет писать SET PERSIST sql_mode = 'STRICT_TRANS_TABLES'; Эффект заключается в том, что этот параметр выдержит перезагрузку сервера. Существует много сценариев использования этой функции, но, самое главное, это дает возможность управлять настройками сервера при редактировании файлов конфигурации неудобно или нет. Например, в некоторых размещенных средах у вас нет доступа к файловой системе, - все, что у вас есть, это возможность подключения к одному или нескольким серверам. Что касается SET GLOBAL, вам нужна супер привилегия для SET PERSIST.

Существует также команда RESET PERSIST, которая имеет семантику удаления переменной конфигурации из конфигурации persist, таким образом, ее преобразование имеет аналогичное поведение, как SET GLOBAL.

MySQL 8.0 позволяет SET PERSIST устанавливать большинство переменных только для чтения, новые значения вступают в силу при следующем перезапуске сервера. Обратите внимание, что небольшое подмножество переменных только для чтения оставляется намеренно недоступным.

Удаленное управление

MySQL 8.0 реализует команду SQL RESTART. Целью является дистанционное управление сервером MySQL через соединение SQL, например, для установки нединамической переменной конфигурации SET PERSIST, за которой следует RESTART.

Переименование табличного пространства (SQL DDL)

MySQL 8.0 реализует ALTER TABLESPACE s1 RENAME TO s2; Поделенное / общее табличное пространство является объектом, видимым пользователем, к которому пользователи могут применять CREATE, ALTER и DROP. См. также «Ошибка № 26949», «Ошибка № 32497» и «Ошибка № 58006».

Переименование столбца (SQL DDL)

MySQL 8.0 реализует ALTER TABLE ... RENAME COLUMN old_name TO new_name; это улучшение по сравнению с существующим синтаксисом ALTER TABLE <table_name> CHANGE ..., который требует повторной спецификации всех атрибутов столбца. Старый / существующий синтаксис имеет такой недостаток, что вся информация о столбцах может быть недоступна для приложения, пытающегося выполнить переименование. Также существует риск случайного изменения типа данных в старом / существующем синтаксисе, который может привести к потере данных.

Функции безопасности

Новый плагин аутентификации по умолчанию

MySQL 8.0 изменяет плагин аутентификации по умолчанию с mysql_native_password на caching_sha2_password. Соответственно, libmysqlclient также будет использовать caching_sha2_password в качестве механизма аутентификации по умолчанию. Новый caching_sha2_password сочетает лучшую безопасность (алгоритм SHA2) с высокой производительностью (кэширование). Общее направление состоит в том, что мы рекомендуем всем пользователям использовать TLS / SSL для всей их сетевой связи.

OpenSSL по умолчанию в Community Edition

MySQL 8.0 объединяет OpenSSL как стандартную библиотеку TLS / SSL для MySQL Enterprise Edition и MySQL Community Edition. Ранее MySQL Community Edition использовала YaSSL. Поддержка OpenSSL в MySQL Community Edition была одной из наиболее часто запрашиваемых функций.

OpenSSL динамически связан

MySQL 8.0 динамически связан с OpenSSL. С точки зрения пользователей MySQL репозитория пакеты MySQL зависят от файлов OpenSSL, предоставляемых системой Linux под рукой. Благодаря динамической привязке обновления OpenSSL могут применяться при доступности без необходимости обновления или патча MySQL. См. Сообщение в блоге от Frédéric Descamps.

Шифрование журнала UNDO и REDO

MySQL 8.0 реализует шифрование данных в режиме останова в журналах UNDO и REDO. В 5.7 было введено табличное шифрование таблиц InnoDB, хранящихся в табличных пространствах файлов за таблицей. Эта функция обеспечивает шифрование при отключении для файлов данных физического табличного пространства. В 8.0 это распространяется на включение журналов UNDO и REDO.

Роли SQL

MySQL 8.0 реализует SQL-роли. Роль - это именованная коллекция привилегий. Целью является упрощение управления правами доступа пользователей. Можно предоставлять роли пользователям, предоставлять привилегии ролям, создавать роли, ронять роли и определять, какие роли применимы во время сессии.

Предоставление и отмена полномочий

MySQL 8.0 вводит обязательные роли конфигурации, которые могут использоваться для автоматического назначения и предоставления ролей по умолчанию при создании новых пользователей. Пример: role1 @%, role2, role3, role4 @ localhost. Все указанные роли всегда считаются предоставленными каждому пользователю и не могут быть отменены. Эти роли по-прежнему требуют активации, если они не включены в роли по умолчанию. Когда новая переменная конфигурации сервера activate-all-roles-on-login устанавливается на «ON», все предоставленные роли всегда активируются после аутентификации пользователя.

Дробление супер привилегий

MySQL 8.0 определяет набор новых детализированных привилегий для различных аспектов того, что SUPER используется в предыдущих выпусках. Цель состоит в том, чтобы ограничить права доступа пользователей к тому, что необходимо для работы под рукой, и не более того. Например, BINLOG_ADMIN, CONNECTION_ADMIN и ROLE_ADMIN.

Модель авторизации для управления XA-транзакциями

MySQL 8.0 представляет новую системную привилегию XA_RECOVER_ADMIN, которая контролирует возможность выполнения оператора XA RECOVER. Попытка выполнить XA RECOVER пользователем, которому не была предоставлена новая системная привилегия XA_RECOVER_ADMIN, приведет к ошибке.

Политика ротации пароля

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

Медленная атака грубой силы на пароли пользователей

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

skip-grant-tables

MySQL 8.0 запрещает удаленные подключения при запуске сервера с помощью -skip-grant-tables.

Добавление функциональности mysqld_safe на сервер

MySQL 8.0 реализует части логики, которые в настоящее время находятся в скрипте mysqld_safe внутри сервера. Работа улучшает удобство использования сервера в некоторых сценариях, например, при использовании опции -daemonize startup. Работа также делает пользователей менее зависимыми от сценария mysqld_safe, который, вероятно, будет в ближайшем будущем устранен. Он также исправляет ошибку # 75343.

Производительность

MySQL 8.0 поставляется с лучшей производительностью для рабочих нагрузок Read / Write, рабочих нагрузок с привязкой IO и высокой рабочей нагрузки критических участков кода. Кроме того, новая функция Resource Group предоставляет пользователям возможность оптимизировать определенные рабочие нагрузки на конкретном оборудовании путем сопоставления пользовательских потоков с процессорами.

Масштабирование рабочих нагрузок чтения / записи

MySQL 8.0 хорошо масштабируется для RW и больших загрузок. На интенсивных рабочих нагрузках RW мы наблюдаем более высокую производительность уже от 4 одновременных пользователей и более чем в 2 раза более высокую производительность при высоких нагрузках по сравнению с MySQL 5.7. Можно сказать, что в то время как 5.7 значительно улучшила масштабируемость для рабочих нагрузок только для чтения, 8.0 значительно улучшает масштабируемость для рабочих нагрузок чтения / записи. Эффект заключается в том, что MySQL улучшает аппаратное использование (эффективность) для стандартного оборудования на стороне сервера (например, системы с 2 гнездами процессора). Это улучшение связано с перестройкой, как InnoDB пишет в журнал REDO. В отличие от исторической реализации, когда пользовательские потоки постоянно борются за регистрацию своих изменений данных, в новом решении журнала REDO пользовательские потоки теперь блокируются, REDO-запись и очистка управляются выделенными фоновыми потоками, а вся обработка REDO становится управляемой событиями.

Использование емкости ввода-вывода (быстрое хранение)

MySQL 8.0 позволяет пользователям использовать все устройства хранения в полной мере. Например, при тестировании с помощью флеш-устройств Intel Optane разработчики MySQL смогли выйти из 1M Point-Select QPS в полной нагрузке с привязкой к IO. (Привязка IO означает, что данные не кэшируются в пуле буферов, а должны быть получены из вторичного хранилища). Это улучшение связано с избавлением от глобальной блокировки fil_system_mutex.

Лучшая производительность при высоких конкурирующих нагрузках («горячие строки»)

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

Группы ресурсов

MySQL 8.0 представляет глобальные группы ресурсов для MySQL. С группами ресурсов DevOps / DBAs могут управлять отображением между потоками пользователей / систем и процессорами. Это можно использовать для разделения рабочих нагрузок между процессорами, чтобы повысить эффективность и / или производительность в некоторых случаях использования. Таким образом, группы ресурсов добавляют инструмент в панель инструментов DBA, который может помочь администратору баз данных увеличить использование аппаратного обеспечения или повысить стабильность запросов. В качестве примера, с рабочей нагрузкой Sysbench RW, работающей на процессоре Intel® R / Xeon (R) E7-4860 2.27 ГГц 40 ядро-HT, была удвоена общая пропускная способность с ограничением нагрузки Write на 10 ядер. Группы ресурсов - довольно продвинутый инструмент, который требует эффективного использования DevOps / DBA, поскольку эффекты будут варьироваться в зависимости от типа нагрузки и наличия оборудования.

Другие преимущества

Улучшенные значения по умолчанию

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

Протокол

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

C Client API

MySQL 8.0 расширяет API C libmysql со стабильным интерфейсом для получения событий репликации с сервера в виде потока пакетов. Цель состоит в том, чтобы избежать необходимости вызывать недокументированные API и упаковывать внутренние файлы заголовков для реализации программ на основе binlog, таких как MySQL Applier for Hadoop.

Memcached

MySQL 8.0 улучшает функциональность InnoDB Memcached с несколькими операциями получения и поддержкой запросов диапазона. Была добавлена поддержка операции множественного ввода для дальнейшего улучшения производительности чтения, то есть пользователь может получить несколько пар значений ключа в одном запросе memcached. С запросами диапазона пользователь может указать конкретный диапазон и получить все допустимые значения в этом диапазоне. Обе функции могут значительно сократить количество обращений между клиентом и сервером.

Устойчивые счетчики Autoinc

MySQL 8.0 хранит счетчики AUTOINC, записывая их в журнал повтора. Это исправление для очень старой ошибки # 199. Процесс восстановления MySQL будет воспроизводить журнал повтора и обеспечить правильные значения счетчиков AUTOINC. Откат счетчиков AUTOINC не будет. Это означает, что восстановление базы данных восстановит последнее известное значение счетчика после сбоя. Он поставляется с гарантией того, что счетчик AUTOINC не может получить одно и то же значение дважды. Счетчик монотонно увеличивается, но обратите внимание, что могут быть пробелы (неиспользуемые значения). Отсутствие постоянного AUTOINC было замечено как проблематичное в прошлом.

Резюме

Как показано выше, MySQL 8.0 поставляется с большим набором новых функций и улучшением производительности. Загрузите его с dev.mysql.com и испытайте!

Вы также можете обновить существующий MySQL 5.7 до MySQL 8.0. Вы можете попробовать новый Upgrade Checker, который поставляется с новой оболочкой MySQL (mysqlsh). Эта утилита проанализирует ваш существующий сервер 5.7 и расскажет вам о потенциальной несовместимости 8.0.