Сравнение MySQL vs MariaDB. MariaDB замена MySQL сравнение Движок БД - что это такое

MariaDB - программа для работы с базами данных. Является свободно распространяемым приложением, которое было создано, как альтернатива лицензионного MySQL. По принципу своей работы очень схожа с идентичным продуктом компании Oracle. СУБД поддерживает стандартные функции и форматы: myisam, blackhole, csv. Поддерживает такие же клиентские интерфейсы API, протоколы и структуры, как и MySQL. Все коннекторы (PHP, Perl, Python, Java, .NET, MyODBC, Ruby) отлично взаимодействуют с системой управления БД. Время выполнения запроса значительно меньше, чем у лицензионного аналога. Репликации протекают быстрее и безопаснее. Улучшен асинхронный ввод-вывод для таблиц InnoDB. Поддерживает сегментирование кеша для MyISAM. Это позволяет ускорить работу с MyISAM-таблицами в 4 раза.

- Позволяет работать с различными базами данных.
- Представляет собой систему управления базами хранения данных.
- Поддерживает множество клиентских приложений и API.
- Отлично подключается к большинству коннекторов.
- Позволяет создавать различные базы для хранения информации.
- Механизм хранения Aria позволяет быстрее обрабатывать сложные запросы.
- Поддерживает функцию «Убить все запросы для пользователя».
- Имеет богатый набор улучшенных функций.
- Имеет улучшенный асинхронный ввод-вывод для таблиц MyISAM.
- Поддерживает параллельные репликации.
- Имеет множество оптимизированных параметров.
- Отличное решение для веб-разработчиков, предпочитающих свободно распространяемое ПО.
- Есть поддержка русского языка.

- Процессор с тактовой частотой 1200 MHz или более мощный.
- Оперативная память 256 Мб или больше.
- Свободное место на жёстком диске от 636 Мб.
- Архитектура с разрядностью 32 бит или 64 бит (x86 или x64).
- Операционная система Windows XP, Windows Vista, Windows 7, Windows 8, Windows 10

СУБД: Таблицы сравнения

Оригинальная версия MySQL была разработана фино-шведской компанией MySQL AB, которую основали Джвид Ахмарк, Аллан Ларссон и Майкл Монти. Первая версия MySQL появилась в 1995 году. Изначально она предназначалась для личного пользования, но спустя несколько лет превратилась в базу данных корпоративного уровня.

В январе 2008 Sun Microsystems приобрела MySQL AB за 1 миллиард долларов. Вскоре после этого, Oracle купила Sun Microsystems с разрешения Европейской комиссии, которая изначально опасалась, что такое решение повредить свободному проекту MySQL, поскольку он был прямым конкурентом СУБД Oracle. Из-за недоверия к стратегии развития MySQL был создан форк под названием MariaDB.

Шли годы и за это время MariaDB начала использоваться во многих дистрибутивах Linux по умолчанию. Она используется для обеспечения работы большинства сайтов интернета. В этой статье мы попытаемся выполнить сравнение MySQL vs MariaDB и разобраться почему вторая лучше первой и когда нужна именно оригинальная MySQL.

В отличие от многих других проектов с открытым исходным кодом полученных от Sun Microsystems, Oracle до сих пор развивает MySQL. После того как много разработчиков подали в отставку, были наняты новые люди. Но разработка новых версий MySQL ведется закрыто. Исходный код доступен только команде разработчиков и выгружается в публичный репозиторий только после завершения работы. Все решения обсуждаются внутри компании

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

Из-за раскрученности бренда у MySQL все еще есть большое сообщество, но все больше и больше проектов переходят на MariaDB. Такие известные корпоративные дистрибутивы, как REHL 7 и SLES 12 уже используют MariaDB, а это значит, что в сражении MySQL или MariaDB победит последняя.

2. Частота релизов

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

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

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

4. Возможности и функциональность

В целом MariaDB развивается быстрее и имеет больше возможностей. Эти возможности касаются оптимизации, улучшения работы с памятью, и много другого. Обычно, со временем, эти возможности переносятся в MySQL. Например, та же поддержка GIS появилась в MariaDB раньше, чем в MySQL. Среди прочего MariaDB имеет множество улучшений производительности Inodb, MyISAM и движка обработки запросов, поддерживает GIS, ликвидацию таблиц, виртуальные и динамические колонки, репликацию с несколькими источниками, роли и многое другое.

