Состоялся выпуск СУБД MariaDB 12.1.2, который отмечен как первый стабильный релиз ветки 12.1. Ветка MariaDB 12.1 отнесена к промежуточным выпускам (rolling), продолжает постепенное развитие функциональности и пришла на смену ветке MariaDB 12.0. Одновременно опубликован выпуск MariaDB 12.2.1, имеющий статус кандидата в релизы. Ветка MariaDB 12.1 будет сопровождаться до формирования выпуска 12.2.2.
Oracle уволила порядка 70 членов команды проекта системы управления реляционными базами данных (СУБД) MySQL. Решение американской компании вызвало обеспокоенность по поводу будущего одной из самых популярных в мире баз данных с открытым исходным кодом, пишет Register.
7 августа 2025 года состоялся выпуск СУБД MariaDB 12.0.2, который отмечен как первый стабильный релиз ветки 12.0. Ветка MariaDB 12.0 отнесена к промежуточным выпускам (rolling), продолжает постепенное развитие функциональности и пришла на смену ветке MariaDB 11.8. Одновременно опубликован выпуск MariaDB 12.1.1, имеющий статус кандидата в релизы. Ветка MariaDB 12.0 будет сопровождаться до формирования выпуска 12.1.2.
Представлен выпуск СУБД MariaDB 11.8.2, который отмечен как первый стабильный релиз ветки 11.8. Ветка MariaDB 11.8 отнесена к выпускам с длительным сроком поддержки (LTS) и будет сопровождаться как минимум 5 лет.
Не грустите, что лето прошло. Ведь дайджест с самыми интересными релизами и новостями Клауда всегда с вами. В этот раз мы приготовили для вас рекап августа — всё самое главное за прошлый месяц.
В начале июля 2024 года Oracle выпустила СУБД MySQL 9.0.0. Разработчики проекта подготовили и выложили в открытый доступ сборки MySQL Community Server 9.0.0 для основных дистрибутивов Linux, FreeBSD, macOS и Windows.
Microsoft Azure объявила, что прекратит поддержку MariaDB 19 сентября 2025 года и рекомендует перейти на гибкий сервер — базу данных Azure для MySQL.
После обновления марии до 10.9-версии FORCE INDEX перестал работать.
Как известно, оптимизатор запросов не всегда определяет верно индексы, которые нужно использовать. Это происходит ещё и потому, что оптимизатор учитывает объём доступной памяти, а она может быть занята другими выполняющимися запросами. Поэтому часто возникают "плавающие баги", когда один и тот же запрос то использует нужные индексы, то нещадно тормозит. USE INDEX в этом случае бессмысленно использовать — оптимизатор его просто игнорирует.
Почему же FORCE INDEX перестал работать? Оказывается изменился его синтаксис.
Новый синтаксис: FORCE INDEX [{FOR {JOIN|ORDER BY|GROUP BY}] ([index_list]).
Новый синтаксис предполагает, что если проиндексированный столбец находится не в WHERE, а в JOIN или ORDER BY или в GROUP BY, то это нужно указывать явно, иначе оптимизатор и не почешется.
Этичные хакеры из Go Secure обнаружили ошибку в MySQL, угрожающую безопасности. Из-за неё клиенты AWS Web Application Firewall (WAF) остались незащищёнными от внедрения SQL. Ещё одна исследовательская группа дополнительно подтвердила, что это влияет на безопасность, и предоставила один из способов, как исправить эту ошибку.
Онлайн митап, посвященный опыту внедрения микросервисов и выбору между PHP и Go для этого, про эксплуатацию MySql на постоянно растущих нагрузках, а также про асинхронный PHP, его настоящее и будущее.
