TIMESTAMP agora é retornado como uma string com o formato 'YYYY-MM-DD HH:MM:SS'. (A opção --new pode ser usada a partir da versão 4.0.12 para fazer um servidor 4.0 se comportar como 4.1 a este respeito.) Se você quiser tê-lo com um número (como a Versão 4.0 faz) deve-se adicionar +0 a coluna TIMESTAMP a eles:

mysql> SELECT ts_col + 0 FROM tbl_name;

Tamanhos de display para TIMESTAMP não são mais suportados. Por exemplo, se você declarar um coluna como TIMESTAMP(10), o (10) é ignorado.

Esta mudança era necessária para compatibilidade com os padrões SQL. Em uma versão futura. Em uma versão futura, uma alteração adicional será feita (compatível com versões anteriores com esta mudaça), permitindo que o tamanho do timestamp indique o número desejado de dígitos de frações de um segundo.

Valores binários (0xFFDF) agora são assumidos como strings em vez de números. Isto corrige o problema com conjunto de caracteres onde é conveniente colocar a string como um valor binário. Com esta alteração você deve usar CAST() se você quiser comparar valores binários numericamente como inteiros:

SELECT CAST(0XFEFF AS UNSIGNED INTEGER) < CAST(0XFF AS UNSIGNED INTEGER)

Se você não usa CAST(), uma comparação lexicográfica da string será feita:

mysql> SELECT 0xFEFF < 0xFF;
        -> 1

Usando itens binários em um contexto numérico ou comparando-os usando o operador = deve funcionar como antes. (A opção --new pode ser usado para fazer o servidor 4.0 se comportar como 4.1 a partir da versão 4.0.13.)

Para funções que produzem um valor DATE, DATETIME, ou TIME, o resultado retornado para o cliente agora está corrigido para ter um tipo temporal. Por exemplo, no MySQL 4.1, você tem este resultado:

mysql> SELECT CAST("2001-1-1" as DATETIME);
    -> '2001-01-01 00:00:00'

No MySQL 4.0, o resultado é diferente:

mysql> SELECT CAST("2001-1-1" as DATETIME);
-> '2001-01-01'

Valores DEFAULT não podem mais ser especificado para colunas AUTO_INCREMENT (Na versão 4.0, um valor DEFAULT é ignorado sem aviso, na 4.1 ocorre um erro).

LIMIT não aceita mais argumentos negativos. Use 18446744073709551615 em vez de -1.

SERIALIZE não é mais uma opção válida para sql_mode. Deve-se usar SET TRANSACTION ISOLATION LEVEL SERIALIZABLE. SERIALIZE também não é mais válido para a opção --sql-mode do mysqld. Use --transaction-isolation=SERIALIZABLE

Todas tabelas e colunas strings agora têm um conjunto de caracter. See Capítulo 9, Conjunto de Caracteres Nacionais e Unicode. A informação do conjunto de caracteres é mostrada por SHOW CREATE TABLE e mysqldump. (O MySQL versão 4.0.6 e acima pode ler o novo arquivo dump; versões mais antigas não podem.)

O formato de definição de tabela usado nos arquivos .frm mudaram um pouco na versão 4.1. O MySQL 4.0.11 e adiante leêm o novo formato .frm diretamente, mas versões mais antigas não podem. Se você precisa mover tabelas da versão 4.1. para uma mais nova que a 4.0.11, você de usar mysqldump. See Secção 4.9.7, “mysqldump, Descarregando a Estrutura de Tabelas e Dados”.

Se você estiver executando vários servidores na mesma máquina Windows, você deve usar uma opção --shared_memory_base_name diferentes para cada máquina

A interface para agrupar funções UDF alterou um pouco. Você deve agora declarar uma função xxx_clear() para cada função de agrupamento.

Verifique na seção de alterações se houve alguma mudança que pode afetar a sua aplicação.

Leia os novos itens da versão 4.1 para ver quais itens interessantes que você pode usar na versão 4.1. See Secção D.2, “Alterações na distribuição 4.1.x (Alpha)”.

Se você estiver executando o MySQL Server no Windows, veja também Secção 2.5.8, “Atualizando o MySQL no Windows”.

Após o upgrade, atualize a tabela de permissões para gerar uma nova coluna Password maior que é necessária para tratamento seguro de senhas. O procedimento usa mysql_fix_privilege_tables e está descrito em Secção 2.5.6, “Atualizando a Tabela de Permissões”. Estratégias alternativas para tratamento de senhas depois de uma atualização estão descritos posteriormente nesta seção.

Não atualizar para a versão 4.1. Nenhum comportamento será alterado, mas é claro que você não poderá usar qualquer um dos novos recursos fornecido pelo protocolo cliente/servidor da versão 4.1. (O MySQL 4.1 tem um protocolo cliente/servidor extendido que oferece tais recursos como instruções preparadas e conjuntos de múltiplos resultados.) See Secção 12.1.4, “Instruções Preparadas da API C”.

Atualizar para a versão 4.1 e executar o script mysql_fix_privilege_tables para aumentar a coluna Password na tabela user e assim poder guardar hashes de senhas longos. Mas execute o servidor com a opção --old-passwords para fornecer compatibilidade com versões anteriores que premitem que clientes pre-4.1 continuem a conectar em suas contas de hash curto. Eventualmente, quando todos os seus clientes estiverem atualizados para a versão 4.1, você pode parar de usar a opção do servidor --old-passwords. Você também pode alterar as senhas em sua conta MySQL para usar o novo formato que é mais seguro.

Atualizar para versão 4.1 e executar o script mysql_fix_privilege_tables para aumentar a coluna Password na tabela user. Se você sabe que todos os clientes também foram atualizados para a versão 4.1, não execute o servidor com a opção --old-passwords. Em vez disso, altere a senha em todas as contas existentes para que elas tenham o novo formato. Uma instalação pura da versão 4.1 é o mais seguro.