SQL ported from PostgreSQL or SQL Server that uses dialect-specific syntax MySQL does not support — for example `ILIKE`, `::cast`, `TOP N`, `QUALIFY`, or `FETCH FIRST N ROWS ONLY` will all trigger 1064 on MySQL.. A table or column name collides with a MySQL reserved word (`order`, `group`, `key`, `index`, `status`, `type`, `rows`, `rank`) and is not wrapped in backticks. MySQL reserves significantly more keywords than most other databases.. A missing or mismatched delimiter in a complex query — unclosed parenthesis in a subquery, a missing comma between column definitions in `CREATE TABLE`, or a missing `END` for a `CASE` expression.. Attempting to use a CTE (`WITH ... AS (...)`) on a MySQL version older than 8.0. MySQL only introduced CTE support in 8.0; running it against 5.7 or earlier produces a 1064 at the `WITH` keyword.. A stored procedure or trigger body contains a `DELIMITER` change that was valid in the MySQL CLI but is passed literally to a JDBC or ODBC driver, which does not understand `DELIMITER $$` as a command.. String literals that contain an unescaped single quote, causing the parser to see the rest of the query as a continuation of the string: `WHERE name = 'O'Brien'` ends the string at the second apostrophe and the remaining `Brien'` is unparseable.. Using MySQL's `LIMIT offset, count` syntax in reverse order, or mixing it with an explicit `OFFSET` clause which MySQL does not accept when using the comma form (`LIMIT 5, 10 OFFSET 2` is invalid; use either form, not both).

Step 1: Read the error position precisely. The message `near 'token' at line N` tells you where the parser gave up — the actual mistake is usually 1-2 tokens before that. Isolate that line and the line above it.. Step 2: Check the MySQL server version before assuming syntax support. Run `SELECT VERSION();` — if the result is below 8.0, CTEs, window functions (`ROW_NUMBER() OVER ()`), and `JSON_TABLE` are unavailable and must be rewritten.. Step 3: Quote every identifier that might be a reserved word using backticks: `` SELECT `order`, `key`, `status` FROM `group` ``. To check whether a word is reserved run `SELECT * FROM information_schema.keywords WHERE RESERVED = 1 AND WORD = 'yourword';` on MySQL 8.0+.. Step 4: Validate the full query in isolation before embedding it in a pipeline. Run it directly via the MySQL CLI: `mysql -u -p -e " "` or paste it into MySQL Workbench's query editor, which highlights the problematic token visually.. Step 5: For dbt models, run `dbt compile --select model_name` and inspect the compiled SQL in `target/compiled/`. Copy that compiled SQL verbatim into the MySQL CLI — this rules out Jinja rendering artifacts like unterminated macros or missing commas in `dbt_utils.star()`.. Step 6: For ADF Script activities, check the activity's JSON definition in the pipeline editor. The SQL is stored under `typeProperties.scripts[].text` — copy it out, strip ADF parameter placeholders (`@pipeline().parameters.X`), substitute literal values, and test directly against MySQL.. Step 7: If the query runs in one client but fails in another (e.g. works in Workbench, fails in JDBC), check the `sql_mode` setting. Run `SELECT @@sql_mode;` in both contexts — modes like `ANSI_QUOTES` change how double-quotes are interpreted and can cause 1064 in one environment but not the other.

High severityquery

MySQL Error:
1064

Impact

Any ADF pipeline with a Script, Lookup, or Copy activity using a custom query will fail immediately and not retry — 1064 is a deterministic parse error, not a transient fault. Downstream datasets that depend on this activity will not refresh, and dbt models built on the failing source will produce stale or missing tables until the syntax is corrected and the pipeline reruns successfully.

Because 1064 is a parse error, MySQL rejects the query before acquiring any locks or reading any rows — there is no partial write and no need to roll back. However, the pipeline activity fails immediately with exit code 1 and ADF marks the activity as Failed without triggering retry logic (retries are only attempted for transient errors by default). Any downstream activities dependent on the output of the failed activity are skipped, leaving target tables unpopulated or stale. If the pipeline runs on a schedule, every subsequent run will fail identically until the SQL is corrected and the pipeline is republished.

What does this error mean?

MySQL's parser failed to interpret the SQL statement and aborted execution before any rows were read or written. Error 1064 is a pure parse-time failure: the query never reached the storage engine. In a data pipeline context this means the ADF Script activity, dbt model, or BI tool query returns immediately with a non-zero exit code and the full error string `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`. The fragment shown after 'near' is the token that broke the parser — the actual mistake is usually one or two tokens earlier.

Common causes

