Skip to main content

MySQL Variables

info

Note: Changes made to the configuration on this page must be explicitly loaded to the runtime to take effect. Please refer to the Admin Commands documentation for details on the LOAD and SAVE commands.

List of MySQL Variables

NOTE: You can click on the variable name to jump to its definition

Variable NameDefault Value
mysql-add_ldap_user_comment
mysql-auditlog_filename
mysql-auditlog_filesize100MB
mysql-aurora_max_lag_ms_only_read_from_replicas2
mysql-auto_increment_delay_multiplex5
mysql-auto_increment_delay_multiplex_timeout_ms10000
mysql-autocommit_false_is_transactionfalse
mysql-autocommit_false_not_reusablefalse
mysql-automatic_detect_sqlifalse
mysql-binlog_reader_connect_retry_msec3000
mysql-client_host_cache_size0
mysql-client_host_error_counts0
mysql-client_found_rowstrue
mysql-client_multi_statementstrue
mysql-client_session_track_gtidtrue
mysql-commands_statstrue
mysql-connect_retries_delay1
mysql-connect_retries_on_failure10
mysql-connect_timeout_client10000
mysql-connect_timeout_server3000
mysql-connect_timeout_server_max10000
mysql-connection_delay_multiplex_ms0
mysql-connection_max_age_ms0
mysql-connection_warmingfalse
mysql-connpoll_reset_queue_length50
mysql-protocol_compression_level3
mysql-default_authentication_pluginmysql_native_password
mysql-default_character_set_resultsNULL
mysql-default_charsetutf8
mysql-default_collation_connection
mysql-default_isolation_levelREAD COMMITTED
mysql-default_max_join_size18446744073709551615
mysql-default_max_latency_ms1000
mysql-default_net_write_timeout60
mysql-default_query_delay0
mysql-default_query_timeout86400000
mysql-default_reconnecttrue
mysql-default_schemainformation_schema
mysql-default_session_track_gtidsOFF
mysql-ignore_min_gtid_annotationsfalse
mysql-default_sql_auto_is_nullOFF
mysql-default_sql_mode
mysql-default_sql_safe_updatesOFF
mysql-default_sql_select_limitDEFAULT
mysql-default_time_zoneSYSTEM
mysql-default_transaction_readWRITE
mysql-default_tx_isolationREAD-COMMITTED
mysql-enable_client_deprecate_eoftrue
mysql-enable_load_data_local_infilefalse
mysql-enable_server_deprecate_eoftrue
mysql-enforce_autocommit_on_readsfalse
mysql-evaluate_replication_lag_on_servers_load1
mysql-eventslog_default_log0
mysql-eventslog_filename
mysql-eventslog_filesize104857600
mysql-eventslog_format1
mysql-eventslog_stmt_parameters0
mysql-firewall_whitelist_enabledfalse
mysql-firewall_whitelist_errormsgFirewall blocked this query
mysql-forward_autocommitfalse
mysql-free_connections_pct10
mysql-handle_unknown_charset1
mysql-handle_warnings1
mysql-have_compresstrue
mysql-have_ssltrue (since v2.6.0)
mysql-hostgroup_manager_verbose1
mysql-init_connect
mysql-interfaces0.0.0.0:6033
mysql-keep_multiplexing_variablestx_isolation,version
mysql-kill_backend_connection_when_disconnecttrue
mysql-ldap_user_variable
mysql-log_mysql_warnings_enabledfalse
mysql-log_unhealthy_connectionstrue
mysql-long_query_time1000
mysql-max_allowed_packet4194304
mysql-max_connections2048
mysql-max_stmts_cache10000
mysql-max_stmts_per_connection20
mysql-max_transaction_idle_time14400000
mysql-max_transaction_time14400000
mysql-min_num_servers_lantency_awareness1000
mysql-monitor_aws_rds_topology_discovery_interval0
mysql-proxy_protocol_networks''
mysql-mirror_max_concurrency16
mysql-mirror_max_queue_length32000
mysql-multiplexingtrue
mysql-ping_interval_server_msec120000
mysql-ping_timeout_server500
mysql-poll_timeout2000
mysql-poll_timeout_on_failure100
mysql-query_cache_handle_warnings0
mysql-query_cache_size_MB256
mysql-query_cache_soft_ttl_pct0
mysql-query_cache_stores_empty_resulttrue
mysql-query_digeststrue
mysql-query_digests_grouping_limit3
mysql-query_digests_groups_grouping_limit0
mysql-query_digests_keep_commentfalse
mysql-query_digests_lowercasefalse
mysql-query_digests_max_digest_length2048
mysql-query_digests_max_query_length65000
mysql-query_digests_no_digitsfalse
mysql-query_digests_normalize_digest_textfalse
mysql-query_digests_replace_nullfalse
mysql-query_digests_track_hostnamefalse
mysql-query_processor_iterations0
mysql-query_processor_regex1
mysql-data_packets_history_size0
mysql-parse_failure_logs_digestfalse
mysql-processlist_max_query_length2097152
mysql-query_rules_fast_routing_algorithm1
mysql-query_retries_on_failure1
mysql-reset_connection_algorithm2
mysql-server_capabilities569867
mysql-server_version5.5.30
mysql-servers_statstrue
mysql-session_idle_ms1
mysql-session_idle_show_processlisttrue
mysql-sessions_sorttrue
mysql-set_parser_algorithm2
mysql-set_query_lock_on_hostgroup1
mysql-show_processlist_extended0
mysql-shun_on_failures5
mysql-shun_recovery_time_sec10
mysql-ssl_p2s_ca
mysql-ssl_p2s_capath
mysql-ssl_p2s_cert
mysql-ssl_p2s_cipher
mysql-ssl_p2s_key
mysql-ssl_p2s_crl
mysql-ssl_p2s_crlpath
mysql-stacksize1048576
mysql-stats_time_backend_queryfalse
mysql-stats_time_query_processorfalse
mysql-tcp_keepalive_time0
mysql-fast_forward_grace_close_ms5000
mysql-threads4
mysql-threshold_query_length524288
mysql-threshold_resultset_size4194304
mysql-throttle_connections_per_sec_to_hostgroup1000000
mysql-throttle_max_bytes_per_second_to_client0
mysql-throttle_ratio_server_to_client0
mysql-unshun_algorithm0
mysql-use_tcp_keepalivefalse
mysql-verbose_query_errorfalse

mysql-add_ldap_user_comment

MySQL VariableNamemysql-add_ldap_user_comment
DynamicYes
Permitted ValuesTypeString
DefaultNULL
Valid values

If mysql-add_ldap_user_comment is set, a comment like the following will be added on the query:

valueof_mysql-add_ldap_user_comment=frontend_username

mysql-ldap_user_variable

MySQL VariableNamemysql-ldap_user_variable
DynamicYes
Permitted ValuesTypeString
DefaultNULL
Valid values

When set, sessions will have a variable set with the user_name value, ie: SET @mysql-ldap_user_variable:='username' The use of this variable can be for auditing purposed backend side. For example, if a trigger on a table will use that session variable.

mysql-auditlog_filename

MySQL VariableNamemysql-auditlog_filename
DynamicYes
Permitted ValuesTypeString
DefaultNULL
Valid values

Setting this variable automatically enables Audit Log . This variable defines the base name of the audit log where audit events are logged. The filename of the log file will be the base name followed by an 8 digits progressive number. Files are automatically rotated based on the value of mysql-auditlog_filesize .

mysql-auditlog_filesize

System VariableNamemysql-auditlog_filesize
DynamicYes
Permitted ValuesTypeInteger (count)
Default104857600
Minimum1MB
Maximum1GB

This variable defines the maximum file size of the audit log file (see mysql-auditlog_filename) when the current file will be closed and a new file will be created. The default value is 104857600 (100MB)

mysql-aurora_max_lag_ms_only_read_from_replicas

System VariableNamemysql-aurora_max_lag_ms_only_read_from_replicas
DynamicYes
Permitted ValuesTypeInteger (count)
Default2
Minimum0
Maximum

If max_lag_ms is used for the query, send traffic only to replicas if at least N replicas are good candidates.

mysql-auto_increment_delay_multiplex

System VariableNamemysql-auto_increment_delay_multiplex
DynamicYes
Permitted ValuesTypeInteger (count)
Default5
Minimum0
Maximum1000000

Several applications rely, explicitly or implicitly, on the value returned by LAST_INSERT_ID(). If multiplexing is not configured correctly, or if the queries pattern is really unpredictable (for example if new queries are often deployed), it is possible that the query using LAST_INSERT_ID() uses a connection different than the connection where an auto-increment was used. If mysql-auto_increment_delay_multiplex is set, after an OK packet with last_insert_id is received, multiplexing is temporarily disabled for the same number of queries as specified in mysql-auto_increment_delay_multiplex. Note that disabling multiplexing doesn't disable routing, so it is important to configure read/write split correctly. Furthermore, please note that ProxySQL is able to handle these queries correctly even if mysql-auto_increment_delay_multiplex is set to 0:

  • SELECT LAST_INSERT_ID()
  • SELECT LAST_INSERT_ID() LIMIT 1
  • SELECT @@IDENTITY

Therefore you should configure mysql-auto_increment_delay_multiplex greater than 0 only if your application relies on LAST_INSERT_ID() in some way other than the queries listed above. As the name suggests, mysql-auto_increment_delay_multiplex disables multiplexing: one of the most important and advanced feature of ProxySQL. If your application doesn't use LAST_INSERT_ID() it is recommended to lower mysql-auto_increment_delay_multiplex to 0.

mysql-auto_increment_delay_multiplex_timeout_ms

Introduced in v2.4.0. Specifies the timeout in milliseconds after which mysql-auto_increment_delay_multiplex gets invalidated (i.e. set back to '0'), thus re-enabling multiplexing.

System VariableNamemysql-auto_increment_delay_multiplex_timeout_ms
DynamicYes
Permitted ValuesTypeInteger (milliseconds)
Default10000
Minimum0
Maximum3600000 (1 hour)

mysql-autocommit_false_is_transaction

System VariableNamemysql-autocommit_false_is_transaction
DynamicYes
Permitted ValuesTypeBoolean
Defaultfalse

If mysql-autocommit_false_is_transaction=true (false by default), a connection with autocommit=0 is treated as a transaction and it is not returned to the connection pool. That is, autocommit=0 disables multiplexing. Please note that autocommit=0 isn't enough to start a transaction: at the database level, a transaction is started when a query is executed against a transactional table. It is recommended to not change this variable.

mysql-autocommit_false_not_reusable

System VariableNamemysql-autocommit_false_not_reusable
DynamicYes
Permitted ValuesTypeBoolean
Defaultfalse

When set to true, a connection with autocommit=0 is not re-used and is destroyed when the connection is returned to the connection pool. It is recommended to not change this variable.

mysql-automatic_detect_sqli

System VariableNamemysql-automatic_detect_sqli
DynamicYes
Permitted ValuesTypeBoolean
Defaultfalse

When set to true, automatic detection of SQL injection is enabled. For further reference, please also see SQL Injection Engine.

mysql-binlog_reader_connect_retry_msec

Controls the connect retry timeout for the binlog reader (introduced in ProxySQL 2.0).

System VariableNamemysql-binlog_reader_connect_retry_msec
DynamicYes
Permitted ValuesTypeInteger (milliseconds)
Default3000
Minimum200
Maximum120000

mysql-client_found_rows

System VariableNamemysql-client_found_rows
DynamicYes
Permitted ValuesTypeBoolean
Defaulttrue

This variable is deprecated since 2.0.6 . For older versions: when set to true, client flag CLIENT_FOUND_ROWS is set when connecting to MySQL backends. Since ProxySQL version 2.0.6 , ProxySQL matches flag CLIENT_FOUND_ROWS in frontend and backend connections.

mysql-client_host_cache_size

System VariableNamemysql-client_host_cache_size
DynamicYes
Permitted ValuesTypeInteger
Default0
Minimum0
Maximum1048576

In combination with mysql-client_host_error_counts offers control over Client Error Limit feature. This variable specifies the maximum size of the cache to be used for storing client addresses which have previously performed invalid connections attempts.