Но у MariaDB есть и свои минусы, она не поддерживает некоторые возможности, которые есть в MySQL. А именно, MariaDB несовместима с синтаксисом JSON MySQL, не поддерживаются плагины ngram, MeCab, MySQL X, а также пространства таблиц, которые позволяют присваивать данные нескольким таблицам одновременно. Но разработчики активно работают над исправлением недостатков.

Для тех, кого интересуют кластеры MySQL будет интересно то, что в MariaDB используется новая система репликации Galera, прием ее работа отличается от стандартного master-salve. Galera разрабатывается с 2007 года, но она никогда не включалась в официальную версию MySQL.

5. Поддержка движков хранения данных

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

• Aria;
• XtraDB - улучшенная версия InnoDB;
• FederatedX - улучшенная версия Federated;
• OQGRAPH;
• SphinxSE;
• IBMDB2I;
• TokuDB;
• Cassandra;
• CONNECT;
• SEQUENCE;
• Spider;
• ColumnStore;
• MySIAM.

Напомню, что оригинальная MySQL поддерживает по умолчанию только три типа таблиц - Aria, MySIAM и InnoDB. Это важный аспект в выборе MySQL или MariaDB.

6. Имя и нумерация версий

Эти отличия MariaDB от MySQL не столь важны, но, возможно, они будут кому-то интересными. Имя MySQL было дано в честь первой дочери одного из разработчиков - Майкл Монти, ее зовут My. Разработку MariaDB продолжил тот же человек и на этот раз программа была названа в честь его младшей дочери - Марии.

Что касается версий, то изначально, до версии 5.6 версии MariaDB нумеровались синхронно до версий MySQL, на которых они были основаны. Но когда накопилось достаточно изменений и за основу стал браться код MariaDB номера версий было принято поменять на 10. С того момента нумерация MariaDB выполняется только так.

Выводы

В этой статье мы сделали сравнение MySQL vs MariaDB. По большинству параметров MariaDB намного лучше, чем MySQL, поэтому не зря большинство дистрибутивов Linux теперь используют ее по умолчанию в своих репозиториях. Оригинальная версия может понадобиться только в очень редких случаях.

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

Что такое MariaDB?

MariaDB - это альтернативная MySQL СУБД, которую разрабатывает автор MySQL Michael "Monty" Widenius. Основная цель проекта MariaDB - создание полностью бинарно совместимой с оригинальной MySQL версии СУБД, которая при этом будет иметь значительное количество улучшений в коде, влияющих на производительность. MariaDB разрабатывается как drop-in замена для MySQL, полностью имитируя поведение MySQL.

Почему вообще Monty решил сделать клон своего же детища? Дело в том, что права на MySQL принадлежат компании MySQL AB, которую сначала купили Sun Microsystems, а затем уже Sun продались корпорации Oracle. В итоге Monty решил уйти из Oracle и сделать, в некотором смысле, MySQL "на стероидах".

MariaDB: что в ней есть нового?

MariaDB версий 5.1, 5.2 и 5.3 (beta) базируется на коде MySQL 5.1, но с рядом нововведений и улучшений.

Во-первых, это ряд новых движков (database engine) для хранения данных. А именно: Aria - альтернатива таблицам MyISAM, более быстрая и устойчивая к сбоям. Таблицы Aria используются в MariaDB для внутренних нужд, в частности все temporary tables работают именно на движке Aria, за счет чего в ряде случаев получилось добиться значительно большей производительности на сложных запросах. Кроме того, таблицы InnoDB заменены на XtraDB (альтернатива InnoDB от компании Percona), так же более быстрые, чем оригинал, и более устойчиывые к сбоям.

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

Так же в MariaDB появился новый способ доступа к данным InnoDB - HandlerSocket. HandlerSocket в каком-то смысле является альтернативой memcached. Через интерфейс HandlerSocket с данными в таблицах InnoDB (XtraDB) можно работать как с набором данных "ключ-значение", где в качестве ключа выступает любой из индексов, созданных по любой из InnoDB-таблиц. По скорости работы HandlerSocket практически не уступает memcached и некоторые источники даже сообщают, что им удалось добиться большей, чем с memcached, производительности.

Сравнительные тесты

