MySQL Error:
1193

What does this error mean?

MySQL throws error 1193 when a SET statement (SET GLOBAL, SET SESSION, or SET in a stored procedure) references a system variable name that does not exist in the running MySQL server. In data pipelines, this typically surfaces when an ADF Stored Procedure activity or dbt on-run-start hook executes a SET statement against a MySQL version that lacks the target variable — for example, setting `group_replication_consistency` on a MySQL 5.7 server where that variable only exists in 8.0+. The engineer sees the query fail immediately with ERROR 1193 (HY000): Unknown system variable 'variable_name'. No partial execution happens; the entire SET statement is rejected.

Common causes

• 1Setting a variable introduced in MySQL 8.0 (e.g., `cte_max_recursion_depth`, `group_replication_consistency`) on a MySQL 5.7 server that does not have it.
• 2Using a variable that was removed between versions — `query_cache_size`, `query_cache_type`, and `innodb_file_format` no longer exist in MySQL 8.0.
• 3Typo in the variable name: `transaction_isolation` (correct in 8.0) vs. `tx_isolation` (deprecated alias removed in 8.0.3).
• 4Copying a my.cnf or init script from one MySQL instance to another running a different major version without checking variable compatibility.
• 5A dbt on-run-start hook or ADF pre-copy script that sets session variables assumes a specific MySQL version but the Linked Service points to an Aurora MySQL or MariaDB fork where the variable has a different name.
• 6Using plugin-specific variables (e.g., `clone_autotune_concurrency`) without the corresponding plugin being installed — MySQL treats unloaded plugin variables as unknown.

How to fix it

1. 1Step 1: Confirm the exact variable name in the error message and check if it exists on the server: `SHOW VARIABLES LIKE '%variable_name%';` — an empty result set means the variable is not available.
2. 2Step 2: Check the running MySQL version: `SELECT VERSION();` — note whether it is MySQL Community, Aurora MySQL, or MariaDB, since variable support differs across forks.
3. 3Step 3: Look up the variable in the MySQL docs for your version. For 8.0: https://dev.mysql.com/doc/refman/8.0/en/server-system-variables.html — search for the variable name and check the 'Introduced' and 'Removed' columns.
4. 4Step 4: If the variable was renamed, update your SET statement. Common renames: `tx_isolation` → `transaction_isolation`, `log_warnings` → `log_error_verbosity`, `innodb_file_format` → removed (always Barracuda in 8.0).
5. 5Step 5: If the variable requires a plugin, install it first: `INSTALL PLUGIN clone SONAME 'mysql_clone.so';` — then retry the SET statement.
6. 6Step 6: For dbt projects, wrap version-dependent SET statements in a Jinja conditional: `{% if target.mysql_version >= '8.0' %}SET SESSION cte_max_recursion_depth = 10000;{% endif %}`
7. 7Step 7: For ADF Stored Procedure activities, move session variable initialization into the stored procedure itself with version detection: `IF @@version >= '8.0' THEN SET SESSION ... END IF;`

Example log output

ERROR 1193 (HY000): Unknown system variable 'query_cache_size'
2026-05-11 08:14:22 [ERROR] ADF activity 'Init_MySQL_Session' failed: ErrorCode=UserErrorExecutionFailed, Message='Unknown system variable query_cache_size'
2026-05-11 08:14:23 [WARN] dbt on-run-start hook failed: mysql.connector.errors.DatabaseError: 1193 (HY000): Unknown system variable 'query_cache_size'

Frequently asked questions

Other configuration errors