How to Fix MySQL Error 1193: Unknown System Variable

ERROR 1193 (HY000): Unknown system variable 'variable_name' is raised when a SET statement or a SELECT @@variable expression references a system variable name that the MySQL server does not recognize. The error symbol is ER_UNKNOWN_SYSTEM_VARIABLE.

Impact

The statement that references the unknown variable fails immediately and no change is applied. If the SET statement is part of a session initialization sequence — such as commands issued by a connection pool, ORM, or client driver on connect — the entire connection attempt may fail, making the application unable to reach the database at all.

Developers most commonly encounter this error when migrating between MySQL versions, switching between MySQL and MariaDB, or deploying configuration scripts written for a different server edition. ORMs and frameworks that emit SET commands automatically (e.g., setting sql_mode, time_zone, or character_set) can surface this error as a cryptic connection-level exception rather than a clear variable-name message.

Common Causes

Typo in the variable name. Variable names like innodb_buffer_pool_size are easy to mistype. MySQL performs no fuzzy matching and any spelling difference raises 1193.
Variable introduced in a newer MySQL version. For example, caching_sha2_password_digest_rounds was added in MySQL 8.0.24. Running that SET on 8.0.20 or any 5.7 server raises 1193.
Variable removed or renamed in a newer MySQL version. query_cache_size and query_cache_type were removed in MySQL 8.0. Scripts written for 5.7 that set these variables break on 8.0.
MariaDB vs MySQL mismatch. MariaDB exposes variables like wsrep_on or aria_pagecache_buffer_size that do not exist in MySQL, and vice versa. Connection strings or init scripts are sometimes shared between the two without adjustment.
Plugin-provided variable used before the plugin is loaded. Variables like validate_password_policy (5.7) or validate_password.policy (8.0) only exist when the validate_password plugin or component is active. Referencing them without the plugin raises 1193.
Wrong scope prefix. Attempting SET GLOBAL on a variable that only exists as a session variable, or vice versa, sometimes surfaces as 1193 rather than the more specific 1238 error, depending on the MySQL version.

Troubleshooting and Resolution Steps

Confirm the exact variable name on your server version.
```
SHOW VARIABLES LIKE 'validate_password%';
```
Or query information_schema for a precise search:
```
SELECT VARIABLE_NAME
FROM performance_schema.global_variables
WHERE VARIABLE_NAME LIKE '%query_cache%';
```
If the query returns no rows, the variable does not exist on this server.
Check your MySQL version to understand what variables are available.
```
SELECT VERSION();
```
Cross-reference the variable against the MySQL documentation for your specific release.
Replace removed variables with their MySQL 8.0 equivalents. The query cache was removed in 8.0. Remove or comment out any references to query_cache_size, query_cache_type, and query_cache_limit in configuration scripts and my.cnf option files.
Check whether the required plugin or component is loaded.
```
-- For plugins (MySQL 5.7 style)
SHOW PLUGINS;

-- For components (MySQL 8.0 style)
SELECT * FROM mysql.component;
```
If validate_password is absent, either install it or remove the SET statement that references its variables.
Correct the variable name for the target server. In MySQL 8.0, validate_password_policy (plugin variable) became validate_password.policy (component variable). Update scripts accordingly:
```
-- MySQL 5.7 (plugin)
SET GLOBAL validate_password_policy = 'MEDIUM';

-- MySQL 8.0 (component)
SET GLOBAL validate_password.policy = 'MEDIUM';
```
Guard version-specific SET statements with a conditional in application bootstrap code. If the application must support multiple MySQL versions, check the version at runtime before issuing version-specific variable assignments, or catch the 1193 error and continue.

Additional Information

Related errors: Error 1238 (ER_INCORRECT_GLOBAL_LOCAL_VAR) is raised when the variable exists but is used with the wrong scope (GLOBAL vs SESSION). Error 1229 (ER_GLOBAL_VARIABLE) is raised when a session-only variable is set with SET GLOBAL.
MariaDB compatibility: MariaDB has its own distinct set of system variables and does not raise 1193 with the same MySQL symbol, but produces an equivalent error. Always validate variable names against the actual server type and version.
ORM and driver behavior: Connectors/J, the Go go-sql-driver/mysql driver, and other clients often allow configuring sessionVariables or connectionInitSql options. Variables set through these options trigger 1193 at connection time, which may appear in application logs as a generic "connection refused" or "driver error" rather than a MySQL error.
my.cnf vs runtime: Error 1193 only applies to runtime SET commands. Invalid variable names in my.cnf or my.ini cause the MySQL server to refuse to start, not to raise 1193.

Frequently Asked Questions

Why does this error appear only after upgrading MySQL? Variables that existed in older versions are sometimes removed or renamed in newer releases. The query cache variables (query_cache_*) are a well-known example removed in MySQL 8.0. After an upgrade, any script or ORM init command that references these variables immediately raises 1193.

How do I find which variable name to use in MySQL 8.0 vs 5.7? Use SHOW VARIABLES LIKE 'pattern%' on both server versions to compare the available names. The MySQL upgrade guide also documents renamed and removed variables for each major release.

Can I set an unknown variable without an error to make scripts portable? MySQL does not have an IF EXISTS clause for SET. The common workaround is to use a stored procedure that reads @@version and branches, or to catch error 1193 at the application level and treat it as a non-fatal warning when the variable is optional.

Does this error affect transactions? If the SET statement is issued inside a transaction, the failed statement itself has no effect, but the transaction remains open. The rest of the transaction is unaffected unless the application logic aborts on the error. In autocommit mode, the statement simply fails with no side effects.