MySQL 8 Strict Mode: Por que seu sistema antigo começou a dar erro?

Nos últimos dias, um dos assuntos mais comentados entre desenvolvedores foi a obrigatoriedade do uso de strict mode no MySQL 8 e os impactos em sistemas legados. Muitos sistemas antigos simplesmente começaram a quebrar após atualização de versão.

O Problema

Em versões antigas do MySQL (5.6 / 5.7), era comum comportamentos permissivos como:

  • Inserir string em coluna INT e virar 0
  • Inserir data inválida como ‘0000-00-00’
  • Colunas NOT NULL aceitarem valores vazios
  • Campos INT sem DEFAULT assumirem 0 automaticamente

No MySQL 8, com STRICT_TRANS_TABLES habilitado por padrão, isso passou a gerar erro.

Exemplo clássico:

CREATE TABLE pedidos (
    id INT NOT NULL AUTO_INCREMENT,
    quantidade INT NOT NULL,
    PRIMARY KEY (id)
);
 
INSERT INTO pedidos (quantidade) VALUES ('abc');

Antes: gravava 0.
Agora: erro de conversão.

A Solução

1️⃣ Verificar o modo SQL ativo

SELECT @@sql_mode;

Se aparecer algo como:

STRICT_TRANS_TABLES,ERROR_FOR_DIVISION_BY_ZERO,NO_ENGINE_SUBSTITUTION

O modo estrito está ativo.

2️⃣ Ajustar o banco corretamente (recomendado)

Corrigir modelagem e validações na aplicação:

$quantidade = filter_input(INPUT_POST, 'quantidade', FILTER_VALIDATE_INT);
 
if ($quantidade === false) {
    die('Quantidade inválida');
}

Garantir DEFAULT explícito:

ALTER TABLE pedidos 
MODIFY quantidade INT NOT NULL DEFAULT 0;

3️⃣ Remover strict mode (não recomendado em produção)

SET GLOBAL sql_mode='';

Ou ajustar no my.cnf:

[mysqld]
sql_mode=""

⚠️ Isso apenas mascara o problema.

Impacto Real em Sistemas Legados

Ao migrar hospedagem ou atualizar servidor:

  • INSERTs começam a falhar
  • Datas inválidas não são mais aceitas
  • Integers vazios geram erro
  • Triggers antigas param de funcionar

Muitos sistemas antigos dependiam do comportamento permissivo sem saber.

Conclusão

O MySQL 8 ficou mais rigoroso — e isso é positivo.

Se seu sistema quebrou após atualização, não é bug. É ajuste de padrão.

A abordagem correta é:

  • Validar dados na aplicação
  • Definir DEFAULT explícito
  • Evitar datas inválidas
  • Não depender de conversão implícita

Strict mode não é problema. Ele apenas expõe problemas que já existiam.

Deixe um comentário

O seu endereço de e-mail não será publicado. Campos obrigatórios são marcados com *

Rolar para cima