XOOPS Brasil

 

Capítulo 1. Informações Gerais

Índice

1.1. Sobre Este Manual
1.1.1. Convenções Usadas Neste Manual
1.2. Visão Geral do Sistema de Gerenciamento de Banco de Dados MySQL
1.2.1. História do MySQL
1.2.2. As Principais Características do MySQL
1.2.3. Estabilidade do MySQL
1.2.4. Qual o Tamanho Que as Tabelas do MySQL Podem Ter?
1.2.5. Compatibilidade Com o Ano 2000 (Y2K)
1.3. Visão Geral da MySQL AB
1.3.1. O Modelo de Negócio e Serviços da MySQL AB
1.3.2. Informações para Contato
1.4. Suporte e Licenciamento do MySQL
1.4.1. Suporte Oferecido pela MySQL AB
1.4.2. Copyrights e Licenças Usadas pelo MySQL
1.4.3. Licenças do MySQL
1.4.4. Logomarcas e Marcas Registradas da MySQL AB
1.5. Mapa de Desenvolvimento do MySQL
1.5.1. MySQL 4.0 in a Nutshell
1.5.2. MySQL 4.1 in a Nutshell
1.5.3. MySQL 5.0, A Próxima Distribuição de Desenvolvimento
1.6. MySQL e o Futuro (o TODO)
1.6.1. Novos Recursos Planejados Para a Versão 4.1
1.6.2. Novos Recursos Planejados Para a Versão 5.0
1.6.3. Novos Recursos Planejados Para a Versão 5.1
1.6.4. Novos Recursos Planejados Para a Versão em um Futuro Próximo
1.6.5. Novos Recursos Planejados Para a Versão em um Futuro a Médio Prazo
1.6.6. Novos Recursos que Não Planejamos Fazer
1.7. Fontes de Informações do MySQL
1.7.1. Listas de Discussão MySQL
1.7.2. Suporte a Comunidade MySQL Atrvés do IRC (Internet Relay Chat)
1.8. Qual compatibilidade aos padrões o MySQL oferece ?
1.8.1. Qual Padrão o MySQL Segue?
1.8.2. Executando o MySQL no modo ANSI
1.8.3. Extensões do MySQL para o Padrão SQL-92
1.8.4. Diferenças do MySQL em Comparação com o SQL-92
1.8.5. Como o MySQL Lida com Restrições
1.8.6. Erros Conhecidos e Deficiências de Projetos no MySQL

O programa MySQL (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. MySQL é uma marca registrada da MySQL AB.

O programa MySQL é de Licença Dupla. Os usuários podem escolher entre usar o programa MySQL 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 MySQL AB. Veja mais informações sobre isto na Seção 1.4, “Suporte e Licenciamento do MySQL”.

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

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

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 MySQL. Veja mais informações sobre isto na Seção 1.7.1.1, “As Listas de Discussão do MySQL”. See Seção 1.7.1.3, “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 .

1.1. Sobre Este Manual

Este é o manual de referência MySQL; ele documenta o MySQL 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 MySQL (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 MySQL 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 MySQL.

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 MySQL AB. See Seção 1.4.2, “Copyrights e Licenças Usadas pelo MySQL”.

1.1.1. 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 mysql;

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}

1.2. Visão Geral do Sistema de Gerenciamento de Banco de Dados MySQL

MySQL, o mais popular sistema de gerenciamento de banco de dados SQL Open Source, é desenvolvido, distribuído e tem suporte da MySQL AB. A MySQL AB é uma empresa comercial, fundada pelos desenvolvedores do MySQL, cujos negócios é fornecer serviços relacionados ao sistema de gerenciamento de banco de dados MySQL. See Seção 1.3, “Visão Geral da MySQL AB”.

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

  • O MySQL é 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 MySQL. 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 MySQL é 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 ``MySQL'' 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 é MySQL um software Open Source.

    Open Source significa que é possível para qualquer um usar e modificar o programa. Qualquer pessoa pode fazer download do MySQL 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 MySQL 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 MySQL em uma aplicação comercial¸ você pode adquirir a versão comercial licenciada conosco. See Seção 1.4.3, “Licenças do MySQL”.

  • Por que usar o Banco de Dados MySQL?

    O servidor de banco de dados MySQL é 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 Veja mais informações sobre isto na Seção 5.1.4, “O Pacote de Benchmark do MySQL”.

    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 MySQL seja altamente adaptável para acessar bancos de dados na Internet.

  • As características técnicas do MySQL

    Para informações técnicas avançadas, veja Capítulo 6, Referência de Linguagem do MySQL. O Programa de Banco de Dados MySQL é 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 MySQL.

A pronúncia oficial do MySQL é ``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.

1.2.1. História do MySQL

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 MySQL.

A derivação do nome MySQL 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 MySQL continua sendo um mistério, mesmo para nós.

O nome do golfinho do MySQL (nosso logo) é Sakila. Sakila foi escolhido pelos fundadores da MySQL AB 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.

1.2.2. As Principais Características do MySQL

A seguinte lista descreve algumas das características mais importantes do Progrma de Banco de Dados MySQL. Veja mais informações sobre isto na Seção 1.5.1, “MySQL 4.0 in a Nutshell”.

  • Portabilidade e

    • Escrito em C e C++.

    • Testado com um amplo faixa de compiladores diferentes.

    • Funciona em diversas plataformas. See Seção 2.2.3, “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. See Capítulo 12, Ferramentas de Clientes e APIs do MySQL.

    • 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 MySQL 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. See Seção 6.2, “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 MySQL 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. See Seção 6.1.7, “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 MySQL). Um índice pode usar o prefixo de campo com um tipo CHAR ou VARCHAR.

  • Conectividade

    • Os clientes podem se conectar ao servidor MySQL 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 MySQL 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 MySQL. 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.

      Veja mais informações sobre isto na Seção 12.2, “Suporte ODBC ao MySQL”.

  • Localização

    • O servidor pode apresentar mensagem de erros aos clientes em várias línguas. See Seção 4.7.2, “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 MySQL é 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 MySQL 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 MySQL inclui também o myisamchk, um utilitário muito rápido para realizar estas operações em tabelas MyISAM. See Capítulo 4, Administração do Bancos de Dados MySQL.

    • Todos os programas MySQL podem ser chamados com as opções --help ou -? para obter ajuda online.

