Diferencas de MariaDB e MySQL

Posted on: October 27, 2021 12:19 PM

Posted by: Renato

Diferencas de MariaDB e MySQL

# MariaDB e MySQL

O MariaDB é um fork do MySQL, os dois sistemas de gerenciamento de banco de dados são bastante diferentes:

- MariaDB é totalmente licenciada com GPL, enquanto o MySQL tem uma abordagem de dupla licença.
- Cada lida com pools de thread de uma maneira diferente.
- MariaDB suporta muitos mecanismos de armazenamento diferentes.
- Em muitos cenários, o MariaDB oferece melhor desempenho.

# O que é o MySQL

MySQL é um banco de dados relacional (RDBMS) que surgiu pela primeira vez em 1995, criado por Michael Monty Widenius e David Axmark.
Foi criada quando o mercado era dominado pela Microsoft e pelas soluções proprietárias (e caras) da Oracle.
- https://web.archive.org/web/20090313160628/http://www.opensourcereleasefeed.com/interview/show/five-questions-with-michael-widenius-founder-and-original-developer-of-mysql
- https://twitter.com/montywi
- https://en.wikipedia.org/wiki/David_Axmark

Página antiga do MySQL de 1998 (Fonte da imagem: Archive.org)
- https://web.archive.org/web/19980701000000*/https://www.mysql.com/

Com a sua adopção antecipada do licenciamento duplo — e usando a GNU GPL para a sua versão livre — o MySQL abriu caminho para muitos outros vendedores de software que vieram mais tarde.

Palavras de Michael Widenius sobre licenciamento duplo:
```
"…uma vez que o MySQL é um produto de infra-estrutura que é facilmente incorporado noutros produtos, poderíamos vender licenças àqueles que queriam incorporar o MySQL no seu produto mas não queriam tornar o seu produto open source."

```
Menos de uma década após o seu lançamento público, o MySQL estava a dominar o mercado das bases de dados relacionais de código aberto.

# Algumas das empresas notáveis que usam o MySQL incluem:

- Facebook, uma reportagem de 2011 menciona tanto quanto “60 milhões de consultas por segundo, e quase 4 milhões de mudanças de linha por segundo” e a manipulação do MySQL “praticamente toda interação do usuário: gostos, compartilhamentos, atualizações de status, alertas, solicitações”.
- A parte de facturação da Netflix na sua plataforma
- Youtube
- Booking.com
- Airbnb
- e muitos outros.

Mais um fator que contribuiu para a ascensão e adoção do MySQL que vale a pena mencionar é o phpMyAdmin.

PhpMyAdmin é uma ferramenta de administração de banco de dados baseado na web que remonta a 1998, o que fez seu caminho bastante cedo para os consoles de gerenciamento de provedores de hospedagem compartilhada, incluindo cPanel. É uma ferramenta escrita em PHP que facilitou a administração do MySQL em servidores LAMP. Importar, exportar, compor consultas complexas, apagar e criar tabelas, realizar pesquisas complexas são apenas algumas das coisas que o phpMyAdmin tornou possíveis sem que os utilizadores tivessem de usar o terminal Linux.

# WordPress e MySQL
Um dos factores por detrás da popularidade do MySQL é, sem dúvida, o WordPress, que hoje alimenta cerca de 60% dos sistemas CMS ou 34% de toda a web.
O WordPress foi criado em 2003 por Matt Mullenweg e Mike Little, como um garfo de outro projecto. Foi escrito em PHP, usava o MySQL como base de dados e, quando apareceu, a sua adopção foi apanhada como um incêndio.

O WordPress rapidamente se tornou sinônimo do conceito de software de código aberto, assim como sua pilha de servidores subjacentes. DisplayWP tem um bom gráfico da versão mínima necessária do MySQL para cada versão do WordPress.
- http://displaywp.com/wordpress-minimum-mysql-version/

Um dos fatores que impulsionou a adoção do MySQL foi o lado GPL de seu licenciamento. Como ele é compatível com o Linux, ele começou a ser incluído por padrão nas distribuições Linux. Hoje ele vem incluído por padrão no Ubuntu.