Для того, чтобы понять, стоит ли овчинка выделки и действительно ли проделанные в MariaDB оптимизации заметны на глаз, мы провели ряд сравнительных тестов. Тесты проводились на сервере в конфигурации HP ProLiant DL160 G6, 2x E5520 Xeon QC CPU (16 cores), 20 Gb RAM, H/W RAID 10: 4x 300 Gb SAS 15k RPM. В качестве теста использовалась утилита mysqlslap следующим образом:

Mysqlslap --auto-generate-sql --concurrency=$i --number-of-queries=$(($i*500)) --iterations=3

то есть мы в цикле меняем переменную $i от 10 до 200, эмулируя при этом одновременную работу от 10 до 200 клиентов, каждый из которых делает по 500 запросов к базе данных. Далее мы замеряем общее время выполнения тестов. Тесты проводились на MariaDB версии 5.1 в сравнении с MySQL тоже версии 5.1

Таблицы MyISAM

Ниже приведены графики замеров производительности MySQL (верхний график) и MariaDB (нижний) на таблицах MyISAM. По оси X изображено количество одновременно работающих клиентов, по Y - время в секундах, затраченное на тест.

Как интерпретировать результаты: чем ниже точка на графике, тем быстрее отработал тест. Судя по графику, уже начиная с 60 одновременно работающих клиентов, MariaDB отработала тесты почти в 1,5 раза быстрее, чем MySQL.

Таблицы InnoDB

Здесь ситуация аналогичная: MariaDB победила, но только перевес здесь гораздо более значительный: производительность InnoDB в MySQL в разы хуже, чем производительность XtraDB в MariaDB.

Следует так же отметить, что данный тест замерял производительность работы только с одной таблицей, поэтому роста производительности на JOIN"ах, и особенно на запросах, выполнение которых делается при помощи создания временных таблиц, на этих графиках не видно. Реально при переходе на MariaDB даже для таблиц MyISAM производительность БД может вырасти в несколько раз.

Обращаем ваше внимание, что версия 5.1 у MariaDB, на которой проводились приведенные тесты, - это первоначальная версия, содержащая минимальный набор улучшений. В реальности мы используем на серверах MariaDB 5.2, а со временем планируем перейти на MariaDB 5.3, где улучшений и оптимизаций еще больше.

Которая вскоре была сама куплена Oracle). Это довольно оправданные сомнения, о которых я поговорю немного позже. Кроме своей роли "упрощенной версии" MySQL, MariaBD также обладает несколькими новыми функциями, которые, по мнению некоторых, делают её лучше MySQL.

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

Команда разработчиков MariaDB, должно быть, знают об этом, так как они решили использовать новую схему нумерации. Самая новая версия MariDB (которая всё ещё является альфа-версией) - Maria 10.0, за которой следует младший номер устройства:

Mysql -P 3406 -u root -p Enter password: ******** Welcome to the MariaDB monitor. Commands end with ; or \g. Your MariaDB connection id is 1 Server version: 10.0.2-MariaDB mariadb.org binary distribution Copyright (c) 2000, 2013, Oracle, Monty Program Ab and others. Type "help;" or "\h" for help. Type "\c" to clear the current input statement. MariaDB [(none)]> select version(); +------+ | version() | +------+ | 10.0.2-MariaDB | +------+ 1 row in set (0.01 sec) MariaDB [(none)]>

Люди, работающие над MariaDB, дают длинное и довольно пространное объяснение, почему они так сделали - что всё ещё разочаровывает некоторых разработчиков - но что есть, то есть. Они не могут продолжать добавлять новые функции и постоянно утверждать, что это ускоренная, полностью совместимая с MySQL версия.

Так что за новые функции? Давайте рассмотрим парочку из них.

Движок Cassandra

Одной из уникальных функций MariaDB является её движок для соединения с серверной версией СУБД Cassandra. Сам движок является просто посредником, который соединяется с сервером Cassandra, запущенным отдельно. Cassandra - это NoSQL хранилище данных, которое изначально было создано для Facebook , а затем стало проектом Apache ; хотя оно и может использоваться в кластерах без единой точки отказа, оно всё ещё не является совместимым с ACID. Вообще, если вы собираетесь использовать Cassandra в качестве движка, не ожидайте такой же скорости производительности, как у InnoDB или ExtraBD.

Но вы можете получить доступ к информации с помощью MySQL, добавив интерфейс, похожий на SQL , а также допуская в какой-то степени выборки, вставки, обновления, удаления и даже присоединения. Однако команда MariaDB утвержает, что движок Cassandra лучше не использовать для чего-то более существенного, чем простое использование данных.

