23 ноября 2025 года вышел первый стабильный релиз ветки MariaDB 12.1 — версия 12.1.2. Эта ветка относится к rolling-релизам: фичи сюда прилетают быстрее, чем в долгоживущие LTS-линейки, но и обновляться нужно с головой, а не вслепую ночью в пятницу.
Официальный анонс можно посмотреть на сайте MariaDB. А я ниже пробегусь по изменениям простым языком, без маркетинга, с прицелом на реальные сервера — в первую очередь на Debian (Ubuntu тоже можно, но под сервер я всё равно чаще ставлю именно Debian).
Коротко про контекст:
- MariaDB — это форк MySQL, который давно пошёл своим путём, но сохранил совместимость по протоколу и SQL.
- Проектом рулит MariaDB Foundation, а не один вендор.
- Во многих дистрибутивах Linux MariaDB ставится вместо MySQL по умолчанию.
Ветка 12.1 — это:
- свежие фичи;
- быстрые минорные релизы;
- не LTS, то есть не та серия, которую ставят в банки и забывают на годы.
Я бы смотрел на 12.1 так:
- для новых проектов и тестовых стендов — отличный кандидат;
- для продакшена — да, но после тестов и с нормальным планом отката;
- если нужен “бетон” на годы — оставить LTS-ветку и наблюдать.
В движке хранения Aria появился сегментированный кэш ключей. Раньше все лезли в один общий кэш, как к одному холодильнику на общагу. Теперь кэш можно делить на сегменты, и параллельные запросы меньше мешают друг другу.
Настраивается это так:
SET GLOBAL aria_pagecache_segments = 8; -- от 1 до 128, по умолчанию 1
Где полезно:
- много параллельных запросов;
- активные Aria-таблицы (логи, временные данные);
- сервер, который под нагрузкой постоянно “задумывается” на ровном месте.
Чем больше ядер и клиентов — тем заметнее эффект.
MDL (Metadata Lock) — это блокировки на уровне схемы: когда один клиент меняет структуру таблицы, а остальные в это время не должны уехать в параллельную вселенную.
В 12.1 разработчики подтянули масштабируемость MDL. На практике это даёт:
- меньше подвисаний вида “Table metadata lock”;
- более предсказуемое поведение при миграциях и тяжёлых DDL;
- приятную жизнь на серверах с десятками и сотнями подключений.
Если вы используете Galera Cluster, есть хорошая новость: при асинхронной репликации между двумя кластерами теперь можно включить параллельную репликацию.
Типичный сценарий:
- есть основной кластер;
- есть резервный или отчётный кластер;
- между ними крутится репликация.
Раньше события часто применялись последовательно, сейчас можно разложить их по потокам и быстрее догонять мастера. Для распределённых систем и DR-схем — прям плюс в копилку.
Плагин server_audit наконец-то научился буферизовать записи в файл.
Появилась настройка:
SET GLOBAL server_audit_file_buffer_size = 1048576; -- например, 1 МБ
Вместо записи каждого события по отдельности база может собирать их в буфер и писать пачкой. В итоге:
- меньше I/O;
- меньше системных вызовов;
- аудит остаётся подробным, но перестаёт быть тормозом.
Если по требованиям безопасности логировать нужно всё и вся — обновление заметное.
Тип данных VECTOR, который нужен для работы с embedding-ами и “умным” поиском, в 12.1.2 заметно ускорили. Операции поиска по векторам стали примерно на 30–50% быстрее.
Где это может пригодиться:
- семантический поиск по текстам;
- подбор похожих товаров/статей/фильмов;
- рекомендательные системы для небольших проектов, где отдельная векторная база — это уже перебор.
Если вы строите что-то с поиском “по смыслу”, MariaDB 12.1 смотрится гораздо интереснее.
Добавили плагин caching_sha2_password:
- использует SHA-2 вместо SHA-1;
- совместим с одноимённым механизмом в новых MySQL.
Это нормальный шаг вперёд по безопасности. Для свежих проектов логично сразу планировать работу с этим плагином, чтобы потом не мигрировать пароли в спешке.
Для режима совместимости с Oracle завезли:
- ассоциативные массивы (INDEX BY);
- поддержку синтаксиса внешних объединений через
(+).
Если у вас живёт старый Oracle-код, который хочется аккуратно переносить на MariaDB, теперь придётся меньше переписывать руками. Для миграционных проектов это важно.
В 12.1 стало больше опций, которыми можно управлять оптимизатором: [NO_]JOIN_INDEX, [NO_]GROUP_INDEX, [NO_]ORDER_INDEX и так далее.
Смысл простой: если оптимизатор упорно выбирает “не тот” план, вы можете аккуратно ткнуть его носом в нужный путь. Это уже история для сложных отчётных запросов и больших схем, но иметь такие рычаги полезно.
В mariadb-dump появилась поддержка масок через --wildcards. Пример:
mariadb-dump -u root -p -L --wildcards "client*_shop" > shops.sql
То есть можно одной командой вытащить сразу группу баз по шаблону, без дополнительных скриптов, которые сначала собирают их список.
Пара приятных мелочей:
- имена внешних ключей (
FOREIGN KEY) теперь должны быть уникальны только в рамках таблицы, а не всей БД; - появились функциональные индексы — индексы на выражениях, например
LOWER(email)илиDATE(created_at).
Пример функционального индекса:
CREATE INDEX idx_lower_email ON users ((LOWER(email))); SELECT * FROM users WHERE LOWER(email) = 'user@example.com' ORDER BY LOWER(email);
Раньше такие запросы плохо использовали индекс и часто всё сортировали в лоб. Теперь оптимизатор понимает, что выражение уже проиндексировано, и работает быстрее.
Стандартные репозитории Debian/Ubuntu обычно живут на более консервативных версиях MariaDB. Если хочется поставить именно 12.1.2, есть два нормальных пути:
- Подключить официальный репозиторий MariaDB и поставить
mariadb-server-12.1черезapt. Конфиг для APT удобно сгенерировать на сайте MariaDB (там есть генератор репозиториев). - Использовать Docker-образ MariaDB 12.1.2, а данные хранить в примонтированном томе.
Лично я всё чаще выбираю второй вариант:
- легче откатываться;
- не мешается с системной MySQL/MariaDB;
- удобно переносить между серверами.
Моё видение такое.
Обновляться смело:
- dev-стенды, тестовые окружения;
- новые проекты;
- Galera-кластеры, где важна скорость асинхронной репликации;
- любые истории, где нужен VECTOR, функциональные индексы и свежая Oracle/MySQL-совместимость.
Обновляться аккуратно, но имеет смысл:
- продакшены на MariaDB 12.0 — логичный шаг пойти дальше на 12.1;
- крупные инсталляции на 11.x, если очень нужны новые фичи.
Подождать:
- консервативные системы, где всё и так работает и важнее LTS и предсказуемость;
- проекты, в которых никто даже не слышал слова “VECTOR”, а база просто хранит обычные таблички.
Чтобы потом не вспоминать этот апгрейд как страшный сон:
- Сделать бэкап всего.
И дамп, и файловую копию каталога данных. - Развернуть тест.
Поднять копию БД на 12.1.2 и прогнать критичные сценарии и отчёты. - Проверить конфиги.
Aria, Galera, аудит, логирование, лимиты памяти. - Следить за мониторингом.
Сравнить нагрузку и задержки “до” и “после”.
MariaDB 12.1.2 — живой, рабочий стабильный rolling-релиз:
- быстрее Aria и VECTOR;
- умнее работа Galera;
- аккуратнее аудит;
- плюс удобные мелочи вроде функциональных индексов и масок в
mariadb-dump.
Если вы на Debian/Ubuntu, любите современные фичи и готовы нормально тестировать, эта ветка явно стоит внимания. Главное — не превращать апгрейд в аттракцион “жми apt upgrade прямо на проде”. Бэкапы, тест, план отката — и MariaDB 12.1 будет радовать, а не портить выходные.
