MariaDB 13.0.1 опубликована 29 мая 2026 года как Release Candidate для ветки 13.0. Это важный этап перед стабильной версией: релиз показывает, какие новые возможности уже готовы к широкому тестированию, и помогает администраторам заранее оценить изменения в SQL, InnoDB, репликации и диагностике.
MariaDB 13.0.1 переводит ветку 13.0 из preview к предрелизному тестированию
Согласно официальной странице релизов MariaDB Foundation, MariaDB 13.0.1 вышла 29 мая 2026 года и получила статус RC. Это означает, что версия предназначена для проверки перед финальным стабильным выпуском, особенно в тестовых средах, CI/CD-контурах и стендах совместимости.
Ветка 13.0 относится к rolling release. В официальной документации MariaDB она описана как развитие MariaDB 12.3 с новыми возможностями, а не как долгосрочная LTS-линейка. Для production-систем, где важнее предсказуемая поддержка, логичнее смотреть на актуальные LTS-релизы, например MariaDB 12.3.2, которая вышла почти одновременно со статусом Stable.
Новые SQL-возможности расширяют совместимость и удобство разработки
В MariaDB 13.0.1 заметная часть изменений связана с SQL и хранимыми процедурами. Среди ключевых новинок — поддержка TYPE .. IS REF CURSOR. Для разработчиков, которые переносят код из Oracle-экосистемы или пишут сложную серверную логику внутри базы данных, это важное расширение синтаксиса.
Также появилась поддержка RECORD в параметрах процедур и в RETURN-части функций. Простыми словами, разработчик получает более гибкий способ описывать сложные структуры данных внутри серверной логики, а не сводить всё к набору отдельных скалярных значений.
Ещё одно практичное изменение — UPDATE ... RETURNING. Такой синтаксис позволяет обновить строки и сразу получить результат в ответе. Это удобно в приложениях, где после изменения записи нужно сразу узнать новое значение поля, идентификатор, статус или вычисляемый результат.
Atomic CREATE OR REPLACE TABLE снижает риск промежуточных состояний
В релиз добавлен atomic CREATE OR REPLACE TABLE. Атомарность означает, что операция выполняется как единое действие: база данных должна либо завершить замену таблицы корректно, либо сохранить согласованное состояние.
Для разработчиков и администраторов это особенно важно при миграциях, автогенерации таблиц, обновлении временных структур и сценариях, где таблица пересоздаётся во время работы приложения. Чем меньше промежуточных состояний, тем ниже риск странных ошибок на стыке DDL-операций и пользовательских запросов.
InnoDB получил механизм сохранения WAL через innodb_log_archive
Одна из заметных системных новинок — переменная innodb_log_archive. В release notes она описана как механизм, который позволяет InnoDB сохранять WAL, то есть write-ahead log, вместо перезаписи данных по кольцевому принципу.
WAL — это журнал изменений, который помогает базе данных восстанавливаться после сбоев и поддерживать целостность данных. Возможность сохранять такие журналы может быть полезна в сценариях восстановления, аудита, анализа аварий и сложной эксплуатации, где важно глубже понимать, что происходило с данными до инцидента.
Перед использованием этой функции стоит отдельно проверить влияние на дисковое пространство, политику ротации логов и резервное копирование. Новая возможность выглядит полезной, но требует аккуратной настройки в реальной инфраструктуре.
Audit plugin стал гибче за счёт формата времени в логах
MariaDB 13.0.1 добавляет возможность задавать формат timestamp для audit plugin log. Это небольшое на первый взгляд изменение может заметно упростить жизнь администраторам и специалистам по безопасности.
Единый формат времени важен, когда логи MariaDB отправляются в SIEM, централизованное хранилище, observability-платформу или внутреннюю систему расследования инцидентов. Если формат времени заранее согласован с остальной инфраструктурой, логи проще сопоставлять с событиями в приложении, Nginx, Kubernetes, системных журналах и внешних сервисах.
Optimizer Trace и QB_NAME помогают точнее разбирать поведение запросов
В MariaDB 13.0.1 улучшена диагностика оптимизатора. Optimizer Trace теперь включает использованную статистику оптимизатора. Это помогает понять, почему сервер выбрал конкретный план выполнения запроса.
Также появился новый optimizer hint QB_NAME(). Он позволяет задавать имена блокам запроса и точнее управлять подсказками оптимизатора в сложных SQL-конструкциях. Это полезно при разборе тяжёлых запросов с подзапросами, представлениями и вложенными блоками.
Для обычного пользователя сайта такие изменения незаметны. Для разработчика backend-приложения или DBA они могут сократить время диагностики медленных запросов, особенно когда проблема проявляется на больших таблицах и в нестандартных планах выполнения.
PERFORMANCE_SCHEMA переходит на XXH3_128 для digest
В notable items указано, что PERFORMANCE_SCHEMA теперь использует XXH3_128 для digest. В документации MariaDB отмечено, что такой digest внешне выглядит как MD5, при этом работает быстрее и не создаёт проблем в FIPS-режиме.
Практический смысл простой: серверу нужно эффективно группировать и анализировать похожие SQL-запросы. Более быстрый хеш может уменьшить накладные расходы на такую диагностику, а совместимость с FIPS-ограничениями важна для организаций с жёсткими требованиями к криптографическим алгоритмам и регуляторному соответствию.
Репликация и binary log получили несколько эксплуатационных улучшений
MariaDB 13.0.1 включает изменения, связанные с репликацией и binary log. Среди них — увеличение значения по умолчанию для binlog_row_event_max_size до 64 КБ. Binary log используется для репликации и восстановления, поэтому параметры его записи напрямую влияют на эксплуатацию распределённых баз данных.
Также default_master_connection теперь можно задавать на глобальном уровне. Это упрощает работу с конфигурациями, где используются несколько соединений репликации или требуется централизованнее управлять поведением сервера.
Ещё одно изменение: CHANGE MASTER теперь сбрасывает Master_Server_Id в SHOW SLAVE STATUS. Это помогает избежать устаревших значений в статусе репликации после изменения источника.
Метаданные INFORMATION_SCHEMA стали информативнее
В MariaDB 13.0.1 INFORMATION_SCHEMA.SYSTEM_VARIABLES показывает, является ли переменная устаревшей. Для администраторов это полезный сигнал при обновлениях: можно заранее увидеть, какие настройки стоит заменить до будущих релизов.
Также INFORMATION_SCHEMA.STATISTICS и INFORMATION_SCHEMA.COLUMNS теперь показывают engine-specific create options. Это помогает точнее видеть, с какими параметрами созданы индексы и колонки на уровне конкретного движка хранения.
Такие изменения особенно полезны для инструментов инвентаризации, миграционных скриптов, админ-панелей и внутренних проверок конфигурации базы данных.
MEMORY-таблицы и CHAR-индексы получили ускорение
Среди notable items указано ускорение уникальных индексов по CHAR-колонкам в MEMORY-таблицах, включая временные таблицы. MEMORY-таблицы часто применяются для промежуточных вычислений и временных операций, поэтому оптимизация уникальных индексов может быть полезна в нагрузочных сценариях.
Эффект будет зависеть от конкретной схемы, объёма данных, кодировки и типа запросов. Для проектов с активным использованием временных таблиц имеет смысл прогнать собственные бенчмарки на копии рабочей нагрузки.
Reversed executable comments улучшают совместимость SQL-комментариев
В список новых возможностей вошли reversed executable comments. Исполняемые комментарии позволяют помещать SQL-фрагменты в комментарии так, чтобы одни серверы их игнорировали, а другие выполняли при подходящих условиях.
Это важно для совместимости между версиями и диалектами SQL, особенно в миграционных сценариях и инструментах, которые генерируют SQL для разных окружений. В changelog также есть исправления, связанные с записью таких комментариев в binary log и их взаимодействием с query cache.
MariaDB 13.0.1 стоит тестировать заранее, но внедрять осторожно
MariaDB 13.0.1 выглядит как насыщенный RC-релиз для разработчиков, DBA и команд, которые заранее готовятся к ветке 13.0. Главная практическая ценность версии — ранняя проверка новых SQL-возможностей, диагностики оптимизатора, поведения InnoDB, репликации и audit log на реальных сценариях.
Для боевой инфраструктуры разумный путь выглядит так: поднять отдельный стенд, восстановить копию базы, прогнать миграции, проверить slow queries, репликацию, резервное копирование, аудит и совместимость ORM. После этого можно оценивать, какие изменения ветки 13.0 действительно полезны проекту и какие настройки потребуют адаптации.
