How to Fix MySQL Error 1064 (Syntax Error)

1. How to Read Error 1064 Correctly

A typical 1064 looks like this:

mysql> SELECT id, name, rank FROM players ORDER BY rank DESC;
ERROR 1064 (42000): 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 'rank FROM players ORDER BY rank DESC' at line 1

Two details in that message do all the work:

• The quoted fragment after near is where the parser gave up. Everything from that token onward was unconsumed input.
• The real mistake is usually at — or one token before — the start of the quote. MySQL parses left to right and only fails when it hits something it cannot continue with. In the example above, the quoted text starts at rank, and rank is the problem: it is a reserved word in MySQL 8.0.

The 42000 is the SQLSTATE class for syntax errors and access violations — it tells you nothing beyond what 1064 already did. Ignore the "check the manual" sentence; it is boilerplate. Your debugging loop should be: find the quoted fragment, look at the token just before it, and match against the five causes below.

One quirk worth knowing: when the error points near the end of your statement (or shows an empty quote like near ''), the parser ran out of input while still expecting something — an unclosed parenthesis, a missing closing quote, or a truncated statement. The bug is a missing character, not a wrong one.

2. Cause 1: Reserved Words as Column or Table Names

This is the single most common 1064, and it often appears after a MySQL upgrade — the query worked on 5.7 and breaks on 8.0 because 8.0 reserved new words like RANK, GROUPS, LEAD, and SYSTEM.

Broken vs. fixed

-- FAILS on MySQL 8.0 (RANK is reserved)
SELECT id, name, rank FROM players ORDER BY rank DESC;

-- FIXED: backtick-quote the identifier
SELECT id, name, `rank` FROM players ORDER BY `rank` DESC;

-- BETTER FIX: rename the column once, never escape again
ALTER TABLE players CHANGE `rank` player_rank INT;
SELECT id, name, player_rank FROM players ORDER BY player_rank DESC;

The same trap hits table names. order is a classic in e-commerce schemas:

-- FAILS: 'order' is reserved
CREATE TABLE order (id INT PRIMARY KEY, total DECIMAL(10,2));

-- FIXED
CREATE TABLE `order` (id INT PRIMARY KEY, total DECIMAL(10,2));

-- What most teams eventually do: rename it
CREATE TABLE orders (id INT PRIMARY KEY, total DECIMAL(10,2));

Words that bite people most often

My recommendation: backticks are the correct fix, but if you find yourself escaping the same column in twenty queries, rename it. Escaped identifiers leak into ORM configs, export scripts, and hand-written reporting SQL where someone will inevitably forget the backticks.

3. Cause 2: Mismatched, Unescaped, and Smart Quotes

MySQL uses three quote characters with different jobs, and mixing them up produces 1064 in several distinct ways.

Unescaped apostrophe inside a string

-- FAILS: the apostrophe in O'Brien closes the string early
SELECT * FROM users WHERE name = 'O'Brien';

-- FIXED: double the apostrophe
SELECT * FROM users WHERE name = 'O''Brien';

-- FIXED: backslash escape (MySQL-specific)
SELECT * FROM users WHERE name = 'O\'Brien';

-- ACTUALLY FIXED: parameterized query in application code
-- Python:  cursor.execute("SELECT * FROM users WHERE name = %s", (name,))

Quotes around identifiers instead of backticks

-- FAILS: 'users' is a string literal, not a table name
SELECT * FROM 'users';

-- FIXED
SELECT * FROM `users`;   -- or just: SELECT * FROM users;

Smart quotes pasted from chat apps and documents

-- FAILS: these are Unicode curly quotes (U+2018/U+2019), not ASCII apostrophes
SELECT * FROM users WHERE name = ‘Alice’;

-- FIXED: retype the quotes in your editor
SELECT * FROM users WHERE name = 'Alice';

Smart quotes are nasty because they look correct on screen. If a query copied from Slack, Word, or a PDF fails with 1064 near a string literal, delete both quote characters and retype them. Pasting SQL through a plain-text editor or a formatter strips most of these on the way in.

4. Cause 3: Typos, Trailing Commas, and Missing Pieces

The unglamorous majority. Three patterns cover most of them.

Trailing comma before a keyword

-- FAILS: comma before FROM
SELECT id, name, email, FROM users;

-- FIXED
SELECT id, name, email FROM users;

The error will read near 'FROM users' — the parser expected another column expression after the comma and found a keyword instead. Same bug in other shapes:

-- FAILS: trailing comma in column list
INSERT INTO users (id, name,) VALUES (1, 'Alice');

-- FAILS: missing comma between values
INSERT INTO users (id, name) VALUES (1 'Alice');

-- BOTH FIXED
INSERT INTO users (id, name) VALUES (1, 'Alice');

Misspelled keywords

-- FAILS
SELCT * FROM users;
UPDATE users SET active = 1 WHER id = 5;

-- FIXED
SELECT * FROM users;
UPDATE users SET active = 1 WHERE id = 5;

A misspelled first keyword gives near the whole statement. A misspelled keyword mid-query (like WHER) points at the token after it, because MySQL happily reads WHER as... nothing it recognizes, and fails at the next word.