mysql-client_host_error_counts

System VariableNamemysql-client_host_error_counts
DynamicYes
Permitted ValuesTypeInteger
Default0
Minimum0
Maximum1048576

In combination with mysql-client_host_cache_size offers control over 'Client Error Limit' feature. This variable specifies the maximum number of consecutive unsuccessful connections attempts that can be performed from a particular address before any further connections attempts are dropped.

mysql-client_multi_statements

System VariableNamemysql-client_multi_statements
DynamicYes
Permitted ValuesTypeBoolean
Defaulttrue

This variable is deprecated since 2.0.6 . For older versions: when set to true, client flag CLIENT_MULTI_STATEMENTS is set when connecting to MySQL backends. Since ProxySQL version 2.0.6 , ProxySQL matches flag CLIENT_MULTI_STATEMENTS in frontend and backend connections.

mysql-client_session_track_gtid

When activated ProxySQL will keep track of the GTID status on the backend serves in the stats_mysql_gtid_executed table.

System VariableNamemysql-client_session_track_gtid
DynamicYes
Permitted ValuesTypeBoolean
Defaulttrue

mysql-commands_stats

System VariableNamemysql-commands_stats
DynamicYes
Permitted ValuesTypeBoolean
Defaulttrue

Enable per-command MySQL query statistics. A command is a type of SQL query that is being executed. Some examples are: SELECT<code>, </code>INSERT or ALTER TABLE. All the statistics can be retrieved querying table stats_mysql_commands_counters. Disabling this variable also disables the population of table stats_mysql_query_digest.

mysql-connect_retries_delay

System VariableNamemysql-connect_retries_delay
DynamicYes
Permitted ValuesTypeInteger (milliseconds)
Default1
Minimum0
Maximum10000

The delay (in milliseconds) before trying to reconnect after a failed attempt to a backend MySQL server. Failed attempts can take place due to numerous reasons: too busy backend, timed out for the current attempt, etc. Connections will be retried for mysql-connect_retries_on_failure times.

mysql-connect_retries_on_failure

System VariableNamemysql-connect_retries_on_failure
DynamicYes
Permitted ValuesTypeInteger
Default10
Minimum0
Maximum1000

The number of times for which a reconnect should be attempted in case of an error, timeout, or any other event that led to an unsuccessful connection to a backend MySQL server. After the number of attempts is depleted, if a connection still couldn't be established, an error is returned. The error returned is either the last connection attempt error or a generic error ("Max connect failure while reaching hostgroup" with error code 28000). See also mysql-connect_retries_delay. Be careful about tweaking this parameter - a value that is too high can significantly increase the latency with which an unresponsive hostgroup is reported to the MySQL client.

mysql-connect_timeout_client

System VariableNamemysql-connect_timeout_client
DynamicYes
Permitted ValuesTypeInteger (milliseconds)
Default10000
Minimum
Maximum

Maximum time to wait for a client connection to be established before closing it.

mysql-connect_timeout_server

System VariableNamemysql-connect_timeout_server
DynamicYes
Permitted ValuesTypeInteger (milliseconds)
Default1000
Minimum10
Maximum120000

The timeout for a single attempt at connecting to a backend server from proxysql. If this fails, proxysql will try to reconnect according to parameters mysql-connect_retries_on_failure and mysql-connect_retries_delay . If none of the server in the destination hostgroup is reachable after mysql-connect_timeout_server_max milliseconds, an error is returned to the client. See mysql-connect_timeout_server_max for further details. We believe that the default value of 1000 milliseconds is already a big value: if proxysql and a backend aren't able to fully establish a connection after 1000 milliseconds, there is either a network issue or the backend is overloaded and unable to quickly create a connection. Therefore if a connection isn't established quickly it is a warning signal. Nonetheless, some users prefer to increase mysql-connect_timeout_server a bit higher, allowing connections to be established to a generally slow backend.

mysql-connect_timeout_server_max

System VariableNamemysql-connect_timeout_server_max
DynamicYes
Permitted ValuesTypeInteger (milliseconds)
Default10000
Minimum10
Maximum3600000

The maximum timeout for connecting from ProxySQL to a backend in a hostgroup. When ProxySQL tried to establish a connection to a backend, the attempts can timeout after mysql-connect_timeout_server milliseconds and ProxySQL will retry to establish a new connection (against the same backend or another backend in the same hostgroup) according to parameters mysql-connect_retries_on_failure and mysql-connect_retries_delay . Connection attempts are not retried anymore when a final timeout of mysql-connect_timeout_server_max milliseconds is reached, and an error is returned to the client with code 9001 and the message "Max connect timeout reached while reaching hostgroup...". See also mysql-shun_recovery_time_sec Due to a bug fixed in version 2.0.7, for all previous releases it is recommended to not set this value higher than 10 minutes.

mysql-connection_delay_multiplex_ms

System VariableNamemysql-connection_delay_multiplex_ms
DynamicYes
Permitted ValuesTypeInteger (milliseconds)
Default0
Minimum0
Maximum300000

After executing a query on a backend connection, if ProxySQL determines that the same backend connection can be safely assigned to another client (multiplexing is enabled, or in other words there is no need to keep the backend connection linked to a specific frontend connection), the backend connection is immediately returned to the connection pool. Variable mysql-connection_delay_multiplex_ms modifies this behavior, and instead of return the backend connection immediately to the connection pool, it will keep multiplexing disabled for a short period of time on a connection. This will allow a frontend connection to re-use the same backend connection for successive queries (e.g. when batching queries). The delay is measured for the time there is no activity on the connection. Please note that this variable temporary disable only multiplexing: query routing it is not affected by it. This is important because if the application run a query that is destinated to a different target hostgroup, it will not use the same backend connection.

mysql-connection_max_age_ms

System VariableNamemysql-connection_max_age_ms
DynamicYes
Permitted ValuesTypeInteger (milliseconds)
Default0
Minimum0
Maximum86400000

When mysql-connection_max_age_ms is set to a value greater than 0, inactive connections in the connection pool (therefore not currently used by any session) are closed if they were created more than mysql-connection_max_age_ms milliseconds ago. By default, connections aren't closed based on their age. When mysql-connection_max_age_ms is reached, connections are simply disconnected, without sending COM_QUIT command to the server, so this might result in Aborted connection warnings showing up in your MySQL server logs (this behaviour is intended, see GH #1861).

mysql-connection_warming

System VariableNamemysql-connection_warming
DynamicYes
Permitted ValuesTypeBoolean
Defaultfalse
When enabled, ProxySQL will keep opening new connections for all servers in all hostgroups, until the expected number of warm connections is reached. This number can be computed as: mysql-free_connections_pct * mysql_servers.max_connections / 100

mysql-connpoll_reset_queue_length

PoxySQL 1.4.0 introduced a background thread (HGCU_thread_run()) responsible for resetting connections instead of dropping them when MySQL_HostGroups_Manager::destroy_MyConn_from_pool() is called. There could be cases in which this behavior is not beneficial. In ProxySQL 1.4.4 mysql-connpoll_reset_queue_length allows this behavior to be configurable by destroying the connection when the defined threshold is reached.

System VariableNamemysql-connpoll_reset_queue_length
DynamicYes
Permitted ValuesTypeInteger
Default50
Minimum0
Maximum1000

mysql-protocol_compression_level

Introduced in 2.7.2. Specifies the compression level to be used for fronted connections with compression. When changing this value, it should be taken into account that higher compression levels translate into higher CPU usage, and that finding the right balance is up to the user and specific use case. The special value -1 sets the default internal value used by the library (zlib).

System VariableNamemysql-protocol_compression_level
DynamicYes
Permitted ValuesTypeInteger
Default3
Minimum-1
Maximum9

mysql-default_authentication_plugin

System VariableNamemysql-default_authentication_plugin
DynamicYes
Permitted ValuesTypeString
Defaultmysql_native_password
Valid Valuesmysql_clear_password
mysql_native_password
caching_sha2_password

Introduced in 2.6.0, allows selecting the authentication plugin that ProxySQL announces to the client in the Initial Handshake Packet. This option doesn't disable any of the authentication methods supported by ProxySQL, just allows to optimize the client-server communication during handshake by making the default authentication announced by the server, match the authentication the client is expected to request. Thus avoiding unnecessary AuthSwitchRequests.

This variable overrides mysql-have_ssl, enabling SSL for fronted connections when set to caching_sha2_password. This is because caching_sha2_password requires a safe channel for performing full authentication, due to clear text password sharing. If a user password is stored as a hashed caching_sha2_password, yet no secure channel (SSL connection) is able to be created between client and ProxySQL, authentication is expected to fail, this is a requirement of caching_sha2_password itself.

mysql-default_character_set_results

Deprecated in version 2.0.11.

mysql-default_charset

System VariableNamemysql-default_charset
DynamicYes
Permitted ValuesTypeString
Defaultutf8
Valid ValuesRun select * from mysql_collations; in the Admin interface to view the full list

The default server charset to be used in the communication with the MySQL clients. Note that this is the default for client connections, not for backend connections. To be more specific, during the handshake with a client, ProxySQL will advertise this as its default charset. Values for mysql-default_charset and mysql-default_collation_connection must be compatible to each other. If they are not, ProxySQL will configure mysql-default_charset using the default charset of collation mysql-default_collation_connection. The default charset for a given collation can be found in table mysql_collations.

mysql-default_collation_connection

System VariableNamemysql-default_collation_connection
DynamicYes
Permitted ValuesTypeString
DefaultNULL
Valid ValuesRun select * from mysql_collations; in the Admin interface to view the full list

The default server collation to be used in the communication with the MySQL clients. Note that this is the default for client connections, not for backend connections. To be more specific, during the handshake with a client, ProxySQL will advertise this as its default charset. Values for mysql-default_charset and mysql-default_collation_connection must be compatible to each other. If they are not, ProxySQL will configure mysql-default_charset using the charset of collation mysql-default_collation_connection.

mysql-default_isolation_level

Deprecated in version 2.0.11.

mysql-default_max_join_size

Deprecated in version 2.0.11.

mysql-default_max_latency_ms

System VariableNamemysql-default_max_latency_ms
DynamicYes
Permitted ValuesTypeInteger (milliseconds)
Default1000
Minimum0
Maximum1728000000

ProxySQL uses a mechanism to automatically ignore backend servers if their latency is excessive. Note that backend servers are not disabled, but only ignored: in other words, ProxySQL will prefer hosts with a smaller latency. This feature is useful to provide a basic location awareness in which ProxySQL will prefer servers that are closer, avoiding sending traffic to servers that are physically far or simply slow. It is possible to configure the maximum latency for each backend in mysql_servers, column max_latency_ms. If mysql_servers.max_latency_ms is 0, the default value mysql-default_max_latency_ms applies. Note: establishing a connection using TLS is more time consuming because of extra handshake and authentication performed by both ProxySQL and the backend, therefore it is recommended to increase mysql-default_max_latency_ms to take into consideration the extra cost of establishing a connection using TLS.

mysql-default_net_write_timeout

Deprecated in version 2.0.11.

mysql-default_query_delay

System VariableNamemysql-default_query_delay
DynamicYes
Permitted ValuesTypeInteger (milliseconds)
Default0
Minimum0
Maximum3600000

This variable allows to create a simple throttling mechanism, delaying the excution of queries to the backends. Setting this variable to a non-zero value (in miliseconds) will delay the execution of all queries, globally. There is a more fine-grained throttling mechanism in the admin table mysql_query_rules, where for each rule there can be one delay that is applied to all queries matching the rule. If a delay is specified in mysql_query_rules.delay, the global value mysql-default_query_delay is ignored. This variable can be useful in emergency situation when a user can decide to back-off traffic from backends simply delaying the execution of every query.

mysql-default_query_timeout

System VariableNamemysql-default_query_timeout
DynamicYes
Permitted ValuesTypeInteger (milliseconds)
Default86400000
Minimum1000
Maximum1728000000

ProxySQL is able to track the execution time of every query that has sent to the backend, and is able to timeout such queries if they run for too long. There are two ways to configure the timeout (maximum execution time) of a query:

The default value for mysql-default_query_timeout is 86400000 milliseconds, equivalent to 24 hours. When the timeout is reached, ProxySQL spawn a separate thread that connects to the backend and runs a KILL query in order to stop the query from running in the backend. After that, ProxySQL will return an error to the client. Please note that when ProxySQL interrupts the execution of a query because of a timeout, the retry mechanism for queries is automatically disabled and ProxySQL will not retry to execute the killed query.

mysql-default_reconnect

Not used for now.

mysql-default_schema

System VariableNamemysql-default_schema
DynamicYes
Permitted ValuesTypeString
Defaultinformation_schema
Valid ValuesAny existing schema

The default schema to be used for incoming MySQL client connections which do not specify a schema name. This variable is required because ProxySQL doesn't allow connections without a schema. Please note that this is a important difference compared to connecting directly to a MySQL server: MySQL allows a client to be connected without a default schema, while ProxySQL doesn't allow that, therefore it needs a default one.

mysql-default_session_track_gtids

Controls whether the server tracks GTIDs within the current session and returns them to the client. Depending on the variable value, at the end of executing each transaction, the server GTIDs are captured by the tracker. The GTID value is also returned to the client if required.

System VariableNamemysql-default_session_track_gtids
DynamicYes
Permitted ValuesType
DefaultOFF
Valid Valuesvalid only at SESSION scope: Note: ALL_GTIDS is not supported by ProxySQL; attempting to set ALL_GTIDS will set the variable to OWN_GTID

mysql-ignore_min_gtid_annotations

Controls whether ProxySQL processes or ignores min_gtid query annotations in SQL comments. These annotations are used in MySQL/MariaDB GTID-based replication systems to specify the minimum Global Transaction ID that should be executed for a query.

For detailed information about query annotations, see Query Annotations.

The min_gtid annotation format is: min_gtid=uuid:transaction_id

When this variable is set to true, ProxySQL will ignore min_gtid annotations and allow queries to execute normally without GTID validation. When set to false, ProxySQL will process min_gtid annotations, validate the GTID format, and store the values for session management.

Algorithm Behavior:

When mysql-ignore_min_gtid_annotations = true (Ignore):

  • ProxySQL skips all min_gtid annotations found in SQL comments
  • No GTID validation is performed
  • Debug logging shows: "Ignoring min_gtid=value"
  • Queries execute regardless of GTID annotation validity

When mysql-ignore_min_gtid_annotations = false (Process - Default):

  • ProxySQL processes all min_gtid annotations
  • Validates GTID format using _is_valid_gtid() function
  • Validates that GTID follows proper format: uuid:transaction_id
  • Stores valid GTID values for MySQL session management
  • Logs warnings for invalid GTID values
  • May affect query execution based on GTID consistency

GTID Validation Requirements:

  • Minimum 3 characters total
  • Must contain colon separator (:)
  • UUID component must be at least 1 character
  • Total length sufficient for complete UUID and transaction ID
  • Must follow MySQL UUID format conventions

Configuration:

-- Enable ignoring min_gtid annotations
SET mysql-ignore_min_gtid_annotations = true;
LOAD MYSQL VARIABLES TO RUNTIME;

-- Disable ignoring min_gtid annotations (process normally)
SET mysql-ignore_min_gtid_annotations = false;
LOAD MYSQL VARIABLES TO RUNTIME;

This variable provides fine-grained control over GTID annotation processing, allowing administrators to balance strict GTID compliance with operational flexibility when dealing with complex GTID annotation scenarios.

System VariableNamemysql-ignore_min_gtid_annotations
DynamicYes
Permitted ValuesTypeBoolean
Defaultfalse

mysql-default_sql_auto_is_null

Deprecated in version 2.0.11. See mysql-default_variables . If this variable is enabled, then after a statement that successfully inserts an automatically generated AUTO_INCREMENT value, you can find that value by issuing a statement of the following form: SELECT * FROM tbl_name WHERE auto_col IS NULL If the statement returns a row, the value returned is the same as if you invoked the LAST_INSERT_ID() function. If no AUTO_INCREMENT value was successfully inserted, the SELECT statement returns no rows.

System VariableNamemysql-default_sql_auto_is_null
DynamicYes
Permitted ValuesTypeString
DefaultOFF
Valid ValuesON|OFF

mysql-default_sql_mode

Deprecated in version 2.0.11. See mysql-default_variables When a client requires a different sql_mode, ProxySQL needs to track the change to ensure that the needed sql_mode is the same on every backend connection used by that specific client. When ProxySQL establishes a new connection to a backend it doesn't know the current sql_mode. Although it is possible to query the backend to retrieve sql_mode and other variables, querying the backend has a latency cost. For this reason ProxySQL doesn't query the backend to know the value of sql_mode, and instead it assumes that all the backend connections have by default the sql_mode defined in mysql-default_sql_mode. If a client changes sql_mode to a value different than mysql-default_sql_mode, ProxySQL will ensure to change sql_mode on every connection used by that client. On the other hand, if a client sets sql_mode to the same value specified in mysql-default_sql_mode, ProxySQL won't change the sql_mode on the backend connection because it assumes that the sql_mode is already correct. A misconfigured mysql-default_sql_mode can lead to unexpected results. For example, if mysql-default_sql_mode='' (the default in ProxySQL, and also the default for MySQL &lt;= 5.6.5) while the backend has sql_mode different than '', if a client executes set session sql_mode='' ProxySQL won't change the sql_mode on the backend. This variable needs to be configured as the default sql_mode across all backends. If backends have different sql_mode or if you want ProxySQL to always enforce the sql_mode specified by the client, mysql-default_sql_mode can be configured using an invalid sql_mode. This will force ProxySQL to always change the sql_mode on the backend to whatever value is specified by the client.

System VariableNamemysql-default_sql_mode
DynamicYes
Permitted ValuesTypeString
Default''
Valid ValuesAny valid or invalid sql_mode

mysql-default_sql_safe_updates

Deprecated in version 2.0.11. See mysql-default_variables If this variable is enabled, UPDATE and DELETE statements that do not use a key in the WHERE clause or a LIMIT clause produce an error. This makes it possible to catch UPDATE and DELETE statements where keys are not used properly and that would probably change or delete a large number of rows.

System VariableNamemysql-default_sql_safe_updates
DynamicYes
Permitted ValuesTypeString
DefaultOFF
Valid ValuesON|OFF

mysql-default_sql_select_limit

Deprecated in version 2.0.11. See mysql-default_variables The maximum number of rows to return from SELECT statements. The default value for a new connection is the maximum number of rows that the server permits per table. Typical default values are (232)−1 or (264)−1. If you have changed the limit, the default value can be restored by assigning a value of DEFAULT. If a SELECT has a LIMIT clause, the LIMIT takes precedence over the value of sql_select_limit.

System VariableNamemysql-default_sql_select_limit
DynamicYes
Permitted ValuesTypeInteger
DefaultDEFAULT
Valid ValuesThe default value for a new connection is the maximum number of rows that the server permits per table. Typical default values are (232)−1 or (264)−1. If you have changed the limit, the default value can be restored by assigning a value of DEFAULT.

mysql-default_time_zone

Deprecated in version 2.0.11. See mysql-default_variables If a client doesn't specify any time_zone, the time zone assigned to the client is whatever time zone is currently assigned to mysql-default_time_zone. When a client requires a different time_zone, ProxySQL needs to track the change to ensure that the needed time_zone is the same on every backend connection used by that specific client. When ProxySQL establishes a new connection to a backend it doesn't know the current time_zone. Although it is possible to query the backend to retrieve time_zone and other variables, querying the backend has a latency cost. For this reason ProxySQL doesn't query the backend to know the value of time_zone, and instead it assumes that all the backend connections have by default the time_zone defined in mysql-default_time_zone. If a client changes time_zone to a value different than mysql-default_time_zone, ProxySQL will ensure to change time_zone on every connection used by that client. On the other hand, if a client sets time_zone to the same value specified in mysql-default_time_zone, ProxySQL won't change the time_zone on the backend connection because it assumes that the time_zone is already correct. A misconfigured mysql-default_time_zone can lead to unexpected results so this variable needs to be configured as the default time_zone across all backends. If backends have different time_zone or if you want ProxySQL to always enforce the time_zone specified by the client, mysql-default_time_zone can be configured using an invalid time_zone. This will force ProxySQL to always change the time_zone on the backend to whatever value is specified by the client.

System VariableNamemysql-default_time_zone
DynamicYes
Permitted ValuesTypeString
DefaultSYSTEM
Valid ValuesAny valid or invalid MySQL time_zone

mysql-default_transaction_read

Deprecated in version 2.0.11. See mysql-default_variables ProxySQL tracks the transaction access modes, READ WRITE or READ ONLY clause. If manually set what is mandatory for ProxySQL is the SESSION scope definition:

- SET SESSION TRANSACTION READ WRITE
- SET SESSION TRANSACTION READ ONLY

SET TRANSACTION READ (WRITE|ONLY) is not supported, and it will automatically disable multiplexing. In MySQL by default, a transaction takes place in read/write mode, with both reads and writes permitted to tables used in the transaction. This mode may be specified explicitly using SET **SESSION** TRANSACTION with an access mode of READ WRITE.

System VariableNamemysql-default_transaction_read
DynamicYes
Permitted ValuesTypeString
DefaultWRITE
Valid ValuesREAD|WRITE

mysql-default_tx_isolation

Variable deprecated in 2.1.1 .
ProxySQL supports the change of the Transaction Isolation level ONLY at SESSION level. Any attempts to run a command like SET TRANSACTION ISOLATION LEVEL value are not supported, and it will automatically disable multiplexing. Correct syntax is: SET SESSION TRANSACTION ISOLATION LEVEL value

System VariableNamemysql-default_tx_isolation
DynamicYes
Permitted ValuesTypeString
DefaultREAD-COMMITTED
Valid ValuesREAD COMMITTED, REPEATABLE READ, and SERIALIZABLE

mysql-log_mysql_warnings_enabled

Introduced in ProxySQL v2.1.1. If enabled, all generated MySQL warnings will be logged to ProxySQL log.

System VariableNamemysql-log_mysql_warnings_enabled
DynamicYes
Permitted ValuesTypeBoolean
Defaultfalse

mysql-log_unhealthy_connections

If a client disconnects in a not graceful way and if mysql-log_unhealthy_connections is enabled (default), ProxySQL will log a warning Closing unhealthy client connection IP:port. The most common reasons for a client to disconnect not gracefully are client just closing the socket without sending any QUIT packet, or a client disconnecting without even starting the MySQL authentication (action performed mostly by monitoring tools that are only checking if the port is open and accepting TCP connections)

System VariableNamemysql-log_unhealthy_connections
DynamicYes
Permitted ValuesTypeBoolean
Defaulttrue

mysql-multiplexing

If mysql-multiplexing is enabled (true by default) multiplexing is globally enabled. We recommend to keep multiplexing enabled (the default). Please note that even if multiplexing is globally enabled, it can still be disabled for other reasons If mysql-multiplexing is disabled globally, multiplexing is never enabled.

System VariableNamemysql-multiplexing
DynamicYes
Permitted ValuesTypeBoolean
Defaulttrue

mysql-enable_client_deprecate_eof

System VariableNamemysql-enable_client_deprecate_eof
DynamicYes
Permitted ValuesTypeBoolean
Defaulttrue
Enables ProxySQL support for MySQL CLIENT_DEPRECATE_EOF for client connections.

mysql-enable_load_data_local_infile

System VariableNamemysql-enable_load_data_local_infile
DynamicYes
Permitted ValuesTypeBoolean
Defaultfalse

ProxySQL doesn't support remote execution of LOAD DATA LOCAL INFILE command, that is, when using LOAD DATA LOCAL INFILE command against ProxySQL the target file needs to be in the local filesystem of the machine running ProxySQL, not in the client filesystem. To avoid this confusion, the command is disabled and listed as unsupported by default.

mysql-enable_server_deprecate_eof

System VariableNamemysql-enable_server_deprecate_eof
DynamicYes
Permitted ValuesTypeBoolean
Defaulttrue