Так что эта функция может быть полезной, если вы... мм... дайте подумать... ну...

Если вы пишете программное приложение, которое требует доступа к данным в Cassandra, тогда вам, возможно, лучше использовать встроенный Cassandra API, а не MySQL. Полагаю, что если вы мучаетесь с интерфейсом командной строки MySQL и нужно взять кое-какие данные, то Cassandra может оказаться полезной - но если вы собираетесь воспользоваться этим, то не проще ли помучаться с интерфейсом командной строки Cassandra?

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

Движок OQGraph

Не буду слишком много о нём рассказывать, так как идея та же, что и в Cassandra: движок является просто интерфейсом вычислительного движка Open Query Graph (хранилища для организации сложных графов). Это может помочь в некоторых специализированных приложениях, хотя адаптация структур графов к SQL формату является на первый взгляд немного странной.

Одним важным улучшением, что делает MariaDB более мощной, является использование XtraDB в качестве ускоренного замещения InnoDB. Но XtraDB добавляет новые возможности масштабирования, в которых нуждаются современные приложения - и именно в этом заключается главное отличие. Oracle утверждает, что на данный момент MySQL масштабирует лучше, чем когда-либо раньше. Возможно, это так и есть, но она хороша так же, как и её движок. А если движок на практике не масштабирует так, как следует, то и MySQL не сможет сделать этого лучше.

Режим атомарной записи

Одной из главных причин, почему следует выбирать реляционную базу данных, а не обычную NoSQL, является то, что реляционная база полностью совместима с ACID. Проще говоря, если возникает какая-либо ошибка, никто не хочет, чтобы все данные исчезли. И хотя на компьютерах разработчиков ошибки - явление не частое, они всё ещё происходят во многих IT центрах. На данный момент, стандартный InnoDB/XtraDB движок для записи данных использует двойную буферизацию , чтобы гарантировать успешную запись данных в случае какого-либо сбоя. Как бы то ни было, при работе с высокоскоростными SSD устройствами (возьмём в качестве примера), двойной буфер может плохо сказаться на производительности, не давая вам возможности использовать всю скорость SSD. Какое решение? Вы можете выбрать один буфер и воспользоваться режимом атомарной записи (Atomic Writes). Попробуйте на свой страх и риск и, лучше не на производстве.

Повторюсь, функция интересная, но не настолько, чтобы убедить вас забросить MySQL и перейти на MariaDB.

Сравнение производительности MySQL и MariaDB

А сейчас я хочу обратить ваше внимание на сравнительные тесты, проведенные командой MariaDB, и добавить кое-какие комментарии. В этом блоге выдвинута интересная точка зрения: если потоков меньше 16, MySQL работает хорошо, а если их количество больше - хотя, конечно, производительность продолжает немного расти, но не так хорошо, как в других версиях, с которыми её сравнивали (включая MariaDB-5.5.28a и MariaDB-10.0.1; посмотрите график теста производительности в начале этой статьи). Это довольно часто встречающаяся проблема в параллельном программировании при попытке ориентации на несколько ядер и потоков внутри ядра. Если построенные алгоритмы верны, то вы будете ощущать преимущества по мере увеличения ядер. Проблема в том, что вам придётся использовать в своём параллельном программировании 2 метода: 1) многопотоковый на нескольких ядрах и 2) векторизацию. Эти методы являются двумя сторонами нынешнего многоядерного программирования, и ваш код должен корректно их использовать.

Одним из наиболее распространённых результатов неправильного кодирования является то, что вы будете наблюдать прирост производительности при работе с первыми 8 или 16 потоками, после чего никакого улучшения наблюдаться не будет. Если у вас возникла такая проблема, то скорее всего дело в алгоритмах. И это будет в случае или с гиперпотоками, или с аппаратными потоками. Это именно то, что мы наблюдаем в тестах MySQL. Для меня это означает наличие проблем с масштабированием в MySQL, и это повод задуматься. В том же тесте у MariaDB также наблюдались некоторые проблемы, т.к. производительность уменьшалась, но незначительно; я предполагаю, что это не касается параллельных алгоритмов.