# Breve visão geral do MySQL e do modelo de banco de dados relacional

O MySQL foi concebido como um RDBMS (Relational Database Management System). O modelo de Banco de Dados Relacional remonta à década de 1970, conforme descrito pelos “Doze Mandamentos do Codd“. Em poucas palavras, este modelo estrutura os dados em tabelas que consistem em colunas e linhas. Cada linha é identificada exclusivamente por uma chave (Primary Key para usar jargão SQL).
- https://en.wikipedia.org/wiki/Edgar_F._Codd
- https://en.wikipedia.org/wiki/Codd%27s_12_rules

Essas Chaves Primárias podem ser usadas como pinos de um tipo que são usados por outras tabelas para definir uma relação com a linha específica. Assim, a coluna FOREIGN KEY em uma tabela de banco de dados relacional se referirá a uma coluna PRIMARY KEY em outra tabela, definindo uma relação entre linhas em diferentes tabelas.

Como o Essential SQL explica, “A chave primária consiste em uma ou mais colunas cujos dados contidos dentro dela são usados para identificar exclusivamente cada linha da tabela. Os dados nas colunas-chave primárias devem ser únicos e não podem ser vazios ou NULL. Em um banco de dados relacional “a tabela tem apenas uma chave primária e sua definição é obrigatória”.
Ao mesmo tempo, “chave estrangeira é um conjunto de uma ou mais colunas em uma tabela que se refere à chave primária em outra tabela. Não há qualquer código especial, configurações ou definições de tabela que você precisa colocar para “designar” oficialmente uma chave estrangeira.
- https://www.essentialsql.com/what-is-the-difference-between-a-primary-key-and-a-foreign-key/
Por esta razão, as bases de dados relacionais – e as bases de dados em geral – utilizam linguagens específicas de domínio entre as quais a SQL, que significa Structured Query Language, é a prevalente, se não a única utilizada pela RDBMS.

- https://en.wikipedia.org/wiki/SQL

# Aquisição pela Sun
Em 2008, a MySQL AB, a empresa por trás do MySQL, foi adquirida pela Sun Microsystems. Esta empresa criou a JAVA, Solaris Unix OS e contribuiu significativamente para diferentes tecnologias informáticas. Como a Business Wire reportou na altura:
- https://www.businesswire.com/news/home/20080116005349/en/Sun-Microsystems-Announces-Agreement-Acquire-MySQL-Developer

“Sun Microsystems, Inc. (NASDAQ:JAVA) anunciou hoje que entrou num acordo definitivo para adquirir a MySQL AB, um ícone open source e desenvolvedor de uma das bases de dados open source de crescimento mais rápido do mundo por aproximadamente $1 bilhão em consideração total”.

Em breve provará que esta aquisição não foi suficiente para evitar a queda da Sun, mas pinta um quadro de como o MySQL era grande naqueles dias.

# Oracle
A Oracle Corporation é fornecedora do maior banco de dados de código fechado até hoje, o banco de dados Oracle.

Era uma concorrente directa do MySQL e virtualmente a antítese da GPL, modelo de software livre e de código aberto que o MySQL estava a tornar-se nessa altura.

Quando a Oracle comprou a Sun, e a MySQL com ela em 2010 (ganhando contra a IBM por isso), o mundo FOSS viu isso como algo tão “sinistro” como um ataque Borg em Star Trek. Um utilizador lembra-se do evento em Quora:

O MySQL era uma grave ameaça para a Oracle – na altura a base de dados da Oracle representava algo a norte de 80% de todas as receitas (e dada a tripulação esqueleto necessária para a manter, ainda mais dos lucros).

A MySQL estava a fazer incursões sérias – grandes empresas da Fortune 50 com licenças de sítios que custaram milhões estavam a transferir bases de dados (especialmente as de leitura apenas) da Oracle para a MySQL porque as despesas administrativas eram muito mais baixas. Eu sei, eu ajudei a fazer algumas destas coisas.

Muitos na comunidade MySQL queriam adicionar funcionalidades que tornariam o uso de uma versão gratuita da Oracle obsoleta. O MySQL estava definitivamente a seguir esse caminho. As ferramentas estavam a amadurecer e o Larry estava com medo.

