10 lat po założeniu gałęzi 10.x wypuszczono wersję MariaDB 11.0.0, która oferowała kilka znaczących ulepszeń i zmian psujących kompatybilność. Oddział jest obecnie w wersji alfa i będzie gotowy do użytku produkcyjnego po ustabilizowaniu się. Kolejna duża gałąź MariaDB 12, zawierająca zmiany psujące kompatybilność, spodziewana jest nie wcześniej niż za 10 lat (w 2032 roku).
Projekt MariaDB opracowuje rozwidlenie MySQL, zachowując kompatybilność wsteczną, gdy tylko jest to możliwe, i uwzględniając integrację dodatkowych silników pamięci masowej i zaawansowanych możliwości. Rozwój MariaDB jest nadzorowany przez niezależną Fundację MariaDB, zgodnie z otwartym i przejrzystym procesem rozwoju, niezależnym od poszczególnych dostawców. DBMS MariaDB jest dostarczany zamiast MySQL w wielu dystrybucjach Linuksa (RHEL, SUSE, Fedora, openSUSE, Slackware, OpenMandriva, ROSA, Arch Linux, Debian) i został wdrożony w tak dużych projektach jak Wikipedia, Google Cloud SQL i Nimbuzz.
Kluczowym usprawnieniem w gałęzi MariaDB 11 jest przejście optymalizatora zapytań na nowy model wag (model kosztowy), który zapewnia dokładniejsze przewidywanie wag każdego planu zapytań. Chociaż nowy model może złagodzić niektóre wąskie gardła w wydajności, może nie być optymalny we wszystkich scenariuszach i może spowolnić niektóre zapytania, dlatego zachęca się użytkowników do udziału w testach i powiadamiania programistów, jeśli pojawią się problemy.
Poprzedni model dobrze radził sobie ze znajdowaniem optymalnego indeksu, ale miał problemy z możliwością zastosowania skanowania tabel, skanowania indeksów lub operacji pobierania zakresu. W nowym modelu tę wadę eliminuje się poprzez zmianę masy podstawowej operacji z silnikiem magazynującym. Oceniając wydajność operacji zależnych od szybkości dysku, takich jak sekwencyjne skanowanie zapisu, zakładamy teraz, że dane są przechowywane na dysku SSD zapewniającym prędkość odczytu 400 MB na sekundę. Dodatkowo dostrojono inne parametry wagowe optymalizatora, co m.in. pozwoliło zaimplementować możliwość wykorzystania indeksów dla operacji „ORDER BY/GROUP BY” w podzapytaniach i przyspieszyć pracę z bardzo małymi tabelami.
Należy zauważyć, że nowy model wag pozwoli wybrać bardziej optymalny plan wykonania zapytania w następujących sytuacjach:
- Podczas korzystania z zapytań obejmujących więcej niż 2 tabele.
- Gdy masz indeksy zawierające dużą liczbę identycznych wartości.
- W przypadku korzystania z zakresów obejmujących więcej niż 10% tabeli.
- Gdy masz złożone zapytania, w których nie wszystkie używane kolumny są indeksowane.
- Kiedy używane są zapytania, które obejmują różne silniki pamięci masowej (na przykład, gdy jedno zapytanie uzyskuje dostęp do tabel w silnikach InnoDB i Memory).
- Podczas korzystania z FORCE INDEX w celu ulepszenia planu zapytań.
- Gdy plan zapytań ulegnie pogorszeniu podczas korzystania z „ANALIZUJ TABELĘ”.
- Gdy zapytanie obejmuje dużą liczbę tabel pochodnych (duża liczba zagnieżdżonych wyborów).
- Podczas używania wyrażeń ORDER BY lub GROUP BY, które wchodzą w zakres indeksów.
Główne problemy ze zgodnością w gałęzi MariaDB 11:
- Uprawnienia SUPER nie pozwalają już na wykonywanie czynności, dla których dostępne są oddzielnie ustawione uprawnienia. Na przykład, aby zmienić format logów binarnych, będziesz potrzebować uprawnień BINLOG ADMIN.
- Usunięto implementację bufora zmian w InnoDB.
- Metody Innodb_flush_method i innodb_file_per_table zostały uznane za przestarzałe.
- Obsługa nazw Mysql* jest przestarzała.
- Ustawienie valid_defaults_for_timestamp na 0 zostało uznane za przestarzałe.
- Dowiązania symboliczne znajdują się w oddzielnym pakiecie zapewniającym kompatybilność z MySQL.
- Domyślna wartość parametru innodb_undo_tablespaces została zmieniona na 3.
Źródło: opennet.ru