What's happening
Your query didn't run. MySQL threw ERROR 1064 (42000): You have an error in your SQL syntax — its catch-all way of saying "I couldn't parse this." Something in your statement broke the grammar rules MySQL's parser expects.
One thing trips people up: the error points to the position after MySQL got confused, not where the actual mistake is. So "near '...' at line 1" is a clue, not a confession. The real offender is usually one token earlier.
Common scenarios that trigger ERROR 1064
- Using a reserved keyword as a table or column name without backticks
- Missing or misplaced comma, parenthesis, or quote
- Wrong quote style — curly quotes from Word or Google Docs instead of straight quotes
- Running MySQL 8.0 syntax on a 5.7 server (or the reverse)
- Pasting SQL from a document editor that sneaks in invisible Unicode characters
- Forgetting the
SETkeyword in anUPDATE - Extra or missing semicolon inside a stored procedure
Quick fixes by cause
1. Reserved keyword used as identifier
This is the #1 culprit. Names like order, key, value, rank, group, desc, and status are reserved words. MySQL chokes on them the moment they appear unquoted.
-- Fails
SELECT order, status FROM users;
-- Fixed: wrap reserved words in backticks
SELECT `order`, `status` FROM users;
The full list lives at MySQL 8.0 Reserved Words. Worth bookmarking.
2. Mismatched or missing quotes
-- Fails: missing closing quote
SELECT * FROM products WHERE name = 'Widget;
-- Fails: curly quotes copied from a document editor
SELECT * FROM products WHERE name = ‘Widget’;
-- Fixed
SELECT * FROM products WHERE name = 'Widget';
Copied SQL from a PDF or doc? Retype the quotes by hand in your terminal. Curly quotes look identical on screen but are completely different characters.
3. Missing comma between columns
-- Fails
SELECT id name email FROM users;
-- Fixed
SELECT id, name, email FROM users;
4. Wrong UPDATE syntax — missing SET
-- Fails
UPDATE users name = 'Alice' WHERE id = 1;
-- Fixed
UPDATE users SET name = 'Alice' WHERE id = 1;
5. INSERT with wrong parenthesis structure
-- Fails
INSERT INTO users (id, name) VALUES 1, 'Alice';
-- Fixed
INSERT INTO users (id, name) VALUES (1, 'Alice');
6. Using MySQL 8.0 window functions on MySQL 5.7
-- Fails on MySQL 5.7 — no window function support
SELECT id, ROW_NUMBER() OVER (PARTITION BY dept_id ORDER BY salary DESC) AS rn
FROM employees;
-- Check your server version first
SELECT VERSION();
Stuck on 5.7 and need window functions? Either upgrade to MySQL 8.0 or rewrite the logic using subqueries.
7. Stored procedure missing DELIMITER change
The mysql CLI treats ; as end-of-input. Hit one inside a procedure body and the CLI sends a broken partial statement immediately.
-- Fails: CLI fires at the first ;
CREATE PROCEDURE get_users()
BEGIN
SELECT * FROM users;
END;
-- Fixed
DELIMITER //
CREATE PROCEDURE get_users()
BEGIN
SELECT * FROM users;
END //
DELIMITER ;
Debugging approach
When the error message isn't obvious, narrow it down step by step.
Step 1 — Read the "near" hint literally
MySQL shows the token where it gave up. The real mistake is almost always just before that token.
ERROR 1064 (42000): ... near 'WHERE id = 1' at line 1
The parser choked at WHERE. That points back to the clause before it — the SET clause is probably malformed.
Step 2 — Strip the query to its minimum
Delete everything except the bare skeleton. Add clauses back one at a time until it breaks again. The last addition that breaks it is your culprit.
-- Start here
SELECT * FROM users;
-- Add WHERE
SELECT * FROM users WHERE id = 1;
-- Add the rest
SELECT * FROM users WHERE id = 1 ORDER BY name;
Step 3 — Hunt for invisible characters
SQL pasted from browsers or document editors often carries hidden Unicode — zero-width spaces, non-breaking spaces, Windows line endings. None of them are visible but all of them break the parser.
cat -A query.sql | head -5
# Look for ^M (Windows line endings) or other unexpected chars
Alternatively, open the file in vim and run :set list to reveal every hidden character.
Step 4 — Validate syntax without executing
# MySQL CLI: catch syntax errors via EXPLAIN
mysql -u root -p -e "EXPLAIN SELECT * FROM users WHERE id = 1"
# Or verify a whole database with mysqlcheck
mysqlcheck -u root -p --check mydb
Stop it from happening again
Always backtick table and column names when in doubt
CREATE TABLE `order` (
`id` INT PRIMARY KEY,
`status` VARCHAR(50),
`value` DECIMAL(10,2)
);
Use a SQL linter in your editor
Extensions like SQLTools (VS Code) or sql-language-server flag syntax errors before you ever hit run. Catch it at write time, not at runtime.
Use parameterized queries in application code
Building SQL by string concatenation is where both injection bugs and syntax errors come from. Prepared statements eliminate both problems at once:
# Python (mysql-connector)
cursor.execute("SELECT * FROM users WHERE id = %s", (user_id,))
// Node.js (mysql2)
connection.execute('SELECT * FROM users WHERE id = ?', [userId])
Verify the fix worked
Run the query again. A result set or Query OK, N rows affected means the syntax error is gone.
-- For SELECT
SELECT id, name FROM users WHERE id = 1;
-- Expected: 1 row returned
-- For INSERT/UPDATE/DELETE
UPDATE users SET name = 'Alice' WHERE id = 1;
-- Expected: Query OK, 1 row affected
Fixed a stored procedure? Call it right after creation to confirm it runs end-to-end:
CALL get_users();