1.2.3. Estabilidade do MySQL

Esta seção discute as questões ``Quão estável é o MySQL?'' e ``Posso depender do MySQL 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 MySQL vem trabalhando sem problemas em nossos projetos desde o meio de 1996. Quando o Programa de Banco de Dados MySQL 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. Veja mais informações sobre isto na Seção 1.8.6, “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 MySQL 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 MySQL 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 MySQL 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 MySQL 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 MySQL AB. A MySQL AB 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.

1.2.4. Qual o Tamanho Que as Tabelas do MySQL Podem Ter?

A Versão 3.22 do MySQL tem suporte para tabelas com limite de tamanho até 4G. Com o novo MyISAM no MySQL 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 MySQL é normalmente limitado pelas restrições do sistema operacional quanto ao tamanho dos arquivos, não mais por limites internos do MySQL.

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

Sistema OperacionalLimite do tamanho do arquivo
Linux-Intel 32 bit2G, muito mais usando LFS
Linux-Alpha8T (?)
Solaris 2.5.12G (É possível 4GB com patch)
Solaris 2.64G (pode ser alterado com parâmetro)
Solaris 2.7 Intel4G
Solaris 2.7 ULTRA-SPARC8T (?)

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 MySQL 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 Veja mais informações sobre isto na Seção 4.6.8, “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. Veja mais informações sobre isto na Seção 6.5.3, “Sintaxe CREATE TABLE. Você pode também alterar isso mais tarde com ALTER TABLE. Veja mais informações sobre isto na Seção 6.5.4, “Sintaxe ALTER TABLE.

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

1.2.5. 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 MySQL estão no arquivo sql/time.cc e codificadas com muito cuidado para ser compatível com o ano 2000.

  • No MySQL 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 Seção 6.2.2.1, “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.

1.3. Visão Geral da MySQL AB

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

Os desenvolvedores do servidor MySQL 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 MySQL e propagar nosso banco de dados a novos usuários.A MySQL AB detém os direitos autorais do código fonte do MySQL, do logo e da marca MySQL e deste manual. See Seção 1.2, “Visão Geral do Sistema de Gerenciamento de Banco de Dados MySQL”.

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