Unclosed parentheses and truncated statements

-- FAILS: missing closing paren
SELECT * FROM users WHERE (id = 5 AND active = 1;

-- FIXED
SELECT * FROM users WHERE (id = 5 AND active = 1);

These produce errors pointing near the end of the statement, which is why the "empty quote" variant (near '') almost always means an unbalanced paren or quote. Count your openers against your closers — or format the query so each nesting level sits on its own line and the imbalance becomes visible.

5. Cause 4: Syntax Your MySQL Version Doesn't Support

Error 1064's message literally says "check the manual that corresponds to your MySQL server version" — because syntax support varies by version. A query can be perfectly valid on MySQL 8.4 and still throw 1064 on 5.7. First, find out what you're actually running:

SELECT VERSION();
-- e.g. 5.7.44-log (no CTEs, no window functions)
-- e.g. 8.0.36      (CTEs and window functions OK)

CTEs and window functions on MySQL 5.7

-- FAILS on 5.7: error near 'WITH active_users AS ...'
WITH active_users AS (
  SELECT * FROM users WHERE active = 1
)
SELECT * FROM active_users;

-- FAILS on 5.7: error near 'OVER (ORDER BY score DESC)'
SELECT name, RANK() OVER (ORDER BY score DESC) AS rnk FROM players;

-- 5.7 WORKAROUND: derived table + user variable for row numbering
SELECT name, @r := @r + 1 AS row_num
FROM players CROSS JOIN (SELECT @r := 0) AS init
ORDER BY score DESC;

Feature-to-version reference

The reverse case exists too: MariaDB and MySQL diverged years ago, and syntax copied from a MariaDB tutorial can throw 1064 on MySQL (and vice versa). If a query "should work" per a blog post, check which engine and version that post was written against.

6. Cause 5: The -- Comment Space Rule

MySQL's double-dash comment has a rule most other databases do not: -- only starts a comment if it is followed by a space (or a control character like a newline). This deviates from the SQL standard on purpose — it prevents 1--5 from being parsed as "1 comment".

-- FAILS: no space after the dashes, MySQL keeps parsing "get"
SELECT * FROM users; --get all users

-- FIXED: add the space
SELECT * FROM users; -- get all users

-- ALSO VALID: MySQL's hash comment
SELECT * FROM users; # get all users

-- ALSO VALID: standard block comment, safe on every engine
SELECT * FROM users; /* get all users */

This bug loves generated SQL and one-liners squeezed into shell commands, where someone strips "unnecessary" whitespace. It also breaks copied code: --TODO: refactor with no space will take down the whole statement. If a query fails with 1064 pointing at text that looks like a comment, check the two dashes.

One more comment gotcha: MySQL treats /*! ... */ as an executable version-gated comment, not a comment at all. If you strip or reformat those blocks with a tool that doesn't understand MySQL, you can delete live SQL or expose syntax the server can't parse.

7. Preventing Error 1064: A Validation Workflow

Fixing 1064s is fast once you can read them. Not getting them is better. This is the loop I use for any SQL that will run somewhere I can't watch it fail:

Step 1: Validate the parse before executing

Paste the statement into the SQL validator. It parses the query and reports syntax problems with a location — the same information 1064 gives you, but before the statement touches a server, and without needing a database connection at all. For migration scripts and stored procedures, this alone catches the trailing commas, unbalanced parens, and misspelled keywords that make up most 1064s.

Step 2: Format it so structure is visible

A 200-character one-liner hides missing commas. Run the query through the MySQL formatter so every clause and list item sits on its own line:

-- Before: where is the bug?
SELECT u.id, u.name, o.total, FROM users u JOIN orders o ON o.user_id = u.id WHERE o.created > '2026-01-01';

-- After formatting: the trailing comma jumps out
SELECT
  u.id,
  u.name,
  o.total,        -- ← trailing comma before FROM
FROM users u
JOIN orders o ON o.user_id = u.id
WHERE o.created > '2026-01-01';

Step 3: Match syntax to your oldest supported version

If production runs 5.7 but your laptop runs 8.4, develop against 5.7 syntax or you will ship CTEs that throw 1064 in production only. Keep the version table from section 5 handy, and run SELECT VERSION(); on every environment — people are regularly surprised by what's actually deployed.

Step 4: Parameterize application queries

Prepared statements with bound parameters eliminate the entire quote-escaping class of 1064 (and SQL injection with it). If your application builds SQL by concatenating strings, that is the real bug; 1064 is just the symptom that occasionally surfaces.

Step 5: Check the plan of anything complex

Once a query parses, run it through EXPLAIN before trusting it in production. It confirms MySQL understood your query the way you meant it — join order, index usage, row estimates — which catches semantic mistakes that 1064 can't.

Quick triage table

Error 1064 has a reputation as a mystery, but it is the most forthcoming error MySQL produces: it quotes the exact spot where parsing died. Read the fragment, check the token before it, work down the five causes — and validate before you execute so most of them never reach the server in the first place.

FAQ