Como corrigir o erro MySQL 1064?

Erro MySQL 1064 — mensagem exata: You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near '...' at line N

O MySQL não consegue interpretar o SQL que você enviou. O fragmento mostrado entre aspas marca exatamente onde a análise parou — comece seu diagnóstico por aí.

O erro MySQL 1064 é um erro de sintaxe: o MySQL recebeu uma instrução SQL que não conseguiu interpretar. A mensagem de erro sempre inclui o número da linha e o fragmento da consulta que provocou a falha — ambos são suas pistas de diagnóstico mais rápidas. Causas comuns:

1. Sintaxe incorreta — um erro de digitação, uma vírgula faltante ou uma palavra-chave fora do lugar.
2. Erros de ortografia — SLECT em vez de SELECT, WHER em vez de WHERE.
3. Palavras reservadas — usar order, table ou key como nomes de colunas ou tabelas sem backticks.
4. Parênteses não correspondidos — um ( não fechado ou um ) extra em uma subconsulta.
5. Dados faltantes ou incorretos — uma variável na consulta está vazia ou contém um valor inesperado.
6. Sintaxe obsoleta — comandos de versões mais antigas do MySQL (TYPE=MyISAM, CHARSET=latin1) que falham em servidores mais recentes.

Qual é a minha causa?

Use esta tabela para identificar a causa mais provável antes de mergulhar nas soluções:

Resolvendo o erro MySQL 1064

1. Verifique sua sintaxe duas vezes

A mensagem de erro do MySQL informa a posição exata do caractere onde a análise parou. Leia o fragmento entre aspas no erro e, em seguida, examine o SQL imediatamente antes desse ponto. Os problemas estruturais mais comuns:

• Vírgula faltante entre definições de colunas em CREATE TABLE
• Um ponto e vírgula dentro do corpo de uma stored procedure que encerra toda a instrução prematuramente
• Uma palavra-chave usada na cláusula errada (WHERE em vez de HAVING em uma consulta de agregação)

Exemplo antes/depois — vírgula faltante:

-- Broken: no comma after the first column definition
CREATE TABLE users (
    id INT NOT NULL
    username VARCHAR(50)
);

-- Fixed
CREATE TABLE users (
    id INT NOT NULL,
    username VARCHAR(50)
);

2. Preste atenção aos parênteses

Todo parêntese de abertura precisa de um de fechamento correspondente. Subconsultas e cláusulas IN (...) são a fonte mais comum de desequilíbrio de parênteses — especialmente ao editar uma consulta manualmente ou montá-la a partir de partes.

Exemplo antes/depois — subconsulta não fechada:

-- Broken: missing closing ) for the IN subquery
SELECT * FROM orders WHERE user_id IN (
    SELECT id FROM users WHERE active = 1
;

-- Fixed
SELECT * FROM orders WHERE user_id IN (
    SELECT id FROM users WHERE active = 1
);

3. Erros de ortografia: Um culpado comum

O MySQL não tenta corrigir automaticamente uma palavra-chave com erro de digitação — ele para a análise imediatamente e retorna um erro 1064. Um único caractere trocado em SELECT, INSERT, UPDATE, WHERE ou qualquer outra palavra reservada provoca isso.

Exemplo antes/depois — SELECT com erro de digitação:

-- Broken
SLECT id, name FROM users;
-- Error: ... near 'SLECT id, name FROM users'

-- Fixed
SELECT id, name FROM users;

Um robusto SQL Syntax Checker detecta esses erros de digitação antes de você executar a consulta em um banco de dados em produção.

Aqui, ele identifica o erro e especifica a linha que contém o erro.

4. Escape adequadamente as palavras reservadas

O MySQL reserva certas palavras para sua própria sintaxe: ORDER, TABLE, KEY, INDEX, DATABASE, SELECT, FROM, WHERE e muitas outras. Usar qualquer uma delas como nome de tabela ou coluna sem backticks causa um erro 1064. A solução é envolver o identificador em backticks.

Exemplo antes/depois — palavra reservada como nome de tabela:

-- Broken: ORDER is a MySQL reserved word
SELECT name FROM order WHERE id = 1;
-- Error: ... near 'order WHERE id = 1'

-- Fixed: backticks tell MySQL this is an identifier, not a keyword
SELECT name FROM `order` WHERE id = 1;

CREATE TABLE `order` (...

Diferentes versões do MySQL têm listas de palavras reservadas diferentes. Ao migrar um banco de dados de uma versão mais antiga do MySQL, uma palavra que era segura no MySQL 5.7 pode ser reservada no MySQL 8.0. Consulte o MySQL Reference Manual para a sua versão de destino e faça uma busca e substituição no dump antes de importar.

5. Resolvendo dados faltantes

Se uma variável PHP que alimenta uma consulta SQL estiver vazia ou indefinida, o SQL montado fica malformado. Uma consulta como WHERE id = (sem nada depois do =) é uma concatenação de strings PHP válida, mas um SQL inválido.

Exemplo antes/depois — variável vazia:

// $orderId is empty — the POST field was not submitted
$orderId = $_POST['order_id'] ?? '';

// Resulting SQL is broken:
// SELECT * FROM orders WHERE id =
$sql = "SELECT * FROM orders WHERE id = $orderId";

Valide a variável antes de montar a consulta:

// Fixed: validate before use
if (empty($orderId) || !is_numeric($orderId)) {
    return; // do not run a malformed query
}
$sql = "SELECT * FROM orders WHERE id = " . intval($orderId);

Para diagnosticar isso em um ambiente WordPress em produção, abra o phpMyAdmin ou o Adminer, vá até o painel de consultas SQL e execute a consulta com um valor literal conhecido e válido para confirmar que a sintaxe está correta isoladamente. Se passar ali, o problema está em como a variável é preenchida, não na estrutura da consulta em si.

6. Atualizando comandos obsoletos

A sintaxe do MySQL muda entre versões principais. Dumps de banco de dados gerados no MySQL 5.x frequentemente contêm sintaxe que falha imediatamente em servidores MySQL 8.x. As duas causas mais comuns em migrações de sites WordPress:

TYPE=MyISAM (removido; use ENGINE=InnoDB):

-- Broken on MySQL 5.5+ (TYPE= keyword was removed)
CREATE TABLE wp_options (
    option_id BIGINT(20) NOT NULL AUTO_INCREMENT,
    PRIMARY KEY (option_id)
) TYPE=MyISAM;

-- Fixed
CREATE TABLE wp_options (
    option_id BIGINT(20) NOT NULL AUTO_INCREMENT,
    PRIMARY KEY (option_id)
) ENGINE=InnoDB;

DEFAULT CHARSET=latin1 no MySQL 8 estrito:

Dumps mais antigos especificam CHARSET=latin1. No MySQL 8.0 com character_set_server=utf8mb4 e sql_mode=STRICT_TRANS_TABLES, isso pode produzir um erro 1064 na linha CREATE TABLE. Corrija o dump antes de importar:

-- Find in the dump file:
) ENGINE=InnoDB DEFAULT CHARSET=latin1;

-- Replace with:
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_unicode_ci;

Pelos tickets de suporte do WP STAGING, o gatilho mais comum do erro 1064 em migrações WordPress é um dump antigo que contém TYPE=MyISAM — ele falha no primeiro CREATE TABLE e aborta toda a importação. Uma busca e substituição em um editor de texto antes de executar a importação resolve isso imediatamente.

Para confirmar a versão do MySQL que seu servidor está executando:

SELECT VERSION();

Consulte o MySQL Reference Manual para obter a lista completa de sintaxe removida e alterada entre versões.

O que fazer se a solução não funcionar

Se você passou por todas as seis causas e o erro 1064 persiste, use esta lista de verificação para isolar a causa raiz:

1. Confirme que você está conectado ao banco de dados correto. Execute SHOW TABLES; para verificar se a tabela que você está consultando existe e tem exatamente o nome que sua consulta espera — incluindo o prefixo de tabela do WordPress.
2. Verifique a sua versão do MySQL:Se a sintaxe da consulta exigir uma versão do MySQL mais recente do que a instalada, atualize o MySQL ou reescreva a consulta para a versão instalada.
3. Verifique o prefixo de tabela do WordPress. As tabelas do WordPress usam o prefixo definido em wp-config.php (geralmente wp_). Uma consulta que fixa wp_options no código falha se o prefixo real for wpstg_ ou outro.
4. Isole a cláusula que falha. Reduza a consulta à sua forma mais simples — remova joins, subconsultas e cláusulas WHERE uma de cada vez até o erro 1064 desaparecer. A última cláusula que você removeu é a causa.
5. Ative o registro de depuração do WordPress. Se o erro 1064 tiver origem em um plugin ou tema, ativar WP_DEBUG e WP_DEBUG_LOG captura a consulta completa com seu rastreamento de pilha. Veja como ativar o modo de log de depuração do WordPress — a entrada do log nomeará a função exata que gera a consulta malformada.

Conclusão

O erro MySQL 1064 sempre remete a uma causa específica: um erro de digitação, uma palavra reservada usada sem backticks, parênteses não correspondidos, uma variável faltante ou sintaxe obsoleta em um dump de banco de dados. A mensagem de erro do MySQL fornece o número da linha e o fragmento exato onde a análise falhou — esse é o seu ponto de partida. Aplique a solução correspondente acima e use a lista de verificação se a primeira tentativa não resolver.

Artigos Relacionados

• 3 maneiras de solucionar erro de sintaxe no WordPress
• Como solucionar o erro 502 Bad Gateway no WordPress
• Como criar e adicionar um usuário administrador com MySQL no WordPress
• Como corrigir ‘Another Update is Currently in Progress’ no WordPress
• 3 maneiras de alterar o prefixo da tabela do banco de dados WordPress

Autor: Rene Hermenau

Sobre o autor: René Hermenau é o fundador do WP STAGING. Ele trabalha com backups do WordPress, ambientes de staging, migrações, gestão de bases de dados e fluxos de implantação seguros.

Ver o perfil completo do autor Rene Hermenau