10 anos despois da fundación da rama 10.x, lanzouse MariaDB 11.0.0, que ofreceu varias melloras e cambios significativos que romperon a compatibilidade. A rama está actualmente en calidade de lanzamento alfa e estará lista para o seu uso en produción despois da estabilización. A próxima rama principal de MariaDB 12, que contén cambios que rompen a compatibilidade, espérase non antes de 10 anos (en 2032).
O proxecto MariaDB está a desenvolver un fork de MySQL, mantendo a compatibilidade con versións anteriores sempre que sexa posible e incorporando a integración de motores de almacenamento adicionais e capacidades avanzadas. O desenvolvemento de MariaDB está supervisado pola Fundación MariaDB independente, seguindo un proceso de desenvolvemento aberto e transparente que é independente dos provedores individuais. O DBMS MariaDB ofrécese en lugar de MySQL en moitas distribucións de Linux (RHEL, SUSE, Fedora, openSUSE, Slackware, OpenMandriva, ROSA, Arch Linux, Debian) e implementouse en proxectos tan grandes como Wikipedia, Google Cloud SQL e Nimbuzz.
Unha mellora clave na rama MariaDB 11 é a transición do optimizador de consultas a un novo modelo de ponderación (modelo de custo), que proporciona unha predición máis precisa dos pesos de cada plan de consulta. Aínda que o novo modelo pode aliviar algúns embotellamentos de rendemento, é posible que non sexa óptimo en todos os escenarios e pode ralentizar algunhas consultas, polo que se anima aos usuarios a participar nas probas e notificar aos desenvolvedores se xurden problemas.
O modelo anterior era bo para atopar o índice óptimo, pero tiña problemas coa aplicabilidade das exploracións de táboas, exploracións de índices ou operacións de busca de intervalos. No novo modelo, este inconveniente elimínase cambiando o peso base das operacións co motor de almacenamento. Ao avaliar o rendemento para operacións dependentes da velocidade do disco, como escaneos de escritura secuenciais, agora asumimos que os datos se almacenan nun SSD que proporciona velocidades de lectura de 400 MB por segundo. Ademais, axustáronse outros parámetros de peso do optimizador, o que permitiu, por exemplo, implementar a posibilidade de utilizar índices para operacións "ORDER BY/GROUP BY" en subconsultas e acelerar o traballo con táboas moi pequenas.
Nótase que o novo modelo de peso permitirá escoller un plan de execución de consultas máis óptimo nas seguintes situacións:
- Cando se usan consultas que abranguen máis de 2 táboas.
- Cando tes índices que conteñen un gran número de valores idénticos.
- Cando se usan intervalos que cobren máis do 10% da táboa.
- Cando ten consultas complexas nas que non todas as columnas utilizadas están indexadas.
- Cando se utilizan consultas que impliquen diferentes motores de almacenamento (por exemplo, cando unha consulta accede ás táboas dos motores InnoDB e Memory).
- Cando se usa FORCE INDEX para mellorar o plan de consulta.
- Cando o plan de consulta se deteriora ao usar "ANALIZAR TÁBOA".
- Cando a consulta abarca un gran número de táboas derivadas (gran número de SELECT anidados).
- Cando se usan expresións ORDER BY ou GROUP BY que están en índices.
Principais problemas de compatibilidade na rama MariaDB 11:
- Os dereitos SUPER xa non che permiten realizar accións para as que estean dispoñibles privilexios definidos por separado. Por exemplo, para cambiar o formato dos rexistros binarios, necesitará dereitos de ADMINISTRADOR BINLOG.
- Eliminouse a implementación do búfer de cambios en InnoDB.
- Innodb_flush_method e innodb_file_per_table quedaron en desuso.
- O soporte de nomes Mysql* quedou en desuso.
- Establecer explicit_defaults_for_timestamp como 0 quedou en desuso.
- As ligazóns simbólicas inclúense nun paquete separado para a compatibilidade con MySQL.
- O valor predeterminado do parámetro innodb_undo_tablespaces cambiouse a 3.
Fonte: opennet.ru