Então a Oracle comprou o MySQL para ter a certeza que teria um controlo sobre a marca, dispersar a comunidade e salvar a sua bandeira das massas não lavadas.

Esta foi uma conclusão lógica, porque o MySQL, nessa altura, tornou-se tão popular que pode ter sido visto como uma ameaça real ao core business da Oracle. Como disse Ankush Thakur da Geekflare, o MySQL tornou-se tão popular que, muito em breve, os programadores esqueceram que SQL e MySQL eram duas coisas diferentes.
- https://geekflare.com/mysql-to-mariadb-migration/

Antes mesmo da aquisição acontecer, no final de 2009, Monty Widenius, que deixou a equipa MySQL nesse ano para estabelecer a sua própria empresa de garfos e bases de dados, publicou um apelo dramático no seu blog (vamos citar apenas o início):
- http://monty-says.blogspot.com/2009/12/help-saving-mysql.html

# Ajuda para salvar o MySQL

Eu, Michael “Monty” Widenius, o criador do MySQL, estou a pedir-lhe urgentemente para ajudar a salvar o MySQL das garras da Oracle. Sem a sua ajuda imediata, a Oracle poderá ficar com o MySQL a qualquer momento. Ao escrever à Comissão Europeia (CE) pode apoiar esta causa e ajudar a garantir o futuro desenvolvimento do produto MySQL como um projecto Open Source.

A aquisição, no entanto, passou por um mês depois, para consternação de muitos na comunidade open source. A Widenius já tinha deixado a Sun, formado a Monty Program AB, e forjado o MySQL, lançando as bases para MariaDB. Enquanto levava com ele muitos programadores MySQL.
- http://monty-says.blogspot.com/2009/02/time-to-move-on.html
Até hoje, as pessoas continuam a questionar a legitimidade dos receios de Monty. Especialmente, uma vez que o pior cenário não aconteceu de todo: A Oracle não adquiriu o MySQL apenas para o matar.

Alguns argumentam que o MySQL foi comprado pela Oracle como nada mais do que uma “vítima colateral” da aquisição da Sun. Em 2009, aqueles que tinham os olhos no mercado de bases de dados tinham razões para se preocuparem.

Os avisos estavam lá. O desenvolvedor do principal motor de armazenamento da MySQL, InnoDB, uma companhia da Finlândia, foi adquirido pela Oracle em 2005. Mais tarde, foram totalmente fundidos na Oracle, terminando a empresa original. Em 2006, a Oracle comprou os criadores de Berkeley DB, fornecedor de outro motor de armazenamento BDB menos importante. Eles estavam circulando ao redor.
- https://www.quora.com/Why-did-Oracle-buy-MySQL-if-they-dont-even-make-money-out-of-it/answer/David-Tydeman-2?ch=10&share=9c0f838a&srid=hGRF
- https://en.wikipedia.org/wiki/Berkeley_DB

# O que é MariaDB
- https://mariadb.com/kb/en/library/mariadb-5138-release-notes/

MariaDB teve seu primeiro lançamento em outubro de 2009, com a versão 5.1.38 Beta, baseada no MySQL 5.1.38. Era um fork destinado a “assegurar que a base de código MySQL seria livre para sempre”.

Na altura do forking, o medo mais comum era que a aquisição fosse uma aquisição hostil com o objectivo de matar o MySQL. Esta preocupação, pelo menos em parte, revelou-se infundada.

Novamente em 2009, a Monty Program AB e a Percona, uma companhia que fornece serviços MySQL premium, estabeleceram a Open Database Alliance. O seu objectivo era “unificar todo o desenvolvimento e serviços relacionados com o MySQL, fornecendo uma solução para a fragmentação e incerteza que as comunidades, negócios e especialistas técnicos envolvidos com o MySQL enfrentam.
- https://www.computerworld.com.au/article/457551/dead_database_walking_mysql_creator_why_future_belongs_mariadb/
- https://www.infoq.com/news/2009/05/mysql-open-database-alliance/