1SQL ported from PostgreSQL or SQL Server that uses dialect-specific syntax MySQL does not support — for example `ILIKE`, `::cast`, `TOP N`, `QUALIFY`, or `FETCH FIRST N ROWS ONLY` will all trigger 1064 on MySQL.
2A table or column name collides with a MySQL reserved word (`order`, `group`, `key`, `index`, `status`, `type`, `rows`, `rank`) and is not wrapped in backticks. MySQL reserves significantly more keywords than most other databases.
3A missing or mismatched delimiter in a complex query — unclosed parenthesis in a subquery, a missing comma between column definitions in `CREATE TABLE`, or a missing `END` for a `CASE` expression.
4Attempting to use a CTE (`WITH ... AS (...)`) on a MySQL version older than 8.0. MySQL only introduced CTE support in 8.0; running it against 5.7 or earlier produces a 1064 at the `WITH` keyword.
5A stored procedure or trigger body contains a `DELIMITER` change that was valid in the MySQL CLI but is passed literally to a JDBC or ODBC driver, which does not understand `DELIMITER $$` as a command.
6String literals that contain an unescaped single quote, causing the parser to see the rest of the query as a continuation of the string: `WHERE name = 'O'Brien'` ends the string at the second apostrophe and the remaining `Brien'` is unparseable.
7Using MySQL's `LIMIT offset, count` syntax in reverse order, or mixing it with an explicit `OFFSET` clause which MySQL does not accept when using the comma form (`LIMIT 5, 10 OFFSET 2` is invalid; use either form, not both).

How to fix it

1Step 1: Read the error position precisely. The message `near 'token' at line N` tells you where the parser gave up — the actual mistake is usually 1-2 tokens before that. Isolate that line and the line above it.
2Step 2: Check the MySQL server version before assuming syntax support. Run `SELECT VERSION();` — if the result is below 8.0, CTEs, window functions (`ROW_NUMBER() OVER ()`), and `JSON_TABLE` are unavailable and must be rewritten.
3Step 3: Quote every identifier that might be a reserved word using backticks: `` SELECT `order`, `key`, `status` FROM `group` ``. To check whether a word is reserved run `SELECT * FROM information_schema.keywords WHERE RESERVED = 1 AND WORD = 'yourword';` on MySQL 8.0+.
4Step 4: Validate the full query in isolation before embedding it in a pipeline. Run it directly via the MySQL CLI: `mysql -u <user> -p <db> -e "<your query>"` or paste it into MySQL Workbench's query editor, which highlights the problematic token visually.
5Step 5: For dbt models, run `dbt compile --select model_name` and inspect the compiled SQL in `target/compiled/`. Copy that compiled SQL verbatim into the MySQL CLI — this rules out Jinja rendering artifacts like unterminated macros or missing commas in `dbt_utils.star()`.
6Step 6: For ADF Script activities, check the activity's JSON definition in the pipeline editor. The SQL is stored under `typeProperties.scripts[].text` — copy it out, strip ADF parameter placeholders (`@pipeline().parameters.X`), substitute literal values, and test directly against MySQL.
7Step 7: If the query runs in one client but fails in another (e.g. works in Workbench, fails in JDBC), check the `sql_mode` setting. Run `SELECT @@sql_mode;` in both contexts — modes like `ANSI_QUOTES` change how double-quotes are interpreted and can cause 1064 in one environment but not the other.

Example log output

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 'QUALIFY ROW_NUMBER() OVER (PARTITION BY customer_id ORDER BY created_at DESC) =' at line 7
[ADF] Activity 'LookupLatestOrders' failed: MySQL returned error code 1064. See inner exception for query text.
[dbt] Compilation Error in model stg_orders: Runtime Error in model stg_orders (models/staging/stg_orders.sql): (1064, "You have an error in your SQL syntax...")

Frequently asked questions

How do I find the exact location of a MySQL 1064 syntax error?

The error message includes `near 'text' at line N` — the text shown is the token where the parser stopped. The actual mistake is almost always one or two tokens before that point. Count the line number in your SQL, look at the token just before the one shown, and check for a missing comma, unclosed parenthesis, or unquoted reserved word.

MySQL 1064 error with WITH (CTE) — how do I fix it?

CTEs using `WITH ... AS (SELECT ...)` are only supported from MySQL 8.0 onwards. If you're on MySQL 5.7 or earlier, rewrite the CTE as a subquery in the FROM clause or as a temporary table: `CREATE TEMPORARY TABLE tmp_name AS SELECT ...;` followed by a query against `tmp_name`. Check your version with `SELECT VERSION();`.

Which SQL keywords need backtick quoting in MySQL?

Common reserved words that cause 1064 when used unquoted as identifiers: `order`, `group`, `key`, `index`, `table`, `select`, `from`, `where`, `status`, `type`, `rows`, `rank`, `lead`, `lag`. Wrap them in backticks: `` `order` ``, `` `status` ``. On MySQL 8.0+ you can verify: `SELECT WORD FROM information_schema.keywords WHERE RESERVED = 1 ORDER BY WORD;`.

MySQL 1064 in Azure Data Factory — where do I find the actual query?

In the ADF pipeline editor, open the failing activity and go to Settings. For Script activities the SQL is under the Scripts tab; for Copy activities with a custom query it is under Source → Query. Copy the SQL, replace any ADF dynamic expressions (`@pipeline().parameters.X`) with literal test values, and run it directly against MySQL to reproduce and fix the error outside ADF.

Source · dev.mysql.com/doc/mysql-errors/8.0/en/server-error-reference.html