Enables ProxySQL support for MySQL CLIENT_DEPRECATE_EOF for backend connections.

mysql-enforce_autocommit_on_reads

System VariableNamemysql-enforce_autocommit_on_reads
DynamicYes
Permitted ValuesTypeBoolean
Defaultfalse

In MySQL it is possible to start a transaction in two ways:

  • explictly starting a transaction with BEGIN, START TRANSACTION or similar
  • setting autocommit=0 and run a query against a transactional table

A lot of drivers and applications use the second approach, setting autocommit=0 . This can create a problem if some form of read/write split is configured. In fact, if a SELECT statement is executed immediately after SET autcommit=0 , a transaction could be started on a reader server and any DML query will therefore fail. mysql-enforce_autocommit_on_reads controls if autocommit=0 is set on the backend connection if a transaction is not yet started and a SELECT statement is executed:

  • false : (default) SELECT statement is executed with autocommit=1 . This prevents to start a transaction on a reader server potentially configured in read_only=ON mode
  • true : SELECT statement is executed with autocommit=0 . If the SELECT statement is routed to a reader node, this will start a transaction there

The majority of applications work will with mysql-enforce_autocommit_on_read=false , and it is the default configuration. If an application requires mysql-enforce_autocommit_on_read=true to start a transaction with a SELECT statement following SET autocommit=0 , it is likely that more complex query rules are needed to ensure that certain SELECT statements are executed on the writer node. It is also important to remember that mysql-enforce_autocommit_on_reads applies only to SELECT statements when a transaction is not started yet: this means that when mysql-enforce_autocommit_on_read=false and autocommit=0, a transaction will start on the first DML.

mysql-eventslog_filename