A ideia era “tornar-se o centro da indústria para a base de dados de código aberto MySQL, incluindo MySQL e código derivado, binários, formação, suporte e outras melhorias para a comunidade MySQL e o ecossistema de parceiros”.

Olhando para trás: é possível que esses passos tenham impedido um cenário pior para o famoso banco de dados.
- https://www.percona.com/about-us/pressreleases/mysql-founder-monty-widenius-and-percona-ceo-peter-zaitsev-launch-the-open-database-alliance

# MariaDB vs MySQL: Compatibilidade

O objectivo da forquilha da MySQL da MariaDB (com o nome da filha da Widenius) era assegurar o futuro acesso à MySQL e o seu desenvolvimento futuro. É por isso que MariaDB foi concebida como uma substituição binária completa – uma substituição “drop-in”, por assim dizer – permitindo a todos os utilizadores do MySQL trocar um pelo outro nos seus sistemas.
- https://www.linux.com/news/special-qa-monty-widenius

O MySQL é uma aplicação cliente-servidor, e tanto o seu programa servidor mysqld, o seu cliente mysql, como programas auxiliares, como o mysqldump, mantêm o mesmo nome com MariaDB.

Substituir o MySQL pelo MariaDB torna-se um processo perfeito para a maioria das aplicações e propósitos, especialmente o WordPress. Software existente, de ferramentas CMS populares a aplicativos como phpMyAdmin, apenas funciona fora da caixa, e os dados reais podem ser exportados/importados de um para outro sem qualquer alteração.

O objetivo declarado da MariaDB é manter a compatibilidade com o MySQL. De acordo com o site da MariaDB,
- https://mariadb.com/kb/en/library/what-is-the-goal-of-mariadb/
- https://mariadb.com/kb/en/library/mariadb-vs-mysql-compatibility/

- os ficheiros de dados e de definição de tabelas são compatíveis.
-Todas as APIs e protocolos do cliente são compatíveis.
- Nomes de arquivos, binários e caminhos são os mesmos no MySQL e no MariaDB.
- Portas e soquetes são os mesmos.
- Todos os conectores MySQL – PHP, Perl, Python, Java e outros – funcionam com MariaDB.
- O pacote cliente MySQL funciona indistintamente com o MariaDB tal como com o MySQL.

As fusões mensais são conduzidas para garantir a compatibilidade e para obter quaisquer novas funcionalidades e correções de bugs da Oracle.

# As razões por trás da Forking

Havia várias razões por detrás do lançamento da MariaDB. O medo de que a Oracle simplesmente matasse seu crescente concorrente para proteger seu produto principal mais lucrativo era certamente um dos maiores. Os utilizadores teriam perdido um produto fantástico e gratuito!

Outras razões estavam relacionadas com a garantia de que o MySQL teria ficado livre e de código aberto. Hoje, a MariaDB está totalmente licenciada em GPL com todo o seu conjunto de funcionalidades, enquanto o MySQL mantém uma abordagem de dupla licença, com funcionalidades premium licenciadas sob licença proprietária e paga:
- https://mariadb.com/kb/en/library/licensing-questions/
- https://www.mysql.com/products/enterprise/

“O MySQL Enterprise Edition inclui o conjunto mais abrangente de recursos avançados, ferramentas de gerenciamento e suporte técnico para atingir os mais altos níveis de escalabilidade, segurança, confiabilidade e disponibilidade do MySQL. Ele reduz o risco, o custo e a complexidade no desenvolvimento, implantação e gerenciamento de aplicativos MySQL essenciais aos negócios.”

Se compararmos os dois aqui, MariaDB tem uma clara vantagem fornecida pela licença GPL sobre a qual é lançada. Por causa da base de código proprietária, a Oracle não pode legalmente tirar vantagem do código MariaDB e mesclá-lo em seu banco de dados.

Widenius prometeu: “Quando a Oracle lançar uma extensão de código fechado para o MySQL, nós também lançaremos uma de código aberto.
- https://www.linux.com/news/special-qa-monty-widenius

## Assuntos Comunitários

