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

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 utilizadores. 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 utilizadores 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 utilizadores começam a usar o código das ``áreas cinzentas.'' Naturalmente, novos utilizadores 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.

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:

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:

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

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.