Índice
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
. See Secçã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:
Para informações sobre a empresa por trás do
Servidor do Banco de Dados MySQL
, veja
Secção 1.3, “Visão Geral da MySQL AB”.
Para discussões das capacidades do Servidor do Banco
de Dados MySQL
, veja Secção 1.2.2, “As Principais Características do MySQL”.
Para instruções de instalação, veja Capítulo 2, Instalação do MySQL.
Para dicas sobre a portabilidade do Servidor do Banco
de Dados MySQL
para novas arquiteturas ou sistemas
operacionais, veja Apêndice E, Portando para Outros Sistemas.
Para informações sobre a atualização da versão 4.0, veja Secção 2.5.1, “Atualizando da Versão 4.0 para 4.1”.
Para informações sobre a atualização da versão 3.23, veja Secção 2.5.2, “Atualizando da Versão 3.23 para 4.0”.
Para informações sobre a atualização da versão 3.22, veja Secção 2.5.3, “Atualizando da versão 3.22 para 3.23”.
Para um tutorial de introdução ao Servidor do Banco
de Dados MySQL
, veja Capítulo 3, Tutorial de Introdução Do MySQL.
Para exemplos de SQL
e informações sobre
benchmarks, veja o diretório de benchmarks
(sql-bench
na distribuição).
Para o histórico de novos recursos e correções de erros, veja Apêndice D, Histórico de Alterações do MySQL.
Para uma lista de erros atualmente conhecidos e mal-funcionamento, veja Secção 1.8.6, “Erros Conhecidos e Deficiências de Projetos no MySQL”.
Para projetos futuros, veja Secção 1.6, “MySQL e o Futuro (o TODO)”.
Para ver a lista de todos os colaboradores deste projeto, veja Apêndice C, Colaboradores do MySQL.
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. See Secção 1.7.1.1, “As Listas de Discussão do MySQL”. See Secçã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
<security@mysql.com>
.
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 <docs@mysql.com>
.
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 Secção 1.4.2, “Copyrights e Licenças Usadas pelo MySQL”.
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}
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
Secçã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
Secçã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
See Secçã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.
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.
A seguinte lista descreve algumas das características mais
importantes do Progrma de Banco de Dados
MySQL
. See Secçã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 Secçã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
Secçã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
Secçã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.
Localização
O servidor pode apresentar mensagem de erros aos clientes em várias línguas. See Secçã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.
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. See Secçã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.
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 Operacional | Limite do tamanho do arquivo |
Linux-Intel 32 bit | 2G, muito mais usando LFS |
Linux-Alpha | 8T (?) |
Solaris 2.5.1 | 2G (É possível 4GB com patch) |
Solaris 2.6 | 4G (pode ser alterado com parâmetro) |
Solaris 2.7 Intel | 4G |
Solaris 2.7 ULTRA-SPARC | 8T (?) |
No Linux 2.2 você pode ter tabelas maiores que 2 GB usando o patch LFS para o sistema de arquivos ext2. No Linux 2.4 já existem patches para o sistema de arquivos ReiserFS para ter suporte a arquivos maiores. A maioria das distribuições atuais são baseadas no kernel 2.4 e já incluem todos os patches Suporte a Arquivos Grandes (Large File Support - LFS) exigidos. No entanto, o tamanho máximo disponível ainda depende de diversos fatores, sendo um deles o sistema de arquivos usado para armazenar as tabelas MySQL.
Para um visão mais detalhada sobre LFS no Linux, dê uma olha na página Andreas Jaeger's "Large File Support in Linux" em http://www.suse.de/~aj/linux_lfs.html.
Por padrão, o 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
See Secçã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. See Secção 6.5.3, “Sintaxe CREATE TABLE
”. Você pode também
alterar isso mais tarde com ALTER TABLE
. See
Secção 6.5.4, “Sintaxe ALTER TABLE
”.
Outros modos se contornar o limite do tamanho do arquivo das
tabelas MyISAM
são os seguintes:
Se sua tabela grande será somente leitura, você poderá
usar o myisampack
para unir e comprimir
várias tabelas em uma. mysisampack
normalmente comprime uma tabela em pelo menos 50%, portanto
você pode obter, com isso, tabelas muito maiores. See
Secção 4.8.4, “myisampack
, O Gerador de Tabelas Compactadas de Somente Leitura do MySQL”.
Outra opção para contornar o limite de tamanho de arquivos
do sistema operacional para arquivos de dados
MyISAM
usando a opção
RAID
. See Secção 6.5.3, “Sintaxe CREATE TABLE
”.
O MySQL
incluí uma biblioteca
MERGE
que permite acessar uma coleção
de tabelas idênticas como se fosse apenas uma. See
Secção 7.2, “Tabelas MERGE
”.
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
Secçã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.
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
Secçã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.
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.
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
Secçã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
<sales@mysql.com>
.
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: <training@mysql.com>
.
Para detalhes sobre o Programa de Certificação
MySQL
, veja
http://www.mysql.com/certification/.
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/.
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
Secção 1.4.3, “Licenças do MySQL”.
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
<partner@mysql.com>
.
A palavra MySQL
e o logomarca do golfinho
da MySQL
são marcas registradas da
MySQL AB
. See
Secçã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.
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 <press@mysql.com>
.
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
Secçã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 <sales@mysql.com>
.
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
<training@mysql.com>
. See
Secçã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/.
See Secçã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/. See Secção 1.3.1.3, “Consultoria”.
Licenças comerciais podem ser compradas online em
https://order.mysql.com/.
Lá você também encontrará informações de como enviar um
fax da sua ordem de compra para a 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 <licensing@mysql.com>
(para
questões sobre licenciamento) ou para
<sales@mysql.com>
(para pedidos de compra). See
Secção 1.4.3, “Licenças do MySQL”.
Se você está interessado em fazer parceira com a
MySQL AB
, envie um e-mail para
<partner@mysql.com>
. See
Secçã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 <trademark@mysql.com>
. See
Secçã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 <jobs@mysql.com>
. Não nos
envie o seu CV em anexo, mas como texto no final de sua mensagem
de email.
Para discussões gerais entre nosso muitos usuários, direcione a sua atenção para a lista de discussão apropriada. See Secçã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. See Secçã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
<security@mysql.com>
. See
Secçã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 <benchmarks@mysql.com>
.
Se você tiver sugestões a respeito de adições ou conexões
para este manual, envie-os para a equipe do manual via e-mail em
<docs@mysql.com>
.
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 <webmaster@mysql.com>
.
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 <privacy@mysql.com>
.
Para todos os outros assunto, envie um e-mail para
<info@mysql.com>
.
Esta seção descreve os contratos de licenciamento e suporte do
MySQL
.
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 API
s, 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
.
MySQL AB
possui os direitos sobre o código
fonte do MySQL
, as logomarcas e marcas
registradas do MySQL
e este manual. See
Secção 1.3, “Visão Geral da MySQL AB”. Diversas licenças são
relevantes a distribuição do MySQL
:
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.
A biblioteca GNU
getopt
é coberta pela GNU
Lesser General Public License
. Veja
http://www.fsf.org/licenses/.
Algumas partes da fonte (a biblioteca
regexp
) é coberta por um copyright no
estilo Berkeley.
Versões mais antiga do MySQL
(3.22 e
anteriror) estão sujeitos a uma licença estrita
(http://www.mysql.com/products/mypl.html).
Veja a documentação da versão específica para mais
informação.
O manual de referência do 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 <docs@mysql.com>
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
Secção 1.4.3, “Licenças do MySQL”. Veja também
Secção 1.4.4, “Logomarcas e Marcas Registradas da MySQL AB”.
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
https://order.mysql.com/.
Veja
http://www.mysql.com/products/licensing.html
para mais informações.
Versões mais antigas do MySQL
(3.22 e
anteriores) estão sujeitos a uma licença mais estrita
(http://www.mysql.com/products/mypl.html).
Veja a documentação da versão específica para mais
informação.
Note que o uso do programa 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
.
See Secção 1.4.4, “Logomarcas e Marcas Registradas da MySQL AB”.
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
só 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
Secçã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://www.mysql.com/products/licensing.html.
Para contrato de suporte, veja
http://www.mysql.com/support/.
Se você tiver necessidades especiais ou tiver acesso restrito
a Internet, contate a nossa quipe de vendas via email em
<sales@mysql.com>
.
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.
See Secçã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).
MySQL
em Texto Impresso ou ApresentaçãoMySQL
em Nomes de Companhias e Produtos
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.
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.
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 <trademark@mysql.com>
para saber sobre os nosso acordos especiais que sirvam as suas
necessidades.
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
.
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, Secção 1.3.1.5, “Parcerias”.
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.
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.
Feature | MySQL version |
Unions | 4.0 |
Subqueries | 4.1 |
R-trees | 4.1 (para tabelas MyISAM) |
Stored procedures | 5.0 |
Views | 5.0 ou 5.1 |
Cursors | 5.0 |
Foreign keys | 5.1 (3.23 com InnoDB) |
Triggers | 5.1 |
Full outer join | 5.1 |
Constraints | 5.1 |
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. See Secçã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). See Secção 1.5.2, “MySQL 4.1 in a Nutshell”.
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 Secçã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
INSERT
s 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 Secçã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.
See Secçã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. See Secçã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 Secçã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). See Secçã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. See Secção D.3, “Alterações na distribuição 4.0.x (Production)”.
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
Secção 12.1.15, “libmysqld, a Biblioteca do Servidor Embutido MySQL”.
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.
Os recursos listados nesta seção estão implementados no MySQL 4.1. Outros poucos recursos estão planejados para o MySQL 4.1. See Secçã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 Secçã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
Secçã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 Secçã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. See Secçã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 Secçã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. See Secçã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
Secçã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. See Secção D.2, “Alterações na distribuição 4.1.x (Alpha)”.
Novos recursos estão sendo adicionados ao MySQL 4.1. A versão Alfa já stá disponível para download. See Secçã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).
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 Secçã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 Secção 2.3.4, “Instalando pela árvore de fontes do desenvolvimento”.
O novo desenvolvimento para o MySQL está focado na distribuição 5.0, comrecursos como Stored Procedures entre outros. See Secçã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. See Secção 2.3.4, “Instalando pela árvore de fontes do desenvolvimento”.
Esta seção lista os recursos que planejamos impementar no
MySQL Server
. As listas são apresentadas por
versão, e os itens estão aproximadamente na ordem em que serão
feitos.
Nota: Se você é um usuário
corporativo com uma necessidade urgente de um recurso particular,
por favor, contate <sales@mysql.com>
para
conversarmos sobre patrocínio. Financiamento feito por uma ou
mais companhias nos permite alocar recursos adicionais para aquele
propósito específico. Um exemplo de um recurso patrocinado no
passado é a replicação.
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 Secçã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.
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 Secçã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. See Secçã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.
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.
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.
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). See Secçã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.
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.
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. See Secçã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
Secçã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.
<mysql-france-subscribe@yahoogroups.com>
Lista de mensagens na
língua francesa.
<list@tinc.net>
Lista de mensagens
coreana.
Envie subscribe mysql
your@email.address
para esta lista.
<mysql-de-request@lists.4t2.com>
Lista de mensagens alemã.
Envie subscribe mysql-de
your@email.address
para esta lista. Você pode
encontrar informações sobre esta lista de mensagens em
http://www.4t2.com/mysql.
<mysql-br-request@listas.linkway.com.br>
Lista de mensagens
em português Envie subscribe mysql-br
your@email.address
para esta lista.
<mysql-alta@elistas.net>
Lista de
mensagens espanhola.
Envie subscribe mysql
your@email.address
para esta lista.
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.
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 <security@mysql.com>
.
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 See Secçã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 Secçã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. See Secçã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
<bugs@lists.mysql.com>
para um tratamento de
alta prioridade!
Se não puder fornecer o script, você ao menos deve
incluir a saída de mysqladmin variables
extended-status processlist
na sua mensagem para
fornecer alguma informação da performance do seus
sistema.
Se você não puder produzir um caso de teste em algumas
linhas, ou se a tabela de testes for muito grande para ser
enviada por email para a lista de mensagens (mais de 10
linhas), você deverá dar um dump de suas tabelas usando
o mysqldump
e criar um arquivo
README
que descreve seu problema.
Crie um arquivo comprimido de seus arquivos usando
tar
e gzip
ou
zip
, e use o ftp
para transferir o arquivo para
ftp://support.mysql.com/pub/mysql/secret/.
E envie uma pequena descrição do problema para
<bugs@lists.mysql.com>
.
Se você achar que o 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 <mysql-licensing@mysql.com>
e perguntar por uma oferta para implementá-lo!
Se o manual cobrir a sintaxe que você estiver usando, mas você tiver uma versão mais antiga do 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. See 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.
See Secçã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
Secçã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! See Secçã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 <mysql-support@mysql.com>
para tratamento de alta prioritário, bem como para a lista de
mensagens apropriada para ver se mais alguém teve
experiências com (e talvez resolveu) o problema.
Para informações sobre relatar erros no MyODBC, veja Secçã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!
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!
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.
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. See Secçã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.
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.
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
Secçã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"
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 Secçã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
. See Secçã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
. See Secçã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
Secção 6.5.4, “Sintaxe ALTER TABLE
”.
O uso de RENAME TABLE
. See
Secçã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
. See Secçã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
Secçã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
Secçã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
Secçã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
. See Secçã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
Secçã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
Secção 6.3.7, “Funções e Modificadores para Usar com Cláusulas GROUP BY
”.
Uso de REPLACE
no lugar de
DELETE
+ INSERT
. See
Secçã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;
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 campos VARCHAR
, expaços extras são
removidos quando o valor é armazenado. See
Secção 1.8.6, “Erros Conhecidos e Deficiências de Projetos no MySQL”.
Em alguns casos, campos CHAR
são
alterados sem perguntas para o tipo de campo
VARCHAR
. See
Secção 6.5.3.1, “Alteração de Especificações de Colunas”.
Privilégios para uma tabela não são negadas
automaticamente quando você apaga uma tabela. Você deve
usar explicitamente um REVOKE
para negar
privilégios para uma tabela. See Secção 4.4.1, “A Sintaxe de GRANT
e REVOKE
”.
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. See Secção 1.6, “MySQL e o Futuro (o TODO)”.
MySQL Version 4.1 supports subqueries and derived tables (unnamed views). See Secçã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 Secção 6.4.2.11, “Rewriting Subqueries for Earlier MySQL Versions”.
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
Secçã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.
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?
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.
Mais do que nunco, atualizações transacionais fatais
podem ser reescritas para serem atômicas. De fato podemos
dizer que todos problemas de integridade que transações
resolvem podem ser feitas com LOCK
TABLES
ou atualizações atômicas, assegurando
que você nunca irá ter uma finalização automática da
tabela, o que é um problema comum em bancos de dados
transacionais.
Nem mesmo transações podem prevenir todas as falhas se o servidor cair. Nestes casos mesmo um sistema transacional pode perder dados. A diferença entre sistemas diferentes é apenas em quão pequeno é o lapso de tempo em que eles podem perder dados. Nenhum sistema é 100% seguro, somente ``seguro o suficiente.'' Mesmo o Oracle, com reputação de ser o mais seguro bancos de dados transacionais, tem relatos de algumas vezes perder dados nestas situações.
Para estar seguro com o 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
Secçã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:
Use LOCK TABLES ...
para fazer um
lock todas as tabelas que você quer acessar.
Condições de teste.
Atualize se estiver tudo OK.
Use UNLOCK TABLES
para liberar seus
locks.
Isto é normalmente um método muito mais rápido que usar
transações com possíveis ROLLBACK
s,
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
Secçã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;
Steored procedures estão sendo implementadas em nossa versão 5.0 na árvore de desenvolvimento. See Secçã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.
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
Secçã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;
See Secção 6.4.1.1, “Sintaxe JOIN
”. See
Secção 3.6.6, “Utilizando Chaves Estrangeiras”.
Quando usada como uma restrição, FOREIGN
KEY
s 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. See Secçã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.
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 Secçã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.
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
Secçã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
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. See Secçã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.
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
. See Secção 12.1.3.30, “mysql_info()
”. See
Secção 4.6.8.9, “SHOW WARNINGS | ERRORS
”.
Note que no momento apenas as tabelas
InnoDB
suportam chaves estrangeiras. See
Secçã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.
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
Secçã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.
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
Secçã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. See Secçã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
Secção 6.2.3.4, “O Tipo SET
”.
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.
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 BLOB
s 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 Secçã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.