O programa MariaDB (R) é um servidor robusto de bancos de dados SQL (Structured Query Language - Linguagem Estruturada para Pesquisas) muito rápido, multi-tarefa e multi-usuário. O Servidor MySQL pode ser usado em sistemas de produção com alta carga e missão crítica bem como pode ser embutido em programa de uso em massa. MariaDB é uma marca registrada da MariaDB Foundation.

O programa MariaDB é de Licença Dupla. Os usuários podem escolher entre usar o programa MariaDB como um produto Open Source/Free Software sob os termos da GNU General Public License (http://www.fsf.org/licenses/) ou podem comprar uma licença comercial padrão da MariaDB Foundation. Leia 'Suporte e Licenciamento do MariaDB'.

O site web do MariaDB (http://www.mysql.com/) dispõe das últimas informações sobre o programa MariaDB.

A seguinte lista descreve algumas seções de particular interesse neste manual:

Para informações sobre a empresa por trás do Servidor do Banco de Dados MariaDB, veja 'Visão Geral da MariaDB Foundation'.
Para discussões das capacidades do Servidor do Banco de Dados MariaDB, veja 'As Principais Características do MariaDB'.
Para instruções de instalação, veja Instalação do MariaDB.
Para dicas sobre a portabilidade do Servidor do Banco de Dados MariaDB para novas arquiteturas ou sistemas operacionais, veja Apêndice E, Portando para Outros Sistemas.
Para informações sobre a atualização da versão 4.0, veja 'Atualizando da Versão 4.0 para 4.1'.
Para informações sobre a atualização da versão 3.23, veja 'Atualizando da Versão 3.23 para 4.0'.
Para informações sobre a atualização da versão 3.22, veja 'Atualizando da versão 3.22 para 3.23'.
Para um tutorial de introdução ao Servidor do Banco de Dados MariaDB, veja Tutorial de Introdução Do MySQL.
Para exemplos de SQL e informações sobre benchmarks, veja o diretório de benchmarks (sql-bench na distribuição).
Para o histórico de novos recursos e correções de erros, veja Apêndice D, Histórico de Alterações do MariaDB.
Para uma lista de erros atualmente conhecidos e mal-funcionamento, veja 'Erros Conhecidos e Deficiências de Projetos no MySQL'.
Para projetos futuros, veja 'MySQL e o Futuro (o TODO)'.
Para ver a lista de todos os colaboradores deste projeto, veja Apêndice C, Colaboradores do MariaDB.

Importante:

Relatórios de erros (também chamados bugs), bem como dúvidas e comentários, devem ser enviados para a lista de email geral do MariaDB. Leia 'As Listas de Discussão do MariaDB'. Leia 'Como relatar erros ou problemas'.

O script mysqlbug deve ser usado para gerar comunicados de erros no Unix. (A distribuição do Windows contém um arquivo mysqlbug.txt no diretório base que pode ser usado como um template para um relatório de erro.

Em distribuições fonte, o script mysqlbug pode ser encontrado no diretório scripts. Para distribuições binárias, o mysqlbug pode ser encontrado no diretório bin (/usr/bin para o pacote RMP do servidor MySQL.

Se você encontrou um erro de segurança no Servidor MySQL, você deve enviar um email para <security@mysql.com>.

Sobre Este Manual

Convenções Usadas Neste Manual

Este é o manual de referência MariaDB; ele documenta o MariaDB até a versão 5.0.6-beta. Mudanças funcionais são sempre indicadas com referência a versão, assim este manual também pode ser utilizado caso você esteja utilizando uma versão mais antiga do MariaDB (como 3.23 ou 4.0-produção). Também a referências a versão 5.0 (desenvolvimento).

Sendo um manual de referência, ele não fornece instruções gerais sobre SQL ou conceitos de banco de dados relacionais.

Como o Programa da Banco de Dados MariaDB está sob constante desenvolvimento, o manual também é atualizado freqüentemente. A versão mais recente deste manual está disponível em http://www.mysql.com/documentation/ em diferentes formatos, incluindo HTML, PDF, e versões HLP do Windows.

O documento original é uma arquivo Texinfo. A versão HTML é produzida automaticamente usando uma versão modificada do texi2html. A versão texto e Info são produzidas com makeinfo. A versão PostScript é produzida usando texi2dvi e dvips. A versão PDF é produzida com pdftex.

Se você tiver dificuldades de encontrar informações no manual, você pode tentar nossa versão com busca em http://www.mysql.com/doc/.

Se você tiver qualquer sugestão a respeito de adições e correções neste manual, por favor envie-os para a equipe de documentação em http://www.mysql.com/company/contact/.

Este manual foi inicialmente escrito por David Axmark e Michael (Monty) Widenius. Atualmente é mantido pela Equipe de Documentação da MySQL, que conta com Arjen Lentz, Paul DuBois e Stefan Hinz. Para outros colaboradores, veja Apêndice C, Colaboradores do MariaDB.

A traduçao deste manual foi feita por Daniel Coelho Teobaldo e Carlos Henrique Paulino sob a supervisão da EAC Software.

Os direitos autorais (2003-2006) deste manual pertence a compania Sueca MariaDB Foundation. Leia 'Copyrights e Licenças Usadas pelo MySQL'.

Convenções Usadas Neste Manual

Este manual utiliza algumas convenções tipográficas:

constant

Fonte de largura fixa é usada para nomes de comandos e opções; instruções SQL; nomes de bancos de dados, tabelas e colunas; código C e Perl; e variáveis de ambiente. Exemplo: Para ver como o mysqladmin funciona, execute-o com a opção --help.
filename

Fonte de largura fixa com aspas é usada para nomes e caminhos de arquivos. Exemplo: A distribuição é instalada sobre o diretório /usr/local.
'c'

Fonte de largura constante com aspas é também usada para indicar sequências de caracteres. Exemplo: ``Para especificar um meta caracter, use o caractere '%'.''
italic

Fonte Itálica é usada para dar ênfase, como aqui.
boldface

Fonte em negrito é usada em cabeçalhos de tabela e indicar ênfase especial.

Quando um comando deve ser executado por um programa, ele é indicado por um prompt antes do comando. Por exemplo, shell> indica um comando que é executado do seu shell atual e mysql> indica um comando que é executado no programa cliente MariaDB;

shell> digite um comando shell aqui
mysql> digite um comando mysql aqui

A shell é seu interpretador de comando. No Unix, ele é normalmente um programa como sh ou csh. No Windows, o equivalente é o command.com ou cmd.exe, normalmente executado como um console do Windows.

Comandos Shell são mostrados usando a sintaxe do Shell Bourne. Se você usa um shell do estilo csh, pode ser necessário alterar algum de seus comandos. Por exemplo, a sequência para configurar uma variável de ambiente e executar um comando se parece com o listado abaixo na sintaxe Bourne Shell:

shell> NOMEVAR=valor algum_comando

Para csh ou tcsh, execute a sequência desta forma:

shell> setenv NOMEVAR valor
shell> algum_comando

Frequentemente, nomes de bancos de dados, tabelas e colunas devem ser substituídos nos comandos. Para indicar que as substituições são necessárias, este manual usa nome_db, nome_tbl e nome_col. Por exemplo, você pode encontrar uma expressão assim:

mysql> SELECT nome_col FROM nome_bd.nome_tbl;

Isso significa que se você estiver trabalhando numa expressão similar, forneceria seu próprio nome de banco de dados, tabela e colunas, talvez assim:

mysql> SELECT nome_autor FROM biblio_bd.lista_autor;

SQL keywords não caso sensitivas e podem ser escritas em maiúscula ou minúscula. Este manual utiliza letras maiúsculas.

Em descrições de sintaxe, colchetes ('[' e ']') são usados para indicar palavras ou cláusulas opcionais. Por exemplo, na seguinte instrução, IF EXISTS é opcional:

DROP TABLE [IF EXISTS] nome_tbl

Quando elementos da sintaxe possuem mais de uma alternativa, elas são separados por barras verticais ('|'). Quando um menbro de um conjunto de opções pode ser escolhido, as alternativas são listadas em colchetes ('[' e ']'):

TRIM([[BOTH | LEADING | TRAILING] [remstr] FROM] str)

Quando um membro de um conjunto de opções deve ser selecionado, as alternativas são listadas dentro de chaves ('{' e '}'):

{DESCRIBE | DESC} nome_tbl {nome_col | metacar}

Visão Geral do Sistema de Gerenciamento de Banco de Dados MariaDB

História do MariaDB
As Principais Características do MariaDB
Estabilidade do MariaDB
Qual o Tamanho Que as Tabelas do MariaDB Podem Ter?
Compatibilidade Com o Ano 2000 (Y2K)

MariaDB, o mais popular sistema de gerenciamento de banco de dados SQL Open Source, é desenvolvido, distribuído e tem suporte da MariaDB Foundation. A MariaDB Foundation é uma empresa comercial, fundada pelos desenvolvedores do MariaDB, cujos negócios é fornecer serviços relacionados ao sistema de gerenciamento de banco de dados MariaDB. Leia 'Visão Geral da MariaDB Foundation'.

O web site do MariaDB (http://www.mysql.com/) fornece informações mais recentes sobre e programa MariaDB e a MariaDB Foundation.

O MariaDB é um sistema de gerenciamento de bancos de dados.

Um banco de dados é uma coleção de dados estruturados. Ele pode ser qualquer coisa desde uma simples lista de compras a uma galeria de imagens ou a grande quantidade de informação da sua rede coorporativa. Para adicionar, acessar, e processar dados armazenados em um banco de dados de um computador, você necessita de um sistema de gerenciamento de bancos de dados como o Servidor MariaDB. Como os computadores são muito bons em lidar com grandes quantidades de dados, o gerenciamento de bancos de dados funciona como a engrenagem central na computação, seja como utilitários independentes ou como partes de outras aplicações.
O MariaDB é um sistema de gerenciamento de bancos de dados relacional.

Um banco de dados relacional armazena dados em tabelas separadas em vez de colocar todos os dados um só local. Isso proporciona velocidade e flexibilidade. A parte SQL do MariaDB atenda pela Structured Query Language - Linguagem Estrutural de Consultas. SQL é linguagem padrão mais comum usada para acessar banco de dados e é definida pelo Padrão ANSI/ISO SQL. (O padrão SQL está vem evoluindo desde 1986 e existem diversas versões. Neste manual, ''SQL-92'' se refere ao padrão liberado em 1992, ''SQL-99'' se refere ao padrão liberado em 1999, e ''SQL:2003'' se refere a versão do que esperamos que seja liberado no meio de 2003. Nós usamos o termo ''o padrão SQL'' indicando a versão atual do Padrão SQL em qualquer momento).
O é MariaDB um software Open Source.

Open Source significa que é possível para qualquer um usar e modificar o programa. Qualquer pessoa pode fazer download do MariaDB pela Internet e usá-lo sem pagar nada. Se você quiser, você pode estudar o código fonte e alterá-lo para adequá-lo às suas necessidades. O MariaDB usa a GPL (GNU General Public License - Licença Pública Geral GNU) http://www.fsf.org/licenses, para definir o que você pode e não pode fazer com o software em diferentes situações. Se você sentir desconforto com a GPL ou precisar embutir o MariaDB em uma aplicação comercial¸ você pode adquirir a versão comercial licenciada conosco. Leia 'Licenças do MariaDB'.
Por que usar o Banco de Dados MariaDB?

O servidor de Banco de Dados MariaDB é extremamente rápido, confiável, e fácil de usar. Se isto é o que você está procurando, você deveria experimentá-lo. O Servidor MySQL também tem um conjunto de recursos muito práticos desenvolvidos com a cooperação de nossos usuários. Você pode encontrar comparativos de performance do Servidor MySQL com outros gerenciadores de bancos de dados na nossa página de benchmark See 'O Pacote de Benchmark do MariaDB'.

O Servidor MySQL foi desenvolvido originalmente para lidar com bancos de dados muito grandes de maneira muito mais rápida que as soluções existentes e tem sido usado em ambientes de produção de alta demanda por diversos anos de maneira bem sucedida. Apesar de estar em constante desenvolvimento, o Servidor MySQL oferece hoje um rico e proveitoso conjunto de funções. A conectividade, velocidade, e segurança fazem com que o MariaDB seja altamente adaptável para acessar bancos de dados na Internet.
As características técnicas do MariaDB

Para informações técnicas avançadas, veja Referência de Linguagem do MariaDB. O Programa de Banco de Dados MariaDB é um sistema cliente/servidor que consiste de um servidor SQL multi-tarefa que suporta acessos diferentes, diversos programas clientes e bibliotecas, ferramentas administrativas e diversas interfaces de programação (API's).

Também concedemos o Servidor MySQL como uma biblioteca multi-tarefa que você pode ligar à sua aplicação para chegar a um produto mais rápido, menor e mais fácilmente gerenciável.
MySQL tem muitos softwares de colaboradores disponível.

É bem provável que sua aplicação ou linguagem favorita já suporte o Servidor de Banco de Dados MariaDB.

A pronúncia oficial do MariaDB é Mai Ess Que Ell (e não MAI-SEQUEL). Mas nós não ligamos se você pronunciar MAI-SEQUEL ou de outra forma qualquer.

História do MariaDB

Quando começamos, tínhamos a intenção de usar o mSQL para conectar às nossas tabelas utilizando nossas rápidas rotinas de baixo nível (ISAM). Entretanto, depois de alguns testes, chegamos a conclusão que o mSQL não era rápido e nem flexível o suficiente para nossas necessidades. Isto resultou em uma nova interface SQL para nosso banco de dados, mas com praticamente a mesma Interface API do mSQL. Esta API foi escolhida para facilitar a portabilidade para códigos de terceiros que era escrito para uso com mSQL para ser portado facilmente para uso com o MariaDB.

A derivação do nome MariaDB não é bem definida. Nosso diretório base e um grande número de nossas bibliotecas e ferramentas sempre tiveram o prefixo my por pelo menos 10 anos. A filha de Monty também ganhou o nome My. Qual das duas originou o nome do MariaDB continua sendo um mistério, mesmo para nós.

O nome do golfinho do MariaDB (nosso logo) é Sakila. Sakila foi escolhido pelos fundadores da MariaDB Foundation de uma enorme lista de nomes sugeridos pelos usuários em nosso concurso 'Name the Dolphin'. O nome vencedor foi enviado por Ambrose Twebaze, um desenvolvedor de programas open source de Swaziland, Africa. De acordo com Ambrose, o nome Sakila tem as suas raízes em SiSwati, a língua local de Swaziland. Sakila é também o nome de uma cidade em Arusha, Tanzania, próxima ao país de orígem de Ambrose, Uganda.

As Principais Características do MariaDB

A seguinte lista descreve algumas das características mais importantes do Progrma de Banco de Dados MariaDB. Leia 'MariaDB in a Nutshell'.

Portabilidade e
- Escrito em C e C++.
- Testado com um amplo faixa de compiladores diferentes.
- Funciona em diversas plataformas. Leia 'Sistemas Operacionais suportados pelo MySQL'.
- Utiliza o GNU Automake, Autoconf, e Libtool para portabilidade.
- APIs para C, C++, Eiffel, Java, Perl, PHP, Python, Ruby e Tcl estão disponíveis. Leia Ferramentas de Clientes e APIs do MariaDB.
- Suporte total a multi-threads usando threads diretamente no kernel. Isto significa que se pode facilmente usar múltiplas CPUs, se disponível.
- Fornece mecanismos de armazenamento transacional e não transacional.
- Tabelas em disco (MyISAM) baseadas em árvores-B extremamente rápidas com compressão de índices.
- É relativamente fácil se adicionar outro mecanismo de armazenamento. Isto é útil se você quiser adicionar uma interface SQL a um banco de dados caseiro.
- Um sistema de alocação de memória muito rápido e baseado em processo(thread).
- Joins muito rápidas usando uma multi-join de leitura única otimizada.
- Tabelas hash em memória que são usadas como tabelas temporárias.
- Funções SQL são implementadas por meio de uma biblioteca de classes altamente otimizada e com o máximo de performance. Geralmente não há nenhuma alocação de memória depois da inicialização da pesquisa.
- O código do MariaDB foi testado com Purify (um detector comercial de falhas de memória) e também com o Valgrind, uma ferramenta GPL (http://developer.kde.org/~sewardj/).
- Disponível como versão cliente/servidor ou embutida(ligada).
Tipos de Coluna
- Aceita diversos tipos de campos: tipos inteiros de 1, 2, 3, 4 e 8 bytes com e sem sinal, FLOAT, DOUBLE, CHAR, VARCHAR, TEXT, BLOB, DATE, TIME, DATETIME, TIMESTAMP, YEAR, SET e ENUM. Leia 'Tipos de Campos'.
- Registros de tamanhos fixos ou variáveis.
Comandos e Funções
- Completo suporte a operadores e funções nas partes SELECT e WHERE das consultas. Por exemplo:
```
mysql> SELECT CONCAT(first_name, ' ', last_name)
 -> FROM nome_tbl
 -> WHERE income/dependents > 10000 AND age > 30;
```
- Suporte pleno às cláusulas SQL GROUP BY e ORDER BY. Suporte para funções de agrupamento (COUNT(), COUNT(DISTINCT ...), AVG(), STD(), SUM(), MAX() e MIN()).
- Suporte para LEFT OUTER JOIN e RIGHT OUTER JOIN com as sintaxes SQL e ODBC.
- Alias em tabelas e colunas são disponíveis como definidos no padrão SQL92.
- DELETE, INSERT, REPLACE, e UPDATE retornam o número de linhas que foram alteradas (afetadas). É possível retornar o número de linhas com padrão coincidentes configurando um parâmetro quando estiver conectando ao servidor.
- O comando específico do MariaDB SHOW pode ser usado para devolver informações sobre bancos de dados, tabelas e índices. O comando EXPLAIN pode ser usado para determinar como o otimizador resolve a consulta.
- Nomes de funções não conflitam com nomes de tabelas ou colunas. Por exemplo, ABS é um nome de campo válido. A única restrição é que para uma chamada de função, espaços não são permitidos entre o nome da função e o '(' que o segue. Leia 'Tratamento de Palavras Reservadas no MySQL'.
- Você pode misturar tabelas de bancos de dados diferentes na mesma pesquisa (como na versão 3.22).
Segurança
- Um sistema de privilégios e senhas que é muito flexível, seguro e que permite verificação baseada em estações/máquinas. Senhas são seguras porque todo o tráfico de senhas é criptografado quando você se conecta ao servidor.
Escalabilidade e limites
- Lida com bancos de dados enormes. Usamos o Servidor MySQL com bancos de dados que contém 50.000.000 registros e sabemos de usuários que usam o Servidor MySQL com 60.000 tabelas e aproximadamente 5.000.000.000 de linhas.
- São permitidos até 32 índices por tabela. Cada índice pode ser composto de 1 a 16 colunas ou partes de colunas. O tamanho máximo do índice é de 500 bytes (isto pode ser alterado na compilação do MariaDB). Um índice pode usar o prefixo de campo com um tipo CHAR ou VARCHAR.
Conectividade
- Os clientes podem se conectar ao servidor MariaDB usando sockets TCP/IP, em qualquer plataforma. No sistema Windows na família NT (NT, 2000 ou XP), os clientes podem se conectar usando named pipes. No sistema Unix, os clientes podem se conectar usando arquivos sockets.
- A interface Connector/ODBC fornece ao MariaDB suporte a progras clientes que usam conexão ODBC (Open-DataBase-Connectivity). Por exemplo, você pode usar o MS Access para conectar ao seu servidor MariaDB. Os clientes podem ser executados no Windows ou Unix. O fonte do Connector/ODBC está disponível. Todas as funções ODBC são suportadas, assim como muitas outras.
  
  See Seção 12.2, 'Suporte ODBC ao MySQL'.
Localização
- O servidor pode apresentar mensagem de erros aos clientes em várias línguas. Leia 'Mensagens de Erros em Outras Línguas'.
- Suporte total para vários conjuntos de caracteres, que incluem ISO-8859-1 (Latin1), big5, ujis e mais. Por exemplo, os caracteres Escandinavos 'â', 'ä', 'ö' são permitidos em nomes de tabelas e colunas.
- Todos os dados são armazenados no conjunto de caracteres escolhido. Todas as comparações em colunas de seqüências caso-insensitivo.
- A ordenação é feita de acordo com o conjunto de caracteres escolhido (o modo sueco por padrão). É possível alterar isso quando o servidor MariaDB é iniciado. Para ver um exemplo de várias ordenações avançadas, procure pelo código de ordenação Tcheca. O Servidor MySQL suporta diversos conjuntos de caracteres que podem ser especificados em tempo de compilação e execução.
Clientes e Ferramentas
- O servidor MariaDB foi construído com suporte para instruções SQL que verificam, otimizam e reparam tabelas. Estas instruções estão disponíveis a partir da linha de comando por meio do cliente myisamcheck, O MariaDB inclui também o myisamchk, um utilitário muito rápido para realizar estas operações em tabelas MyISAM. Leia Administração do Bancos de Dados MySQL.
- Todos os programas MariaDB podem ser chamados com as opções --help ou -? para obter ajuda online.

Estabilidade do MariaDB

Esta seção discute as questões Quão estável é o MySQL? e Posso depender do MariaDB neste projeto?. Tentaremos deixar claro estes assuntos e responder algumas das questões mais importantes que dizem respeito a muito de nossos usuários. A informação nesta seção é baseada em dados colhidos da lista de discussão, que é muito ativa na identificação de problemas e assim como nos relatos de tipos de uso.

Originalmente, o código vem do início dos anos 80, fornecendo um código estável e o formato de tabelas ISAM permanece compatível com versões anteriores. Na TcX, a predecessora da MySQLAB, o MariaDB vem trabalhando sem problemas em nossos projetos desde o meio de 1996. Quando o Programa de Banco de Dados MariaDB foi disponibilizado para um público maior, nossos novos usuários rapidamente encontraram algumas partes de código sem testes. Desde então, cada distribuição nova teve menos problemas de portabilidade (mesmo com os novos recursos implementados em cada uma destas versões)

Cada distribuição do Servidor MySQL foi sendo usado, e os problemas tem ocorrido somente quando os usuários começam a usar o código das áreas cinzentas. Naturalmente, novos usuários não sabem o que são as áreas cinzentas; esta seção tenta indicar aquelas que são conhecidas atualmente. As descrições lidam com a Versão 3.23 e 4.0 do Servidor MySQL. Todos os erros conhecidos e relatados são corrigidos na última versão, com a exceção dos bugs listados na seção de erros, os quais são relacionados ao desenho. Leia 'Erros Conhecidos e Deficiências de Projetos no MySQL'.

O Servidor MySQL é escrito em múltiplas camadas com módulos independentes. Alguns dos novos módulos estão listados abaixo com indicações de quão bem-testado foi cada um deles.

Replicação --- Gamma

Grandes grupos de servidores usando replicação estão em uso, com bom resultados. O trabalho no aprimoramento dos recursos de replicação continua no MariaDB 4.x.
Tabelas InnoDB --- Estável (na 3.23, 3.23.49)

O mecanismo de armazenamento transacional InnoDB foi declarado estável na árvore do MariaDB 3.23, a partir da versão 3.23.49. InnoDB tem sido usado em sistema de produção grandes e com carga pesada.
Tabelas BDB --- Gamma

O código do Berkeley DB é muito estável, mas ainda estamos melhorando a interface do mecanismo de armazenamento transacional do BDB no Servidor MySQL, assim levará algum tempo até que ele esteja tão bem testado quanto os outro tipos de tabela.
Pesquisas Full-text --- Beta

Pesquisa full-text funcionam mas ainda não são largamente usadas. Melhoramentos importantes forma implementados no MariaDB 4.0.
MyODBC 3.51 (usa ODBC SDK 3.51) --- Estável

Em grande uso na produção. Alguns problemas apresentados parecem ser relacionados a aplicação e independente do driver ODBC ou do servidor de banco de dados.
Recuperação automática de tabelas MyISAM --- Gamma

Este status se aplica apenas ao novo código que confere no mecanismo de armazenamento MyISAM que verifica, na inicialização, se a tabela foi fechada corretamente e executa uma conferência/reparo automático da tabela em caso negativo.
Bulk-insert --- Alpha

Novo recurso nas tabelas MyISAM no MariaDB 4.0 para inserções mais rápidas de vários registros.
Locking --- Gamma

Esse módulo é muito dependente do sistema. Em alguns sistemas existem certos problemas por utilizar o locking padrão do SO (fcntl(). Nestes casos, você deve executar o mysqld com o parâmetro --skip-external-locking. São conhecidos alguns problemas ocorridos em alguns sistemas Linux e no SunOS quando utiliza-se sistemas de arquivos montados em NFS.

Clientes que pagam recebem suporte direto e de alta qualidade da MariaDB Foundation. A MariaDB Foundation também fornece uma lista de discussão como um recurso da comunidade onde qualquer pessoa pode tirar suas dúvidas.

Erros são normalmente corrigidos com um patch; para erros sérios, normalmente é lançada uma nova distribuição.

Qual o Tamanho Que as Tabelas do MariaDB Podem Ter?

A Versão 3.22 do MariaDB tem suporte para tabelas com limite de tamanho até 4G. Com o novo MyISAM no MariaDB versão 3.23 o tamanho máximo foi expandido até 8 milhões de terabytes (2 ^ 63 bytes). Com este tamanho de tabela maior permitido, o tamanho máximo efetivo das tabelas para o banco de dados MariaDB é normalmente limitado pelas restrições do sistema operacional quanto ao tamanho dos arquivos, não mais por limites internos do MariaDB.

A seguinte tabela lista alguns exemplos do limite do tamanho de arquivos do sistema operacional:

Sistema Operacional	Limite do tamanho do arquivo
Linux-Intel 32 bit	2G, muito mais usando LFS
Linux-Alpha	8T (?)
Solaris 2.5.1	2G (É possível 4GB com patch)
Solaris 2.6	4G (pode ser alterado com parâmetro)
Solaris 2.7 Intel	4G
Solaris 2.7 ULTRA-SPARC	8T (?)

No Linux 2.2 você pode ter tabelas maiores que 2 GB usando o patch LFS para o sistema de arquivos ext2. No Linux 2.4 já existem patches para o sistema de arquivos ReiserFS para ter suporte a arquivos maiores. A maioria das distribuições atuais são baseadas no kernel 2.4 e já incluem todos os patches Suporte a Arquivos Grandes (Large File Support - LFS) exigidos. No entanto, o tamanho máximo disponível ainda depende de diversos fatores, sendo um deles o sistema de arquivos usado para armazenar as tabelas MySQL.

Para um visão mais detalhada sobre LFS no Linux, dê uma olha na página Andreas Jaeger's 'Large File Support in Linux' em http://www.suse.de/~aj/linux_lfs.html.

Por padrão, o MariaDB cria tabelas MyISAM com uma estrutura interna que permite um tamanho máximo em torno de 4G. Você pode verificar o tamanho máximo da tabela com o comando SHOW TABLE STATUS ou com o myisamchk -dv nome_tabela Leia 'Sintaxe de SHOW'.

Se você precisa de tabelas maiores que 4G (e seu sistema operacional suporta arquivos grandes), a instrução CREATE TABLE permite as opções AVG_ROW_LENGHT e MAX_ROWS. Use estas opções para criar uma tabela que possa ter mais de 4GB. Leia 'Sintaxe CREATE TABLE'. Você pode também alterar isso mais tarde com ALTER TABLE. Leia 'Sintaxe ALTER TABLE'.

Outros modos se contornar o limite do tamanho do arquivo das tabelas MyISAM são os seguintes:

Se sua tabela grande será somente leitura, você poderá usar o myisampack para unir e comprimir várias tabelas em uma. mysisampack normalmente comprime uma tabela em pelo menos 50%, portanto você pode obter, com isso, tabelas muito maiores. Leia 'myisampack, O Gerador de Tabelas Compactadas de Somente Leitura do MariaDB'.
Outra opção para contornar o limite de tamanho de arquivos do sistema operacional para arquivos de dados MyISAM usando a opção RAID. Leia 'Sintaxe CREATE TABLE'.
O MariaDB incluí uma biblioteca MERGE que permite acessar uma coleção de tabelas idênticas como se fosse apenas uma. Leia 'Tabelas MERGE'.

Compatibilidade Com o Ano 2000 (Y2K)

O Servidor MySQL não apresenta nenhum problema com o ano 2000 (Y2K compatível)

O Servidor MySQL usa funções de tempo Unix que tratam datas até o ano 2037 para valores TIMESTAMP; para valores DATE e DATETIME, datas até o ano 9999 são aceitas.
Todas as funções de data do MariaDB estão no arquivo sql/time.cc e codificadas com muito cuidado para ser compatível com o ano 2000.
No MariaDB versão 3.22 e posterior, o novo tipo de campo YEAR pode armazenar anos 0 e 1901 até 2155 em 1 byte e mostrá-lo usando 2 ou 4 dígitos. Todos os anos de 2 dígitos são considerados estar na faixa de 1970 até 2069; o que significa que se você armazenar 01 em uma coluna YEAR, O Servidor MySQL o tratará como 2001.

O seguinte demonstração simples ilustra que o MySQL Server não tem nenhum problema com datas até depois do ano 2030:

mysql> DROP TABLE IF EXISTS y2k;
Query OK, 0 rows affected (0.01 sec)
mysql> CREATE TABLE y2k (date DATE,
 -> date_time DATETIME,
 -> time_stamp TIMESTAMP);
Query OK, 0 rows affected (0.00 sec)
mysql> INSERT INTO y2k VALUES
 -> ('1998-12-31','1998-12-31 23:59:59',19981231235959),
 -> ('1999-01-01','1999-01-01 00:00:00',19990101000000),
 -> ('1999-09-09','1999-09-09 23:59:59',19990909235959),
 -> ('2000-01-01','2000-01-01 00:00:00',20000101000000),
 -> ('2000-02-28','2000-02-28 00:00:00',20000228000000),
 -> ('2000-02-29','2000-02-29 00:00:00',20000229000000),
 -> ('2000-03-01','2000-03-01 00:00:00',20000301000000),
 -> ('2000-12-31','2000-12-31 23:59:59',20001231235959),
 -> ('2001-01-01','2001-01-01 00:00:00',20010101000000),
 -> ('2004-12-31','2004-12-31 23:59:59',20041231235959),
 -> ('2005-01-01','2005-01-01 00:00:00',20050101000000),
 -> ('2030-01-01','2030-01-01 00:00:00',20300101000000),
 -> ('2050-01-01','2050-01-01 00:00:00',20500101000000);
Query OK, 13 rows affected (0.01 sec)
Records: 13 Duplicates: 0 Warnings: 0
mysql> SELECT * FROM y2k;
+------------+---------------------+----------------+
| date | date_time | time_stamp |
+------------+---------------------+----------------+
| 1998-12-31 | 1998-12-31 23:59:59 | 19981231235959 |
| 1999-01-01 | 1999-01-01 00:00:00 | 19990101000000 |
| 1999-09-09 | 1999-09-09 23:59:59 | 19990909235959 |
| 2000-01-01 | 2000-01-01 00:00:00 | 20000101000000 |
| 2000-02-28 | 2000-02-28 00:00:00 | 20000228000000 |
| 2000-02-29 | 2000-02-29 00:00:00 | 20000229000000 |
| 2000-03-01 | 2000-03-01 00:00:00 | 20000301000000 |
| 2000-12-31 | 2000-12-31 23:59:59 | 20001231235959 |
| 2001-01-01 | 2001-01-01 00:00:00 | 20010101000000 |
| 2004-12-31 | 2004-12-31 23:59:59 | 20041231235959 |
| 2005-01-01 | 2005-01-01 00:00:00 | 20050101000000 |
| 2030-01-01 | 2030-01-01 00:00:00 | 20300101000000 |
| 2050-01-01 | 2050-01-01 00:00:00 | 00000000000000 |
+------------+---------------------+----------------+
13 rows in set (0.00 sec)

O valor da coluna TIMESTAMP final é zero porque o ano final (2050) excede o TIMESTAMP maximo. O tipo de dados TIMESTAMP, que é usado para armazenar a hora atual, suporta valores na faixa de 19700101000000 a 20300101000000 em máquinas 32 bits (valor com sinal). Em máquinas de 64 bits, TIMESTAMP trata valores até 2106 (valores sem sinal).

O exemplo mostra que os tipos DATE e DATETIME não tem problemas com as datas usadas. Eles irão conseguir trabalhar com datas até o ano 9999.

Embora o MySQL Server seja seguro em relação ao ano 2000, você pode ter problemas se você usá-lo com aplicações que não são seguras com o ano 2000. Por exemplo, muitas aplicações antigas armazenam ou manipulam anos usando valores de 2 digitos (que são ambíguos) em vez de 4 dígitos. Este problema pode ser aumentado por aplicações que usam valores como 00 ou 99 como indicadores de valores perdidos. Infelizmente, estes problemas pode ser difíceis de corrigir, cada um deles pode usar um conjunto diferente de convenções e funções de tratamento de datas.

Assim, apesar do Servidor MySQL não ter problemas com o ano 2000, é de responsabilidade de sua aplicação fornecer datas que não sejam ambíguas. Veja 'Assuntos referentes ao ano 2000 (Y2K) e Tipos de Data' para as regras do Servidor MySQL para lidar com entrada de datas ambíguas que contenham valores de ano com 2 dígitos.

Visão Geral da MariaDB Foundation

O Modelo de Negócio e Serviços da MariaDB Foundation
Informações para Contato

MariaDB Foundation é a companhia dos fundadores e principais desenvolvedores do MariaDB. A MariaDB Foundation foi estabelecida originalmente na Suécia por David Axmark, Allan Larsson e Michael Monty Widenius.

Os desenvolvedores do servidor MariaDB são todos empregados pela companhia. ny Nós somo uma organização virtual com pessoas em uma dúzia de países. Nos comunicamos extensivamente na internet todos os dias uns com os outros e com nossos usuários, agentes de suporte e parceiros.

Nós nos dedicamos a desenvolver o programa MariaDB e propagar nosso banco de dados a novos usuários.A MariaDB Foundation detém os direitos autorais do código fonte do MariaDB, do logo e da marca MariaDB e deste manual. Leia 'Visão Geral do Sistema de Gerenciamento de Banco de Dados MariaDB'.

A ideologia do MariaDB mostra nossa dedicação ao MariaDB e ao Open Source.

Nós desejamos que o Programa de Banco de Dados MariaDB seja:

O melhor e o mais usado banco de dados no mundo.

Acessível e disponível para todos.
Fácil de usar.
Melhorado continuamente, permanecendo rápido e seguro.
Divertido de se usar e aprimorar.
Livre de erros (bugs).

A MariaDB Foundation e sua equipe:

Promovem a filosofia Open Source e suporte à comunidade Open Source.
Tem como objetivo serem bons cidadãos.
Tem preferência por parceiros que compartilhem nossos valores e idéias.
Respondem e-mails e dão suporte.
São uma empresa virtual, conectada com outras.
Trabalha contra patentes de sistemas.

O site do MariaDB (http://www.mysql.com/) fornece as últimas informações sobre o MariaDB e a MariaDB Foundation.

A propósito, a parte AB do nome da companhia é o acrônimo para a palavra suéca aktiebolag, ou sociedade anônima. Ela é traduzida para MariaDB Foundation De fato, MariaDB Foundation e MariaDB Foundation são exemplos de subsidiárias da MariaDB Foundation. Elas estão localizadas nos EUA e Alemanha, respectivamente.

O Modelo de Negócio e Serviços da MariaDB Foundation

Suporte
Treinamento e Certificação
Consultoria
Licenças Comerciais
Parcerias

Uma das dúvidas mais comuns que encontramos é: Como você pode viver de algo que você disponibiliza sem custo? É assim que fazemos.

A MariaDB Foundation ganha dinheiro com suporte, serviços, licenças comerciais e royalties. Usamos estes rendimentos para patrocinar o desenvolvimento de produtos e para expandir os negócios da MariaDB.

A compania tem sido luccrativa desde de sua criação. Em Outubro de 2001, aceitamos um financiamento de risco de investidores Escandinavos e um pounhado de pessoas de negócio. Este investimento é usado para solidificarmos nosso modelo de negócio e construir um base para o crescimento sustentável.

Suporte

A MariaDB Foundation é gerenciada pelos fundadores e principais desenvolvedores do banco de dados MariaDB. Os desenvolvedores tem o compromisso de dar suporte aos clientes e outros usuários com objetivo de manterem contato com as suas necessiades e problemas. Todo o nosso suporte é dado por desenvolvedores qualificado. Dúvidas mais complicadas são respondidas por Michael Monty Widenius, principal autor do MySQL Server. Leia 'Suporte Oferecido pela MariaDB Foundation'.

Para maiores informações e pedido de suporte de diversos níveis, veja http://www.mysql.com/support/ ou contate nossos vendedores em <sales@mysql.com>.

Treinamento e Certificação

A MariaDB Foundation distribui o MariaDB e treinamentos relacionados mundialmente. Oferecemos tanto cursos abertos quanto fechados voltado para a necessidade específica da sua empresa. O Treinamento do MariaDB também está disponível por meio de seus parceiros, os Centros de Treinamento Autorizados do MariaDB.

Nosso material de treinamento usa os mesmos bancos de dados exemplos usados em nossa documentação e nossos exemplos de aplicativos. Ele está sempre atualizado de acordo com a última versão do MariaDB. Nossos instrutores são apoiados por nossa equipe de desenvolvimento para garantir a qualidade do treinamento e o desenvolvimento contínuo do material de nossos cursos. Isto também assegura que nenhuma questão surgida durante o curso fique sem resposta.

Fazendo nossos cursos de treinamento permitirá que você alcance os objetivos de seu aplicativo MariaDB. você também irá:

Economizar tempo.
Melhorar o desempenho de seus aplicativos.
Reduzir ou eliminar a necessidade de hardware adicional, baixando o custo.
Melhorar a segurança.
Aumentar a satisfação dos clientes e colabloradores.
Preparar-se para Certificação MySQL.

Se você estiver interessado em nosso treinamento como um participante em portencial ou como um parceiro de treinamento, viste a seção de treinamento em http://www.mysql.com/training/ ou contate nos em: <training@mysql.com>.

Para detalhes sobre o Programa de Certificação MySQL, veja http://www.mysql.com/certification/.

Consultoria

A MariaDB Foundation e seus Parceiros Autorizados oferecem serviços de consultoria para usuários do Servidor MySQL e àqueles que utilizam o Servisdor MySQL embutido em seus programas, em qualquer parte do mundo.

Nossos consultores podem ajudá-lo projetando e ajustando o seu banco de dados, criar consultas eficientes, ajustar sua plataforma para uma melhor performance, resolver questões de migração, configurar replicação, criar aplicações transacionais robustas, e mais. Também ajudamos os nossos clientes com o Servidor MySQL embutido em seus produtos e aplicações para desenvolvimento em larga-escala.

Nossos consultores trabalham em colaboração com a nossa equipe de desenvolvimento, o que assegura a qualidade técnica de nossos serviços profissionais. Os serviços de consultoria varia de sessões de 2 dias a projetos que gastam semanas e meses. Nosso peritos não apenas cobrem o Servidor MySQL¯eles também conhecem sobre linguagens de programação e scripts tais como PHP, Perl e mais.

Se estiver interessado em nossos serviços de consultoria ou quiser se tornar nosso parceiro, visite a seção sobre consultaria em nosso web site em http://www.mysql.com/consulting/.

Licenças Comerciais

O banco de dados MariaDB é liberado sob a licença GNU General Public License (GPL). Isto significa que o programa MariaDB pode ser usado sem custos sob a GPL. Se você não deseja estar limitado pelos termos da GPL (tais como a exigência de que a sua aplicação também deva ser GPL), você pode comprar uma licença comercial para o mesmo produto da MariaDB Foundation; veja http://www.mysql.com/products/pricing.html. Desde de que a MariaDB Foundation é dona dos direitos do código fonte do MariaDB, estamos aptos a empregar o Licenciamento Dual, que significa que o mesmo produto está disponível sob a GPL e sob uma licença comercial. Isto não afeta o nosso comprometimento com o Open Source de forma alguma. Para detalhes sobre quando uma licença comercial é exigida, veja 'Licenças do MariaDB'.

Parcerias

A MariaDB Foundation tem um programa de parceria mundial que cobre cursos de treinamento, consultaria e suporte, publicações, mais a revenda e distribiuição do MariaDB e produtos relacionados. Os Parceiros da MariaDB Foundation ganham visibilidade no nosso web site (http://www.mysql.com/) e o direito de usarem versões especiais da marca MariaDB para identificar seus produtos e promoverem os seus negócios.

Se você está interessado em se tornar um Parceiro da MariaDB Foundation, envie-nos um email para <partner@mysql.com>.

A palavra MariaDB e o logomarca do golfinho da MariaDB são marcas registradas da MariaDB Foundation. Leia 'Logomarcas e Marcas Registradas da MariaDB Foundation'. Estas marcas registradas representam um valor significante que os fundadores do MariaDB construiram ao longo dos anos.

O web site do MariaDB (http://www.mysql.com/) é popular entre desenvolvedores e usuários. Em Outubro de 2001, obtivemos mais de 10 milhões e views. Nossos visitantes representam um grupo que tomam decisões de compra e fazem recomendções de software e hardware. Vinte por cento de nossos vistantes autorizam decisões de compra e apenas nove por cento não estão envolvidos com a área de compras. Mais de 65% fizeram uma ou mais compras online no último semaster e 70% planejam fazer uma compra nos próximos meses.

Informações para Contato

O web site do MariaDB (http://www.mysql.com/) fornece as últimas informações sobre MariaDB e MariaDB Foundation.

Para serviços de imprensa e questões não cobertas por nossas releases de nottícias (http://www.mysql.com/news/), envie-nos um email para <press@mysql.com>.

Se você tiver um contrato de suporte válido com a MariaDB Foundation, você receberá em tempo, respostas precisas para as suas questões técnicas sobre o programa MariaDB. Para mais informações, veja 'Suporte Oferecido pela MariaDB Foundation'. Em nosso site na web, veja http://www.mysql.com/support/, ou envie um e-mail para <sales@mysql.com>.

Para informações sobre treinamento MariaDB, visite a seção de treinamento em http://www.mysql.com/training/. Se você tiver acesso restrito à Internet, conte a equipe de treinamento da MariaDB Foundation via e-mail em <training@mysql.com>. Leia 'Treinamento e Certificação'.

Para informações sobre o Progrma de Certificaço MySQL, veja http://www.mysql.com/certification/. Leia 'Treinamento e Certificação'.

Se você estiver interessado em consultoria, visite a seção de consultorias de nosso web site em http://www.mysql.com/consulting/. Leia 'Consultoria'.

Licenças comerciais podem ser compradas online em https://order.mysql.com/. Lá você também encontrará informações de como enviar um fax da sua ordem de compra para a MariaDB Foundation. Mais informações sobre licenças podem ser encontradas em http://www.mysql.com/products/pricing.html. Se você tiver duvidas em relação a licenciamento ou quiser cota para negociação de um alto volume de licenças, preencha o formulário de contato em nosso site web (http://www.mysql.com/) ou envie um email para <licensing@mysql.com> (para questões sobre licenciamento) ou para <sales@mysql.com> (para pedidos de compra). Leia 'Licenças do MariaDB'.

Se você está interessado em fazer parceira com a MariaDB Foundation, envie um e-mail para <partner@mysql.com>. Leia 'Parcerias'.

Para mais detalhes sobre a política da marca MariaDB, visite http://www.mysql.com/company/trademark.html ou envie um e-mail para <trademark@mysql.com>. Leia 'Logomarcas e Marcas Registradas da MariaDB Foundation'.

Se você está interessado em qualquer um dos trabalhos da MariaDB Foundation lista na seção de trabalhos (http://www.mysql.com/company/jobs/), envie um e-mail para <jobs@mysql.com>. Não nos envie o seu CV em anexo, mas como texto no final de sua mensagem de email.

Para discussões gerais entre nosso muitos usuários, direcione a sua atenção para a lista de discussão apropriada. Leia 'Listas de Discussão MySQL'.

Relatórios de erros (geralmente chamados bugs), assim como questões e comentários, devem ser enviados para a lista de email geral do MariaDB. Leia 'As Listas de Discussão do MariaDB'. Caso você encontre um bug de segurança importante no MySQL Server, envie-nos um e-mail para <security@mysql.com>. See 'Como relatar erros ou problemas'.

Se você tiver resultados de benchmarks que podemos publicar, contate-nos via e-mail em <benchmarks@mysql.com>.

Se você tiver sugestões a respeito de adições ou conexões para este manual, envie-os para a equipe do manual via e-mail em http://www.mysql.com/company/contact/.

Para questões ou comentários sobre o funcionamento ou coteúdo do web site da MariaDB (http://www.mysql.com/), envie um e-mail para <webmaster@mysql.com>.

A MariaDB Foundation tem uma política de privacidade que pode ser lida em http://www.mysql.com/company/privacy.html. Para qualquer questões a respeito desta política, envie um e-mail para <privacy@mysql.com>.

Para todos os outros assunto, envie um e-mail para <info@mysql.com>.

Suporte e Licenciamento do MariaDB

Suporte Oferecido pela MariaDB Foundation
Copyrights e Licenças Usadas pelo MySQL
Licenças do MariaDB
Logomarcas e Marcas Registradas da MariaDB Foundation

Esta seção descreve os contratos de licenciamento e suporte do MariaDB.

Suporte Oferecido pela MariaDB Foundation

O suporte técnico do MariaDB Foundation significa respostas individualizadas as seus problemas particulares diretamente dos engenheiros de software que codificaram o MariaDB.

Tentamos ter uma visão ampla e inclusiva de suporte técnico. Qualquer problema envolvendo o MariaDB é importante par nós se for importante para você. Normalmente os clientes procuram ajuda em como comandos e utilitários diferentes funcionam, remover gargalos de desempenhos, restaurar sistemas com falhas, entender impactos do sistema operacional e rede no MariaDB, configurar melhor práticas de backup e restauração, utiluizaar APIs, e assim por diante. Nosso suporte cobre apenar o servidor MariaDB e nossos próprios utilitários, e não produtos de terceirosque acessam o servidor MariaDB, embora tentamos ajudar com eles quando podemos.

Informações detalhadas sobre nossas várias opções de suporte é dado em

Suporte técnico é como seguro de vida. Você pode viver felizsem ele durante anos, mas quando sua hora chegar ele é de grande importância, mas já é muito tarde para adquirí-lo. Se você utiliza o MySQL Server para aplicações importantes e encontrar dificuldades repentinas, você pode gastar horas tentando resolver os problemas sozinho. Você pode precisar de acesso imediato aos responsáveis pela solução de problemas do MariaDB dsiponíveis, contratados pela MariaDB Foundation.

Copyrights e Licenças Usadas pelo MariaDB

MariaDB Foundation possui os direitos sobre o código fonte do MariaDB, as logomarcas e marcas registradas do MariaDB e este manual. Leia 'Visão Geral da MariaDB Foundation'. Diversas licenças são relevantes a distribuição do MariaDB:

Todo o código específico do MariaDB no servidor, a biblioteca mysqlclient e o cliente, assim como a biblioteca GNU readline é coberta pela GNU General Public License. Leia Apêndice H, GPL - Licença Pública Geral do GNU. O texto desta licença podee ser encontrado no arquivo COPYING na distribuição.
A biblioteca GNU getopt é coberta pela GNU Lesser General Public License. Veja http://www.fsf.org/licenses/.
Algumas partes da fonte (a biblioteca regexp) é coberta por um copyright no estilo Berkeley.
Versões mais antiga do MariaDB (3.22 e anteriror) estão sujeitos a uma licença estrita (http://www.mysql.com/products/mypl.html). Veja a documentação da versão específica para mais informação.
O manual de referência do MariaDB atualmente não é distribuído sob uma licecnça no estilo da GPL. O uso deste manual está sujeito aos seguintes termos:
- A conversão para outros formatos é permitido, mas o conteúdo atual não pode ser alterado ou editado de modo algum.
- Você pode criar uma cópia impressa para seu próprio uso pessoal.
- Para todos os outros usos, como venda de cópias impressas ou uso (de partes) do manual em outra publicação, é necessários um acordo com a MariaDB Foundation previamente escrito.
Envie-nos email para http://www.mysql.com/company/contact/ para maiores informações ou se você estiver interessado em fazer a tradução.

Para informações sobre como as licenças do MariaDB funcionam na prática, de uma olhada em 'Licenças do MariaDB'. Veja também 'Logomarcas e Marcas Registradas da MariaDB Foundation'.

Licenças do MariaDB

Usando o Programa MariaDB Sob uma Licença Comercial
Usando o Programa MariaDB Sem Custo Sob GPL

O programa MariaDB é distribuído sob a GNU General Public License (GPL), que é provavelmente a melhor licença Open Source conhecida. Os termos formais da licença GPL pode ser encontrado em http://www.fsf.org/licenses/. Veja também http://www.fsf.org/licenses/gpl-faq.html e http://www.gnu.org/philosophy/enforcing-gpl.html.

Como o programa MariaDB é distribuído sob a GPL, ele pode ser usa geralmente de graça, mas para certos usos você pode querer ou precisar comprar lincenças comerciais da MariaDB Foundation em https://order.mysql.com/. Veja http://www.mysql.com/products/licensing.html para mais informações.

Versões mais antigas do MariaDB (3.22 e anteriores) estão sujeitos a uma licença mais estrita (http://www.mysql.com/products/mypl.html). Veja a documentação da versão específica para mais informação.

Note que o uso do programa MariaDB sob uma licença comercial, GPL ou a antiga licença do MariaDB não dá automaticamente o direito de usar as marcas registradas da MariaDB Foundation. Leia 'Logomarcas e Marcas Registradas da MariaDB Foundation'.

Usando o Programa MariaDB Sob uma Licença Comercial

A licença GPL é contagiosa no sentido de que quando um programa é ligado a um programa GPL, todo o código fonte para todas as partes do produto resultante também devem ser distribuídas sob a GPL. Se você não seguir esta exigência do GPL, você quebra os termos da licença e perde o seu direito de usar o programa GPL incluído. Você também corre riscos.

Você precisará de uma licença comercial:

Quando você liga um programa com qualquer código GPL do programa MariaDB e não que que o produto resultante seja licenciado sob a GPL, talvez porque você queira criar um produto comercial ou manter fechado o código não GPL adicionado por outras razões. Ao comprar a lincença comercial, você não está usando o programa MariaDB sob GPL embora o código seja o mesmo.
Quando você distribui uma aplicação não GPL que só funciona com o programa MariaDB e a entrega com o programa MariaDB. Este tipo de solução é considerada mesmo se feita em uma rede.
Quando você distribui cópias do programa MariaDB sem fornecer o código fonte como exigido sob a licença GPL.
Quando você quiser dar suporte adional ao desenvolvimento do banco de dados do MariaDB mesmo se você não precisar formalmente de uma licença comercial. Comprar o suporte diretamente da MariaDB Foundation é outro bom modo de contribuir com o desenvolvimento do programa MariaDB, com vantagens imediatas para você. Leia 'Suporte Oferecido pela MariaDB Foundation'.

Se você requisita uma licecnça, você precisará de uma para cada instalação do programa MariaDB. Ela cobre qualquer número de CPUs na máquina, e nãp há nenhum limite artificial no número de clientes que conectam aom servidor de qualquer modo.

Para licenças comercias, ,visite o nosso site web em http://www.mysql.com/products/licensing.html. Para contrato de suporte, veja http://www.mysql.com/support/. Se você tiver necessidades especiais ou tiver acesso restrito a Internet, contate a nossa quipe de vendas via email em <sales@mysql.com>.

Usando o Programa MariaDB Sem Custo Sob GPL

Você pode utilizar o programa MariaDB sem custo sob a GPL se você concordar as condições do GPL. Para detalhes adicionais, incluindo respostas a duvidas comuns sobre a GPL, veja o FAQ gencio da Free Software Foundation em http://www.fsf.org/licenses/gpl-faq.html. Usos comuns da GPL incluem:

Quando você distribui sua própria aplicação e o código fonte da MariaDB com o seu produto.
Quando você distribui o código fonte do MariaDB junto com outros programas que não são ligados ou dependentes do sistema do MariaDB para suas funcionalidades mesmo se você vender a distribuição comercialmente. Isto é chamado agregação na licença GPL.
Quando você não está distribuindo qualquer parte do sistema do MariaDB, você pode usá-lo de graça.
Quando você for um Provedos de Serviços de Internet (Internet Service Provider - ISP), oferecendo hospedagem web com serviodres MariaDB para seus clientes. Encorajamos as pessoas a usarem provedroes que possuem suporte ao MySQL, já que isto lhes dará a confiança qie seus provedores terão, de fato, os recursos para resolver qualquer problema que eles possam experimentar com a instalação do MariaDB. Mesmo se um provedor não tiver uma licença comercial ara o MySQL Server, seus clientes devem ter acesso de leitura ao fonte da instalação do MariaDB para que seus clientes verifiquem que ela está correta.
Quando você usa o banco de dados MariaDB em conjunto com um servidor web, você não precisa de uma licença comercial (uma vez que este não é um produto distribuído por você). Isto é verdade mesmo se você executar um servidor web comercial que utilize MySQL Server, pois você não está distribuindo qualquer parte do sistema MariaDB. No entanto, neste caso nós gostariamos que você adquirisse o suporte ao MariaDB pois o MariaDB está ajudandoa sua empresa.

Se o seu uso do banco de dados MariaDB não exige uma licença comercial, lhe encorajamos a adquirir um suporte da MariaDB Foundation de qualquer forma. Deste modo você contribui com o desenvolvimento do MariaDB e também ganha vantegens imediatas. Leia 'Suporte Oferecido pela MariaDB Foundation'.

Se você utiliza o bancdo de dados MariaDB em um contexto comercial e obtem lucro com o seu uso, pedimos que você ajude no desenvolvimento do MariaDB adquirindo algum nível de suporte. Sentimos que se banco de dados MariaDB ajudou os seus negócios, é razoável pedirmos que você ajude a MariaDB Foundation. (De outra forma, se você nos pedir suporte, você não só estará usando de graça algo em que colocamos muito trabalhom mas também pedindo que lhe forneçamos suporte de graça também).

Logomarcas e Marcas Registradas da MariaDB Foundation

O Logo Original do MariaDB
Logomarcas da MariaDB que Podem Ser Usadas Sem Permissão de Alteração
Quando Você Precisa de Permissão de Alteração para Usar as Logomarcas do MariaDB?
Logomarcas dos Parceiros da MariaDB Foundation
Usando a Palavra MariaDB em Texto Impresso ou Apresentação
Usando a Palavra MariaDB em Nomes de Companhias e Produtos

Muitos usuários do banco de dados MariaDB deseja mostar o logo do golfinho da MariaDB Foundation em seus web sites,livros ou produtos fechados. Isto é bem vindo, mas deve haver anotações indicando que a palavra MariaDB e o logo do golfinho da MariaDB são marcas registradas da MariaDB Foundation e só podem ser usadas como indicado na nossa política de marcas registradas em http://www.mysql.com/company/trademark.html.

O Logo Original do MariaDB

O logo do golfinho do MariaDB foi desenhado pela Finnish advertising agency Priority em 2001. O golfinho foi escolhido como um símbolo para o baco de dados MariaDB já que ele é esperto, rápido e um animal ágil, se esforándo em navegar pelos oceanos de dados. Nós também gostamos de golfinos.

O logo original MariaDB só podem ser usados pr representates da MariaDB Foundation e aqueles que possuem um acordo escrito permitndo-os de fazê-lo.

Logomarcas da MariaDB que Podem Ser Usadas Sem Permissão de Alteração

Projetamos um conjunto de logos especiais de Uso Condicionale que podem se encontrados em nosso site web em http://www.mysql.com/press/logos.html e usado em sites web de terceiros sem permissões de escrita da MariaDB Foundation. O uso destas logomarcas não são totalmente irrestritas mas, como o nome indica, sujeitos a nossa política de marcas registradasque também está disponível em nosso site. Você deve ler a política de marcas registradas se plabeja usá-las. As exigências são basicamente as apresentadas aqui:

Use a logomarca que você preciisa como mostrado no site http://www.mysql.com/. Você pode mudar sua escala para servir as suas necessidades, mas não pode alterar cores ou o desenho, ou alterar os graficos de forma alguma.
Deixe evidente que você, e não a MariaDB Foundation, é o criado e proprietário do site que mostra a logomarca do MariaDB.
Não use a logomarca em detrimento à MariaDB Foundation ou ao valor das marcas registradas da MariaDB Foundation. Nos reservamos o direito de revogar o diretiro de uso da marcas registradas da MariaDB Foundation.
Se você utilizar as maracas em um site da web, faça com que ele contenha um link para http://www.mysql.com/.
Se você utilizar o banco de dados MariaDB sob GPL em uma aplicação, sua aplicação deve ser Open Source deve estar apta a conectar a um servidor MariaDB.

Contate-nos via e-mail em <trademark@mysql.com> para saber sobre os nosso acordos especiais que sirvam as suas necessidades.

Quando Você Precisa de Permissão de Alteração para Usar as Logomarcas do MariaDB?

Você precisa de permissão escrita da MariaDB Foundation antes de usar as logomarcas do MariaDB nos seguintes casos:

Quando exibir qualquer logomarca da MariaDB Foundation em qualquer lugar diferente so seu site.
Quando exibir qualquer logomarca da MariaDB Foundation exceta as de Uso Condicional mencionadas anteiormente em sites ou outro lugar.

Devido a razões comerciais e legais monitoramos o so das marcas registradas do MariaDB em proutos, livros e outros itens. Normalmente exigimos um valor para a exibição das logomarcas da MariaDB Foundation em produtos comerciais, já que achamos razoável que parte dos rendimentos seja retornado para financiar o desenvolvimento do banco de dados MariaDB.

Logomarcas dos Parceiros da MariaDB Foundation

As logomarcas de parceria do MariaDB podem ser usados apenas por companhias e pessoas que possuem um acordo de parceria por escrito com a MariaDB Foundation. Parceiras incluem certificação com treinador ou consultor do MariaDB. Para mais informações, 'Parcerias'.

Usando a Palavra `MariaDB` em Texto Impresso ou Apresentação

A MariaDB Foundation considera bem vindas as referências ao banco de dados MariaDB mas deve ser indicado que a palavra MariaDB é uma marca registrada da MariaDB Foundation. Por isto, você deve adicionar o simbolo de marca registrada (TM) ao primeiro ou mais proeminente uso da palavra MariaDB em um texto e, onde apropriadom indicar que MariaDB é uma marca registrada da MariaDB Foundation. Para mais informações, veja nossa política de marcas registradas em http://www.mysql.com/company/trademark.html.

Usando a Palavra `MariaDB` em Nomes de Companhias e Produtos

O uso da palavra MariaDB em nomes de produtos ou companias ou em dominios de Internet não é permitida sem permissão escrita da MariaDB Foundation.

Mapa de Desenvolvimento do MariaDB

MariaDB in a Nutshell
MySQL in a Nutshell
MySQL 5.0, A Próxima Distribuição de Desenvolvimento

Esta seção fornece uma amostra do mapa de desenvolvimento do MariaDB, incluindo principais recursos imlementados ou planejados para o MariaDB 4.0, 4.1, 5.0 e 5.1. A seguinte seção fornece informação para cada distribuição. O planejamento para alguns dos recursos mais requisitados estão listada na tabela a seguir.

Feature	MySQL version
Unions	4.0
Subqueries	4.1
R-trees	(para tabelas MyISAM)
Stored procedures	5.0
Views	ou 5.1
Cursors	5.0
Foreign keys	(3.23 com InnoDB)
Triggers	5.1
Full outer join	5.1
Constraints	5.1

MariaDB in a Nutshell

Recursos Disponíveis no MariaDB 4.0
Servidor Embutido MySQL

Muito aguardado por nossos usuários, o MariaDB Server 4.0 agora está disponível em sua versão de produção.

O MariaDB está disponível para download em https://mariadb.com/ e nossos sites mirrors. O MariaDB tem sido testado por um grande número de usuários e está em uso em mutios sites.

Os principais novos recursos do MariaDB Server 4.0 são trabalhados em conjunto com os usuários corporativos e da comunidade, melhorando o programa de banco de dados MariaDB como uma solução para missões críticas e sistemas de bancos de dados de alta carga. Outros novos recursos visam os usuários de bancos de dados embutidos.

O MariaDB foi declarado estável para uso em produção a partir da versão 4.0.12 em Março de 2003. Isto significa que, no futuro, apenas correção de erros serão feitas para a distribuição da série 4.0 e apenas correção de erros críticos serão feitas para a antiga série 3.23. Leia 'Atualizando da Versão 3.23 para 4.0'.

Novos recursos para o MariaDB está sendo adicionado ao MariaDB que também está disponível (versão alfa). Leia 'MySQL in a Nutshell'.

Recursos Disponíveis no MariaDB 4.0

Aumento da velocidade
- O MariaDB tem uma cache de consultas que pode dar uma grande aumento na velocidade de aplicações com consutas repetitivas. Leia 'Cache de Consultas do MariaDB'.
- A versão 4.0 aumenta a velocidade do MariaDB Server em um número e áreas tais como INSERTs em bloco, buscas em índices empacotados, criação de índices FULLTEXT, e COUNT(DISTINCT).
Introdução ao Servidor MariaDB Embutido
- A nova biblioteca do Servidor Ebutido pode ser facilmente usada em aplicações standalone e embarcadas. O servidor embutido fornce uma alternativa para o uso do MariaDB em um ambiente cliente/servidor. Leia 'Servidor Embutido MySQL'.
Mecanismo de armazenamento InnoDB como padrão
- O mecanismo de armazenamento InnoDB é oferecido como um recurso padrão do servidor MariaDB. Isto significa suporte a transações ACID, chaves estrangeiras com UPDATE/DELETE em cacata e lock de registro agora são recursos padrões. Leia 'Tabelas InnoDB'.
Novas fncionalidades
- A melhora das propriedades de busca FULLTEXT do MariaDB Server 4.0 habilita indexação FULLTEXT de grandes partes de texto com linguagem natural e binária de lógica de busca. Você pode personalizar o tamanho mínimo de palavras e definir a sua própria lista de palavras de parasa em qualquer linguagem humana, habilitando um novo conjunto de aplicações a serem construídas no MariaDB Server. Leia 'Pesquisa Full-text no MySQL'.
Compatibilidade com os padrões, portabilidade e migração
- Recursos para simplificar a migração de outros sistemas de banco de dados para o MariaDB Server incluem TRUNCATE TABLE (como no Oracle)
- Muitos usuários também ficarão satisfeitos ao perceber que o MariaDB Server agora suporta a instrução UNION, um recurso padrão SQL muito esperado.
- O MariaDB agora pode ser executado nativamente na plataforma Novell NetWare 6.0. Leia 'Notas Novell NetWare'.
Internacionalização
- Nossos usuários alemães, austríacos e suiços notarão que o MariaDB agora suporta um novo conjunto de caracteres, latin1_de, que assegura que a Ordenação em alemão classificará palavras com umlauts na mesma ordem das agendas telefônicas alemãs.
Aprimoramento da Usabilidade

No porcesso de construção de recursos para novos usuários, não esquecemos os pedidos de nossa leal comunidade de usuários.
- A maioria dos parâmetros mysqld (opções de inicialização) agora podem ser definidas se finalizar o servidor. Isto é um recurso conveniente para Administradores de Bancos de Dados (DBAs). Leia 'Sintaxe de SET'.
- Instruções DELETE e UPDATE multi-tabelas foram adicionadas.
- Foi adicionado suporte ao mecanismo de armazenamento MyISAM para link simbólico no nível de tabela (e não apenas a nível de banco de dados como antes) e para habilitar o tratamento de links simbólicos no Windows por padrão.
- SQL_CALC_FOUND_ROWS e FOUND_ROWS() são novas funções que tornaram possível encontrar o números de linhas que uma consulta SELECT que inclui uma cláusula LIMIT teria retornado se a cláusula não fosse utilizada.

A seção de novidades deste manual inclui uma lista mais aprofundada dos recursos. Leia Seção D.3, 'Alterações na distribuição 4.0.x (Production)'.

Servidor Embutido MariaDB

libmysqld faz o MariaDB Server adequado para uma grande área de aplicações. Usando a biblioteca do servidor MariaDB embutido, pode embarcar o MariaDB Server em vários aplicativos e dispositivos eletrônicos, onde o usuário final não têm conhecimento de possuir um banco de dados básico. O servidor MariaDB embutido é ideal para uso nos bastidores em aplicações de Internet, quiosques públicos, responsável por unidades de combinação hardware/software, servidores Internet de alta performance, banco de dados de auto-contenção distribuídos em CDROM, e assim por diante

Muitos usuários da libmysqld se benficiarão da iLicença Dual do MariaDB. Para aqueles que não desejam ser limitar pela GPL, o software é tambem está disponível sob uma licença comercial. A biblioteca embutida do MariaDB também usa a mesma interface que a biblioteca do cliente normal, sendo então conveniente e fácil de usar. Leia Seção 12.1.15, 'libmysqld, a Biblioteca do Servidor Embutido MySQL'.

MySQL in a Nutshell

Recursos Disponíveis no MariaDB 4.1
Stepwise Rollout
Pronto para Uso em Desenvolvimento Imediato

MySQL Server 4.0 prepara a criação de novos recursos como subqueries e Unicode (implementado na versão 4.1) e o funcionamento de stored procedures do SQL-99 está sendo feito para a versão 5.0. Estes recursos estão no topo da lista de recursos desejados de muitos de nossos clientes.

Com estas adições, os críticos do MariaDB Database Server devem ser mais imaginativos que nunca para apontar as deficiências do MariaDB Database Management System. Já conhecido por sua estabilidadem velocidade e facilidade de uso, o MariaDB Server estará apto a atender as necessidades de vários compradores exigentes.

Recursos Disponíveis no MariaDB 4.1

Os recursos listados nesta seção estão implementados no MariaDB 4.1. Outros poucos recursos estão planejados para o MariaDB 4.1. Leia 'Novos Recursos Planejados Para a Versão 4.1'.

A maioria dos novos recursos em codificação, como stored procedures, estarão disponíveis no MariaDB 5.0. Leia 'Novos Recursos Planejados Para a Versão 5.0'.

Suporte a subqueries e tabelas derivadas
- Uma subquery é uma instrução SELECT aninhada dentro de outras instruções. Uma tabela dericada (unnamed view) é uma subquery na cláusula FROM de outras instruções. Leia 'Sintaxe de Subquery'.
Aumento na velocidade
- Protocols binários mais rápidos com instruções preparadas e parâmetros de ligação. Leia Seção 12.1.4, 'Instruções Preparadas da API C'.
- Indexação BTREE agora é suportado por tabelas HEAP, aumentando de forma significante o tempo de resposta para busca que não são exatas.
Nova funcionalidade
- CREATE TABLE tabela1 LIKE tabela2 lhe permite criar uma nova tabela com a estrutura exatamente igual a de uma tabela existente, usando um único comando.
- Suporte aos tipos espaciais OpenGIS (dados geográficos). Leia Extensões Espacias em MySQL.
- A replicação pode ser feita sobre conexão SSL.
Compatibilidade aos padrões, portabilidade e migração
- O novo protocolo cliente/servidor adiciona a possibilidade de se passar múltiplos avisos ao cliente, no lugar se um único resultado. Isto faz com que o trabalho como uma grande carga de dados seja muito mais fácil de rastrear. SHOW WARNINGS exibe avisos para o último comando. Leia 'SHOW WARNINGS | ERRORS'.
Internacionalização
- Para suportar nossa base de usuário sempre em expansão usando linguagens locais nas aplicações, o programa MariaDB agora oferece suporte Unicode extensivo por meio dos conjunto de caracteres utf8 e ucs2.
- Os conjuntos de caracteres agora podem ser definidos por colunas, tabelas e banco de dados. Isto permite um alto grau de flexibilidade no desenho das aplicações, particularmente para sites-web multi-linguagens.
- Para documentação sobre este suporte a conjunto de caracters aprimorados, veja Conjunto de Caracteres Nacionais e Unicode.
Aprimoramento da usabilidade
- Em resposta a demanda popular, adicionamos um comando HELP com base no servidor que pode ser usado para conseguir ajuda para comandos MySQL. A vantagem de se ter esta informação no lado do servidor é que a informação é sempre aplicável para aquela versão do servidor em particular. Como esta informação está disponível executando uma instrução SQL, outros clientes também poderão ser escritos para acessá-la. Por exemplo, o cliente MariaDB de linha de comando foi modificado para ter esta capacidade.
- No novo protocolo cliente/servidor, várias instruções podem ser feitas com uma única chamada. Leia Seção 12.1.8, 'Tratando a Execução de Múltiplas Consultas na API C'.
- O novo protocolo cliente/servidor também suporta retorno de vários resultados. Isto pode ocorrer como resultado de enviar várias instruções, por exemplo (Veja o item anterior).
- Uma nova sintaxe INSERT ... ON DUPLICATE KEY UPDATE ... tem sido implementada. Isto lhe permite executar um UPDATE em um registro existente se o um INSERT criasse uma chave (índice) primária (PRIMARY) ou única (UNIQUE) (index) duplicada. Leia 'Sintaxe INSERT'.
- Projetamos uma nova função de agrupamento GROUP_CONCAT(), adicionando a capacidade de concatenar colunas de registros agrupados em uma única string de resultado, o que é extremamente útil. Leia 'Funções e Modificadores para Usar com Cláusulas GROUP BY'.

A seção de novidades neste manual incluem uma lista mais completa de recursos. Leia Seção D.2, 'Alterações na distribuição 4.1.x (Alpha)'.

Stepwise Rollout

Novos recursos estão sendo adicionados ao MariaDB 4.1. A versão Alfa já stá disponível para download. Leia 'Pronto para Uso em Desenvolvimento Imediato'.

O conjunto de recursos que estão sendo adicionados a versão 4.1 estão, na maioria, corrigidos. Desenvolvimento adicional já está em andamento na versão 5.0. O MariaDB passam pelos passos de Alfa (tempo no qual os novos recursos ainda podem ser adionados/alterados), Beta (quando já implementamos todos os recursos e apenas correções de erros são realizados0) e Gamma (indicando que ima distribuição de produção está quase pronta). No fim deste processo, o MariaDB se tornará o nova distribuição de produção).

Pronto para Uso em Desenvolvimento Imediato

O MariaDB está atualmente no estágio alfa e os binários estão disponíveis para download em https://mariadb.com/downloads/. Todas as distribuições binárias passaram por nossos extensivos teste sem nenhum erro na plataforma em que testamos. Leia Seção D.2, 'Alterações na distribuição 4.1.x (Alpha)'.

Para aqueles que desejam usar o fonte mais recente do desenvolvimento do MariaDB, deixamos nosso repositório do BitKeeper publicamente disponível. Leia 'Instalando pela árvore de fontes do desenvolvimento'.

MySQL 5.0, A Próxima Distribuição de Desenvolvimento

O novo desenvolvimento para o MariaDB está focado na distribuição 5.0, comrecursos como Stored Procedures entre outros. Leia 'Novos Recursos Planejados Para a Versão 5.0'.

Para aqueles que desejam dar uma olhada no desenvolvimento do MariaDB, deixamos o nosso repositórioo do BitKeeper para o MariaDB versão 5.0 disponível publicamente. Leia 'Instalando pela árvore de fontes do desenvolvimento'.

MySQL e o Futuro (o TODO)

Novos Recursos Planejados Para a Versão 4.1
Novos Recursos Planejados Para a Versão 5.0
Novos Recursos Planejados Para a Versão 5.1
Novos Recursos Planejados Para a Versão em um Futuro Próximo
Novos Recursos Planejados Para a Versão em um Futuro a Médio Prazo
Novos Recursos que Não Planejamos Fazer

Esta seção lista os recursos que planejamos impementar no MySQL Server. As listas são apresentadas por versão, e os itens estão aproximadamente na ordem em que serão feitos.

Nota: Se você é um usuário corporativo com uma necessidade urgente de um recurso particular, por favor, contate <sales@mysql.com> para conversarmos sobre patrocínio. Financiamento feito por uma ou mais companhias nos permite alocar recursos adicionais para aquele propósito específico. Um exemplo de um recurso patrocinado no passado é a replicação.

Novos Recursos Planejados Para a Versão 4.1

Os recursos abaixo ainda não estão implementados no MySQL, mass estão planejados para implementação antes que o MariaDB vá para a fase beta. Para uma lista do que já está feito no MySQL, veja 'Recursos Disponíveis no MariaDB 4.1'.

Suporte OpenSSL estável (o MariaDB tem suporte rudimentar ao OpenSSL, não testado 100%).
Mais teste de instruções preparadas
Mais testes de múltiplos conjunto de caracteres para uma tabela.

Novos Recursos Planejados Para a Versão 5.0

Os seguintes recursos estão planejados para inclusão no MariaDB 5.0. Note que como possuimos diversos desenvolvedores que estão trabalhando em diferentes projetos, haverão também muitos recursos adicionais. Há também um pequena chance qie alguns destes recursos sejam adicionados ao MariaDB 4.1. Para uma lista do que já está feito no MySQL, veja 'Recursos Disponíveis no MariaDB 4.1'.

Para aqueles que desejam dar uma olhada nas novidades do desenvolvimento do MariaDB, deixamos nosso repositório BitKeeper para o MariaDB versão 5.0 publicamente disponível. Leia 'Instalando pela árvore de fontes do desenvolvimento'.

Stored Procedures
- Stored procedures estão sendo implementadas atualmente. Este esforço é baseado no SQL-99, o que tem m sintaxe básica similar (mas não idêntica) a do Oracle PL/SQL. Nós também implementaremos o framework do SQL-99 para enganchar em linguagens externas e (onde possível) compatibilidade com p.ex. PL/SQL e T-SQL.
Nova funcionalidade
- Suporte a cursores elementares.
- A habilidade de especificar explicitamente para tabelas MyISAM que um índice deve ser criado como um índice RTREE. Na versão 4.1, índices RTREE são usados internamente para dados geométricos (tipos de dados GIS), mas não podem ser criados no pedido.
- Registros de tamanhos dinâmicas para tabelas HEAP.
Compatibilidade com o padrão, portabilidade e migração
- Adiciona suporte real a VARCHAR (tamanho de colunas maiores que 255, e sem corte de espaços em branco extras). (Já existe suporte para isto nos mecanismos de armazenamento do MyISAM, mas ainda não está disponível a nível de usuário).
Aumento na velocidade
- SHOW COLUMNS FROM nome_tabela (usado pelo cliente MariaDB para permitir expansões de nomes de colunas) não deve abrir a tabela, apenas o arquivo de definição. ISto exigirá menos memória e será muito mais rápido.
- Permite que o DELETE em tabelas MyISAM usem a cache de registros. Para fazer isto, precisamos atualizar a thread da cache de registro quando atualizarmos os arquivos .MYD.
- Melhores tabes em memória (HEAP):
  - Registro de tamanhos dinâmoicos.
  - Tratamento de registro mais rápido (menos cópia).
Internacionalização
- Ap usar SET CHARACTER SET devemos traduzir toda a consulta de uma vez e não apenas as strings. Isto permitirá que os usuários usem caracteres traduzidos nos nomes de banco de dados, tabelas e colunas.
Aprimoramento da usabilidade
- Resolver a questão de RENAME TABLE em uma tabela usada em uma tabela MERGE ativa, o que possivelmente corrompe a tabela.

Novos Recursos Planejados Para a Versão 5.1

Novas funcionalidades
- Suporte FOREIGN KEY para todos os tipos de tabelas.
- Restrições a nível de colunas.
- Replicação seguro a falhas.
- Backup online com baixa queda de desempenho. O backup online tornará mais fácil adicionar um novo slave de replicação sem desligar o master.
Aumento de velocidade
- Novo formato dos arquivos de definição e tabelas baseados em texto (arquivos .frm) e uma cache de tabelas para a definição de tabelas. Isto nos permitirá fazer consultas mais rápidas da estruturas de tabela e dar um suporte a chaves estrangeiras mais eficiente.
- Otimizar o tipo BIT para gastar 1 bit (agora BIT gasta 1 byte; e é tratado como um sinônimo para TINYINT.)
Aprimoramento da usabilidade
- Adicionar opções ao protocolo cliente/servidor para obter notas de progresso para longos comandos em execução.
- Implementar RENAME DATABASE. Para tornar isto seguro para todos os mecanismos de armazenamento, ele deve funcionar como a seguir:
  - Cria um novo banco de dados.
  - Para cada tabelas, renomeie-a para outro banco de dados, o qual fazemos com o comando RENAME.
  - Apagar o banco de dados antigo.
- Nova alteração da interface de arquivo interno. Isto fará todos os manipuladores de arquivos mais gerais e tornará mais fácil adicionar extensões tipo RAID.

Novos Recursos Planejados Para a Versão em um Futuro Próximo

Novas funcionalidade
- Comando como do Oracle CONNECT BY PRIOR ... para estruturas de busca tipo árvore (hierárquica)
- Adicionar todos os tipos que faltam do SQL-92 e ODBC 3.0.
- Adicionar SUM(DISTINCT).
- INSERT SQL_CONCURRENT e mysqld --concurrent-insert para fazer uma inserção concorrente no fim do arquivo se o arquivo tiver lock de leitura.
- Permitir a atualização de variáveis nas instruções UPDATE. Por exemplo: UPDATE TABLE foo SET @a=a+b,a=@a, b=@a+c.
- Alterar quando as variáveis de usuários são atualizadas e assim pode se usá-las com GROUP BY, como no exemplo a seguir: SELECT id, @a:=COUNT(*), SUM(sum_col)/@a FROM nome_tabela GROUP BY id.
- Adicionar a opção IMAGE a LOAD DATA INFILE para não atualizar campos TIMESTAMP e AUTO_INCREMENT.
- Adicionar a sintaxe LOAD DATA INFILE ... UPDATE que funciona assim:
  - Para tabelas com chaves primárias, se o registro de entrada contém um valor de chave primária, linhas existentes correspondendo às chaves primárias são atualizadas para o restante das colunas de entrada. No entanto, colunas faltosas na inserção dos registros de entradas não são alteradas.
  - Para tabelas com chaves primárias, se um registro de entrada não contém um valor de chave primária ou estrá faltando alguma parte da chave, o registro é tratado como um LOAD DATA INFILE ... REPLACE INTO.
- Fazer com que LOAD DATA INFILE entenda a sintaxe do tipo:
```
LOAD DATA INFILE 'file_name.txt' INTO TABLE tbl_name
 TEXT_FIELDS (text_field1, text_field2, text_field3)
 SET table_field1=CONCAT(text_field1, text_field2),
 table_field3=23
 IGNORE text_field3
```
  Isto pode ser usado para saltar colunas extras no arquivo texto, ou atualizar colunas baseadas nas expressões dos dados lidos.
- Novas funções para tyrabalhar com tipos de colunas SET:
  - ADD_TO_SET(valor,conjunto)
  - REMOVE_FROM_SET(valor,conjunto)
- Se você abortar o MariaDB no meio de uma consulta, você deve abrir outra conexão e matar a consulta antiga em execução. Alternativamente, deve ser feita um tentativa de detecção deste problema no servidor.
- Adicione um interface do mecanismo de armazenamento para informações da tabela assim que você puder usá-la como uma tabela de sistema. Isto seria um pouco mais lento se você pedisse informações sobre todas as tabelas, mas muito flexível. SHOW INFO FROM tbl_name para informações básicas das tabelas deve ser implementado.
- Permite SELECT a FROM crash_me LEFT JOIN crash_me2 USING (a); neste caso é considerado que a vem da tabela crash_me.
- Opções DELETE e REPLACE para a instrução UPDATE (isto deletará registros quando se tiver um erro de chave duplicada durante a atualização).
- Altera o formato de DATETIME para armazenar frações de segundo.
- Possibilitar o uso da nova biblioteca regexp GNU em vez da atual (a biblioteca GNU deve ser muito mais rápida que a antiga).
Compatibilidade com os padrões, portabilidade e migração
- Não adicionar valores DEFAULT automáticos as colunas. Enviar um erro ao usar um INSERT que não contenha uma coluna que não tenha um DEFAULT.
- Adicionar as funções de agrupamento ANY(), EVERY() e SOME(). No padrão SQL isto só funciona em colunas booleanas, mas podemos extendê-las para funcionar em qualquer coluna/expressão tratando valores 0 como FALSE e valores diferentes de 0 como TRUE.
- Corrigir para que o tipo de MAX(coluna) seja o mesmo do tipo da coluna:
```
mysql> CREATE TABLE t1 (a DATE);
mysql> INSERT INTO t1 VALUES (NOW());
mysql> CREATE TABLE t2 SELECT MAX(a) FROM t1;
mysql> SHOW COLUMNS FROM t2;
```
Aumento de velocidade
- Não permitir mais que um número definido de threads façam a recuperação do MyISAM ao mesmo tempo.
- Alterar INSERT ... SELECT para usar inserções concorrentes opcionalmente.
- Adicionar uma opção para descarregar paginas de chaves para tabelas com delayed keys se elas não forem usados por um tempo.
- Permitir joins em partes de chaves (otimização).
- Adicionar simulação de pread()/pwrite() no Windows para permitir inserções concorrentes.
- Um analizador de arquivos de log que possam analizar informações sobre quais tabelas são usadas com mais frequência, a frequência com que joins multi-tables são executados, etc. Isto deve ajudar os usuários a identificar áreas ou projetos de tabelas que podiam ser otimizados para executar consultas muito mais eficientes.
Internacionalização
Aprimoramentos de usabilidade
- Retorna os tipos dos campos originais ao se fazer SELECT MIN(coluna) ... GROUP BY.
- Possibilita especificar long_query_time com uma granularidade em microsegundos.
- Ligue o código myisampack no servidor assim ele poderá realizar operações PACK e COMPRESS.
- Adicionar uma cache de chaves temporária durante INSERT/DELETE/UPDATE para podermos fazer um recuperação se o índice ficar cheio.
- Se você realizar um ALTER TABLE em uma tabela que é ligada simbolicamente a outro disco, crie tabelas tenporárias neste disco.
- Implementar um tipo DATE/DATETIME que trate as informações de fusos horários de forma apropriada e assim lidar com datas em diferentes fusos horários será mais fácil.
- Corrigir o configure para se poder compilar todas as bibliotecas (como no MyISAM) sem threads.
- Permitir variáveis SQL em LIMIT, como em LIMIT @a,@b.
- Saída automática do MariaDB para um navegador web.
- LOCK DATABASES (com diversas opções).
- Muito mais variáveis para SHOW STATUS. Leitura e atualização de registros. Selects em 1 tabela e select com joins. Número de tabelas na select. Número de consultas ORDER BY e GROUP BY.
- mysqladmin copy database novo-banco_dados; exige que o comando COPY seja adicionado ao mysqld.
- Lista de processos deve mostar o número de consultas/threads.
- SHOW HOSTS para xibir informações sobre a cache de nome de máquina.
- Alterar o nome de tabelas de string vazias para NULL para colunas calculadas.
- Não usar Item_copy_string em valores numéricos para evitar a conversão number->string->number no casos de: SELECT COUNT(*)*(id+0) FROM nome_tabela GROUP BY id
- Alterar aqueles ALTER TABLE que não abortam clientes que executam INSERT DELAYED.
- Colunas referênciadas em uma cláusula UPDATE irão conter os valores antigos antes da atualização iniciar.
Novos sistemas operacioais.
- Portar os clientes MariaDB para LynxOS.

Novos Recursos Planejados Para a Versão em um Futuro a Médio Prazo

Implementar função: get_changed_tables(timeout,table1,table2,...)
Alterar leitura através de tabelas para usar mapeamento de memória quando possível. Atualmente somente tabelas compactadas usam mapeamento de memória.
Tornar o código de timestamp automático melhor. Adicionar timestamps para o log de atualizações com SET TIMESTAMP=#;
Usar mutex de leitura/escrita em alguns lugares para obter maior velocidade.
Views simples (inicialmente em uma tabela, depois em qualquer expressão). Leia 'Views'.
Fechar algumas tabelas automaticamente se uma tabela, tabela temporária ou arquivos temporários obtiverem o erro 23 (não pode abrir arquivos suficientes).
Melhor propagação de constantes. Quando uma ocorrência de nome_col=n é encontrada em uma expressão, para algumas constantes n, substitua outras ocorrências de nome_col dentro da expressão por n. Atualmente, isto é feito somente para alguns casos simples.
Alterar todas expressões const com expressões calculadas se possível.
Chave otimizadora = expressão. No momento somente a chave = campo ou a chave = constante são otimizadas.
Melhorar o código de algumas das funções de cópia
Alterar sql_yacc.yy para um analizador em linha para reduzir seu tamanho e obter melhores mensagems de erro (5 dias).
Alterar o analisador para usar somente uma regra para diferentes números de argumentos em uma função.
Utilizar nomes de cálculo completos na parte de ordenação. (For ACCESS97)
MINUS, INTERSECT e FULL OUTER JOIN. (Atualmente UNION [na 4.0] e LEFT OUTER JOIN são suportados).
SQL_OPTION MAX_SELECT_TIME=# para colocar um limite de tempo em uma pesquisa.
Fazer o log de atualizações gravar em um banco de dados.
LIMIT negativo para recuperar dados do fim.
Alarmes em funções clientes de conexão, leitura e escrita.
Por favor, perceba as alterações ao mysqld_safe: de acordo com o FSSTND (que o Debian tenta seguir) arquivos PID dever ir em /var/run/<progname>.pid e arquivos de log em /var/log. Seria ótimo se você puder colocar o diretório de dados na primeira declaração de 'pidfile' e 'log', para que a colocação destes arquivos possa ser alterada com uma simples instrução.
Permitir um cliente requisitar log.
Adicionar uso de zlib() a LOAD DATA INFILE, para permitir que as instruções leiam arquivos compactados com gzip.
Corrigir ordenação e agrupamento de colunas BLOB (parcialmente resolvida agora).
Alterar para o uso de semáforos quando contar threads. Devemos primeiro implementar uma biblioteca de semáforos para a MIT-pthreads.
Adicionar suporte pleno para JOIN com parênteses.
Como uma alternativa para uma thread / conexão gerencie uma fila de threads para manipular as pesquisas.
Permitir obter mais de um bloqueio com GET_LOCK. Quando isto for feito, serão, também, tratados os possíveis deadlocks que essa alteração irá acarretar.

O tempo é fornecido de acordo com a quantidade de trabalho, e não tempo real.

Novos Recursos que Não Planejamos Fazer

Nada; Planejamos ser totalmente compatíveis com o ANSI 92 / ANSI 99.

Fontes de Informações do MariaDB

Listas de Discussão MySQL
Suporte a Comunidade MariaDB Atrvés do IRC (Internet Relay Chat)

Listas de Discussão MariaDB

As Listas de Discussão do MariaDB
Fazendo perguntas ou relatando erros
Como relatar erros ou problemas
Guia para responder questões na lista de discussão

Esta seção introduz a lista de deiscussão do MariaDB e dá algumas explicações sobre como a lista deve ser utilizada. Quando você se inscreve na lista de discussão, você receberá, como mensagens de email, tudo o que é enviado para a lista. Você também poderá enviar suas próprias dúvidas e respostas para a lista.

As Listas de Discussão do MariaDB

Para se inscrever ou cancelar a inscrição de qualquer uma das listas de email descritas nesta seção, visite http://lists.mysql.com/. Por favor, não envie mensagem sobre inscrição ou cancelamento para qualquer das listas de emasil, porque tais mensagens são distribuídas automaticamente para milhares de outros usuários.

Seu site local pode ter muitas inscrições para uma lista de email do MariaDB. Se sim, o site pode ter uma lista de email local, assim as mensagens enviadas para lists.mysql.com do seu site são propagadas para a lista local. Nestes casos, por favor, contate seu administrador de sistema para adicionado ou excluido da lista local do MariaDB.

Se você quiser que as mensagens da lista de discussão sejam enceminhadas para uma caixa de correio separada no seu programa de emails, configure um filtro com base nos cabeçalhos das mensagens. Você pode também usar os cabeçalhos List-ID: ou Entregar-Para: para identificar suas mensagens.

Existe também as seguintes listas de discussão sobre MariaDB atualmente:

announce

Esta é para anuncio de novas versões do MariaDB e programas relacionados. Esta é uma lista com baixo volume na qual todos usuarios do MariaDB deveriam se inscrever.
MariaDB

A principal lista para discussões MariaDB em geral. Note que alguns tópicos são mais bem discutidos em listas mais especializadas. Se você enviar para a lista errada você pode não obter resposta.
mysql-digest

A lista mysql na forma resumida. Isto significa que você irá receber todas mensagens individuais, enviadas na forma de uma grande mensagem uma única vez ao dia.
bugs

Esta lista só será do seu interesse se você quiser ficar informado sobre assuntos relatados desde a última distribuição do MariaDB ou se você quiser estar ativamente envolvido no processo de busca e correção de erros. See 'Como relatar erros ou problemas'.
bugs-digest

Uma versão resumida da lista bugs.
internals

Uma lista para pessoas que trabalham no código do MariaDB. Nesta lista pode-se discutir desenvolvimento do MariaDB e pos-patches.
internals

Uma versão resumida da lista internals.
mysqldoc

Esta lista é para pessoas que trabalham na documentação do MariaDB: pessoas da MariaDB Foundation, tradutores e outros membros da comunidade.
mysqldoc-digest

Esta é uma versão resumida da lista mysqldoc.
benchmarks

Esta lista é para qualquer um interessado em assuntos de desempenho. Discussões concentradas em desempenho de banco de dados (não limitado ao MySQL) mas também inclue categorias ,com desempenho do kernel, sistema de arquivos, sistema de disco e outros.
benchmarks

Esta é uma versão resumida da lista benchmarks.
packagers

Esta lista é para discussões sobre empacotamento e distribuição do MariaDB. Este é o fórum usado pela pessoas que mantém a distribuição para troca de idéias de pacotes do MariaDB e para assegurar que o MariaDB esteja o mais parecido possível em todas as plataformas e sistemas operacionais suportados.
packagers-digest

Esta é uma versão resumida da lista packagers.
java

Discussão sobre o servidor MariaDB e Java. É mais usada para discussões sobre o driver JDBC, incluindo MariaDB Connector/J.
java-digest

Uma versão resumida da lista java.
win32

Esta é a lista para todos os tópicos relacionados ao MariaDB em sistemas operacionais Microsoft, como o Win95, Win98, NT e Win2000.
win32-digest

Uma versão resumida da lista win32.
myodbc

Lista para todos os tópicos relacionados a conectividade do MariaDB com ODBC.
myodbc-digest

Uma versão resumida da lista myodbc.
mysqlcc

Esta lista é sobre todos os tópicos relativos ao cliente gráfico MySQL Control Center.
mysqlcc-digest

Esta lista é uma versão resumida da lista mysqlcc.
plusplus

Lista sobre todos os tópicos relacionados à programação da API C++ para o MariaDB.
plusplus-digest

Uma versão resumida da lista plusplus.
msql-mysql-modules

Lista sobre o Suporte MariaDB no Perl com o msql-mysql-modules que é chamado DBD-mysql.
msql-mysql-modules-digest

Lista resumida sobre a versão do msql-mysql-modules.

Se você não obtiver uma resposta para suas questões na lista de mensagens do MariaDB, uma opção é pagar pelo suporte da MariaDB Foundation, que irá colocar você em contato direto com desenvolvedores MySQL. Leia 'Suporte Oferecido pela MariaDB Foundation'.

A seguinte tabela mostra algumas listas de mensagens sobre o MariaDB que utilizam linguas diferentes do Inglês. Perceba que elas não são operadas pela MariaDB Foundation, portanto, não podemos garantir a qualidade destas.

<mysql-france-subscribe@yahoogroups.com> Lista de mensagens na

língua francesa.
<list@tinc.net> Lista de mensagens coreana.

Envie subscribe mysql your@email.address para esta lista.
<mysql-de-request@lists.4t2.com> Lista de mensagens alemã.

Envie subscribe mysql-de your@email.address para esta lista. Você pode encontrar informações sobre esta lista de mensagens em http://www.4t2.com/mysql.
<mysql-br-request@listas.linkway.com.br> Lista de mensagens

em português Envie subscribe mysql-br your@email.address para esta lista.
<mysql-alta@elistas.net> Lista de mensagens espanhola.

Envie subscribe mysql your@email.address para esta lista.

Fazendo perguntas ou relatando erros

Antes de enviar um relato de erro ou uma questão, por favor faça o seguinte:

Comece pesquisando o manual MariaDB online em: http://www.mysql.com/doc/ Nós tentaremos manter o manual atualizado, frequentemente atualizando-o com soluções para novos problemas encontrados! O apêndice de histórico de mudanças (http://www.mysql.com/doc/en/News.html) pode ser útil já que é bem possível que uma versão mais nova ja tenha a solução para o seu problema.
Procure no banco de dados de bugs em https://jira.mariadb.org/ para ver se o erro já foi relatado/resolvido.
Pesquise os arquivos das listas de mensagens MySQL: http://lists.mysql.com/
Você pode também usar a página http://www.mysql.com/search.html para pesquisar todas as páginas Web (incluindo o manual) que estão localizados em http://www.mysql.com/.

Se você não puder encontrar uma resposta no manual ou nos arquivos, confira com seu expert em MariaDB local. Se você continua não encontrando uma resposta para sua questão, vá em frente e leia a próxima seção para saber como enviar email para lista de email do MariaDB.

Como relatar erros ou problemas

Nosso banco de dados de bugs é publico e pode ser pesquisado por qualquer um em https://jira.mariadb.org/. Se você logar no sistema, você poderá entrar novos relatórios.

Escrever um bom relatório de erro exige paciência, e fazê-lo de forma apropriada economiza tempo para nós e para você. Um bom relatório de erros contendo um teste de caso para o bug irá torná-lo muito mais fácil para corrigí-lo no próximo release. Esta seção irá ajudá-lo a escrever seu relatório corretamente para que você não perca seu tempo fazendo coisas que não irão ajudar-nos muito ou nada.

Nós encorajamos todo mundo a usar o script mysqlbug para gerar um relato de erros (ou um relato sobre qualquer problema), se possível. mysqlbug pode ser encontrado no diretório scripts na distribuição fonte, ou, para uma distribuição binária, no diretório bin no diretório de instalação do MariaDB. Se você não puder utilizar o mysqlbug (por exemplo, se você o estiver executando no Windows), é ainda de vital importância que você incluia todas as informações necessárias listadas nesta seção (o mais importante é uma descrição do sistema operacional e a versão do MariaDB).

O script mysqlbug lhe ajudará a gerar um relatório determinando muitas das seguintes informações automaticamente, mas se alguma coisa importante estiver faltando, por favor forneça-o junto de sua mensagem! Por favor leita esta seção com cuidado e tenha certeza que todas as informações descritas aquie estão incluídas no seu relatório.

De preferência, você deve testar o problema usando a última versão de produção ou desenvolvimento do Servidro MariaDB antes do envio. Qualquer um deve estar apto a repetir o erro apenas usando 'mysql test < script' no caso de teste incluido ou executando o script sheel ou Perl que é incluído no relatório de erros.

Todos os erros enviados para o banco de dados dem bugs em https://jira.mariadb.org/ serão corrigidos ou documentados na próxma distribuição do MariaDB. Se apenas pequenas mudanças de código forem necessárias enviaremos um patch para corrigir o problema.

O lugar comum para relatar erros e problemas é https://jira.mariadb.org.

Se você encontrar um erro de segurança no MySQL, envie um email para <security@mysql.com>.

Se você tiver um relatório de erro que possa ser repetido, relate-o no banco de dados de bugs em https://jira.mariadb.org. Note que mesmo neste caso é bom executar o script mysqlbug primeiro para ter informações sobre o sistema. Qualquer erro que pudermos repetir tem uma grande chance de ser corrigido na próxima distribuição do MariaDB.

Para relatar outros problemas, você pode usar a lista de email do MariaDB.

Lembre-se que é possível responder a uma mensagem contendo muita informação, mas não a uma contendo muito pouca. Frequentemente pessoas omitem fatos porque acreditam que conhecem a causa do problema e assumem que alguns detalhes não importam. Um bom principio é: Se você está em dúvida sobre declarar alguma coisa, declare-a ! É milhares de vezes mais rápido e menos problemático escrever um pouco de linhas a mais no seu relatório do que ser forçado a perguntar de novo e esperar pela resposta porque você não forneceu informação sufiente da primeira vez.

Os erros mais comuns acontecem porque as pessoas não indicam o número da versão da distribuição do MariaDB que estão usando, ou não indicam em qual plataforma elas tem o MariaDB instalado (Incluindo o número da versão da plataforma). Essa informação é muito relevante, e em 99% dos casos o relato de erro é inútil sem ela! Frequentemente nós recebemos questões como, Por que isto não funciona para mim? então nós vemos que aquele recurso requisitado não estava implementado naquela versão do MariaDB, ou que o erro descrito num relatório foi resolvido em uma versão do MariaDB mais nova. Algumas vezes o erro é dependente da plataforma; nesses casos, é quase impossível corrigir alguma coisa sem conhecimento do sistema operacional e o número da versão da plataforma.

Lembre-se também de fornecer informações sobre seu compilador, se isto for relacionado ao problema. Frequentemente pessoas encontram erros em compiladores e acreditam que o problema é relacionado ao MariaDB. A maioria dos compiladores estão sobre desenvolvimento todo o tempo e tornam-se melhores a cada versão. Para determinar se o seu problema depende ou não do compilador, nós precisamos saber qual compilador foi usado. Note que todo problema de compilação deve ser estimado como relato de erros e, consequentemente publicado.

É de grande ajuda quando uma boa descrição do problema é incluída no relato do erro. Isto é, um bom exemplo de todas as coisas que o levou ao problema e a correta descrição do problema. Os melhores relatórios são aqueles que incluem um exemplo completo mostrando como reproduzir o erro ou o problema Leia Seção E.1.6, 'Fazendo um Caso de Teste Se Ocorre um Corrompimento de Tabela'.

Se um programa produz uma mensagem de erro, é muito importante incluir essas mensagens no seu relatório! Se nós tentarmos procurar por algo dos arquivos usando programas, é melhor que as mensagens de erro relatadas sejam exatamente iguais a que o programa produziu. (Até o caso deve ser observado!) Você nunca deve tentar lembrar qual foi a mensagem de erro; e sim, copiar e colar a mensagem inteira no seu relatório!

Se você tem um problema com o MyODBC, você deve tentar gerar um arquivo para rastremento de erros (trace) do MyODBC. Leia Seção 12.2.7, 'Relatando Problemas com MyODBC'.

Por favor lembre-se que muitas das pessoas que lerão seu relatório podem usar um vídeo de 80 colunas. Quando estiver gerando relatórios ou exemplos usando a ferramenta de linha de comando MariaDB, então deverá usar a opção --vertical (ou a instrução terminadora \G) para saída que irá exceder a largura disponível para este tipo de vídeo (por exemplo, com a instrução EXPLAIN SELECT; veja exemplo abaixo).

Por favor inclua a seguinte informação no seu relatório:

O número da versão da distribuição do MariaDB que está em uso (por exemplo, MariaDB Version 3.22.22). Você poderá saber qual versão vocês está executando, usando o comando mysqladmin version. mysqladmin pode ser encontrado no diretório bin sob sua instalação do MariaDB.
O fabricante e o modelo da máquina na qual você está trabalhando.
O nome do sistema operacional e a versão. Para a maioria dos sistemas operacionais, você pode obter esta informação executando o comando Unix uname -a. Se você trabalho no Windows, você pode normalmente conseguir o nome e o número da versão com um duplo clique sobre o ícone ''Meu Computador'' e em seguida no menu ''Ajuda/Sobre o Windows''.
Algumas vezes a quantidade de memória (real e virtual) é relevante. Se estiver em dúvida, inclua esses valores.
Se você estiver usando uma distribuição fonte do MariaDB, é necessário o nome e número da versão do compilador usado. Se você estiver usando uma distribuição binária, é necessário o nome da distribuição.
Se o problema ocorre durante a compilação, inclua a(s) exata(s) mensagem(s) de erro(s) e também algumas linhas do contexto envolvendo o código no arquivo onde o erro ocorreu.
Se o mysqld finalizou, você deverá relatar também a consulta que travou o mysqld. Normalmente você pode encontrar isto executando mysqld com o log habilitado. See Seção E.1.5, 'Usando Arquivos de Log para Encontrar a Causa dos Erros no mysqld'.
Se alguma tabela do banco de dados estiver relacionado ao problema, inclua a saída de mysqldump --nodata nome_db nome_tbl1 nome_tbl2.... Isto é muito fácil de fazer e é um modo poderoso de obter informações sobre qualquer tabela em um banco de dados que irá ajudar-nos a criar uma situação parecida da que você tem.
Para problemas relacionados à velocidade ou problemas com instruções SELECT, você sempre deve incluir a saída de EXPLAIN SELECT ... e ao menos o número de linhas que a instrução SELECT produz. Você também deve incluir a saída de SHOW CREATE TABLE nome_tabela para cada tabela envolvida. Quanto mais informação você fornecer sobre a sua situação, mais fácil será para alguém ajudar-lo! A seguir um exemplo de um relatório de erros muito bom (ele deve ser postado com o script mysqlbug):

Exemplo de execução usando a ferramenta de linha de comando MariaDB (perceba o uso do instrução terminadora \G para instruções cuja largura de saída deva ultrapassar 80 colunas):
```
mysql> SHOW VARIABLES;
mysql> SHOW COLUMNS FROM ...\G
 <saida para SHOW COLUMNS>
mysql> EXPLAIN SELECT ...\G
 <saida para EXPLAIN>
mysql> FLUSH STATUS;
mysql> SELECT ...;
 <Uma pequena versão da saída do SELECT,
 incluindo a hora em que a consulta foi executada>
mysql> SHOW STATUS;
 <saida do SHOW STATUS>
```
Se um erro ou problema ocorrer quando estiver executando o mysqld, tente fornecer um script de entrada que irá reproduzir a anomalia. Este script deve incluir qualquer arquivo de fonte necessário. Quanto mais próximo o script puder reproduzir sua situação, melhor. Se você puder fazer uma série de testes repetidos, você poderá postá-lo para o <bugs@lists.mysql.com> para um tratamento de alta prioridade!

Se não puder fornecer o script, você ao menos deve incluir a saída de mysqladmin variables extended-status processlist na sua mensagem para fornecer alguma informação da performance do seus sistema.
Se você não puder produzir um caso de teste em algumas linhas, ou se a tabela de testes for muito grande para ser enviada por email para a lista de mensagens (mais de 10 linhas), você deverá dar um dump de suas tabelas usando o mysqldump e criar um arquivo README que descreve seu problema.

Crie um arquivo comprimido de seus arquivos usando tar e gzip ou zip, e use o ftp para transferir o arquivo para ftp://support.mysql.com/pub/mysql/secret/. E envie uma pequena descrição do problema para <bugs@lists.mysql.com>.
Se você achar que o MariaDB produziu um resultado estranho para uma consulta, não inclua somente o resultado, mas também sua opinião de como o resultado deve ser, e uma conta descrevendo o base de sua opinião.
Quando fornecer um exemplo do problema, é melhor usar os nomes de variáveis, nomes de tabelas, etc. utilizados na sua situação atual do que enviar com novos nomes. O problema pode ser relacionado ao nome da variável ou tabela! Esses casos são raros, mas é melhor prevenir do que remediar. Além disso, será mais fácil para você fornecer um exemplo que use sua situação atual, que é o que mais importa para nós. No caso de ter dados que não deseja mostrar para outros, você pode usar o ftp para transferi-lo para ftp://support.mysql.com/pub/mysql/secret/. Se os dados são realmente confidenciais, e você não deseja mostrá-los nem mesmo para nós, então vá em frente e providencie um exemplo usando outros nome, mas, por favor considere isso como uma única chance.
Inclua, se possível, todas as opções fornecidas aos programas relevantes. Por exemplo, indique as opções que você utiliza quando inicializa o daemon mysqld e aquelas que são utilizadas para executar qualquer programa cliente MySQL. As opções para programas como o mysqld e MariaDB, e para o script configure, são frequentemente chaves para respostas e são muito relevantes! Nunca é uma má idéia incluí-las de qualquer forma! Se você usa algum módulo, como Perl ou PHP por favor forneça o número da versão deles também.
Se sua questão é relacionada ao sistema de privilégios, por favor forneça a saída de mysqlaccess, a saída de mysqladmin reload, e todas as mensagens de erro que você obteve quando tentava conectar! Quando você testar seus privilégios, você deve primeiramente executar mysqlaccess. Depois, execute mysqladmin reload version e tente conectar com o programa que gerou o problema. mysqlaccess pode ser encontrado no diretório bin sob seu diretório de instalação do MariaDB.
Se você tiver um patch para um erro, isso é bom, mas não assuma que o patch é tudo que precisamos, ou que iremos usá-lo, se você não fornecer algumas informações necessárias, como os casos de testes mostrando o erro que seu patch corrige. Nós podemos encontrar problemas com seu patch ou nós podemos não entendê-lo ao todo; se for assim, não podemos usá-lo.

Se nós não verificarmos exatamente o que o patch quer dizer, nós não poderemos usá-lo. Casos de testes irão ajudar-nos aqui. Mostre que o patch irá cuidar de todas as situações que possam ocorrer. Se nós encontrarmos um caso (mesmo que raro) onde o patch não funcionaria, ele pode ser inútil.
Palpites sobre qual é o erro, porque ocorre, ou do que ele depende, geralmente estão errados. Mesmo o time MariaDB não pode adivinhar antecipadamente tais coisas sem usar um debugger para determinar a causa real do erro.
Indique na sua mensagem de e-mail que você conferiu o manual de referência e o arquivo de mensagens para que outros saibam que você tentou solucionar o problema.
Se você obter um parse error, por favor confira sua sintaxe com atenção! Se você não conseguiu encontrar nada errado com ela, é extremamente provável que que sua versão corrente do MariaDB não suporte a consulta que você está utilizando. Se você estiver usando a versão recente e o manual em https://mariadb.com/kb/ não cobrir a sintaxe que você estiver usando, o MariaDB não suporta sua consulta. Neste caso, suas unicas opções são implementar você mesmo a sintaxe ou enviar uma mensagem para <mysql-licensing@mysql.com> e perguntar por uma oferta para implementá-lo!

Se o manual cobrir a sintaxe que você estiver usando, mas você tiver uma versão mais antiga do MariaDB, você deverá conferir o histórico de alterações do MariaDB para ver quando a sintaxe foi implementada. Neste caso, você tem a opção de atualizar para uma nova versão do MariaDB. Leia Apêndice D, Histórico de Alterações do MariaDB.
Se você tiver um problema do tipo que seus dados aparecem corrompidos ou você obtem erros quando você acessa alguma tabela em particular, você deverá primeiro checar depois tentar reparar suas tabelas com myisamchk ou CHECK TABLE e REPAIR TABLE. Leia Administração do Bancos de Dados MySQL.
Se você frequentemente obtém tabelas corrompidas, você deve tentar encontrar quando e porque isto acontece! Neste caso, o arquivo mysql-data-directory/'hostname'.err deve conter algumas informações sobre o que aconteceu. See 'O Log de Erros'. Por favor forneça qualquer informação relevante deste arquivo no seu relatório de erro! Normalmente o mysqld NUNCA deverá danificar uma tabela se nada o finalizou no meio de uma atualização! Se você puder encontrar a causa do fim do mysqld, se torna muito mais fácil para nós fornecemos a você uma solução para o problema! Leia Seção A.1, 'Como Determinar o Que Está Causando Problemas'.
Se possível, faça o download e instale a versão mais recente do MariaDB para saber se ela resolve ou não o seu problema. Todas versões do MariaDB são muito bem testadas e devem funcionar sem problemas! Acreditamos em deixar tudo, o mais compátivel possível com as versões anteriores, e você conseguirá mudar de versões MariaDB em minutos! Leia 'Qual versão do MariaDB deve ser usada'.

Se você é um cliente de nosso suporte, por favor envio o seu relatório de erros em <mysql-support@mysql.com> para tratamento de alta prioritário, bem como para a lista de mensagens apropriada para ver se mais alguém teve experiências com (e talvez resolveu) o problema.

Para informações sobre relatar erros no MyODBC, veja Seção 12.2.4, 'Como Relatar Problemas com o MyODBC'.

Para soluções a alguns problemas comuns, veja Leia Apêndice A, Problemas e Erros Comuns.

Quando respostas são enviadas para você individualmente e não para a lista de mensagens, é considerado boa etiqueta resumir as respostas e enviar o resumo para a lista de mensagens para que outras possam ter o benefício das respostas que você recebeu que ajudaram a resolver seu problema!

Guia para responder questões na lista de discussão

Se você considerar que sua respota possa ter um amplo interesse, você pode querer postá-la para a lista de mensagens em vez de responder diretamente para a pessoa que perquntou. Tente deixar sua resposta da forma mais genérica possível para que outras pessoas além da que postou a pergunda possam se beneficiar dela. Quando você postar para a lista, por favor tenha certeza que sua resposta não é uma réplica de uma resposta anterior.

Tente resumir a parte essencial da questão na sua resposta, não se sinta obrigado a citar a mensagem original inteira.

Por favor não poste mensagens a partir de seu browser com o modo HTML ligado! Muitos usuários não leem e-mail com browser!

Suporte a Comunidade MariaDB Atrvés do IRC (Internet Relay Chat)

Em adição as diversas listas de email, você pode pessoas experientes da comunidade no IRC (Internet Relay Chat). Estes são os melhores canais atualmente conhecidos por nós:

freenode (veja http://www.freenode.net/ para servidores)
- #mysql A princípio são questões sobre o MySQL, mas dúvidas sobre outros bancos de dados e SQL são bemvindas.
- #mysqlphp Questões sobre MySQL+PHP, uma combinação popular.
- #mysqlperl Questões sobre MySQL+Perl, outra combinação popular.
EFnet (veja http://www.efnet.org/ para servidores)
- #mysql Questões sobre MySQL.

Se você está procurando por programas clientes de IRC para conectar a uma rede IRC, dê uma olhada no X-Chat (http://www.xchat.org/). X-Chat (licença GPL) está disponível para as plataformas Unix e Windows.

Qual compatibilidade aos padrões o MariaDB oferece ?

Qual Padrão o MariaDB Segue?
Executando o MariaDB no modo ANSI
Extensões do MariaDB para o Padrão SQL-92
Diferenças do MariaDB em Comparação com o SQL-92
Como o MariaDB Lida com Restrições
Erros Conhecidos e Deficiências de Projetos no MySQL

Esta seção descreve como o MariaDB se relaciona aos padrões ANSI/ISO SQL. O Servidor MariaDB tem muitas extensões aos padrões SQL, e aqui você descobrirá quais são elas, e como usá-las. Você irá também encontrar informação sobre falta de funcionalidade do Servidor MySQL, e como trabalhar com algumas diferenças.

Nosso objetivo é não restringir, sem um boa razão, a usabilidade do MariaDB Server para qualquer uso. Mesmo se não tivermos os recursos para fazer o desenvolvimento para todos os usos possíveis, estamos sempre querendo ajudar e oferecer sugestões para pessoas que estão tentando usar o MariaDB Server em novos territórios.

Um dos nossos principais objetivos com o produto é continuar a trabalhar em acordo com o padrão SQL-99, mas sem sacrificar velocidade e confiança. Não estamos receosos em adicionar extensões ao SQL ou suporte para recursos não SQL se ele aumentar extremamente a usabilidade do MariaDB Server para uma grande parte de nossos usuários. (A nova interface HANDLER no MariaDB Server 4.0 é um exeemplo desta estratégia. Leia 'Sintaxe HANDLER'.)

Continuaremos a suportar bancos de dados transacionais e não transacionais para satisfazer tanto o uso pesado na web quanto o uso de missão crítica 24/7.

O MariaDB Server foi projetado inicialmente para trabalhar com bancos de dados de tamanho médio (10-100 milhões de registros ou cerca de 100 MB por tabela) em sistemas computacionais pequenos. Continuaremos a extender o MariaDB Server para funcionar ainda melhor com banco de dados na ordem de terabytes, assim como tornar possível compilar uma versão reduzida do MariaDB mais apropriadas para handhels e uso embutido. O design compacto do servidor MariaDB tornam ambas as direções possíveis sem qualquer conflito na árvore fonte.

Atualmente não estamos buscando suporte em tempo real (mesmo se você já puder fazer muitas coisas com nossos serviços de replicação).

Suporte a banco de dados em cluster está planejado para 2004 pela implementação de um novo mecanismo de armazenamento.

Estamos buscando melhoras no fornecimento de suporte a XML no servidor de banco de dados.

Qual Padrão o MariaDB Segue?

Entry-level SQL-92. ODBC levels 0-3.51.

We are aiming toward supporting the full SQL-99 standard, but without concessions to speed and quality of the code.

Executando o MariaDB no modo ANSI

Se você inicializa o mysqld com a opção --ansi ou --sql-mode=ANSI, o seguinte comportamento é alterado no MySQL:

|| é um oprador de concatenação de strings em vez de um sinônimo para OR.
''' é tratado como um caracter identificados (com o caracter de aspasr '`' do MariaDB Server)e não um caracter de string. Você ainda pode usar '`' para citar identificadores no modo ANSI. Uma implicação disto é que você não pode usar aspas duplas para citar um string literal, porque ela será intepretada como um identificador.
Você pode ter qualquer número de espaços entre um nome de função e o '('. Isto faz com que todos nomes de funções sejam tratadas como palavras reservadas. Como resultado, se você quiser acessar qualquer banco de dados, tabelas ou coluna que é uma palavra reservada, você deve colocá-lo entre aspas. Por exemplo, por haver a função USER(), o nome da tabela user no banco de dados MariaDB e a coluna User nesta tabela se torna reservada, assim você deve colocá-la entre aspas:
```
SELECT 'User' FROM mysql.'user';
```
REAL é um sinônimo para FLOAT no lugar de um sinônimo de DOUBLE.
O nível de isolamento padrão de um transação é SERIALIZABLE. Leia 'Sintaxe SET TRANSACTION'.
Você pode usar um campo/expressão em GROUP BY que não está na lista de campos.

Executando o servidor em modo ANSI é o mesmo que iniciá-lo com estas opções:

--sql-mode=REAL_AS_FLOAT,PIPES_AS_CONCAT,ANSI_QUOTES, IGNORE_SPACE,ONLY_FULL_GROUP_BY --transaction-isolation=serializable

No MySQL, você pode conseguir o mesmo efeito com estas duas instruções:

SET GLOBAL TRANSACTION ISOLATION LEVEL SERIALIZABLE;
SET GLOBAL sql_mode=
 'REAL_AS_FLOAT,PIPES_AS_CONCAT,ANSI_QUOTES,IGNORE_SPACE,ONLY_FULL_GROUP_BY';

No MariaDB a última opção sql_mode também pode ser dada com:

SET GLOBAL sql_mode='ansi';

No caso acima o sql_mode estará configurado com todas as opções que são relevantes para o modo ANSI. Você pode verificar o resultado fazendo:

mysql> SET GLOBAL sql_mode='ansi';
mysql> SELECT @@GLOBAL.sql_mode;
 -> 'REAL_AS_FLOAT,PIPES_AS_CONCAT,ANSI_QUOTES,IGNORE_SPACE,ONLY_FULL_GROUP_BY,ANSI'

Extensões do MariaDB para o Padrão SQL-92

O MariaDB fornece algumas extensões que você provavelmente não irá encontrar em alguns bancos de dados SQL. Fique avisado que se você usá-las, seu código pode não ser mais portável para outros servidores SQL. Em alguns casos, você pode escrever código que inclui extensões MySQL, mas continua portável, usando comentários da forma /*! ...*/. Neste caso, o MariaDB irá analisar e executar o código com o comentário como irá fazer com qualquer outra instrução MySQL, mas outros servidores SQL irão ignorar as extensões. Por exemplo:

SELECT /*! STRAIGHT_JOIN */ nome_campo FROM table1,table2 WHERE ...

Se você adicionar um número de versão depois do '!', a sintaxe só será executada se a versão do MariaDB é igual ou maior que o número de versão usado:

CREATE /*!32302 TEMPORARY */ TABLE t (a INT);

O exemplo acima significa que se você tiver uma versão do MariaDB ou mais nova, então o MariaDB irá usar a palavra-chave TEMPORARY

Extensões MariaDB são listadas abaixo:

Os tipos de campo MEDIUMINT, SET, ENUM e os diferentes tipos BLOB e TEXT.
Os atributos de campos AUTO_INCREMENT, BINARY, NULL, UNSIGNED e ZEROFILL.
Todas comparações de strings por padrão são caso insensitivo, com classificação ordenada determinada pelo conjunto de caracteres corrente (ISO-8859-1 Latin1 por padrão). Se você não gosta disso você deverá declarar suas colunas com o atributo BINARY ou usar o operador BINARY, que fazendo com que as comparações sejam feitas de acordo com a ordem ASCII usada na máquina servidora do MariaDB.
O MariaDB mapeia cada banco de dados em um diretório sob o diretório de dados do MariaDB, e tabelas internamente num banco de dados para arquivos no diretório do banco de dados.

Isto tem algumas implicações:
- Nomes de bancos de dados e tabelas são caso sensitivoo no MariaDB em sistemas operacionais que possuem o sistema de arquivos caso sensitivoo (como na maioria dos sistemas Unix). Leia 'Caso Sensitivo nos Nomes'.
- Nomes de Bancos de dados, tabelas, índices, campos ou apelidos pode começar com um dígito (porém não podem consistir somente de digitos).
- Você pode usar comandos padrão do sistemas para fazer backups, renomear, apagar e copiar tabelas. Por exemplo, para renomear uma tabela, renomeie os arquivos .MYD, .MYI e .frm. para o nome da tabela correspondente.
Em algumas instruções SQL, você pode acessar tabelas de diferentes bancos de dados com a sintaxe nome_bd.nome_tbl. Alguns servidores SQL fornecem a mesma funcionalidade mas chamam isto de User space. O MariaDB não suporta tablespaces como em: create table ralph.my_table...IN minha_tablespace.
LIKE é permitido em campos numéricos.
O uso de INTO OUTFILE e STRAIGHT_JOIN em uma instrução SELECT. Leia 'Sintaxe SELECT'.
A opção SQL_SMALL_RESULT em uma instrução SELECT.
EXPLAIN SELECT para obter uma descrição de como as tabelas são ligadas.
A utilização de nomes de índices, índices em um prefixo de um campo, e uso de INDEX ou KEY em uma instrução CREATE TABLE. Leia 'Sintaxe CREATE TABLE'.
O uso de TEMPORARY ou IF NOT EXISTS com CREATE TABLE.
O uso de COUNT(DISTINCT lista) onde 'lista' é maior que um elemento.
O uso de CHANGE nome_campo, DROP nome_campo, ou DROP INDEX, IGNORE ou RENAME em uma instrução ALTER TABLE. Leia 'Sintaxe ALTER TABLE'.
O uso de RENAME TABLE. Leia 'Sintaxe RENAME TABLE'.
Utilização de múltiplas cláusulas ADD, ALTER, DROP, ou CHANGE em uma instrução ALTER TABLE.
O uso de DROP TABLE com as palavras-chave IF EXISTS.
Você pode remover múltiplas tabelas com uma instrução única DROP TABLE.
As cláusulas ORDER BY e LIMIT das instruções UPDATE e DELETE.
Sintaxe INSERT INTO ... SET col_name = ....
A cláusula DELAYED das instruções INSERT e REPLACE.
A cláusula LOW_PRIORITY das instruções INSERT, REPLACE, DELETE e UPDATE.
O uso de LOAD DATA INFILE. Em alguns casos essa sintaxe é compatível com o Oracle LOAD DATA INFILE. Leia 'Sintaxe LOAD DATA INFILE'.
As intruções ANALYZE TABLE, CHECK TABLE, OPTIMIZE TABLE, e REPAIR TABLE.
A instrução SHOW. Leia 'Sintaxe de SHOW'.
Strings podem ser fechadas pelo ''' ou ''', não apenas pelo '''.
O uso do meta-caractere de escape '\'.
A instrução SET OPTION. Leia 'Sintaxe de SET'.
Você não precisa nomear todos os campos selecionados na parte GROUP BY. Isto fornece melhor performance para algumas consultas específicas, mas muito comuns. Leia 'Funções e Modificadores para Usar com Cláusulas GROUP BY'.
Pode ser especificado ASC e DESC com o GROUP BY.
Para tornar mais fácil para usuários que venham de outros ambientes SQL, o MariaDB suporta apelidos (aliases) para várias funções. Por exemplo, todas funções de string suportam as sintaxes ANSI SQL e ODBC.
O MariaDB entende os operadores || e && como ou(OR) e e(AND) logicos, como na linguagem de programação C. No MySQL, || e OR são sinônimos, assim como && e AND. Devido a esta ótima sintaxe, o MariaDB não suporta o operador ANSI SQL para concatenação de strings ||; em vez disso, use o CONCAT(). Como CONCAT() aceita vários argumentos, é fácil converter o uso do operador || para MySQL.
CREATE DATABASE or DROP DATABASE. Leia 'Sintaxe CREATE DATABASE'.
O operador % é um sinônimo para MOD(). Isto é, N % M é equivalente a MOD(N,M). % é suportado para programadores C e para compatibilidade com o PostgreSQL.
Os operadores =, <>, <= ,<, >=,>, <<, >>, <=>, AND, OR ou LIKE podem ser utilizados em comparações de campos a esquerda do FROM nas instruções SELECT. Por exemplo:
```
mysql> SELECT col1=1 AND col2=2 FROM nome_tabela;
```
A função LAST_INSERT_ID(). Leia Seção 12.1.3.32, 'mysql_insert_id()'.
Os operadores extendidos REGEXP e NOT REGEXP utilizados em expressões regulares.
CONCAT() ou CHAR() com um ou mais de dois argumentos. (No MySQL, estas funções receber qualquer número de argumentos.)
As funções BIT_COUNT(), CASE, ELT(), FROM_DAYS(), FORMAT(), IF(), PASSWORD(), ENCRYPT(), MD5(), ENCODE(), DECODE(), PERIOD_ADD(), PERIOD_DIFF(), TO_DAYS() ou WEEKDAY().
Uso de TRIM() para cortar substrings. o SQL-99 só suporta remoção de caracteres únicos.
As funções do GROUP BY: STD(), BIT_OR(), BIT_AND() e BIT_XOR() e GROUP_CONCAT(). Leia 'Funções e Modificadores para Usar com Cláusulas GROUP BY'.
Uso de REPLACE no lugar de DELETE + INSERT. Leia 'Sintaxe REPLACE'.
As instruções FLUSH, RESET e DO.

A possibilidade de configurar variáveis em uma instrução com :=:

SELECT @a:=SUM(total),@b=COUNT(*),@a/@b AS media FROM tabela_teste;
SELECT @t1:=(@t2:=1)+@t3:=4,@t1,@t2,@t3;

Diferenças do MariaDB em Comparação com o SQL-92

Subqueries
SELECT INTO TABLE
Transações e Operações Atômicas
Stored Procedures e Triggers
Chaves Estrangeiras
Views
'--' como Início de Comentário

Nós tentamos fazer com que o MariaDB siguisse os padrões ANSI SQL (SQL-92/SQL-99) e o ODBC SQL, mas em alguns casos, o MariaDB realiza operações de forma diferente:

Para campos VARCHAR, expaços extras são removidos quando o valor é armazenado. Leia 'Erros Conhecidos e Deficiências de Projetos no MySQL'.
Em alguns casos, campos CHAR são alterados sem perguntas para o tipo de campo VARCHAR. Leia 'Alteração de Especificações de Colunas'.
Privilégios para uma tabela não são negadas automaticamente quando você apaga uma tabela. Você deve usar explicitamente um REVOKE para negar privilégios para uma tabela. Leia 'A Sintaxe de GRANT e REVOKE'.

Para uma lista priorizada indicando quando novas extensões serão adicionadas ao MariaDB você deve consultar lista TODO online do MariaDB em http://www.mysql.com/doc/en/TODO.html. Esta é a última versão da lista TODO neste manual. Leia 'MySQL e o Futuro (o TODO)'.

Subqueries

MySQL Version 4.1 supports subqueries and derived tables (unnamed views). Leia 'Sintaxe de Subquery'.

For MariaDB versions prior to 4.1, most subqueries can be successfully rewritten using joins and and other methods. Leia 'Rewriting Subqueries for Earlier MariaDB Versions'.

`SELECT INTO TABLE`

O MariaDB ainda não suporta a extensão SQL do Sybase: SELECT ... INTO TABLE .... MariaDB suporta a sintaxe ANSI SQL INSERT INTO ... SELECT ..., que é basicamente a mesma coisa. Leia 'Sintaxe INSERT ... SELECT'.

INSERT INTO tblTemp2 (fldID)
 SELECT tblTemp1.fldOrder_ID
 FROM tblTemp1 WHERE tblTemp1.fldOrder_ID > 100;

De maneira alternativa, você pode usar SELECT INTO OUTFILE... ou CREATE TABLE ... SELECT para resolver seu problema.

Transações e Operações Atômicas

O MariaDB Server (versão 3.23-max e todas as versões 4.0 e acima) suportam transações com os mecanismos de armazenamento transacionais InnoDB e BDB. InnoDB fornece compatibilidade total com ACID. Leia Tipos de Tabela do MariaDB.

Os outros tipos de tabelas não transacionais (tais como MyISAM) no MariaDB Server seguem um paradigma diferente para integridade de dados chamado Operções Atômicas. Em termos de transação, tabelas MyISAM efetivamente sempre operam em modo AUTOCOMMIT=1. Operações atômicas geralmente oferecem integridade comparável com a mais alta performance.

Com o MariaDB Server suportando ambos os paradigmas, o usuário pode decidir se precisa da velocidade das operações atômicas ou se precisa usar recursos transacionais em seu aplicativo. Esta escolha pode ser feita em uma base por tabela.

Como notado, a comparação para tabelas transacionais vs. não transacionais As noted, the trade off for transactional vs. non-transactional table se encontra em grande parte no desempenho. Tabelas transacionais tem uma exigência de memória e espaço em disco significantemente maior e maior sobrecarga da CPU. Tipos de tabelas transacionais como InnoDB oferecem muitos recursos únicos. O projeto modular do MariaDB Server permite o uso concorrente de todas estes mecanismos de armazenamento para servir a diferentes exigências e oferecer um ótimo desempenho em todas as situações.

Mas como fazer uso dos recursos do MariaDB Server para manter uma integridade rigorosa mesmo com tabelas MyISAM não transacionais e como este recurso se compara com os tipos de tabelas transacionais?

No paradigma transacional, se as suas aplicações são escritas de uma forma que é dependente na chamada de ROLLBACK em vez de COMMIT em situações críticas, então transações são mais convenientes. Além disso, transações asseguram que atualizações inacabadas ou atividades corrompidas não sejam executadas no banco de dados; o servidor oferece uma oportunidade para fazer um rollback automático e seu banco de dados é mantido.

O MariaDB Server, na maioria dos casos, permite a você resolver potenciais problemas incluindo simples conferências antes das atualizações e executando scripts simples que conferem inconsistências no banco de dados e, automaticamente, repara ou avisa caso isto ocorra. Perceba que apenas usando o log do MariaDB ou mesmo adicionando um log extra, pode-se corrigir tabelas perfeitamente sem nenhuma perda de integridade.
Mais do que nunco, atualizações transacionais fatais podem ser reescritas para serem atômicas. De fato podemos dizer que todos problemas de integridade que transações resolvem podem ser feitas com LOCK TABLES ou atualizações atômicas, assegurando que você nunca irá ter uma finalização automática da tabela, o que é um problema comum em bancos de dados transacionais.
Nem mesmo transações podem prevenir todas as falhas se o servidor cair. Nestes casos mesmo um sistema transacional pode perder dados. A diferença entre sistemas diferentes é apenas em quão pequeno é o lapso de tempo em que eles podem perder dados. Nenhum sistema é 100% seguro, somente seguro o suficiente. Mesmo o Oracle, com reputação de ser o mais seguro bancos de dados transacionais, tem relatos de algumas vezes perder dados nestas situações.

Para estar seguro com o MariaDB Server, você apenas deve fazer backups e ter o log de atualizações ligado. Com isto você pode se recuperar de qualquer situação possível com bancos de dados transacionais. É sempre bom ter backups, independente de qual banco de dados você usa.

O paradigma transacional tem seus benefícios e suas desvantagens. Muitos usuários e desenvolvedores de aplicações dependem da facilidade com a qual eles podem codificar contornando problemas onde abortar parece ser, ou é necessário. No entanto, se você é novo no paradigma de operações atômicas ou tem mais familiaridade ou conforto com transações, considere o benefício da velocidade que as tabelas não transacionais podem oferece, na ordem de 3 a 5 vezes da velocidade que as tabelas transacionais mais rápidas e otimizadas.

Em situações onde integridade é de grande importância, as atuais características do MariaDB permitem níveis transacionais ou melhor confiança e integridade. Se você bloquear tabelas com LOCK TABLES todos as atualizações irão ser adiadas até qualquer verificação de integridade ser feita. Se você só obter um bloqueio de leitura (oposto ao bloqueio de escrita), então leituras e inserções poderão ocorrer. Os novos registros inseridos não poderão ser visualizados por nenhum dos clientes que tiverem um bloqueio de LEITURA até eles liberarem estes bloqueios. Com INSERT DELAYED você pode enfileirar inserções em uma fila local, até os bloqueios serem liberados, sem que o cliente precise esperar atá a inserção completar. Leia 'Sintaxe INSERT DELAYED'.

Atômico, no sentido em que nós mencionamos, não é mágico. Significa apenas que você pode estar certo que enquanto cada atualização específica está sendo executada, nenhum outro usuário pode interferir com ela, e nunca haverá um rollback automático (que pode acontecer em sistemas baseados em transações se você não tiver muito cuidado). O MariaDB também assegura que nunca ocorrerá uma leitura suja.

A seguir estão algumas técnicas para trabalhar com tabelas não transacionais:

Loops que precisam de transações normalmente pode ser codificados com a ajuda de LOCK TABLES, e você não precisa de cursores para atualizar regitros imeditamente.
Para evitar o uso do ROLLBACK, você pode usar as seguintes estratégias:
1. Use LOCK TABLES ... para fazer um lock todas as tabelas que você quer acessar.
2. Condições de teste.
3. Atualize se estiver tudo OK.
4. Use UNLOCK TABLES para liberar seus locks.
Isto é normalmente um método muito mais rápido que usar transações com possíveis ROLLBACKs, mas nem sempre. A única situação que esta solução não pode tratar é quando alguém mata a threads no meio de uma atualização. Neste caso, todas os locks serão liberados mas algumas das atualização podem não ter sido execuadas.
Você também pode usar funções para atualizar registros em uma única operação. Você pode conseguir uma aplicação muito eficiente usando as seguintes técnicas:
- Modifique campos em relação ao seus valores atuais.
- Atualize apenas aqueles campos que realmente tiveram alterações.
Por exemplo, quando fazemos atualizações em alguma informação de cliente, atualizamoa apenas os dados do clientes que alteraram e testamos apenas aqueles com dados alterados ou dados que dependem dos dados alterados, mudaram em comparação com o registro original. O teste dos dados alterados é feito com a cláusula WHERE na instrução UPDATE. Se o registro não foi atualizado, mandamos ao cliente uma mensagem: ''Some of the data you have changed has been changed by another user.'' Então mostramos o registro antigo versus o novo em uma janela, assim o usuário pode decidir qual versão do registro de cliente de ser usado.

Isto nos dá algo similar a lock de colunas mas que, na verdade, é melhor porque apenas atualizamos algumas das colunas, usando valores relativos ao seu valor atual. Isto significa que instruções UPDATE comuns se parecem com estas:
```
UPDATE nometabela SET pay_back=pay_back+125;
UPDATE customer
 SET
 customer_date='current_date',
 address='new address',
 phone='new phone',
 money_he_owes_us=money_he_owes_us-125
 WHERE
 customer_id=id AND address='old address' AND phone='old phone';
```
Como você pode ver, isto é muito eficiente e funciona mesmo se outro cliente alterar os valores nas colunas pay_back ou money_he_owes_us.
Em muitos casos, usuários querem fazer ROLLBACK e/ou LOCK TABLES com o propósito de gerenciarem identificadores únicos para algumas tabelas. Isto pode ser tratado muito mais eficientemente usando uma coluna AUTO_INCREMENT e também uma função SQL LAST_INSERT_ID() ou a função da API C mysql_insert_id(). Leia Seção 12.1.3.32, 'mysql_insert_id()'.

Geralmente você pode codificar evitando lock de registro. Algumas situações realmente precisam disto, e tabelas InnoDB suportam lock de regitstro. Comoo MyISAM, você pode usar uma coluna de flag na tabela e fazer algo como a seguir:
```
UPDATE nome_tbl SET row_flag=1 WHERE id=ID;
```
O MariaDB retorna 1 para o número de linhas afetadas se as linhas foram encontradas e row_flag já não era 1 na linha original.

Você pode pensar nisto como se o MariaDB Server tivesse alterado a consulta anterior para:
```
UPDATE nome_tbl SET row_flag=1 WHERE id=ID AND row_flag <> 1;
```

Stored Procedures e Triggers

Steored procedures estão sendo implementadas em nossa versão 5.0 na árvore de desenvolvimento. Leia 'Instalando pela árvore de fontes do desenvolvimento'.

Este esforço é baseado no SQL-99, que têm uma sintaxe básica similar (mas não idêntica) ao Oracle PL/SQL. Em adição a isto, estamoas implementando o framework SQL-99 enganchar em linguagens externas.

Uma Stored Procedure é um conjunto de comandos SQL que podem ser compilados e armazenados no servidor. Uma fez feito isso, os clientes não necessitam reescrever toda a consulta mas podem fazer referência à stored procedure. Isto fornece melhor performance porque a query necessita ser analisada pelo servidor somente uma vez, e necessita menos informação para ser enviada entre o servidor e o cliente. Você também pode elevar o nível conceitual tendo bibliotecas de funções no servidor. No entanto, stored procedures aumentam a carga no servidor de banco de dados, já que grande parte do trabalho é feito do lado do servidor e menos do lado do cliente (aplicação).

Triggers estão programados para serem implementados no MariaDB versão 5.1. Um trigger é um tipo de stored procedure que é chamado quando um evento em particular ocorre. Por exemplo, você poderia configurar uma stored procedure que é disparada toda vez que um registro for apagado de uma tabela transacional que automaticamente apaga o cliente correspondente de uma tabela de clientes quando todas as transações forem removidas.

Chaves Estrangeiras

No MariaDB Server 3.23.44 e posterior, tabelas InnoDB suportam verificação de restrição de chaves estrangeiras, incluindo CASCADE, ON DELETE, e ON UPDATE. Leia 'Restrições FOREIGN KEY'.

Para outros tipos de tabela, o MariaDB Server atualmente apenas analisa a sintaxe de FOREIGN KEY no comando CREATE TABLE, mas não usa/armazena esta informação. Em um futuro próximo esta implementação será estendida para que assim a informação seja armazenada num arquivo de especificação de tabela e possa ser recuperado por mysqldump e ODBC. Em um estágio posterior, restrições de chaves estrangeiras serão implementadas para tabelas MyISAM.

Note que as chaves estrangeiras no SQL não são usadas para ligar tabelas, mas são usadas para verificar a integridade referencial. Se você deseja obter resultados de múltiplas tabelas de uma instrução SELECT, você pode fazer isto ligando tabelas:

SELECT * FROM table1,table2 WHERE table1.id = table2.id;

See 'Sintaxe JOIN'. Leia 'Utilizando Chaves Estrangeiras'.

Quando usada como uma restrição, FOREIGN KEYs não precisa ser usado se a aplicação insere duas linhas em tabelas MyISAM na ordem apropriada.

Para tabelas MyISAM, você pode contornar a falta de ON DELETE adicionando a instrução DELETE apropriada a uma aplicação quando você deletar registros de uma tabela que tem uma chave estrangeira. Na prática isto é mais rápido e muito mais portável que utilizar chaves estrangeiras.

No MariaDB Server 4.0 você pode utilizar deleções multi-tabela para apagar linha de muitas tabelas com um comando. Leia 'Sintaxe DELETE'.

A sintaxe FOREIGN KEY sem ON DELETE ... é usada geralmente por aplicacões ODBC para produzir cláusulas WHERE automáticas.

Note que chaves estrangeiras são mal usadas com frequência, o que pode causar graves problemas. Mesmo quando usado apropriadamente, o suporte a chaves estrangeiras não é uma solução mágica para o problema de integridade referêncial, embora possa ajudar.

Algumas vantagens das chaves estrangeiras:

Assumindo o projeto apropriado das relações, as restrições de chaves estrangeiras tornarão mais difícil para um programador introduzir uma inconsistência no banco de dados.
Usar atualizações e deleções em cascata pode simplificar o código do cliente.
Regras de chaves estrangeiras projetados apropriadamente ajudam ao documentar a relação entre as tabelas.

Desvantagens:

Erros, que são facéis de se ter ao projetar a relação das chaves, podem causar graves problemas¯por exemplo, regras circulares ou a combinação errada de uma deleção em cascata.
Verificação adicional no banco de dados afeta o desempenho, por esta razão algumas das principais aplicações comerciais codificam sua lógica no nível da aplicação.
Não é incomum para um DBA fazer uma topologia complexa de relações que torna muito difícl, e em alguns casos impossível, fazer backup ou restaurar tabelas individuais.

Views

Views estão senda implementadas atualmente e aparecerão na versão 5.0 e 5.1 do MariaDB Server.

Historicamente o MariaDB Server tem sido mais usado em aplicações e sistemas web onde o desenvolvedor da aplicação tem total controle sobre o uso do banco de dados. É claro que o uso aumentou em várias vezes e então descobrimos que um crescente números de usuários consideram views como um importante aspecto.

Unnamed views (derived tables, uma seubquery na cláusula FROM de uma SELECT) já estão implementadas na versão 4.1.

Views geralmente são muito úteis para permitir aos usuários acessar uma série de relações (tabelas) como uma tabela, e limitar o acesso a apenas estas relações. Views também podem ser usadas para restringir o acesso aos registros (um subconjunto de uma tabela em particular). Mas views não são necessárias para restringir o acesso a registros já que o MariaDB Server tem um sofisticado sistema de privilégios. Leia 'Detalhes Gerais de Segurança e o Sistema de Privilégio de Acesso do MariaDB'.

Muitos SGBD não permitem atualizar nenhum registro em uma view, mas você tem que fazer as atualizações em tabelas separadas.

Em nosso projeto de implemtação de views, nós buscamos (tanto quanto for possível dentro do SQL) compatibilidade com ``Codd's Rule #6'' para sistemas de banco de dados relacionais: todos os views que são teoricamente atualizáveis, devem se atualizados também na prática.

'`--`' como Início de Comentário

Outros bancos de dados SQL usam '--' para iniciar comentários. O MariaDB usa '#' como o caractere para início de comentário, mesmo se a ferramenta de linha de comando MariaDB remover todas linhas que começam com '--'. Você também pode usar o comentário no estilo C /*isto é um comentário*/ com o MariaDB Server. Leia 'Sintaxe de Comentários'.

O MariaDB Server versão 3.23.3 e superior suporta o estilo de comentário '--' somente se o comentário for seguido por um caractere de espaço (ou por um caracter de controle como uma nova linha). Isto ocorre porque este estilo de comentário causou muitos problemas com queries SQL geradas automaticamente que usavam algo como o código seguinte, onde automaticamente erá inserido o valor do pagamento para !pagamento!:

UPDATE nome_tabela SET credito=credito-!pagamento!

O que você acha que irá acontecer quando o valor de pagamento for negativo? Como 1--1 é legal no SQL, nós achamos terrível que '--' signifique início de comentário.

Usando a nossa implementação deste método de comentário no MariaDB Server Version 3.23.3 e posterior, 1-- Isto é um comentário é atualmente seguro.

Outro recurso seguro é que o cliente de linha de comando MariaDB remove todas as linhas que iniciam com '--'.

A seguinte discussão somente interessa se você estiver executando uma versão do MariaDB inferior a versão 3.23:

Se você tem um programa SQL em um arquivo texto que contêm comentários '--' você deverá usar:

shell> replace ' --' ' #' < arquivo-texto-com-comentário.sql \
 | mysql banco-de-dados

No lugar de:

shell> mysql banco-de-dados < arquivo-texto-com-comentario.sql

Você também pode editar o próprio arquivo de comandos alterando os comentários '--' para '#':

shell> replace ' --' ' #' -- arquivo-texto-com-comentario.sql

Desfaça utilizando este comando:

shell> replace ' #' ' --' -- arquivo-texto-com-comentario.sql

Como o MariaDB Lida com Restrições

Restrições de PRIMARY KEY / UNIQUE
Restrições de NOT NULL
Restrições de ENUM e SET

Como o MariaDB lhe permite trabalhar com tabelas transacionais e não transacionais (que não permitem rollback), o tratamento de restrições é um pouco diferente no MariaDB que em outros bancos de dados.

Temos que tratar o caso quando você atualiza diversos registros com uma tabela não transacional que não pode fazer rollback em erros.

A filosofia básica é tentar obter um erro para qualquer coisa que possamos detectar em temp de compilação mas tentar recuperar de qualquer erro que abtemos em tempo de execução. Fazemos isto na maiorioa dos casos, mas não para todos ainda. See 'Novos Recursos Planejados Para a Versão em um Futuro Próximo'.

A opção básica que o MariaDB tem é parar a instrução no meio ou fazer o melhor para se recuperar do problema e continuar.

A seguir mostramos o que acontece com diferentes tipos de restrições.

Restrições de PRIMARY KEY / UNIQUE

Normalmente você receberá um erro quando tentar fazer um INSERT / UPDATE de um registro que cause uma violação de uma chave primária, chave única ou chave estrangeira. Se você estiver usando um mecanismo de armazenamento transacional, como InnoDB, o MariaDB automaticamente fará um rollback da transação. Se você estiver usando mecanismos de armazenemento não transacionais o MariaDB irá para no registro errado e deiar o resto dos registros se processamento.

Para tornar a vida mais fácil o MariaDB adicionou suporte a diretiva IGNORE para a maioria dos comandos que podem causar uma violação de chave (como INSERT IGNORE ...). Neste caso o MariaDB irá ignorar qualquer violação de chave e continuará com o processamento do próximo registro. Você pode obter informação sobre o que o MariaDB fez com a função da API mysql_info() API function e em versões posteriores do MariaDB 4.1 com o comando SHOW WARNINGS. Leia Seção 12.1.3.30, 'mysql_info()'. Leia 'SHOW WARNINGS | ERRORS'.

Note que no momento apenas as tabelas InnoDB suportam chaves estrangeiras. Leia 'Restrições FOREIGN KEY'.

O suporte a chaves estrangeiras nas tabelas MyISAM está programado para ser incluída na arvoré de fonte do MariaDB 5.0.

Restrições de `NOT NULL`

Para poder suportar um fácil tratamento de tabelas não transacionais todos os campos no MariaDB têm valores padrão.

Se você inserir um valor 'errado' em uma coluna como um NULL em uma coluna NOT NULL ou um valor numérico muito grande em um campo numérico, o MariaDB irá atribuir a coluna o 'melhor valor possível' em vez de dar uma mensagem de erro. Para strings este valor é uma string vazia ou a maior string possível que possa estar na coluna.

Isto significa que se você tentar armazenar NULL em uma coluna que não aceita valores NULL, o MariaDB Server armazenará 0 ou '' (strig vazia) nela. Este último comportamento pode, para uma simples inserção de registro, ser alterado com a opção de compilação -DDONT_USE_DEFAULT_FIELDS.) Leia Seção 2.3.3, 'Opções típicas do configure'. Isto faz com que as instruções INSERT gerem um erro a menos que você explicite valores específicos para todas as colunas que exigem um valor diferente de NULL.

A razão para as regras acima é que não podemos verificar estas condições antes da consulta começar a executar. Se encontrarmos um problema depois de atualizar algumas linahs, não podemos fazer um rollback já que o tipo de tabela não suporta isto. A opção de parar não é tão boa como no caso em que a atualização esteja feita pela metade que é provavelmente o pior cenário possível. Neste caso é melhor 'fazer o possível' e então continuar como se nada tivesse acontecido. No MariaDB 5.0 plenejamos melhorar into forncendo avisos para conversões automáticas de campo, mais uma opção para deixar você fazer um rollback das instruções que usam apenas tabelas transacionais no caso de tal instrução fizer uma definição de campo não permitida.

O mostrado acima significa que não se deve usar o MariaDB para verificar o conteúdo dos campos, mas deve se fazê-lo por meio da aplicação.

Restrições de `ENUM` e `SET`

No MariaDB 4.x ENUM não é uma restrição real, mas um modo mauis eficiente de armazenar campos que possam apenas conter um conjunto de valores dados. Isto é devido as mesmas razões pelas quais NOT NULL não é respeitado. Leia 'Restrições de NOT NULL'.

Se você inserir um valor errado em um campo ENUM, ele será configurado com uma string vazia em um contexto string. Leia 'O Tipo ENUM'.

Se você inserir uma opção errada em um campo SET, o valor errado será ignorado. Leia 'O Tipo SET'.

Erros Conhecidos e Deficiências de Projetos no MariaDB

Erros da Versão 3.23 Corrigidos em Versões Posteriores do MariaDB
Open Bugs / Deficiências de Projeto no MySQL

Erros da Versão 3.23 Corrigidos em Versões Posteriores do MariaDB

Os seguintes erros/bugs conhecidos não estão corrigidos no MariaDB 3.23 porque corrigí-los involveria a mudança de muito código, o que poderia introduzir outros erros, talvez piores. Os erros são também classificados como 'não fatal' ou 'tolerável'.

Pode se obter um deadlock ao fazer LOCK TABLE em multiplas tabelas e então na mesma conexão fizer um DROP TABLE em uma delas enquanto outra thread está tentando bloquear a tabela. Pode-se no entanto fazer um KILL em qualquer uma das threads envolvidas para resolver isto. Corrigido na versão 4.0.12
SELECT MAX(campo_chave) FROM t1,t2,t3... onde uma das três tabelas está vazia não retorna NULL, mas sim o valor máximo da coluna. Corrigido na versão 4.0.11.
DELETE FROM heap_table sem um WHERE não funcionam em tabelas HEAP com lock.

Open Bugs / Deficiências de Projeto no MariaDB

Os seguintes problemas são conhecidos e tem prioridade muito alta para serem corrigidos:

FLUSH TABLES WITH READ LOCK não bloqueia CREATE TABLE ou COMMIT, que pode criar um problema com a posição do log binário ao se fazer um backup completo de tabelas e do log binário.
ANALYZE TABLE em uma tabela BDB pode, em alguns, casos inutilizar a tabela até que se reinicie o servidor mysqld. Quando isto acontecer você irá ver o seguinte tipo de erro no arquivo de erros do MariaDB.
```
001207 22:07:56 bdb: log_flush: LSN past current end-of-log
```
O MariaDB aceita parenteses na parte FROM, mas os ignora sem aviso. A razão pela qual não são retornados erros é que muitos clientes que geram consultas automaticamente adicionam parentesis na parte FROM mesmo onde eles não são necessários.
Concatenar muitos RIGHT JOINS ou combinar joins LEFT e RIGHT na mesma consulta podem dar uma resposta incorreta ja que o MariaDB só gera registros NULL para tabelas que precedem um join LEFT ou antes de um join RIGHT. Isto será corrigido na versão 5.0 junto com o suporte a parentesis na parte FROM.
Não execute ALTER TABLE em uma tabela BDB em que você estiver executando transações multi-instruções não completadas. (A transação provavelmente será ignorada).
ANALYZE TABLE, OPTIMIZE TABLE e REPAIR TABLE podem causar problemas em tabelas para as quais você estiver usando INSERT DELAYED.
Fazendo um LOCK TABLE .. e FLUSH TABLES .. não garante que não existem transações não terminadas em progresso na tabela.
Tabelas BDB são um pouco lentas para abrir. Se você tiver várias tabelas BDB em um banco de dados, gastará muito tempo para usar o cliente MariaDB no banco de dados se você não estiver usando a opção -A ou se você estiver usando rehash. Isto é percebido principalmente quando você tiver um cache de tabelas grandes.
A replicação utiliza o log a nivel de consulta: o master grava a consulta no log binário. Isto é um rápido, compacto e eficiente método de registro o que funciona perfeitamente na maioria dos casos. Embora nunca tenhamos ouvido sobre um caso ocorrido, há uma chance teórica que o dado no master e slave sejam diferente se uma consulta é feita de tal modo que a modificação do dado é não determinística, isto é, deixar ao desejo do otimizador de consultas (o que geralmente não é uma boa prática, mesmo fora da replicação!). Por exemplo:
- CREATE ... SELECT ou INSERT ... SELECT que preenchem com zeros ou NULL uma coluna auto_increment.
- DELETE se você estiver apagando registros de uma tabela que tem chaves estrangeiras com a propriedade ON DELETE CASCADE.
- REPLACE ... SELECT, INSERT IGNORE ... SELECT se você tiver valores de chaves duplicados nos dados inseridos.
Se e somente se todos estas consultas NÃO tiverem cláusulas ORDER BY garantindo uma ordem determinística.

Na verdade, por exemplo para INSERT ... SELECT sem ORDER BY, o SELECT pode retornar registros em uma ordem diferente (no qual resultará em um registro tendo diferentes posições, obtendo um número diferente na coluna auto_increment), dependendo da escolhe feita pelo otimizador no master e slave. Uma consulta será otimizada deiferentemente no master e slave apenas se:
- Os arquivos usados pelas duas consultas não são exatamente a mesma; por exemplo OPTIMIZE TABLE foi executado nas tabelas master e não nas nas tabelas slave (para corrigir isto, desde o MariaDB, OPTIMIZE, ANALYZE e REPAIR são escritos no log binário).
- A tabela está armazenada em um mecanismo de armazenamento diferente no master e no slave (pode se executar diferentes mecanismos de armazenamento no metre e no slave: por exemplo, InnoDB ne master e MyISAM no slave, se o slave possuir menos espaço dispponível em disco).
- The MariaDB buffers' sizes (key_buffer_size etc) are different on the master and slave.
- O master e slave executam versões diferentes do MariaDB, e o código do toimizador é diferente entre estas versões.
Este problema também pode afetar a restauração de um banco de dados usando mysqlbinlog|mysql.

O modo mais fácil de evitar este problema em todos os casos é adicionar uma cláusula ORDER BY para tal consulta não determinística assegure que os registros são sempre armazenados/modificados na mesma ordem. Nas versões futuras do MariaDB adicionaremos automaticamente uma cláusula ORDER BY quando necessário.

Os seguintes problemas são conhecidos e serão corrigidos na hora certa:

Ao usar funções RPAD, ou qualquer outra função string que termina adicionando espaços em branco a direita, em uma consulta que preisa usar tabelas temporárias para ser rsolvida, todas as strings resultantes serão cortadas a direita (como em RTRIM). Este é um exemplo de uma consulta:

SELECT RPAD(t1.field1, 50, ' ') AS f2, RPAD(t2.field2, 50, ' ') AS f1 FROM table1 as t1 LEFT JOIN table2 AS t2 ON t1.record=t2.joinID ORDER BY t2.record;

O resultado final deste erro é que o usuário não conseguira espaços em branco do lado direito do campo resultante.

O comportamento anterior existe em todas as versões do MariaDB.

A razão disto é devido ao fato de tabelas HEAP, que são usadas primeiro para tabelas temporárias, não são capazes de tratar colunas VARCHAR.

Este comportamento será corrigido em uma das distribuições da série 4.1.
Devido ao modo como os arquvos de definições de tabelas são armazenados não se pode usar 255 caracteres (CHAR(255)) em nomes de tabelas, nomes de colunas e enum. Isto está programado para ser corrigido na versão 5.1 quando temos novos arquivos de formatos de definição de tabelas.
Quando estiver usando SET CHARACTER SET, não é permitido usar caracteres especias no nome do banco de dados, tabelas ou campos.
Pode-se usar _ ou % com ESCAPE em LIKE ... ESCAPE.
se você tiver uma coluna DECIMAL com um número armazenado em diferentes formatos (+01.00, 1.00, 01.00), GROUP BY pode considerar cada valor como um valor diferente.
DELETE FROM merge_table usado sem WHERE irá apenas apagar o mapeamento para a tabela, não apagando tudo nas tabelas mapeadas.
Você não pode construir em outro diretório quando estiver utilizando MIT-pthreads. Como isto necessitaria de alterações na MIT-pthreads, nós não estamos aptos a corrigí-la.
BLOB valores não podem ser usados com confiança em GROUP BY, ORDER BY ou DISTINCT. Somente os primeiros bytes (padrão 1024) max_sort_length são usados quando estiver comparando BLOBs nestes casos. Isto pode ser alterado com a opção -0 max_sort_lenght para mysqld. Uma forma de contornar este problema para a maioria dos casos é usar a substring: SELECT DISTINCT LEFT(blob,2048) FROM nome_tabela.
Cálculos são feitos com BIGINT ou DOUBLE (normalmente, ambos tem o tamanho de 64 bits). Depende da precisão utilizada na função. A regra geral é que funções binárias são feitas com precisão BIGINT, IF e ELT() com precisão BIGINT ou DOUBLE e o resto com precisão DOUBLE. Devemos evitar o uso de valores sem sinal maiores que 63 bits (9223372036854775807) para qualquer outra coisa além de campos binários!
Todas os campos string, exceto campos do tipo BLOB e TEXTO tem, automaticamente, todos os espaços extras removidos quando recuperados. Para tipos CHAR, isto não tem problema, e pode ser considerado como um recurso de acordo com o ANSI SQL92. O problema é que no MySQL, campos VARCHAR são tratados desta mesma forma.
Você só pode ter até 255 colunas ENUM e SET em uma tabela.
Em MIN(), MAX() e outras funções de agrupamente, o MariaDB atualmente compara as colunas ENUM e SET pelo valor de suas strings ao invés da posição relativa da string no conjunto.
mysqld_safe redireciona todas as mensagens de mysqld para o log mysqld. Um problema com isto é que se você executar o mysqladmin refresh para fechar e reabrir o log, a stdout e a stderr continuam redirecionadas para o log antigo. Se você utiliza --log extensivamente, deverá editar o mysqld_safe para logar em 'hostname'.err em vez de 'hostname'.log; assim você pode facilmente utilizar o espaço do log antigo apagando-o e executando mysqladmin refresh.
Em instruções UPDATE, colunas são atualizadas da esquerda para a direita. Se você referenciar a uma coluna atualizada, você irá obter o valor atualizado em vez do valor original, por exemplo:
```
mysql> UPDATE nome_tabela SET KEY=KEY+1,KEY=KEY+1;
```
Isto atualiza KEY com 2 no lugar de 1.
Você pode se referir a múltiplas tabelas em uma mesma consulta, mas você não pode se referir a qualquer tabelas temporárias dada mais de uma vez. Por exemplo, a seguinte instrução não funciona.
```
mysql> SELECT * FROM temporary_table, temporary_table AS t2;
```
RENAME não funciona com tabelas temporárias (TEMPORARY) ou tabelas usadas em uma tabelas MERGE.
O otimizador pode lidar com o DISTINCT de forma diferente se você estiver usando colunas 'escondidas' em uma join ou não. Em uma join, colunas escondidas são contadas como parte do resultado (mesmo se elas não são mostradas) enquanto que em queries normais colunas escondidas não participam na comparação DISTINCT. Nós provavelmente iremos alterar isto no futuro para nunca comparar as colunas escondidas quando executando DISTINCT.

um exemplo disto é:
```
SELECT DISTINCT mp3id FROM band_downloads
 WHERE userid = 9 ORDER BY id DESC;
```
and
```
SELECT DISTINCT band_downloads.mp3id
 FROM band_downloads,band_mp3
 WHERE band_downloads.userid = 9
 AND band_mp3.id = band_downloads.mp3id
 ORDER BY band_downloads.id DESC;
```
No segundo caso, você pode obter duas linhas idênticas no MariaDB 3.23.x na série do resultado (porque o campo escondido 'id' pode variar).

Perceba que isto somente acontece em consultas onde você não tem colunas ORDER BY no resultado, algo não permitido no SQL-92.
Como o MariaDB permite trabalhar com tipos de tabelas que não suportam transações (e assim não pode fazer rollback em dados) algumas coisas funcionam um pouco diferentes de outros servidores SQL em MariaDB (Isto serve para garantir que o MariaDB nunca necessitará de um rollback para um comando SQL). Porém isto pode ser um pouco estranho em casos que os valores dos campos devem ser verificados na aplicação, mas isto ira fornacer um ótimo ganho de velocidade assim como permite ao MariaDB fazer algumas otimizações que de outro modo seriam muito difíceis para serem feitas.

Se você informar um valor incorreto em uma coluna, o MySQL, em vez de fazer um rollback, aramzenará o melhor valor possível no campo.
- Se tentar armazenar um valor fora da faixa em uma coluna numérico, o MariaDB irá armazenar o menor ou maior valor possível no campo.
- Se tentar armazenar uma string que não comece com um número em uma coluna numérica, o MariaDB irá armazenar 0 na coluna.
- Se você tentar armazenar NULL em uma coluna que não aceita valores nulos, MariaDB irá armazenar 0 ou '' (string vazia) na coluna. (Este comportamento pode, entretanto, ser alterado com a opção de compilação -DDONT_USE_DEFAULT_FIELDS).
- O MariaDB permite o armazenamento de alguns valores errados de data em campos do tipo DATE e DATETIME. (Como 2000-02-31 ou 2000-02-00). A idéia é que não é serviço do servidor SQL validar datas. Se o MariaDB pode armazenar uma data e recuperar extamente a mesma data, então o MariaDB armazenará a data. Se a data estiver totalmente errada, o MariaDB irá armazenar a data 0000-00-00 no campo.
- Se você especificar um valor não suportado para um campo do tipo enum, ele será alterado para o valor de erro 'empty string', com valor numérico 0.
- Se você definir uma coluna SET com um valor não suportado, o valor será ignorado.
Se você executar uma PROCEDURE em uma pesquisa que retorna uma série vazia, em alguns casos a instrução PROCEDURE não irá transformar as colunas.
Criação da tabela do tipo MERGE não verifiva se as tabelas envolvidas são de tipos compatíveis.
O MariaDB ainda não pode lidar com valores NaN, -Inf e Inf em tipos double. Usá-los causará problemas na exportação e importação de dados. Uma solução intermediária é alterar NaN para NULL (se for possível) e -Inf e Inf para o valor double mínimo ou máximo respectivo possível.
Se você usar ALTER TABLE para primeiro adicionar um índice UNIQUE a uma tabela usada em uma tabela MERGE e então usar ALTER TABLE para adicionar um índice normal na tabela MERGE, a ordem das chaves será diferente para as tabelas se existir uma chave antiga não única na tabela. Isto é porque o ALTER TABLE coloca chaves UNIQUE antes de chaves normais para ser possível detectar chaves duplicadas o mais cedo o possível.

Os seguintes erros são conhecidos em versões mais antigas do MariaDB:

Você pode pendurar um processo se você fizer um DROP TABLE em uma tabela entre outras que esteja travada com LOCK TABLES.
No caso seguinte você pode obter um descarrego de memória para o arquivo core:
- Tratamento de inserções com atraso tem deixado inserções pendentes na tabela.
- LOCK table com WRITE
- FLUSH TABLES
Antes da versão 3.23.2 do MariaDB um UPDATE que atualizava uma chave com um WHERE na mesma chave podia falhar porque a chave era usada para procurar por registros e a mesma linha poderia ter encontrado vários itens:
```
UPDATE nome_tabela SET KEY=KEY+1 WHERE KEY > 100;
```
Um modo de contornar este erro é utilizar:
```
mysql> UPDATE nome_tabela SET KEY=KEY+1 WHERE KEY+0 > 100;
```
Isto funcionará porque MariaDB não utilizará indices em expressões com a cláusula WHERE.
Antes da versão 3.23 do MariaDB, todos os tipos numéricos tratados como campos de pontos fixos. Isto significa que você tem que especificar quantas casas decimais um campo de ponto flutuante deve ter. Todos os resultados eram retornados com o número correto de casas decimais.

Para erros específicos na plataforma, vejas as seções sobre compilação e portabilidade. Leia 'Instalando uma distribuição com fontes do MariaDB'. Leia Apêndice E, Portando para Outros Sistemas.

Anterior		Próximo
Preface	Início	Instalação do MariaDB

Informações Gerais - MariaDB - Databases - Software - Computers