Outra razão por trás do garfo foi manter o projeto “aberto” no sentido de ser um projeto voltado para a comunidade (como o WordPress), cuja direção e desenvolvimento estão abertos assim como sua licença. Se olharmos para o registo de submissão, é fácil concluir que a maior parte do código MySQL vem de programadores internos. Os programadores da Oracle agradecem as contribuições ocasionais e notáveis da comunidade, por exemplo, mas isso está longe da abertura da MariaDB e longe do que era o MySQL.
- https://github.com/mysql/mysql-server/commits/8.0
- https://mysql.wisborg.dk/2019/05/01/mysql-server-8-0-16-thanks-for-the-contributions/

Para colocar as coisas em perspectiva, o repositório do servidor MariaDB no momento deste artigo tem mais de 186k commits, 370+ branches, e 200 contribuidores. O MySQL, por outro lado, tem mais de 148k commits, 9 branches, e 72 contribuidores.
- https://github.com/MariaDB/server
- https://github.com/mysql/mysql-server

A discussão sobre o desenvolvimento do MariaDB, sua direção, votação sobre as funcionalidades, etc. é feita em uma lista de discussão publicamente disponível:
- https://login.launchpad.net/+openid

Além desta, há também a lista de discussão da Maria Discuss.
- https://launchpad.net/~maria-captains

Maria Captains é uma equipe de desenvolvedores confiáveis para quem os desenvolvedores podem enviar patches. Como diz a página da equipe no Launchpad:

“Os capitães são desenvolvedores confiáveis com acesso de escrita às principais árvores MariaDB. Se você quiser ter um patch na árvore, envie-o para a lista de desenvolvedores maria e um ou mais dos capitães irão trabalhar com você para obter o patch revisado, aprovado e finalmente empurrado para a árvore MariaDB apropriada.”

Houve algumas ocasiões em que o processo de desenvolvimento animado da MariaDB provou sua vantagem sobre o processo fechado da Oracle.
- http://www.h-online.com/open/news/item/MariaDB-fixes-zero-day-vulnerability-in-MySQL-1761451.html

No final de 2012, a fundação MariaDB foi formada para supervisionar o desenvolvimento do banco de dados.

Pouco depois da forquilha, muitos desenvolvedores originais do MySQL se juntaram ao projeto MariaDB. Vendedores de Linux como Red Hat, CentOS, Arch Linux, Debian, OpenSuse, Slackware, Fedora mudaram para MariaDB como RDBMS padrão, assim como distribuições BSD, FreeBSD e OpenBSD, enquanto o Ubuntu inclui MariaDB. A lista completa pode ser encontrada aqui.

Empresas como Alibaba Cloud, Tencent, IBM, Microsoft, Booking.com tornaram-se patrocinadoras platinas.

É interessante mencionar que entre os diretores da Fundação MariaDB estão pessoas da Automattic, um sinal claro de que os criadores do WordPress abraçaram o MariaDB.
- https://mariadb.org/about/board/

Nos anos seguintes à divisão, a MariaDB teve um desenvolvimento animado, tanto que, devido a todo o conjunto de novas funcionalidades introduzidas em 2012, a MariaDB saltou do número da versão 5.*, compatível com o MySQL, para o 10.0, querendo refletir o salto nas funcionalidades que havia alcançado.
- https://blog.mariadb.org/explanation-on-mariadb-10-0/

Por razões de desempenho, a Wikimedia Foundation anunciou em 2013 que estava mudando a Wikipedia para MariaDB. O mesmo aconteceu com o Google, e sua lista de usuários agora inclui Deutsche Bank, DBS Bank, Nasdaq, Verizon, Craigslist, entre outros.
- https://blog.wikimedia.org/2013/04/22/wikipedia-adopts-mariadb/

Entre os usuários do MySQL, temos GitHub, US Navy, NASA, Tesla, Netflix, WeChat, Facebook, Zendesk, Twitter, Zappos, YouTube, Spotify.

Desde o seu primeiro lançamento, o interesse no sucessor do MySQL tem vindo a crescer constantemente, como mostra a Tendências de Pesquisa do Google:
- https://trends.google.com/trends/explore?q=%2Fm%2F09gc20r&date=all