Nós desejamos que o Programa de Banco de Dados MySQL 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 MySQL AB 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 MySQL (http://www.mysql.com/) fornece as últimas informações sobre o MySQL e a MySQL AB.

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 ``MySQL, Inc.'' De fato, MySQL Inc. e MySQL GmbH são exemplos de subsidiárias da MySQL AB. Elas estão localizadas nos EUA e Alemanha, respectivamente.

1.3.1. O Modelo de Negócio e Serviços da MySQL AB

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

A MySQL AB 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 MySQL.

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.

1.3.1.1. Suporte

A MySQL AB é gerenciada pelos fundadores e principais desenvolvedores do banco de dados MySQL. 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. See Seção 1.4.1, “Suporte Oferecido pela MySQL AB”.

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

1.3.1.2. Treinamento e Certificação

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

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 MySQL. 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 MySQL. 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: .

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

1.3.1.3. Consultoria

A MySQL AB 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/.

1.3.1.4. Licenças Comerciais

O banco de dados MySQL é liberado sob a licença GNU General Public License (GPL). Isto significa que o programa MySQL 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 MySQL AB; veja http://www.mysql.com/products/pricing.html. Desde de que a MySQL AB é dona dos direitos do código fonte do MySQL, 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 Seção 1.4.3, “Licenças do MySQL”.

1.3.1.5. Parcerias

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

Se você está interessado em se tornar um Parceiro da MySQL AB, envie-nos um email para .

A palavra MySQL e o logomarca do golfinho da MySQL são marcas registradas da MySQL AB. See Seção 1.4.4, “Logomarcas e Marcas Registradas da MySQL AB”. Estas marcas registradas representam um valor significante que os fundadores do MySQL construiram ao longo dos anos.

O web site do MySQL (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.

1.3.2. Informações para Contato

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

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 .

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

Para informações sobre treinamento MySQL, visite a seção de treinamento em http://www.mysql.com/training/. Se você tiver acesso restrito à Internet, conte a equipe de treinamento da MySQL AB via e-mail em . Veja mais informações sobre isto na Seção 1.3.1.2, “Treinamento e Certificação”.

Para informações sobre o Progrma de Certificaço MySQL, veja http://www.mysql.com/certification/. Veja mais informações sobre isto na Seção 1.3.1.2, “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/. Veja mais informações sobre isto na Seção 1.3.1.3, “Consultoria”.

Licenças comerciais podem ser compradas online em http://mariadb.org/. Lá você também encontrará informações de como enviar um fax da sua ordem de compra para a MySQL AB. 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 (para questões sobre licenciamento) ou para (para pedidos de compra). Veja mais informações sobre isto na Seção 1.4.3, “Licenças do MySQL”.

Se você está interessado em fazer parceira com a MySQL AB, envie um e-mail para . Veja mais informações sobre isto na Seção 1.3.1.5, “Parcerias”.

Para mais detalhes sobre a política da marca MySQL, visite http://www.mysql.com/company/trademark.html ou envie um e-mail para . Veja mais informações sobre isto na Seção 1.4.4, “Logomarcas e Marcas Registradas da MySQL AB”.

Se você está interessado em qualquer um dos trabalhos da MySQL AB lista na seção de trabalhos (http://www.mysql.com/company/jobs/), envie um e-mail para . 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. Veja mais informações sobre isto na Seção 1.7.1, “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 MySQL. Veja mais informações sobre isto na Seção 1.7.1.1, “As Listas de Discussão do MySQL”. Caso você encontre um bug de segurança importante no MySQL Server, envie-nos um e-mail para . Veja mais informações sobre isto na Seção 1.7.1.3, “Como relatar erros ou problemas”.

Se você tiver resultados de benchmarks que podemos publicar, contate-nos via e-mail em .

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 MySQL (http://www.mysql.com/), envie um e-mail para .

A MySQL AB 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 .

Para todos os outros assunto, envie um e-mail para .

1.4. Suporte e Licenciamento do MySQL

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

1.4.1. Suporte Oferecido pela MySQL AB

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

Tentamos ter uma visão ampla e inclusiva de suporte técnico. Qualquer problema envolvendo o MySQL é 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 MySQL, configurar melhor práticas de backup e restauração, utiluizaar APIs, e assim por diante. Nosso suporte cobre apenar o servidor MySQL e nossos próprios utilitários, e não produtos de terceirosque acessam o servidor MySQL, 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 MySQL dsiponíveis, contratados pela MySQL AB.

1.4.2. Copyrights e Licenças Usadas pelo MySQL

MySQL AB possui os direitos sobre o código fonte do MySQL, as logomarcas e marcas registradas do MySQL e este manual. Veja mais informações sobre isto na Seção 1.3, “Visão Geral da MySQL AB”. Diversas licenças são relevantes a distribuição do MySQL:

  1. Todo o código específico do MySQL no servidor, a biblioteca mysqlclient e o cliente, assim como a biblioteca GNU readline é coberta pela GNU General Public License. See 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.

  2. A biblioteca GNU getopt é coberta pela GNU Lesser General Public License. Veja http://www.fsf.org/licenses/.

  3. Algumas partes da fonte (a biblioteca regexp) é coberta por um copyright no estilo Berkeley.

  4. Versões mais antiga do MySQL (3.22 e anteriror) estão sujeitos a uma licença estrita (http://kb.askmonty.org/en/mariadb-license). Veja a documentação da versão específica para mais informação.

  5. O manual de referência do MySQL 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 MySQL AB 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 MySQL funcionam na prática, de uma olhada em Seção 1.4.3, “Licenças do MySQL”. Veja também Seção 1.4.4, “Logomarcas e Marcas Registradas da MySQL AB”.

1.4.3. Licenças do MySQL

O programa MySQL é 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 MySQL é 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 MySQL AB em http://mariadb.org/. Veja http://kb.askmonty.org/en/mariadb-license para mais informações.

Versões mais antigas do MySQL (3.22 e anteriores) estão sujeitos a uma licença mais estrita (http://kb.askmonty.org/en/mariadb-license). Veja a documentação da versão específica para mais informação.

Note que o uso do programa MySQL sob uma licença comercial, GPL ou a antiga licença do MySQL não dá automaticamente o direito de usar as marcas registradas da MySQL AB. Veja mais informações sobre isto na Seção 1.4.4, “Logomarcas e Marcas Registradas da MySQL AB”.

1.4.3.1. Usando o Programa MySQL 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 MySQL 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 MySQL sob GPL embora o código seja o mesmo.

  • Quando você distribui uma aplicação não GPL que funciona com o programa MySQL e a entrega com o programa MySQL. Este tipo de solução é considerada mesmo se feita em uma rede.

  • Quando você distribui cópias do programa MySQL 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 MySQL mesmo se você não precisar formalmente de uma licença comercial. Comprar o suporte diretamente da MySQL AB é outro bom modo de contribuir com o desenvolvimento do programa MySQL, com vantagens imediatas para você. See Seção 1.4.1, “Suporte Oferecido pela MySQL AB”.

Se você requisita uma licecnça, você precisará de uma para cada instalação do programa MySQL. 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://kb.askmonty.org/en/mariadb-license. 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 .

1.4.3.2. Usando o Programa MySQL Sem Custo Sob GPL

Você pode utilizar o programa MySQL 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 MySQL com o seu produto.

  • Quando você distribui o código fonte do MySQL junto com outros programas que não são ligados ou dependentes do sistema do MySQL 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 MySQL, 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 MySQL 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 MySQL. 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 MySQL para que seus clientes verifiquem que ela está correta.

  • Quando você usa o banco de dados MySQL 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 MySQL. No entanto, neste caso nós gostariamos que você adquirisse o suporte ao MySQL pois o MySQL está ajudandoa sua empresa.

Se o seu uso do banco de dados MySQL não exige uma licença comercial, lhe encorajamos a adquirir um suporte da MySQL AB de qualquer forma. Deste modo você contribui com o desenvolvimento do MySQL e também ganha vantegens imediatas. Veja mais informações sobre isto na Seção 1.4.1, “Suporte Oferecido pela MySQL AB”.

Se você utiliza o bancdo de dados MySQL em um contexto comercial e obtem lucro com o seu uso, pedimos que você ajude no desenvolvimento do MySQL adquirindo algum nível de suporte. Sentimos que se banco de dados MySQL ajudou os seus negócios, é razoável pedirmos que você ajude a MySQL AB. (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).

1.4.4. Logomarcas e Marcas Registradas da MySQL AB

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

1.4.4.1. O Logo Original do MySQL

O logo do golfinho do MySQL foi desenhado pela Finnish advertising agency Priority em 2001. O golfinho foi escolhido como um símbolo para o baco de dados MySQL 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 MySQL só podem ser usados pr representates da MySQL AB e aqueles que possuem um acordo escrito permitndo-os de fazê-lo.

1.4.4.2. Logomarcas da MySQL 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 MySQL AB. 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 MySQL AB, é o criado e proprietário do site que mostra a logomarca do MySQL.

  • Não use a logomarca em detrimento à MySQL AB ou ao valor das marcas registradas da MySQL AB. Nos reservamos o direito de revogar o diretiro de uso da marcas registradas da MySQL AB.

  • 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 MySQL sob GPL em uma aplicação, sua aplicação deve ser Open Source deve estar apta a conectar a um servidor MySQL.

Contate-nos via e-mail em para saber sobre os nosso acordos especiais que sirvam as suas necessidades.

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

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

  • Quando exibir qualquer logomarca da MySQL AB em qualquer lugar diferente so seu site.

  • Quando exibir qualquer logomarca da MySQL AB 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 MySQL em proutos, livros e outros itens. Normalmente exigimos um valor para a exibição das logomarcas da MySQL AB em produtos comerciais, já que achamos razoável que parte dos rendimentos seja retornado para financiar o desenvolvimento do banco de dados MySQL.

1.4.4.4. Logomarcas dos Parceiros da MySQL AB

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

1.4.4.5. Usando a Palavra MySQL em Texto Impresso ou Apresentação

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

1.4.4.6. Usando a Palavra MySQL em Nomes de Companhias e Produtos

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

1.5. Mapa de Desenvolvimento do MySQL

Esta seção fornece uma amostra do mapa de desenvolvimento do MySQL, incluindo principais recursos imlementados ou planejados para o MySQL 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.

FeatureMySQL version
Unions4.0
Subqueries4.1
R-trees4.1 (para tabelas MyISAM)
Stored procedures5.0
Views5.0 ou 5.1
Cursors5.0
Foreign keys5.1 (3.23 com InnoDB)
Triggers5.1
Full outer join5.1
Constraints5.1

1.5.1. MySQL 4.0 in a Nutshell

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

O MySQL 4.0 está disponível para download em http://www.mysql.com/ e nossos sites mirrors. O MySQL tem sido testado por um grande número de usuários e está em uso em mutios sites.

Os principais novos recursos do MySQL Server 4.0 são trabalhados em conjunto com os usuários corporativos e da comunidade, melhorando o programa de banco de dados MySQL 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 MySQL 4.0 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. Veja mais informações sobre isto na Seção 2.5.2, “Atualizando da Versão 3.23 para 4.0”.

Novos recursos para o MySQL está sendo adicionado ao MySQL 4.1 que também está disponível (versão alfa). Veja mais informações sobre isto na Seção 1.5.2, “MySQL 4.1 in a Nutshell”.

1.5.1.1. Recursos Disponíveis no MySQL 4.0

  • Aumento da velocidade

    • O MySQL 4.0 tem uma cache de consultas que pode dar uma grande aumento na velocidade de aplicações com consutas repetitivas. See Seção 6.9, “Cache de Consultas do MySQL”.

    • A versão 4.0 aumenta a velocidade do MySQL 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 MySQL 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 MySQL em um ambiente cliente/servidor. See Seção 1.5.1.2, “Servidor Embutido MySQL”.

  • Mecanismo de armazenamento InnoDB como padrão

    • O mecanismo de armazenamento InnoDB é oferecido como um recurso padrão do servidor MySQL. Isto significa suporte a transações ACID, chaves estrangeiras com UPDATE/DELETE em cacata e lock de registro agora são recursos padrões. Veja mais informações sobre isto na Seção 7.5, “Tabelas InnoDB.

  • Novas fncionalidades

    • A melhora das propriedades de busca FULLTEXT do MySQL 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 MySQL Server. Veja mais informações sobre isto na Seção 6.8, “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 MySQL Server incluem TRUNCATE TABLE (como no Oracle)

    • Muitos usuários também ficarão satisfeitos ao perceber que o MySQL Server agora suporta a instrução UNION, um recurso padrão SQL muito esperado.

    • O MySQL agora pode ser executado nativamente na plataforma Novell NetWare 6.0. See Seção 2.6.8, “Notas Novell NetWare”.

  • Internacionalização

    • Nossos usuários alemães, austríacos e suiços notarão que o MySQL 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). Veja mais informações sobre isto na Seção 5.5.6, “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. Veja mais informações sobre isto na Seção D.3, “Alterações na distribuição 4.0.x (Production)”.

1.5.1.2. Servidor Embutido MySQL

libmysqld faz o MySQL Server adequado para uma grande área de aplicações. Usando a biblioteca do servidor MySQL embutido, pode embarcar o MySQL 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 MySQL 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 MySQL. 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 MySQL também usa a mesma interface que a biblioteca do cliente normal, sendo então conveniente e fácil de usar. See Seção 12.1.15, “libmysqld, a Biblioteca do Servidor Embutido MySQL”.

1.5.2. MySQL 4.1 in a Nutshell

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 MySQL Database Server devem ser mais imaginativos que nunca para apontar as deficiências do MySQL Database Management System. Já conhecido por sua estabilidadem velocidade e facilidade de uso, o MySQL Server estará apto a atender as necessidades de vários compradores exigentes.

1.5.2.1. Recursos Disponíveis no MySQL 4.1

Os recursos listados nesta seção estão implementados no MySQL 4.1. Outros poucos recursos estão planejados para o MySQL 4.1. Veja mais informações sobre isto na Seção 1.6.1, “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 MySQL 5.0. See Seção 1.6.2, “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. See Seção 6.4.2, “Sintaxe de Subquery”.

  • Aumento na velocidade

    • Protocols binários mais rápidos com instruções preparadas e parâmetros de ligação. See 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). See Capítulo 10, 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. Veja mais informações sobre isto na Seção 4.6.8.9, “SHOW WARNINGS | ERRORS.

  • Internacionalização

    • Para suportar nossa base de usuário sempre em expansão usando linguagens locais nas aplicações, o programa MySQL 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 Capítulo 9, 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 mysql 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. See 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. Veja mais informações sobre isto na Seção 6.4.3, “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. See Seção 6.3.7, “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. Veja mais informações sobre isto na Seção D.2, “Alterações na distribuição 4.1.x (Alpha)”.

1.5.2.2. Stepwise Rollout

Novos recursos estão sendo adicionados ao MySQL 4.1. A versão Alfa já stá disponível para download. See Seção 1.5.2.3, “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 MySQL 4.1 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 MySQL 4.1 se tornará o nova distribuição de produção).

1.5.2.3. Pronto para Uso em Desenvolvimento Imediato

O MySQL 4.1 está atualmente no estágio alfa e os binários estão disponíveis para download em http://www.mysql.com/downloads/mysql-4.1.html. Todas as distribuições binárias passaram por nossos extensivos teste sem nenhum erro na plataforma em que testamos. See 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 MySQL 4.1, deixamos nosso repositório do BitKeeper publicamente disponível. See Seção 2.3.4, “Instalando pela árvore de fontes do desenvolvimento”.

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

O novo desenvolvimento para o MySQL está focado na distribuição 5.0, comrecursos como Stored Procedures entre outros. Veja mais informações sobre isto na Seção 1.6.2, “Novos Recursos Planejados Para a Versão 5.0”.

Para aqueles que desejam dar uma olhada no desenvolvimento do MySQL, deixamos o nosso repositórioo do BitKeeper para o MySQL versão 5.0 disponível publicamente. Veja mais informações sobre isto na Seção 2.3.4, “Instalando pela árvore de fontes do desenvolvimento”.

1.6. MySQL e o Futuro (o TODO)

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 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.

1.6.1. Novos Recursos Planejados Para a Versão 4.1

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

  • Suporte OpenSSL estável (o MySQL 4.0 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.

1.6.2. Novos Recursos Planejados Para a Versão 5.0

Os seguintes recursos estão planejados para inclusão no MySQL 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 MySQL 4.1. Para uma lista do que já está feito no MySQL 4.1, veja Seção 1.5.2.1, “Recursos Disponíveis no MySQL 4.1”.

Para aqueles que desejam dar uma olhada nas novidades do desenvolvimento do MySQL, deixamos nosso repositório BitKeeper para o MySQL versão 5.0 publicamente disponível. Veja mais informações sobre isto na Seção 2.3.4, “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 mysql 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.

1.6.3. 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.

1.6.4. 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 mysql 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 mysql 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 MySQL para LynxOS.

1.6.5. 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). Veja mais informações sobre isto na Seção 1.8.4.6, “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.

1.6.6. Novos Recursos que Não Planejamos Fazer

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

1.7. Fontes de Informações do MySQL

1.7.1. Listas de Discussão MySQL

Esta seção introduz a lista de deiscussão do MySQL 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.

1.7.1.1. As Listas de Discussão do MySQL

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 MySQL. 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 MySQL.

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 MySQL atualmente:

  • announce

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

  • mysql

    A principal lista para discussões MySQL 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 MySQL ou se você quiser estar ativamente envolvido no processo de busca e correção de erros. Veja mais informações sobre isto na Seção 1.7.1.3, “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 MySQL. Nesta lista pode-se discutir desenvolvimento do MySQL e pos-patches.

  • internals

    Uma versão resumida da lista internals.

  • mysqldoc

    Esta lista é para pessoas que trabalham na documentação do MySQL: pessoas da MySQL AB, 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 MySQL. Este é o fórum usado pela pessoas que mantém a distribuição para troca de idéias de pacotes do MySQL e para assegurar que o MySQL 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 MySQL e Java. É mais usada para discussões sobre o driver JDBC, incluindo MySQL Connector/J.

  • java-digest

    Uma versão resumida da lista java.

  • win32

    Esta é a lista para todos os tópicos relacionados ao MySQL 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 MySQL 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 MySQL.

  • plusplus-digest

    Uma versão resumida da lista plusplus.

  • msql-mysql-modules

    Lista sobre o Suporte MySQL 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 MySQL, uma opção é pagar pelo suporte da MySQL AB, que irá colocar você em contato direto com desenvolvedores MySQL. See Seção 1.4.1, “Suporte Oferecido pela MySQL AB”.

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

1.7.1.2. 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 MySQL 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 http://bugs.mysql.com/ 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 MySQL 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 MySQL.

1.7.1.3. Como relatar erros ou problemas

Nosso banco de dados de bugs é publico e pode ser pesquisado por qualquer um em http://bugs.mysql.com/. 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 MySQL. 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 MySQL).

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 MySQL 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 http://bugs.mysql.com/ serão corrigidos ou documentados na próxma distribuição do MySQL. 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 é http://bugs.mysql.com.

Se você encontrar um erro de segurança no MySQL, envie um email para .

Se você tiver um relatório de erro que possa ser repetido, relate-o no banco de dados de bugs em http://bugs.mysql.com. 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 MySQL.

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

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 MySQL que estão usando, ou não indicam em qual plataforma elas tem o MySQL 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 MySQL, ou que o erro descrito num relatório foi resolvido em uma versão do MySQL 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 MySQL. 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 Veja mais informações sobre isto na 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. See 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 mysql, 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 MySQL que está em uso (por exemplo, MySQL 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 MySQL.

  • 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 MySQL, é 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. Veja mais informações sobre isto na 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 mysql (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 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 .

  • Se você achar que o MySQL 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 mysql, 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 MySQL.

  • 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 MySQL 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 MySQL não suporte a consulta que você está utilizando. Se você estiver usando a versão recente e o manual em http://www.mysql.com/documentation/manual.php não cobrir a sintaxe que você estiver usando, o MySQL não suporta sua consulta. Neste caso, suas unicas opções são implementar você mesmo a sintaxe ou enviar uma mensagem para 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 MySQL, você deverá conferir o histórico de alterações do MySQL para ver quando a sintaxe foi implementada. Neste caso, você tem a opção de atualizar para uma nova versão do MySQL. Veja mais informações sobre isto na Apêndice D, Histórico de Alterações do MySQL.

  • 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. See Capítulo 4, 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. Veja mais informações sobre isto na Seção 4.10.1, “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! See 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 MySQL para saber se ela resolve ou não o seu problema. Todas versões do MySQL 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 MySQL em minutos! Veja mais informações sobre isto na Seção 2.2.4, “Qual versão do MySQL deve ser usada”.

Se você é um cliente de nosso suporte, por favor envio o seu relatório de erros em 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 See 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!

1.7.1.4. 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!

1.7.2. Suporte a Comunidade MySQL 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.

1.8. Qual compatibilidade aos padrões o MySQL oferece ?

Esta seção descreve como o MySQL se relaciona aos padrões ANSI/ISO SQL. O Servidor MySQL 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 MySQL 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 MySQL 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 MySQL Server para uma grande parte de nossos usuários. (A nova interface HANDLER no MySQL Server 4.0 é um exeemplo desta estratégia. Veja mais informações sobre isto na Seção 6.4.9, “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 MySQL 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 MySQL Server para funcionar ainda melhor com banco de dados na ordem de terabytes, assim como tornar possível compilar uma versão reduzida do MySQL mais apropriadas para handhels e uso embutido. O design compacto do servidor MySQL 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.

1.8.1. Qual Padrão o MySQL 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.

1.8.2. Executando o MySQL 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 MySQL 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 mysql 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. See Seção 6.7.6, “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 4.1, 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 MySQL 4.1.1 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"

1.8.3. Extensões do MySQL para o Padrão SQL-92

O MySQL 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 MySQL 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 MySQL é 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 MySQL 3.23.02 ou mais nova, então o MySQL irá usar a palavra-chave TEMPORARY

Extensões MySQL 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 MySQL.

  • O MySQL mapeia cada banco de dados em um diretório sob o diretório de dados do MySQL, 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 MySQL em sistemas operacionais que possuem o sistema de arquivos caso sensitivoo (como na maioria dos sistemas Unix). See Seção 6.1.3, “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 MySQL 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. Veja mais informações sobre isto na Seção 6.4.1, “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. Veja mais informações sobre isto na Seção 6.5.3, “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. See Seção 6.5.4, “Sintaxe ALTER TABLE.

  • O uso de RENAME TABLE. See Seção 6.5.5, “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. Veja mais informações sobre isto na Seção 6.4.8, “Sintaxe LOAD DATA INFILE.

  • As intruções ANALYZE TABLE, CHECK TABLE, OPTIMIZE TABLE, e REPAIR TABLE.

  • A instrução SHOW. See Seção 4.6.8, “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. See Seção 5.5.6, “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. See Seção 6.3.7, “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 MySQL suporta apelidos (aliases) para várias funções. Por exemplo, todas funções de string suportam as sintaxes ANSI SQL e ODBC.

  • O MySQL 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 MySQL 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. Veja mais informações sobre isto na Seção 6.5.1, “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(). See 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(). See Seção 6.3.7, “Funções e Modificadores para Usar com Cláusulas GROUP BY.

  • Uso de REPLACE no lugar de DELETE + INSERT. See Seção 6.4.7, “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;
    

1.8.4. Diferenças do MySQL em Comparação com o SQL-92

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

Para uma lista priorizada indicando quando novas extensões serão adicionadas ao MySQL você deve consultar lista TODO online do MySQL em http://www.mysql.com/doc/en/TODO.html. Esta é a última versão da lista TODO neste manual. Veja mais informações sobre isto na Seção 1.6, “MySQL e o Futuro (o TODO)”.

1.8.4.1. Subqueries

MySQL Version 4.1 supports subqueries and derived tables (unnamed views). Veja mais informações sobre isto na Seção 6.4.2, “Sintaxe de Subquery”.

For MySQL versions prior to 4.1, most subqueries can be successfully rewritten using joins and and other methods. See Seção 6.4.2.11, “Rewriting Subqueries for Earlier MySQL Versions”.

1.8.4.2. SELECT INTO TABLE

O MySQL ainda não suporta a extensão SQL do Sybase: SELECT ... INTO TABLE .... MySQL suporta a sintaxe ANSI SQL INSERT INTO ... SELECT ..., que é basicamente a mesma coisa. See Seção 6.4.3.1, “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.

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

O MySQL 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. See Capítulo 7, Tipos de Tabela do MySQL.

Os outros tipos de tabelas não transacionais (tais como MyISAM) no MySQL 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 MySQL 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 MySQL 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 MySQL 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?

  1. 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 MySQL 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 MySQL ou mesmo adicionando um log extra, pode-se corrigir tabelas perfeitamente sem nenhuma perda de integridade.

  2. 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.

  3. 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 MySQL 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 MySQL 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. See Seção 6.4.3.2, “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 MySQL 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(). See 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 MySQL 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 MySQL Server tivesse alterado a consulta anterior para:

    UPDATE nome_tbl SET row_flag=1 WHERE id=ID AND row_flag <> 1;
    

1.8.4.4. Stored Procedures e Triggers

Steored procedures estão sendo implementadas em nossa versão 5.0 na árvore de desenvolvimento. See Seção 2.3.4, “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 MySQL 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.

1.8.4.5. Chaves Estrangeiras

No MySQL Server 3.23.44 e posterior, tabelas InnoDB suportam verificação de restrição de chaves estrangeiras, incluindo CASCADE, ON DELETE, e ON UPDATE. See Seção 7.5.5.2, “Restrições FOREIGN KEY.

Para outros tipos de tabela, o MySQL 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;

Veja mais informações sobre isto na Seção 6.4.1.1, “Sintaxe JOIN. See Seção 3.6.6, “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 MySQL Server 4.0 você pode utilizar deleções multi-tabela para apagar linha de muitas tabelas com um comando. Veja mais informações sobre isto na Seção 6.4.5, “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.

1.8.4.6. Views

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

Historicamente o MySQL 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 MySQL Server tem um sofisticado sistema de privilégios. See Seção 4.3, “Detalhes Gerais de Segurança e o Sistema de Privilégio de Acesso do MySQL”.

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.

1.8.4.7. '--' como Início de Comentário

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

O MySQL 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 MySQL Server Version 3.23.3 e posterior, 1-- Isto é um comentário é atualmente seguro.

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

A seguinte discussão somente interessa se você estiver executando uma versão do MySQL 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

1.8.5. Como o MySQL Lida com Restrições

Como o MySQL lhe permite trabalhar com tabelas transacionais e não transacionais (que não permitem rollback), o tratamento de restrições é um pouco diferente no MySQL 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. Veja mais informações sobre isto na Seção 1.6.4, “Novos Recursos Planejados Para a Versão em um Futuro Próximo”.

A opção básica que o MySQL 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.

1.8.5.1. 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 MySQL automaticamente fará um rollback da transação. Se você estiver usando mecanismos de armazenemento não transacionais o MySQL irá para no registro errado e deiar o resto dos registros se processamento.

Para tornar a vida mais fácil o MySQL adicionou suporte a diretiva IGNORE para a maioria dos comandos que podem causar uma violação de chave (como INSERT IGNORE ...). Neste caso o MySQL 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 MySQL fez com a função da API mysql_info() API function e em versões posteriores do MySQL 4.1 com o comando SHOW WARNINGS. Veja mais informações sobre isto na Seção 12.1.3.30, “mysql_info(). See Seção 4.6.8.9, “SHOW WARNINGS | ERRORS.

Note que no momento apenas as tabelas InnoDB suportam chaves estrangeiras. See Seção 7.5.5.2, “Restrições FOREIGN KEY.

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

1.8.5.2. Restrições de NOT NULL

Para poder suportar um fácil tratamento de tabelas não transacionais todos os campos no MySQL 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 MySQL 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 MySQL 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.) See 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 MySQL 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 MySQL para verificar o conteúdo dos campos, mas deve se fazê-lo por meio da aplicação.

1.8.5.3. Restrições de ENUM e SET

No MySQL 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. See Seção 1.8.5.2, “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. Veja mais informações sobre isto na Seção 6.2.3.3, “O Tipo ENUM.

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

1.8.6. Erros Conhecidos e Deficiências de Projetos no MySQL

1.8.6.1. Erros da Versão 3.23 Corrigidos em Versões Posteriores do MySQL

Os seguintes erros/bugs conhecidos não estão corrigidos no MySQL 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.

1.8.6.2. Open Bugs / Deficiências de Projeto no MySQL

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 MySQL.

    001207 22:07:56  bdb:  log_flush: LSN past current end-of-log
    
  • O MySQL 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 MySQL 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 mysql 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 MySQL 4.1.1, 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 MySQL buffers' sizes (key_buffer_size etc) are different on the master and slave.

    • O master e slave executam versões diferentes do MySQL, 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 MySQL 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 MySQL.

    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 MySQL 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 MySQL 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 MySQL 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 MySQL (Isto serve para garantir que o MySQL 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 MySQL 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 MySQL 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 MySQL irá armazenar 0 na coluna.

    • Se você tentar armazenar NULL em uma coluna que não aceita valores nulos, MySQL 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 MySQL 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 MySQL pode armazenar uma data e recuperar extamente a mesma data, então o MySQL armazenará a data. Se a data estiver totalmente errada, o MySQL 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 MySQL 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 MySQL:

  • 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 MySQL 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 MySQL não utilizará indices em expressões com a cláusula WHERE.

  • Antes da versão 3.23 do MySQL, 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. See Seção 2.3, “Instalando uma distribuição com fontes do MySQL”. See Apêndice E, Portando para Outros Sistemas.


This is a translation of the MySQL Reference Manual that can be found at dev.mysql.com. The original Reference Manual is in English, and this translation is not necessarily as up to date as the English version.