Также я не знаю, насколько хорошо некоторые версии подходили к компьютерам, которые использовались для проведения теста. При компиляции Intel-кода, вам нужно, чтобы компилятор генерировал SIMD-код размера, подходящего для целевой машины. В случае несоответствия вы не получите ожидаемой производительности от вашего кода векторизации. Чтобы сделать это правильно, вам потребуется вставить в код нужные прагмы, затем правильно написать алгоритмы векторизации и, наконец, запустить соответствующие опции компилятора. Знаю, звучит глупо, но я видел программы, изданные с неправильными опциями чаще, чем вы думаете. В любом случае, чистый MySQL-код не был так оптимизирован для поддержки многоядерности и векторизации, как MariaDB.

Больше всего мне хотелось бы увидеть разновидность или MySQL, или MariaDB, скомпилированную специально для сопроцессора Intel Xeon Phi, где код разгружает 61-ядерный cопроцессор, а кто-то пытается раскрутить все 244 потока. К сожалению, у меня нет доступа к такой машине. Также, если вы хотите узнать больше о векторизации и параллельном кодировании, почитайте последнюю книгу сотрудников Intel Джеймса Джефферса (James Jeffers) и Джеймса Райндерса (James Reinders) "Высокопроизводительное программирование для сопроцессора Intel Xeon Phi".

Следует ли переходить?

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

Так следует ли переходить на MariaDB?

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

Поразмышляйте над всеми вопросами насчёт Oracle и её планами по лицензированию MySQL. MySQL с открытыми исходниками идёт вразрез с патентованными и очень конкурентными программами. Только это является поводом для размышлений - будет ли Oracle что-либо предпринимать, чтобы как-то помешать разработке MySQL? Некоторые утверждают , что это уже происходит.

А что насчёт совместимости MySQL и MariaDB? Команда MariaDB усердно работает над тем, чтобы сделать базу данных полностью совместимой с MySQL, и они продолжают устранять ошибки в исходнике. Однако новые функции (а также схема нумерации версий) предполагают, что, несмотря на все усилия, обе платформы будут сильно различаться.

Если Oracle добавит к MySQL некоторые новые функции, которые не поддерживаются MariaDB, то очевидно, что они не будут доступными для вас. А если вы будете пользоваться функциями, отсутствующими в MySQL, вы не сможете обратно на него перейти, учитывая, что у вас были причины перейти на другую платформу. MariaDB подаёт все признаки того, что она довольно долгое время будет в ходу, что нельзя сказать о MySQL. Другими словами, даже если новые функции MariaDB могут и не быть полезными для всех, на мой взгляд, существует более чем достаточно причин, чтобы отказаться от MySQL и полностью перейти на MariaDB.

Одна маленькая ремарка перед тем, как я закончу. Некоторые блоггеры подняли хороший вопрос по поводу соглашений об обслуживании. Если кто-либо из сотрудников вашей компании взял и купил у Oracle соглашение об обслуживании, чтобы помочь вам с MySQL, возможно, чтобы избежать финансовых и правовых вопросов, возникающих при нарушении договора, вам не захочется переходить на MariaDB. Кроме этой, я больше не вижу веских причин, чтобы продолжать пользоваться MySQL.

После полутора лет разработки и пяти предварительных выпусков сформирован первый стабильный релиз новой ветки СУБД MariaDB 10.2, в рамках которой развивается ответвление от MySQL, сохраняющее обратную совместимость и отличающееся интеграцией дополнительных движков хранения и расширенных возможностей. Развитие MariaDB курирует независимая организация MariaDB Foundation в соответствии с полностью открытым и прозрачным процессом разработки, не зависящим от отдельных вендоров. MariaDB поставляется вместо MySQL во многих дистрибутивах Linux (RHEL 7, SUSE 12, Fedora, openSUSE, Slackware, OpenMandriva, ROSA, Arch Linux, Debian 9) и внедрён в таких крупных проектах, как Wikipedia, Google Cloud SQL и Nimbuzz.

Ключевые улучшения MariaDB 10.2:

• Добавлена экспериментальная поддержка движка хранения MyRocks, разработанного Facebook на базе системы хранения RocksDB, оптимизированной для Flash-накопителей. В хранилище MyRocks применяются страницы данных плавающего размера, позволяющие избежать выравнивания по фиксированной границе блока, и модель хранения данных в форме лога (Log Structured Merge Trees), допускающая только дополнение (чистка производится сборщиком мусора). В процессе выполнение запросов в несколько раз сокращено число операций последовательного чтения/записи, что привело к увеличению производительности по сравнению с InnoDB на 20-30% на SDD и до 6 раз на НЖМД при нагрузке с большим числом операций случайной записи. Кроме того, MyRocks позволяет на 50% сократить размер БД по сравнению со сжатым хранилищем InnoDB и в 3.5 раза по сравнению с InnoDB без применения сжатия. Из недостатков MyRocks можно отметить отсутствие поддержки внешних ключей и полнотекстовых индексов;
• Добавлена поддержка оконных функций, задаваемых ключевым словом OVER и позволяющих совершить вычисление над набором строк, связанных с текущей строкой. По аналогии с агрегатными функциями оконные функции позволяют обратиться к другим строкам в процессе обработки результата запроса, но в отличие от агрегатных функций они не группируют результат в одну строку;
• Поддержка общих табличных выражений (выражение «WITH») и рекурсивных общих табличных выражений («WITH RECURSIVE»). Секцию WITH можно использовать для определения подзапросов как локальных временных таблиц, на которые можно много раз ссылаться в запросе. «WITH RECURSIVE» позволяет обращаться к собственному результату, например, можно организовать обход дерева в процессе выполнении запроса;
• Добавлено выражение «CONSTRAINT… CHECK» в блоке «CREATE TABLE» для задания ограничений столбца;
• Реализована возможность указания выражений в блоке DEFAULT, например «b int DEFAULT (a+1)». Обеспечена поддержка указания значений DEFAULT для полей BLOB и TEXT;
• Хранилище InnoDB обновлено до выпуска из состава MySQL 5.7.18 и задействовано по умолчанию (ранее по умолчанию предлагалось ответвление от InnoDB — XtraDB, смысл использования которого потерялся после того, как в InnoDB реализовали большинство основных возможностей XtraDB). В InnoDB добавлена поддержка пространственных индексов (spatial index);
• Добавлено выражение «SHOW CREATE USER», показывающее полное выражение «CREATE USER», использованное для создания указанного пользователя;
• Для выражения «CREATE USER» реализованы опции для ограничения потребления ресурсов и настройки tls/ssl. Например, теперь можно ограничить максимальное число запросов или соединений в час;
• Представлено новое выражение «ALTER USER», позволяющее внести изменения в учётную запись существующего пользователя;
• Сняты многие ограничения для виртуально вычисляемых столбцов;
• Добавлена поддержка выражения «EXECUTE IMMEDIATE» для запуска динамического SQL-выражения, созданного на лету;
• В оператор PREPARE добавлена возможность использования большинства выражений;
• Добавлены функции для работы с данными в формате JSON;
• Добавлен плагин аутентификации, использующий алгоритм ed25519 для хранения паролей;
• В состав сборок для Windows, CentOS, RHEL и Fedora добавлен плагин для расшифровки ключей, используемых в Amazon Web Services (AWS) Key Management Service (KMS), для их последующего использования для шифрования данных в БД;
• Появилась возможность привязки нескольких разных триггеров к одному событию;
• Добавлена поддержка отложенной репликации, при которой состояние slave-сервера на заданный промежуток времени отстаёт от master-сервера;
• Переработана реализация выражения ANALYZE TABLE, которое теперь не блокирует таблицу во время сбора статистики;
• Библиотека wsrep, используемая для организации синхронной multi-master (active-active) репликации Galera, обновлена до выпуска 25.3.20;
• Обеспечено формирование пакетов для Ubuntu 17.04;
• В mysqldump добавлена опция «—add-drop-trigger», воспроизводящая функциональность MySQL 5.6 по добавлению в SQL-дамп выражения для удаления триггера перед его созданием;
• Добавлен скрипт mysqlbinlog для организации непрерывного бэкапа бинарного лога;
• Добавлена поддержка OpenSSL 1.1 и LibreSSL;
• Добавлены переменные innodb_deadlock_detect и innodb_stats_include_delete_marked для отключения система определения взаимных блокировок и учёта записей, помеченных как удалённые, при расчёте статистики;
• Добавлена переменная read_binlog_speed_limit, задающая ограничение скорости с которой slave-сервер читает бинарный лог master-сервера;
• Удалена старая клиентская библиотека, поставляемая под лицензией GPL, на смену которой пришла новая библиотека, имеющая лицензию LGPL.