# Diferenças chave

O MariaDB é totalmente compatível com o MySQL, podemos esperar que seus caminhos divirjam mais no futuro.

MariaDB vs MySQL

No seu último post no blogue, Widenius felicita a Oracle pelo seu trabalho na versão 8.0 do MySQL, delineando algumas diferenças e advertências tais como:
- http://monty-says.blogspot.com/2018/04/congratulations-to-oracle-on-mysql-80.html

Thread Pool: semelhante ao problema que o servidor Nginx resolve comparado com o Apache, o MySQL estava a atribuir threads a cada ligação de cliente, e isto, que podia ser comparado ao arranque de um programa inteiro num PC, era simplesmente ineficiente. MariaDB introduziu sua própria solução para isso na versão 5.5.
- https://mariadb.com/kb/en/library/thread-pool-in-mariadb/

Invisible Columns são a característica exclusiva da MariaDB da 10.3.3. Elas não retornam resultados em uma instrução SELECT *, nem precisam ser atribuídas valor em uma instrução INSERT.
- https://mariadb.com/kb/en/library/invisible-columns/

MariaDB introduz microssegundos em seus datatypes temporais.
- https://mariadb.com/kb/en/library/microseconds-in-mariadb/

Motores de Armazenamento: Os usos de MariaDB incluem XtraDB, InnoDB, MariaDB ColumnStore, Aria, Archive, Blackhole, Cassandra Storage Engine, Connect, CSV, FederatedX, Memory Storage Engine, Merge, Mroonga, MyISAM, MyRocks, QQGraph, Sequence Storage Engine, SphinxSE, Spider, TokuDB. ColumnsStore é interessante em termos de desempenho, porque torna possível a escala linear para lidar com petabytes de dados. Mais sobre isso em seu blog.
- https://mariadb.com/kb/en/library/storage-engines/
- https://mariadb.com/kb/en/library/mariadb-columnstore/
- https://mariadb.com/resources/blog/tag/columnstore/

Os motores de armazenamento MySQL são InnoDB, MyISAM, Memory, CSV, Archive, Blackhole, Merge, Federated, Example.
- https://dev.mysql.com/doc/refman/8.0/en/storage-engines.html
-

Database Views são um recurso em que a MariaDB introduz otimizações significativas ao consultar apenas as tabelas necessárias.
- https://hackr.io/blog/mariadb-vs-mysql#Database_Views

Algumas características que o MySQL introduz são JSON tipo de dados nativo, MySQL Shell na versão MySQL 8.0 – que permite javascript e python scripting – e não funciona com MariaDB, SHA-256 plugin de autenticação baseado, melhorando a segurança sobre mysql_native_password.
- https://dev.mysql.com/doc/refman/8.0/en/json.html
- https://dev.mysql.com/doc/refman/8.0/en/caching-sha2-pluggable-authentication.html

Aqui você pode encontrar a lista completa das diferenças entre MariaDB vs MySQL e as vantagens do primeiro quando comparado com o segundo.
- https://mariadb.com/kb/en/library/mariadb-vs-mysql-features/

# MariaDB versus MySQL - Compatibilidade

## MariaDB é um binary drop em substituição a MySQL

Para efeitos práticos, MariaDB é um binary drop em substituição da mesma versão do MySQL (por exemplo MySQL 5.1 -> MariaDB 5.1, MariaDB 5.2 e MariaDB 5.3 são compatíveis. O MySQL 5.5 será compatível com o MariaDB 5.5). O que isto quer dizer é que:

Arquivos de definição de tabelas e dados (.frm) são binariamente compatíveis.
Todas as APIs clientes, protocolos e estruturas são identicas.
Todos os nomes de arquivo, binários, caminhos, portas, sockets, etc... deveriam ser os mesmos.
Todos os conectores do MySQL (PHP, Perl, Python, Java, .NET, MyODBC, Ruby, o conector MySQL, etc) funcionam inalterados com MariaDB.
Existem alguns problemas de instalação com PHP5 dos que você deveria estar ciente (um bug em como o antigo cliente PHP5 verifica a compatibilidade de livrarias).
O pacote mysql-client funciona também com o servidor MariaDB.
Isto significa que para a maioria dos casos, você pode apenas desinstalar MySQL, instalar MariaDB e você irá bem. (Não precisa converter nenhum arquivo de dados se você estiver usando a mesma versão principal, como a 5.1).