If this variable is set, ProxySQL will log all traffic to the specified filename. Note that the log file is not a text file, but a binary log with encoded traffic. The value of this variable can be set to an absolute pathname (e.g. /data/events_log/events_log or else a filename (e.g. events_log) will be written to the defined data directory. A sequential number will always be suffixed in the file's extension (e.g. events_log.00000001).

System VariableNamemysql-eventslog_filename
DynamicYes
Permitted ValuesTypeString
Defaultempty string, not set
Valid ValuesA filename or absolute path

mysql-eventslog_filesize

This variable specifies the maximum size of files created by ProxySQL logger as specified in mysql-eventslog_filename. When the maximum size is reached, the file is rotated.

System VariableNamemysql-eventslog_filesize
DynamicYes
Permitted ValuesTypeInteger (bytes)
Default104857600 (100MB)
Minimum1048576
Maximum1073741824

mysql-evaluate_replication_lag_on_servers_load

System VariableNamemysql-evaluate_replication_lag_on_servers_load
DynamicYes
Permitted ValuesTypeBoolean
DefaultTrue

Prior to 2.6.0 when a replica server was in SHUNNED_REPLICATION_LAG state and a user triggered a servers reconfiguration via command LOAD MYSQL USERS TO RUNTIME, the server status will be updated to the one specified by the user, including ONLINE state, the transitory state SHUNNED_REPLICATION_LAG was not preserved in this case. After 2.6.0, it's possible to control this behavior using this configuration variable. When true (default value) the replica server transitory state SHUNNED_REPLICATION_LAG will be preserved when users trigger servers reconfiguration and the target status specified by the user is ONLINE, when false the behavior will be the one prior to 2.6.0, the server won't preserve the state no matter the target state specified by the user.

mysql-eventslog_default_log

ProxySQL is able to log queries that pass through. If there is no definition for Log in a matching rule in mysql_query_rules, mysql-eventslog_default_log applies. See also Query Logging

System VariableNamemysql-eventslog_default_log
DynamicYes
Permitted ValuesTypeBoolean
Defaultfalse

mysql-eventslog_format

System VariableNamemysql-eventslog_format
DynamicYes
Permitted ValuesTypeInteger
Default1
Valid Values1 : this is the default: queries are logged in binary format (like before 2.0.6)
2 : the queries are logged in JSON format.

From version 2.0.6 ProxySQL can handle two different log formats:

  • 1 : this is the default: queries are logged in binary format (like before 2.0.6)
  • 2 : the queries are logged in JSON format

See also Query Logging

mysql-eventslog_stmt_parameters

System VariableNamemysql-eventslog_stmt_parameters
DynamicYes
Permitted ValuesTypeBoolean
Defaultfalse

Due to the potential overhead of logging prepared statements parameters, especially in JSON format and in the presence of large blobs, this variable controls if parameters need to be logged or not.

mysql-firewall_whitelist_enabled

System VariableNamemysql-firewall_whitelist_enabled
DynamicYes
Permitted ValuesTypeBoolean
Defaultfalse

This variable globally toggles the firewall whitelist algorithm on or off. For more information on firewall whitelisting, see also Firewall Whitelist.

mysql-firewall_whitelist_errormsg

System VariableNamemysql-firewall_whitelist_errormsg
DynamicYes
Permitted ValuesTypeString
DefaultFirewall blocked this query

The error message that will be returned to the client, unless mysql_query_rules.error_msg has already set one. See also Firewall Whitelist.

mysql-forward_autocommit

Deprecated in ProxySQL version 2.1.1 . See GH #3253 When mysql-forward_autocommit=false (the default), ProxySQL will track (and remember) the autocommit value that the client wants and change autocommit on a backend connection as needed. For example, if a client sends set autocommit=0, ProxySQL will just reply OK. When the client sends a DDL, ProxySQL will get a connection to target hostgroup, and change autocommit before running the DDL. If mysql-forward_autocommit=true, SET autocommit=0 is forwarded to the backend. SET autocommit=0 doesn't start any transaction, the connection is set in the connection pool, and queries may execute on a different connection. If you set mysql-forward_autocommit=true, you should also set mysql-autocommit_false_not_reusable=true to prevent the connection to be returned to the connection pool. In other words, setting mysql-forward_autocommit=false will prevent this behaviour since the autocommit state is tracked.

System VariableNamemysql-forward_autocommit
DynamicYes
Permitted ValuesTypeBoolean
Defaultfalse

mysql-free_connections_pct

ProxySQL uses a connection pool to connect to backend servers. Connections to backend are never pre-allocated if there is no need, so at start up there will be 0 connections to the backend. When an application starts sending traffic to ProxySQL, this identifies to which backend it needs to send traffic. If there is a connection in the connection pool for that backend, that connection is used, otherwise a new connection is created. When the connection completes serving the client's request, it is sent back to the the Hostgroup Manager. If the Hostgroup Manager determines that the connection is safe to share and the connection pool isn't full, it will place it in the connection pool. Although, not all the unused connections are kept in the connection pool. This variable controls the percentage of open idle connections from the total maximum number of connections for a specific server in a hostgroup. For each hostgroup/backend pair, the Hostgroup Manager will keep in the connection pool up to mysql-free_connections_pct * mysql_servers.max_connections / 100 connections . Connections are kept open with periodic pings. A connection is idle if it hasn't been used since the last round of pings. The time interval between two such rounds of pings for idle connections is controlled by the variable mysql-ping_interval_server_msec.

System VariableNamemysql-free_connections_pct
DynamicYes
Permitted ValuesTypeInteger (percentage)
Default10
Minimum0
Maximum100

mysql-handle_unknown_charset

Allows to select between different behaviors on how ProxySQL should handle the situation of finding a charset in a client connection that *can't* be set for the backend connection as it's unknown for the server.

System VariableNamemysql-handle_unknown_charset
DynamicYes
Permitted ValuesTypeInteger
Default1
Valid Values0 : DISCONNECT_CLIENT: Disconnect client and log error message.
1 : REPLACE_WITH_DEFAULT_VERBOSE: Replace with default character set and log that target one couldn't be found.
2 : REPLACE_WITH_DEFAULT: Replace with default character set silently.

mysql-handle_warnings

When enabled, if a warning is generated for a query execution, multiplexing is temporarily disabled in the connection until a new query is received. If the new query happens to be SHOW WARNINGS or SHOW COUNT(*) FROM WARNINGS it will be executed in the same connection as the previous query, however, if any other query is executed, multiplexing is re-enabled.

System VariableNamemysql-handle_warnings
DynamicYes
Permitted ValuesTypeInteger
Default1

An analogous flag handle_warnings exists for mysql_hostgroup_attributes table, at column hostgroup_settings. This per-hostgroup flag holds priority over this global variable and will override it. For more information about this per-hostgroup flag please refer to mysql_hostgroup_attributes table. Important remarks about the feature:

mysql-have_compress

Currently unused.

mysql-have_ssl

System VariableNamemysql-have_ssl
DynamicYes
Permitted ValuesTypeBoolean
Defaulttrue (since v2.6.0)

Introduced in ProxySQL v2.0, it enables frontend SSL support (see SSL Support for more information). Previous to v2.6.0 was disabled by default for performance considerations, enabled by default since v2.6.0.

This variable is overridden when mysql-default_authentication_plugin is set to caching_sha2_password. See variable documentation for further details.

mysql-hostgroup_manager_verbose

Enable verbose logging of hostgroup manager details in ProxySQL logs (e.g. when running LOAD MYSQL SERVERS TO RUNTIME).

System VariableNamemysql-hostgroup_manager_verbose
DynamicYes
Permitted ValuesTypeInteger
Default1
Minimum0
Maximum2

mysql-init_connect

String containing one or more SQL statements, separated by semicolons, that will be executed by the ProxySQL for each backend connection when created or initialised e.g. SET WAIT_TIMEOUT=28800 (works similarly to MySQL's init_connect variable).

System VariableNamemysql-init_connect
DynamicYes
Permitted ValuesTypeString
Defaultempty string, not set
Valid ValuesString containing one or more SQL statements, separated by semicolons

mysql-interfaces

Semicolon-separated list of hostname:port entries for interfaces for incoming MySQL traffic. Note that this also supports UNIX domain sockets for the cases where the connection is done from an application on the same machine. Note that changing this value has no effect at runtime, if you need to change it you have to restart the proxy. After changing mysql-interfaces, you should not run LOAD MYSQL VARIABLES TO RUNTIME because this variable cannot be loaded at runtime. Attempt to load them at runtime will cause their reset. In other words, after changing mysql-interfaces, you need to run SAVE MYSQL VARIABLES TO DISK and then restart ProxySQL (for example using PROXYSQL RESTART).

System VariableNamemysql-interfaces
DynamicNo
Permitted ValuesTypeString
Default0.0.0.0:6033;/tmp/proxysql.sock
Valid ValuesIP / hostname with ':' seperated port and ';' separated socket filename

mysql-keep_multiplexing_variables

System VariableNamemysql-keep_multiplexing_variables
DynamicYes
Permitted ValuesTypeString
Defaulttrx_isolation,version
Valid Valuesany variables separated by commas

Defines a comma separated list of variables that do not cause multiplexing to be disabled if queried. For example, a query like SELECT @@version, by default would disable multiplexing. But because version is listed in mysql-keep_multiplexing_variables, multiplexing is not disabled.

mysql-max_stmts_cache

Set the total maximum number of statements that can be cached when using Prepared Statements.

System VariableNamemysql-max_stmts_cache
DynamicYes
Permitted ValuesTypeInteger
Default10000
Minimum1024
Maximum1048576

mysql-kill_backend_connection_when_disconnect

When enabled the backend connection for a client connection is killed when the client disconnects (introduced in ProxySQL v2.0).

System VariableNamemysql-kill_backend_connection_when_disconnect
DynamicYes
Permitted ValuesTypeBoolean
Defaulttrue

mysql-long_query_time

Threshold for counting queries passing through the proxy as 'slow'. The total number of slow queries can be found in the stats_mysql_global table, in the variable named Slow_queries (each row in that table represents one variable).

System VariableNamemysql-long_query_time
DynamicYes
Permitted ValuesTypeInteger (milliseconds)
Default1000
Minimum0
Maximum1728000000

mysql-max_allowed_packet

mysql-max_allowed_packet defines the maximum size of a single packet/command received by the client. It mimics the behavior of mysqld's max_allowed_packet

System VariableNamemysql-max_allowed_packet
DynamicYes
Permitted ValuesTypeInteger (bytes)
Default4194304 (4MB)
Minimum8192 (8KB)
Maximum1073741824 (1GB)

mysql-max_connections

The maximum number of client connections that the proxy can handle. After this number is reached, new connections will be rejected with the #HY000 error, and the error message Too many connections.

System VariableNamemysql-max_connections
DynamicYes
Permitted ValuesTypeInteger
Default2048
Minimum1
Maximum1000000

mysql-max_stmts_per_connection

The threshold for the number of statements that can be prepared on a backend connection before that connection is closed (prior to version 1.4.3) or reset (starting version 1.4.4). This is evaluated when a connection is returned to the connection pool.

System VariableNamemysql-max_stmts_per_connection
DynamicYes
Permitted ValuesTypeInteger
Default20
Minimum1
Maximum1024

mysql-max_transaction_idle_time

The maximum waiting time for a connection to have a transaction detected as idle before killing the client connection.

System VariableNamemysql-max_transaction_idle_time
DynamicYes
Permitted ValuesTypeInteger (milliseconds)
Default14400000 (4 hours)
Minimum
Maximum

mysql-max_transaction_time

Sessions with active transactions running more than this timeout are killed.

System VariableNamemysql-max_transaction_time
DynamicYes
Permitted ValuesTypeInteger (milliseconds)
Default14400000 (4 hours)
Minimum1000
Maximum1728000000

mysql-min_num_servers_lantency_awareness

Latency awareness is an algorithm used to send traffic only to the closest backends. IE: In case of slaves in multiple AZs, ProxySQL will send traffic only to the slaves on the same AZ. But to trigger this algorithm, a minimum number of servers is required. In case of 3 slaves in 3 AZs, and application/ProxySQL is in one AZ, you MAY not want to send almost all the traffic to only one slave.

System VariableNamemysql-min_num_servers_lantency_awarenes
DynamicYes
Permitted ValuesTypeInteger
Default1000

mysql-monitor_aws_rds_topology_discovery_interval

Controls the frequency of AWS RDS topology discovery checks for Multi-AZ DB Clusters. This variable determines how often ProxySQL queries the mysql.rds_topology table on AWS RDS endpoints to automatically discover and configure additional cluster members.

This feature is specifically designed for AWS RDS Multi-AZ DB Clusters with reader endpoints, allowing ProxySQL to automatically detect and add new cluster members to the configuration without manual intervention.

Topology Discovery Behavior:

When mysql-monitor_aws_rds_topology_discovery_interval = 0 (Disabled - Default):

  • No automatic topology discovery is performed
  • Only read-only status checks are conducted during monitoring
  • AWS RDS cluster members must be manually configured in mysql_servers
  • Minimal monitoring overhead for read-only checks

When mysql-monitor_aws_rds_topology_discovery_interval > 0 (Enabled):

  • Topology discovery runs every N monitoring cycles (where N = interval value)
  • Discovery only occurs for servers with rds.amazonaws.com hostnames
  • Queries mysql.rds_topology table to discover cluster topology
  • Automatically adds discovered cluster members to runtime_mysql_servers
  • Works in combination with regular read-only status monitoring

Discovery Process:

  1. Endpoint Detection: Identifies AWS RDS endpoints by hostname matching *.rds.amazonaws.com
  2. Topology Query: Executes SELECT @@global.read_only read_only, id, endpoint, port from mysql.rds_topology
  3. Cluster Analysis: Determines if the topology represents an AWS RDS Multi-AZ DB Cluster
  4. Auto-Configuration: Automatically adds discovered members to the runtime server configuration
  5. Integration: Works seamlessly with existing replication hostgroup configurations

Usage Scenarios:

Enable Discovery (>0) for:

  • AWS RDS Multi-AZ DB Cluster deployments
  • Dynamic cluster scaling scenarios
  • Automated failover and load balancing configurations
  • Environments with frequent cluster topology changes
  • Production deployments requiring high availability

Keep Disabled (0) for:

  • Non-AWS RDS deployments (MySQL on-premises, other cloud providers)
  • Static cluster configurations with fixed topology
  • Development or testing environments
  • Single-instance deployments
  • When manual server configuration is preferred

Configuration:

-- Disable topology discovery (default)
SET mysql-monitor_aws_rds_topology_discovery_interval = 0;
LOAD MYSQL VARIABLES TO RUNTIME;

-- Enable topology discovery every 100 monitoring cycles
SET mysql-monitor_aws_rds_topology_discovery_interval = 100;
LOAD MYSQL VARIABLES TO RUNTIME;

-- Frequent discovery for dynamic clusters
SET mysql-monitor_aws_rds_topology_discovery_interval = 10;
LOAD MYSQL VARIABLES TO RUNTIME;

Important Notes:

  • Only works with AWS RDS endpoints ending in rds.amazonaws.com
  • Discovery frequency is in monitoring cycles, not time units
  • Actual time between discoveries depends on monitor_read_only_interval
  • Requires monitor_enabled to be active for topology discovery to work
  • Automatically maintains server group assignments from original configuration

Performance Considerations:

  • Each discovery query adds minimal overhead to the monitoring cycle
  • Discovery frequency should be balanced against cluster change frequency
  • Too frequent discovery may generate unnecessary query load on RDS instances
  • Recommended interval: 100-1000 cycles for most production environments
System VariableNamemysql-monitor_aws_rds_topology_discovery_interval
DynamicYes
Permitted ValuesTypeInteger
Default0
Minimum0
Maximum100000

mysql-proxy_protocol_networks

Specifies which networks are allowed to send PROXY protocol headers to ProxySQL. This is a critical security variable that controls which client connections can include PROXY protocol information for preserving original client IP addresses through proxies and load balancers.

The PROXY protocol enables ProxySQL to extract real client connection information (IP address, port) from connections that pass through TCP proxies, load balancers, or other network intermediaries. This is essential for accurate logging, security policies, and compliance requirements.

Network List Format:

  • Empty string '': Disable PROXY protocol (default, most secure)
  • Asterisk '*': Accept PROXY headers from any network (least secure)
  • Comma-separated CIDR notation for IPv4 and IPv6 networks
  • Networks are evaluated in order; first match determines acceptance

PROXY Protocol Behavior:

When mysql-proxy_protocol_networks = '' (Disabled - Default):

  • PROXY protocol headers are ignored and treated as regular data
  • All client connections use the direct TCP connection information
  • Maximum security against PROXY header spoofing attacks
  • Load balancers must be configured without PROXY protocol

When mysql-proxy_protocol_networks = '*' (Accept All - Insecure):

  • Accept PROXY headers from any client network
  • Security Risk: Malicious clients can spoof client information
  • Only appropriate in trusted, isolated network environments
  • Not recommended for production deployments

When mysql-proxy_protocol_networks = 'specific_networks' (Recommended):

  • Accept PROXY headers only from specified network ranges
  • Networks defined in CIDR notation (IPv4/IPv6)
  • Prevents unauthorized clients from spoofing client information
  • Secure deployment behind trusted load balancers

Configuration Examples:

-- Disable PROXY protocol (default, most secure)
SET mysql-proxy_protocol_networks = '';
LOAD MYSQL VARIABLES TO RUNTIME;

-- Accept from any network (insecure - not recommended for production)
SET mysql-proxy_protocol_networks = '*';
LOAD MYSQL VARIABLES TO RUNTIME;

-- Accept from specific IPv4 load balancer networks
SET mysql-proxy_protocol_networks = '10.0.1.0/24,192.168.100.0/24,172.16.0.0/12';
LOAD MYSQL VARIABLES TO RUNTIME;

-- Accept from specific IPv6 networks
SET mysql-proxy_protocol_networks = '2001:db8::/32,fe80::/10';
LOAD MYSQL VARIABLES TO RUNTIME;

-- Mixed IPv4 and IPv6 networks
SET mysql-proxy_protocol_networks = '10.0.1.0/24,2001:db8::/32,192.168.1.0/24';
LOAD MYSQL VARIABLES TO RUNTIME;

Security Considerations:

  • Always specify trusted networks instead of using wildcards
  • Load balancer IP ranges should be as specific as possible
  • Regular monitoring of unexpected connection patterns
  • Network segmentation to protect against spoofed headers
  • Audit trails to verify PROXY header usage

Integration with Load Balancers:

HAProxy Configuration:

backend mysql_servers
mode tcp
server proxysql1 10.0.1.100:6033 check send-proxy

Required ProxySQL Configuration:

-- Accept only from HAProxy network
SET mysql-proxy_protocol_networks = '10.0.1.0/24';
LOAD MYSQL VARIABLES TO RUNTIME;

Information Preservation: When PROXY headers are processed, ProxySQL stores:

  • Original client IP address (replaces proxy IP in logs)
  • Original client port
  • Proxy IP address (for debugging)
  • Connection metadata (available in stats_mysql_processlist.extended_info when mysql-show_processlist_extended is enabled)

Usage Scenarios:

Enable PROXY Protocol for:

  • Deployments behind TCP load balancers (HAProxy, AWS NLB, etc.)
  • Multi-tier architectures with reverse proxies
  • Cloud load balancer deployments (DigitalOcean, AWS, GCP)
  • Requirements for accurate client IP logging
  • Security policies based on client location
  • Compliance requirements for client identification

Keep Disabled for:

  • Direct client connections without proxies
  • Untrusted network environments
  • Development or testing environments
  • When load balancers are configured without PROXY protocol

Debugging and Monitoring:

-- Check current PROXY protocol settings
SHOW VARIABLES LIKE 'proxy_protocol_networks';

-- Monitor connections with PROXY information
SELECT * FROM stats_mysql_connection_pool;

-- View detailed connection metadata in exports
-- PROXY information appears in JSON exports

Performance Impact:

  • Minimal processing overhead for PROXY header parsing
  • Small memory footprint for storing connection metadata
  • No impact on query performance or routing
  • Negligible latency increase (microseconds)

For comprehensive PROXY protocol documentation, see PROXY Protocol Support.

System VariableNamemysql-proxy_protocol_networks
DynamicYes
Permitted ValuesTypeString
Default'' (empty string, disabled)
Permitted ValuesCIDR notation networks, '*' or ''

mysql-mirror_max_concurrency

System VariableNamemysql-mirror_max_concurrency
DynamicYes
Permitted ValuesTypeInteger
Default16
Minimum1
Maximum8192

Limits the number of concurrent mirror sessions handled by a MySQL_Thread. The mirror sessions to be processed are extracted randomly from a processing queue until reaching this limit. The maximum size of this queue is determined by variable mysql-mirror_max_queue_length.

mysql-mirror_max_queue_length

System VariableNamemysql-mirror_max_queue_length
DynamicYes
Permitted ValuesTypeInteger
Default32000
Minimum0
Maximum1048576

Determines the maximum size for the mirror sessions processing queue. Mirror sessions are placed in this queue when a 'MySQL_Thread' is either already handling the allowed maximum of concurrent mirrors sessions, limited by mysql-mirror_max_concurrency, or the processing queue for the 'MySQL_Thread' already contains mirror sessions.

mysql-ping_interval_server_msec

The interval at which the proxy should ping backend connections in order to maintain them alive, even though there is no outgoing traffic. The purpose here is to keep some connections alive in order to reduce the latency of new queries towards a less frequently used destination backend server.

System VariableNamemysql-ping_interval_server_msec
DynamicYes
Permitted ValuesTypeInteger (milliseconds)
Default10000
Minimum1000
Maximum604800000

mysql-ping_timeout_server

The proxy internally pings the connections it has opened in order to keep them alive. This eliminates the cost of opening a new connection towards a hostgroup when a query needs to be routed, at the cost of additional memory footprint inside the proxy and some extra traffic. This is the timeout allowed for those pings to succeed.

System VariableNamemysql-ping_timeout_server
DynamicYes
Permitted ValuesTypeInteger (milliseconds)
Default200
Minimum10
Maximum600000

mysql-poll_timeout

The minimal timeout used by the proxy in order to detect incoming/outgoing traffic via the poll() system call. If the proxy determines that it should stick to a higher timeout because of its internal computations, it will use that one, but it will never use a value less than this one.

System VariableNamemysql-poll_timeout
DynamicYes
Permitted ValuesTypeInteger (milliseconds)
Default2000
Minimum10
Maximum20000

mysql-poll_timeout_on_failure

The timeout used in order to detect incoming/outgoing traffic after a connection error has occurred. The proxy automatically tweaks its timeout to a lower value in such an event in order to be able to quickly respond with a valid connection.

System VariableNamemysql-poll_timeout_on_failure
DynamicYes
Permitted ValuesTypeInteger (milliseconds)
Default100
Minimum10
Maximum20000

mysql-query_cache_handle_warnings

Determines how the query cache should interact with resultset from queries that have generated warnings. Depending on the value, if a query has produced a warning:

  • 0: The resultset will not be saved in the query cache.
  • 1: The resultset will be saved in the query cache, but its warning count will be reset to 0.
System VariableNamemysql-query_cache_handle_warnings
DynamicYes
Permitted ValuesTypeInteger
Default0
Minimum0
Maximum1

mysql-query_cache_size_MB

The total amount of memory used by the Query Cache, note: the current implementation of mysql-query_cache_size_MB doesn't impose a hard limit . Instead, it is used as an argument by the purging thread.

System VariableNamemysql-query_cache_size_MB
DynamicYes
Permitted ValuesTypeInteger (MB)
Default256
Minimum0
Maximum10485760

mysql-query_cache_soft_ttl_pct

System VariableNamemysql-query_cache_soft_ttl_pct
DynamicYes
Permitted ValuesTypeInteger (percentage)
Default0
Minimum0
Maximum100

If Query Cache entry reaches this soft-TTL, and havent yet reached the cache_ttl, the next query received wont hit the Query Cache entry, but the backend server, refreshing the entry resultset and TTL itself.

mysql-query_cache_stores_empty_result

The variable controls if resultset without rows will be cached or not (introduced in ProxySQL v2.0).

System VariableNamemysql-query_cache_stores_empty_result
DynamicYes
Permitted ValuesTypeBoolean
Defaulttrue

mysql-query_digests

When this variable is set to true, the proxy analyzes the queries passing through it and divides them into classes of queries having different values for the same parameters. It computes a couple of metrics for these classes of queries, all found in the stats_mysql_query_digest table. For more details, please refer to the admin tables documentation. It is also very important to note that query digest is required to determine when multiplexing needs to be disabled, for example in case of TEMPORARY tables, SQL_CALC_FOUND_ROWS , GET_LOCK, etc. Do not disable mysql-query_digests unless you are really sure it won't break your application.

System VariableNamemysql-query_digests
DynamicYes
Permitted ValuesTypeBoolean
Defaulttrue

mysql-query_digests_keep_comment

When set to 'true', comments of the kind '/* */' are not stripped from the query digest.

System VariableNamemysql-query_digests_keep_comment
DynamicYes
Permitted ValuesTypeBoolean
Defaultfalse

mysql-query_digests_lowercase

When this variable is set to true, query digest is automatically converted to lowercase otherwise when false, query digests are case sensitive.

System VariableNamemysql-query_digests_lowercase
DynamicYes
Permitted ValuesTypeBoolean
Defaultfalse

mysql-query_digests_max_digest_length

Defines the maximum length of digest_text as then reported in stats_mysql_query_digest. It's important to note that this variable doesn't affect the size of the digest_text generated when processing the query, and it's only relevant for determining the maximum length for stats_mysql_query_digest, for modifying the maximum size of the digest_text generated please refer to mysql-query_digests_max_query_length.

System VariableNamemysql-query_digests_max_digest_length
DynamicYes
Permitted ValuesTypeInteger
Default2048
Minimum16
Maximum (up to 1.3.1)65000
Maximum (from 1.3.2 onwards)1048576

mysql-query_digests_max_query_length

Defines the maximum size of the buffer being used when computing query's digest and digest_text. DETAILS: This variable effectively limits the size of the generated digest_text, but, it's important to note that this doesn't mean than a query larger than the size specified by this variable wont fit in the generated digest_text. This is due to the multiple compressions that are performed during the digest computation, e.g: 'numbers', 'strings', 'comments', etc... or even grouping of values, like the specified by 'mysql-query_digests_grouping_limit'. These compressions allows ProxySQL to be able to fit larger queries in smaller buffers for the generated digest_texts.

System VariableNamemysql-query_digests_max_query_length
DynamicYes
Permitted ValuesTypeInteger
Default65000
Minimum16
Maximum (up to 1.3.1)65000
Maximum (from 1.3.2 onwards)16777216

mysql-query_digests_grouping_limit

Introduced in v2.1.0. Defines the maximum number of replacements in a digest by the placeholder ?. Elements in a digest will be replaced by the placeholder ?, until reaching element number N, after which all the elements will be compressed into .... E.g: let the mysql-query_digests_grouping_limit=3 the following digest:

SELECT * FROM tablename WHERE id IN (1,2,3,4,5,6,7,8,9,10)

will be compressed into:

SELECT * FROM tablename WHERE id IN (?,?,?,...)
System VariableNamemysql-query_digests_grouping_limit
DynamicYes
Permitted ValuesTypeInteger
Default3
Minimum1
Maximum2089

mysql-query_digests_groups_grouping_limit

Introduced in v2.4.0. Defines the maximum number of consecutive compressed value groups present in a digest, group compression is performed via mysql-query_digests_grouping_limit. After this number is reached, the exceeding compressed value groups are replaced by .... E.g: with mysql-query_digests_groups_grouping_limit=1 and mysql-query_digests_groups_grouping_limit=2 the following digest:

INSERT INTO tablename (a,b,c) VALUES (1,2,3),(4,5,6,),(7,8,9),(9,8,9)

will be compressed into:

INSERT INTO tablename (a,b,c) VALUES (?,...),(?,...),...
System VariableNamemysql-query_digests_groups_grouping_limit
DynamicYes
Permitted ValuesTypeInteger
Default0
Minimum0
Maximum2089

mysql-query_digests_no_digits

When active ProxySQL will replace all numbers in the query to '?' signs for generating digest. This functionality can be controlled by configuring the value of mysql-query_digests_no_digits.

System VariableNamemysql-query_digests_no_digits
DynamicYes
Permitted ValuesTypeBoolean
Defaultfalse

mysql-query_digests_normalize_digest_text

When set to FALSE (default), ProxySQL will cache the SQL digest and related information in the table stats.stats_mysql_query_digest by schema. When this variable is TRUE, queries statistics store digest_text on a different internal hash table. In this way ProxySQL will be able to normalize data, digest_text is internally stored elsewhere, and it deduplicates data. When you query stats_mysql_query_digest, the data is merged together. This drastically reduces memory usage on setups with many schemas but similar queries patterns.

System VariableNamemysql-query_digests_normalize_digest_text
DynamicYes
Permitted ValuesTypeBoolean
Defaultfalse

mysql-query_digests_replace_null

When TRUE, ProxySQL will replace NULLs when creating the Query digest with '?'. This approach will normalize statements like the following:

SQL                                       Digest
INSERT INTO tablename(id) VALUES (1); INSERT INTO tablename(id) VALUES (?);
INSERT INTO tablename(id) VALUES (NULL); INSERT INTO tablename(id) VALUES (?);
CALL spa(NULL, null, NULL, null); CALL spa(?, ?, ?, ?);
CALL spa(1, null, NULL, 4); CALL spa(?, ?, ?, ?);
CALL spa(1, 2, 3, 4); CALL spa(?, ?, ?, ?);
System VariableNamemysql-query_digests_replace_null
DynamicYes
Permitted ValuesTypeBoolean
Defaultfalse

mysql-query_digests_track_hostname

If active it reports the original client address in the table stats_mysql_query_digest See also stats_mysql_query_digest

System VariableNamemysql-query_digests_track_hostname
DynamicYes
Permitted ValuesTypeBoolean
Defaultfalse

mysql-query_processor_iterations

If mysql_query_rules.flagOUT is set and mysql-query_processor_iterations is greater than 0, a matching rule will set flagIN and starts processing rules from the beginning up to mysql-query_processor_iterations iterations. Therefore, mysql-query_processor_iterations allows to jump back to previous mysql_query_rules.

System VariableNamemysql-query_processor_iterations
DynamicYes
Permitted ValuesTypeInteger
Default0
Minimum0
Maximum1000000

mysql-query_processor_regex

This variable defines which regex engine to use:

Before version v1.4.0, only RE2 was available, CASELESS was always enabled, and GLOBAL was always disabled. Starting from v1.4.0, both PCRE and RE2 are available. Now both PCRE and RE2 support CASELESS and GLOBAL using re_modifiers. Although, RE2 doesn't support both CASELESS and GLOBAL at the same time if they are both configured in re_modifiers. For this reason, the default regex engine was changed to PCRE.

System VariableNamemysql-query_processor_regex
DynamicYes
Permitted ValuesTypeInteger
DefaultPCRE1
Valid ValuesPCRE1
RE22

mysql-data_packets_history_size

Controls the size of data packet history buffers maintained by ProxySQL for troubleshooting network communication issues. This feature stores incoming and outgoing MySQL packets in circular buffers to help debug complex protocol problems.

This variable was introduced in v2.5.3 as a troubleshooting feature to capture and analyze raw MySQL protocol traffic between clients and servers through ProxySQL.

Packet History Behavior:

When mysql-data_packets_history_size = 0 (Disabled - Default):

  • No packet history is maintained
  • Minimal memory overhead
  • Normal ProxySQL operation without debugging capabilities
  • Packets are processed and discarded immediately after use

When mysql-data_packets_history_size > 0 (Enabled):

  • Maintains two circular buffers: data_packets_history_IN and data_packets_history_OUT
  • IN buffer stores packets received from clients (queries, commands)
  • OUT buffer stores packets sent to clients (resultsets, responses, errors)
  • Each buffer stores up to the specified number of packets
  • When buffer is full, oldest packets are overwritten (FIFO behavior)

Usage Scenarios:

Enable Packet History (>0) for:

  • Debugging protocol-level communication issues
  • Analyzing malformed packets or protocol violations
  • Troubleshooting connection drops or timeouts
  • Investigating data corruption during transmission
  • Development and testing of MySQL client compatibility

Keep Disabled (0) for:

  • Production environments with normal operation
  • Memory-constrained deployments
  • When packet-level debugging is not needed

Configuration:

-- Disable packet history (default, production recommended)
SET mysql-data_packets_history_size = 0;
LOAD MYSQL VARIABLES TO RUNTIME;

-- Enable with 1000 packets buffer for debugging
SET mysql-data_packets_history_size = 1000;
LOAD MYSQL VARIABLES TO RUNTIME;

-- Large buffer for extensive troubleshooting
SET mysql-data_packets_history_size = 10000;
LOAD MYSQL VARIABLES TO RUNTIME;

Memory Impact:

  • Memory usage varies significantly between IN and OUT buffers
  • IN packets are typically small (queries, commands)
  • OUT packets can be large (resultsets, bulk data transfers)
  • Memory = (history_size × average_IN_packet_size) + (history_size × average_OUT_packet_size)
  • Each packet requires additional overhead for storage metadata
  • Memory is allocated dynamically as packets are processed
  • Consider your specific query patterns and resultset sizes when determining buffer size

Note: This is primarily a debugging feature. The packet history data is primarily accessible through core dump analysis or specialized debugging tools, not through standard ProxySQL administrative interfaces.

System VariableNamemysql-data_packets_history_size
DynamicYes
Permitted ValuesTypeInteger
Default0
Minimum0
Maximum2147483647

mysql-parse_failure_logs_digest

Controls whether ProxySQL logs query digests or full query text when parsing failures occur. This variable determines what information is included in error logs and warning messages when ProxySQL encounters queries it cannot parse.

When parsing fails, ProxySQL generates error code 10002 with the message "Unable to parse query. If correct, report it as a bug". This setting controls whether the query text shown in this message is the full original query or a computed digest.

Logging Behavior:

When mysql-parse_failure_logs_digest = true (Log Digest):

  • Logs the computed query digest instead of full query text
  • Query digests are normalized, simplified representations of the query
  • Hides sensitive data like literal values, user-specific information
  • Consistent logging format for similar queries
  • Useful for identifying query patterns in parsing failures

When mysql-parse_failure_logs_digest = false (Log Full Query - Default):

  • Logs the complete original query text as received
  • Shows exact query that caused the parsing failure
  • Includes all literal values, comments, and formatting
  • Useful for debugging specific query issues
  • May expose sensitive information in logs

Usage Scenarios:

Enable Digest Logging (true) for:

  • Production environments where query privacy is important
  • Log analysis to identify patterns in parsing failures
  • Reducing log volume and storage requirements
  • Avoiding exposure of sensitive data in error logs

Enable Full Query Logging (false) for:

  • Development and debugging environments
  • Troubleshooting specific parsing issues
  • Bug reports to ProxySQL developers
  • Understanding exact query syntax causing failures

Configuration:

-- Log query digests for privacy (production recommended)
SET mysql-parse_failure_logs_digest = true;
LOAD MYSQL VARIABLES TO RUNTIME;

-- Log full queries for debugging (default)
SET mysql-parse_failure_logs_digest = false;
LOAD MYSQL VARIABLES TO RUNTIME;

Security Considerations:

  • Full query logging may expose sensitive data (passwords, personal information)
  • Query digests normalize literals, providing better privacy
  • Consider compliance requirements (GDPR, PCI-DSS) when choosing setting
  • Digest logs are sufficient for identifying query patterns without exposing data
System VariableNamemysql-parse_failure_logs_digest
DynamicYes
Permitted ValuesTypeBoolean
Defaultfalse

mysql-query_rules_fast_routing_algorithm

Controls how ProxySQL manages fast routing rule hashmaps across multiple threads. Fast routing rules are special query rules that provide high-performance routing decisions without the overhead of full rule processing.

This variable determines the memory allocation strategy for fast routing rule hashmaps, balancing memory usage against concurrent access performance.

Algorithm Behavior:

When mysql-query_rules_fast_routing_algorithm = 1 (Per-Thread Hashmaps - Default):

  • Creates separate hashmaps for each processing thread
  • Each thread has its own copy of fast routing rules
  • Higher memory usage but eliminates thread contention
  • Optimal for high-concurrency environments
  • Uses additional memory: rules_size × num_threads × memory_overhead

When mysql-query_rules_fast_routing_algorithm = 2 (Global Shared Hashmaps):

  • Uses single shared hashmap across all threads
  • All threads access the same fast routing rule data
  • Lower memory usage but potential contention under heavy load
  • Optimal for memory-constrained environments or lower concurrency
  • Uses baseline memory only: rules_size × memory_overhead

Configuration:

-- Use per-thread hashmaps (default, better for high concurrency)
SET mysql-query_rules_fast_routing_algorithm = 1;
LOAD MYSQL VARIABLES TO RUNTIME;

-- Use shared hashmaps (lower memory usage)
SET mysql-query_rules_fast_routing_algorithm = 2;
LOAD MYSQL VARIABLES TO RUNTIME;

Performance Considerations:

  • Algorithm 1 is recommended for production environments with high concurrent query volumes
  • Algorithm 2 is suitable for development, testing, or memory-constrained deployments
  • Memory usage difference can be significant with many fast routing rules and multiple threads
  • Performance impact is most noticeable under heavy concurrent load
System VariableNamemysql-query_rules_fast_routing_algorithm
DynamicYes
Permitted ValuesTypeInteger
Default1
Minimum1
Maximum2

mysql-processlist_max_query_length

Controls the maximum length of query text displayed in the SHOW PROCESSLIST output and stats_mysql_processlist table. This variable limits how much of the query string is stored and displayed for monitoring and debugging purposes.

When a query exceeds this length, it will be truncated to fit within the specified limit. This helps control memory usage while still providing useful diagnostic information.

Query Length Behavior:

  • Queries shorter than the limit are stored and displayed in full
  • Queries longer than the limit are truncated to the maximum specified length
  • The truncation happens when the query is recorded in the processlist
  • Both regular queries and prepared statement text are subject to this limit

Usage Context: This variable affects the following monitoring interfaces:

  • SHOW PROCESSLIST command execution
  • stats_mysql_processlist table content
  • Processlist information returned to monitoring tools

Configuration:

-- Set to 1MB (default)
SET mysql-processlist_max_query_length = 1048576;
LOAD MYSQL VARIABLES TO RUNTIME;

-- Increase to 4MB for better debugging with long queries
SET mysql-processlist_max_query_length = 4194304;
LOAD MYSQL VARIABLES TO RUNTIME;

-- Set to minimum (1KB) to save memory
SET mysql-processlist_max_query_length = 1024;
LOAD MYSQL VARIABLES TO RUNTIME;

Memory Considerations:

  • Memory is allocated dynamically based on actual query lengths, not pre-allocated per connection
  • Most queries use minimal memory regardless of this setting
  • Memory spikes occur only for unusually long queries that exceed normal limits
  • Consider the likelihood of very long queries in your workload when setting this value
  • Balance debugging visibility for anomaly queries against potential memory usage during rare events
System VariableNamemysql-processlist_max_query_length
DynamicYes
Permitted ValuesTypeInteger
Default2097152
Minimum1024
Maximum33554432

mysql-query_retries_on_failure

System VariableNamemysql-query_retries_on_failure
DynamicYes
Permitted ValuesTypeInteger
Default1
Minimum0
Maximum1000

In case of failures while running a query, the same can be retried mysql-query_retries_on_failure times. This variable is related with mysql-threshold_resultset_size, since this setting doesn't take effect for queries whose resultsets have started to be streamed to the fronted connection, in that stage, a failed query is not retried.

mysql-reset_connection_algorithm

When reset_connection_algorithm = 2, MySQL_Thread itself tries to reset connections instead of relying on connections purger HGCU_thread_run() (introduced in ProxySQL v2.0), reset_connection_algorithm can be set to:

  • 1 = legacy algorithm used in ProxySQL v1.x
  • 2 = algorithm new since ProxySQL v2.0 (new default)
System VariableNamemysql-reset_connection_algorithm
DynamicYes
Permitted ValuesTypeInteger
Default2
Minimum1
Maximum2

mysql-server_capabilities

The bitmask of MySQL capabilities (encoded as bits) with which the proxy will respond to clients connecting to it. This is useful in order to prevent certain features from being used, although it is planned to be deprecated in the future. The default capabilities are:

server_capabilities = CLIENT_FOUND_ROWS | CLIENT_PROTOCOL_41 | CLIENT_IGNORE_SIGPIPE | CLIENT_TRANSACTIONS | CLIENT_SECURE_CONNECTION | CLIENT_CONNECT_WITH_DB | CLIENT_SSL;

More details about server capabilities in the official documentation.

System VariableNamemysql-server_capabilities
DynamicYes
Permitted ValuesTypeInteger
Default47626
Minimum10
Maximum65535

mysql-server_version

The server version with which the proxy will respond to the clients. Note that regardless of the versions of the backend servers, the proxy will respond with this.

System VariableNamemysql-server_version
DynamicYes
Permitted ValuesTypeString
Default5.5.30

mysql-servers_stats

Currently unused. Will be removed in a future version.

System VariableNamemysql-servers_stats
DynamicYes
Permitted ValuesTypeBoolean
Defaulttrue

mysql-session_debug

DEPRECATED

System VariableNamemysql-session_debug
DynamicYes
Permitted ValuesTypeBoolean
Defaulttrue

mysql-session_idle_ms

Starting from v1.3.0 , each MySQL_Thread has an auxiliary thread that is responsible to handle idle sessions (client connections). mysql-session_idle_ms defines when a session is idle and is passed from the main thread to the auxiliary thread.

System VariableNamemysql-session_idle_ms
DynamicYes
Permitted ValuesTypeInteger (milliseconds)
Default1
Minimum1
Maximum3600000

mysql-session_idle_show_processlist

mysql-session_idle_show_processlist defines if an idle session (as defined by mysql-session_idle_ms) should be listed in SHOW PROCESSLIST (or in general, in stats_mysql_processlist table). For performance reasons, idle sessions are not listed by default.

System VariableNamemysql-session_idle_show_processlist
DynamicYes
Permitted ValuesTypeBoolean
Defaultfalse

mysql-sessions_sort

Sessions are conversations between a MySQL client and a backend server in the proxy. Sessions are generally processed in a stable order but in certain scenarios (like using a transaction workload, which makes sessions bind to certain MySQL connections from the pool), processing them in the same order leads to starvation. This variable controls whether sessions should be processed in the order of waiting time, in order to have a more balanced distribution of traffic among sessions.

System VariableNamemysql-sessions_sort
DynamicYes
Permitted ValuesTypeBoolean
Defaulttrue

mysql-set_parser_algorithm

Controls which parsing algorithm ProxySQL uses to process MySQL SET statements for session variable tracking. This variable determines how ProxySQL parses and handles client SET commands.

ProxySQL supports two parsing algorithms for handling SET statements:

  • Value 1: Legacy parser algorithm using a simple hardcoded regular expression pattern
  • Value 2: Enhanced parser algorithm using a dynamically generated comprehensive pattern (default)

Algorithm Comparison:

Legacy Algorithm (1):

  • Uses a simple hardcoded regex pattern
  • Compiles regex fresh for each parse
  • Fast for simple statements
  • May fail on complex SET statements with function calls or nested expressions

Enhanced Algorithm (2):

  • Uses dynamically generated regex pattern built at runtime
  • Pre-compiles regex pattern per thread for better performance
  • Handles complex SET statements including:
    • Function calls: REPLACE(), IFNULL(), CONCAT(), etc.
    • Nested function calls
    • Various quoting styles and escape sequences
    • Session variables (@@variablename, @variablename)
    • Multi-word values with commas and parentheses
  • Better compatibility with modern MySQL SET statement syntax

Use Cases:

Both algorithms handle simple statements like:

SET character_set_client='utf8mb4';
SET names latin1;
SET sql_mode='STRICT_TRANS_TABLES';
SET @@session.tx_isolation='READ-COMMITTED';

However, Algorithm 2 is required for complex statements like:

SET sql_mode=(SELECT CONCAT(@@sql_mode, ',PIPES_AS_CONCAT'));
SET sql_mode=REPLACE(@@sql_mode, 'STRICT_TRANS_TABLES', '');
SET session_track_gtids=OWN_GTID;

Migration Note: The default changed from 1 to 2 in ProxySQL 2.6.0. Most users should use the default value (2) unless experiencing specific compatibility issues with complex SET statements.

System VariableNamemysql-set_parser_algorithm
DynamicYes
Permitted ValuesTypeInteger
Default2
Min Value1
Max Value2

mysql-set_query_lock_on_hostgroup

ProxySQL tries to track all the session variables configured by the client using SET statements. If the tracking of session variables is successful, ProxySQL is able to configure the same session variables on all the backend connections that will run queries by that specific client. ProxySQL is unable to track variables in the following conditions:

  • multi-statements commands. Example: SET variable=value; SELECT ...
  • user defined variables (all)
  • session variables not tracked by ProxySQL

mysql-set_query_lock_on_hostgroup determines the behavior of ProxySQL if unable to parse a SET statement, or to track all of its variables.

  • 1: (default since version 2.0.6) both multiplexing and query routing is disabled. The client will remain bound to a single backend connection. ProxySQL does it for safety purposes, making the connection to ProxySQL works exactly the same as it was connected direct to MySQL, so it avoids many unexpected behaviors. In other words, any SET statement that ProxySQL doesn't understand or is unable to parse, it will disable multiplexing and routing. It is important to remember that routing is disabled: if a query rule tries to route traffic to a hostgroup different than the hostgroup where the client is locked into, an error will arise.
  • 0: this is the legacy behavior, and generally less safe. Because multiplexing and routing are not disabled, this creates a problem if a future query relies on a previously set variable. In fact, the variable is unlikely to be present in the backend connection because multiplexing and routing were enabled but ProxySQL was not able to track the needed variable

Note: this variable only disables query routing and multiplexing. This means that the queries' destination hostgroup will be fixed to the current session hostgroup. No other features of ProxySQL are impacted.

System VariableNamemysql-set_query_lock_on_hostgroup
DynamicYes
Permitted ValuesTypeBoolean
Defaulttrue

mysql-show_processlist_extended

Configured to 1 or 2, ProxySQL will show extended information in JSON format about the processes running. Information will be available in stats_mysql_processlist.extended_info . With value 2 the JSON output will be indented.

System VariableNamemysql-show_processlist_extended
DynamicYes
Permitted ValuesTypeInteger
Default0
Minimum0
Maximum2

mysql-shun_on_failures

The number of connection errors tolerated to the same server within an interval of 1 second until it is automatically shunned temporarily. For now, this cannot be disabled by setting it to a special value, so if you want to do that, you can increase it to a very large value.

System VariableNamemysql-shun_on_failures
DynamicYes
Permitted ValuesTypeInteger
Default5
Minimum0
Maximum10000000

mysql-shun_recovery_time_sec

A backend server that has been automatically shunned will be recovered after at least this amount of time. ProxySQL will not retry to use such a server again until at least the amount of time specified has passed. Note that a server will only be recognized as ONLINE again by ProxySQL if it starts handling client traffic: when a server is ONLINE, it is considered to be absolutely healthy - something that a connection check (via ping) alone cannot determine. However, once the amount of time specified has passed, the server will be automatically recognized as ONLINE again right before it starts serving at least one client connection. Self tuning:

  • mysql-shun_recovery_time_sec should always be less than mysql-connect_timeout_server_max/1000, in order to prevent that a server is taken out for so long that an error is returned to the client. If mysql-shun_recovery_time_sec > mysql-connect_timeout_server_max/1000, the smaller of the two is used. (See #530)
  • if only one server is present in a hostgroup and mysql-shun_recovery_time_sec > 1, the server is automatically brought back online after 1 second
System VariableNamemysql-shun_recovery_time_sec
DynamicYes
Permitted ValuesTypeInteger (seconds)
Default10
Minimum0
Maximum31536000

mysql-ssl_p2s_ca

SSL CA to be used for backend connections.

System VariableNamemysql-ssl_p2s_ca
DynamicYes
Permitted ValuesTypeString
Default

mysql-ssl_p2s_capath

Defines a path to a directory containing the PEM files that holds one x509 certificate for a Certificate Authority (CA) to use for backend connections.

System VariableNamemysql-ssl_p2s_capath
DynamicYes
Permitted ValuesTypeString
Default

mysql-ssl_p2s_cert

SSL Certificate to be used for backend connections.

System VariableNamemysql-ssl_p2s_cert
DynamicYes
Permitted ValuesTypeString
Default

mysql-ssl_p2s_cipher

SSL Cipher to be used for backend connections (MySQL CIPHER list can be found here).

System VariableNamemysql-ssl_p2s_cipher
DynamicYes
Permitted ValuesTypeString
Default

mysql-ssl_p2s_key

SSL Key to be used for backend connections.

System VariableNamemysql-ssl_p2s_key
DynamicYes
Permitted ValuesTypeString
Default

mysql-ssl_p2s_crl

Path to a PEM file that should contain one or more revoked X509 certificates for backend connections.

System VariableNamemysql-ssl_p2s_crl
DynamicYes
Permitted ValuesTypeString
Default

mysql-ssl_p2s_crlpath

Defines a path to a directory containing the PEM files that holds one x509 certificate revoked for backend connections.

System VariableNamemysql-ssl_p2s_crlpath
DynamicYes
Permitted ValuesTypeString
Default

mysql-stacksize

The stack size to be used with the background threads that the proxy uses to handle MySQL traffic and connect to the backends. Note that changing this value has no effect at runtime, if you need to change it you have to restart the proxy.

System VariableNamemysql-stacksize
DynamicYes
Permitted ValuesTypeInteger (bytes)
Default1048576
Minimum262144
Maximum4194304

mysql-stats_time_backend_query

Enables / disables collection of backend query CPU time statistics.

System VariableNamemysql-stats_time_backend_query
DynamicYes
Permitted ValuesTypeBoolean
Default (up to 1.4.3)true
Default (from 1.4.4 onwards)false

mysql-stats_time_query_processor

Enables / disables collection of query processor CPU time statistics.

System VariableNamemysql-stats_time_query_processor
DynamicYes
Permitted ValuesTypeBoolean
Default (up to 1.4.3)true
Default (from 1.4.4 onwards)false

mysql-tcp_keepalive_time

When mysql-use_tcp_keepalive is active, ProxySQL will start sending KeepAlive to the destination after the connection has been idle for tcp_keepalive_time seconds

System VariableNamemysql-tcp_keepalive_time
DynamicYes
Permitted ValuesTypeInteger (seconds)
Default0

mysql-fast_forward_grace_close_ms

Configures the grace period timeout in milliseconds for fast forward mode session closure. When a backend connection closes unexpectedly during fast forward mode, this variable controls how long ProxySQL will wait to allow pending client output buffers to drain before forcibly closing the session.

This prevents data loss that can occur when clients are still receiving query results but the backend connection terminates abruptly.

System VariableNamemysql-fast_forward_grace_close_ms
DynamicYes
Permitted ValuesTypeInteger
Default5000
Min Value0
Max Value3600000

mysql-use_tcp_keepalive

When active ProxySQL will send KeepAlive signal during the client open session.

System VariableNamemysql-use_tcp_keepalive
DynamicYes
Permitted ValuesTypeBoolean
Defaultfalse

mysql-unshun_algorithm

Introduced in v2.4.0. Allows to specify the behavior for how servers that have been automatically shunned should be unshunned. This variable relates to mysql-shun_recovery_time_sec. Current values are:

  • 0 = default behavior, only servers from hostgroup handling traffic are unshunned.
  • 1 = when a server is unshunned in one particular hostgroup, it's also unshunned in all the other hostgroups.
System VariableNamemysql-unshun_algorithm
DynamicYes
Permitted ValuesTypeInteger
Default0
Minimum0
Maximum1

mysql-threads

The number of background threads that ProxySQL uses in order to process MySQL traffic. Note that there are other "administrative" threads on top of these, such as:

  • the admin interface thread
  • the monitoring module threads that interact with the backend servers (one for monitoring connectivity, one for pinging the servers and one for monitoring the replication lag)
  • occasional temporary threads created in order to kill long running queries that have become unresponsive
  • background threads used by the libmariadbclient library in order to make certain interactions with MySQL servers async

Note that changing this value has no effect at runtime, if you need to change it you have to restart the proxy. After changing mysql-threads, you should not run LOAD MYSQL VARIABLES TO RUNTIME because this variable cannot be loaded at runtime. Attempt to load them at runtime will cause their reset. In other words, after changing mysql-threads, you need to run SAVE MYSQL VARIABLES TO DISK and then restart ProxySQL (for example using PROXYSQL RESTART).

System VariableNamemysql-threads
DynamicNo
Permitted ValuesTypeInteger
Default4
Minimum1
Maximum255

mysql-threshold_query_length

The maximal size of an incoming SQL query to the proxy that will mark the background MySQL connection as non-reusable. This will force the proxy to open a new connection to the backend server, in order to make sure that the memory footprint of the server stays within reasonable limits. More details about it here: https://dev.mysql.com/doc/refman/5.6/en/memory-use.html Relevant quote from the mysqld documentation: "The connection buffer and result buffer each begin with a size equal to net_buffer_length bytes, but are dynamically enlarged up to max_allowed_packet bytes as needed. The result buffer shrinks to net_buffer_length bytes after each SQL statement."

System VariableNamemysql-threshold_query_length
DynamicYes
Permitted ValuesTypeInteger (bytes)
Default524288
Minimum1024
Maximum1073741824

mysql-threshold_resultset_size

System VariableNamemysql-threshold_resultset_size
DynamicYes
Permitted ValuesTypeInteger (bytes)
Default4194304 (4MB)
Minimum1024
Maximum1073741824

Default value: 4194304 (bytes, the equivalent of 4 MB).

If a resultset returned by a backend server is bigger than this, ProxySQL will start sending the result to the MySQL client that was requesting the result in order to limit its memory footprint.

This threshold is also used to throttle data reading from backend connections. If this threshold is exceeded 8 times during resultset reading in a backend connection, resultset reading will be temporarily paused. Pausing will continue until the buffered data by the session is less than 4 times this threshold. When this buffered data (to be sent to the client) goes below the previously mentioned threshold (4 times this threshold), resultset reading from the session backend connection will be resumed.

Considerations:

  • Query Cache wont take effect for any resultsets that exceed this value. Since the resultset is never fully retain, but streamed to the client it's not possible to store it in the cache.
  • mysql-query_retries_on_failure wont take effect for resultsets that exceed this value. Query retrying is disabled for resultsets that have already started streaming to the frontend connection. Setting the value of this setting too low is not recommended for this reason.

mysql-throttle_connections_per_sec_to_hostgroup

System VariableNamemysql-throttle_connections_per_sec_to_hostgroup
DynamicYes
Permitted ValuesTypeInteger
Default1000000

This variable limits the number of new connections per hostgroup, and not per specific node, for its per-hostgroup counterpart see throttle_connections_per_sec field in mysql_hostgroup_attributes. For example, if mysql-throttle_connections_per_sec_to_hostgroup is set to 100, no more than 100 new connections can be created on any hostgroup no matter the number of servers in that hostgroup. The default is very high (1000000) thus not changing default behaviour. Tuning this variable allows to control and throttle connections spikes to the backend servers. This variable is also related with the status variable Server_Connections_delayed, which is a counter on how many times the Hostgroups Manager didn't return a connection because the limit was reached. It is worth to note that a single client request could make multiple requests, therefore this variable counts the number of times a new connection wasn't created and not how many requests were delayed.

Whenever this limit is exceeded in a hostgroup, the client connection will wait at most mysql-connect_timeout_server_max. Passed that threshold the client connection will be disconnected if it wasn't able to obtain a connection.

mysql-throttle_max_bytes_per_second_to_client

System VariableNamemysql-throttle_max_bytes_per_second_to_client
DynamicYes
Permitted ValuesTypeInteger
Default0

Imposes a threshold with the maximum number of bytes that can be sent to a client, per second. The sending of the remaining bytes will be resumed the next second. When imposing a maximum number of bytes to send to the client is interesting to also impose a ratio of the memory being read from backend connections, see mysql-throttle_ratio_server_to_client.

mysql-throttle_ratio_server_to_client

System VariableNamemysql-throttle_ratio_server_to_client
DynamicYes
Permitted ValuesTypeInteger
Default0

Important: Takes effect only when enabled together with variable mysql-throttle_max_bytes_per_second_to_client, otherwise this variable has no effect.

Imposes a throttling ratio in the number of bytes that ProxySQL reads at once from backend connections. This offers a way to control the amount of memory that ProxySQL retains when throttling is imposed for client connections, allowing to prevent spikes in memory usage. This ratio is determined by the following expression:

processed_bytes > (throttle_max_bytes_per_second_to_client/(10 * throttle_ratio_server_to_client))

Whenever the number of bytes found while reading from a resultset in a backend connection exceeds the imposed ratio, further processing of the async store operation will be pause until newer sockets events or poll timeout, see mysql-poll_timeout. When imposing a throttle_ratio_server_to_client of 1, this ratio would be 1/10 of throttle_max_bytes_per_second_to_client.

mysql-verbose_query_error

When active ProxySQL will print additional information in case of error like: user, schema,digest_text, address, port.

System VariableNamemysql-verbose_query_error
DynamicYes
Permitted ValuesTypeBoolean
Defaultfalse

mysql-wait_timeout

If a proxy session (which is a conversation between a MySQL client and a ProxySQL) has been idle for more than this threshold, the proxy will kill the session.

System VariableNamemysql-wait_timeout
DynamicYes
Permitted ValuesTypeInteger (milliseconds)
Default28800000 (8 hours)
Minimum0
Maximum1728000000

Apply your changes: Remember to use the appropriate LOAD and SAVE commands to activate and persist your configuration. See the complete Admin Commands reference.