Nós fazemos fusões mensais com o código base do MySQL para garantir que mantemos a compatibilidade e obtemos cada uma e todas as características assim como correções de bugs que a Oracle adiciona.

Também temos feito um monte de trabalho com os scripts de atualização ao ponto de que agora é mais fácil Atualizar desde MySQL 5.0 para MariaDB 5.1 do que atualizar desde o MySQL 5.0 para o MySQL 5.1.

Dito isto, MariaDB tem um monte de novas opções, mecanismos de extensão e armazenamento, e correções de bugs que não tem no MySQL. Você pode encontrar o conjunto de características para as diferentes versões do MariaDB no site O que é que tem nos diferentes lançamentos do MariaDB

Veja também MariaDB versus MySQL - Características.
- https://mariadb.com/kb/en/mariadb-versus-mysql-features/

# Incompatibilidades entre o MariaDB 5.1 e o MySQL 5.1

Em alguns poucos casos, o MariaDB tem que ser incompatível para permitir o fornecimento de mais e melhor informação do que o MySQL.

Aqui está a lista de todas as incompatibilidades conhecidas a nível de usuário que você pode encontrar usando o MariaDB 5.1 em vez de MySQL 5.1.

Os nomes dos pacotes de instalação começam com "MariaDB" em vez de "MySQL".
Intervalos podem ser diferentes já que em varios casos o MariaDB é mais rápido do que o MySQL.
mysqld no MariaDB também lê as seções [mariadb] dos seus arquivos my.cnf.
Você não pode usar uma livraria com mecanismo de armazenamento apenas binário com o MariaDB se esta não estiver compilada para a mesma versão exata do MariaDB. (Isto por causa de que a estrutura interna THD do servidor é diferente entre MySQL e MariaDB. Isto também é comum entre as diferentes versões do MySQL). Isto não deveria ser um problema já que a maioria das pessoas não carrega novos mecanismos de armazenamento e o MariaDB vem com mais mecanismos de armazenamento do que o MySQL.
CHECKSUM TABLE pode dar um resultado diferente, já que o MariaDB não ignora NULL's nas colunas como o faz o MySQL 5.1 (futuras versões do MySQL deveriam calcular os checksums da mesma forma com que o faz o MariaDB). Você pode obter o checksum de estilo antigo no MariaDB iniciando o mysqld com a opção --old, o comando CHECKSUM será mais lento já que tem de calcular a suma de comprovação linha por linha.
O log de consulta lenta tem mais informação sobre a consulta, o que poderia ser um problema se você tiver um script que analise esse log de consulta lenta.
MariaDB por padrão pega um pouco mais de memoria do que o MySQL devido a que temos habilitado por padrão o mecanismo de armazenamento Aria para manipular tabelas temporárias internas. Se você precisar com que o MariaDB utilize pouquíssima memoria (á custa do desempenho) você pode definir o valor de aria_pagecache_buffer_size para 1M (o padrão é 128M).
Se você estiver usando novas opções de comando, novas características do MariaDB ou novos mecanismos de armazenamento, você não poderá mais ir e vir facilmente entre MySQL e MariaDB.
Incompatibilidades entre MariaDB 5.2 e MySQL 5.1
A lista é a mesma do que entre MariaDB 5.1 e MySQL 5.1.

Para todos os efeitos práticos, MariaDB 5.2 é um lançamento em substituição do MariaDB 5.1 e o MySQL 5.1.
- https://mariadb.com/kb/en/what-is-mariadb-51/
- https://mariadb.com/kb/en/what-is-mariadb-52/
- https://mariadb.com/kb/pt-br/mariadb-versus-mysql-compatibility/

Sysbench OLTP: MySQL-5.6 vs. MariaDB-10.0