How ProxySQL 3.0.8 improves MySQL session-variable tracking

ProxySQL’s connection multiplexing depends on knowing which session variables a client has changed. When the picture is accurate, ProxySQL safely replays state across backend connections. For years, ProxySQL has built that picture by parsing SET statements that flow through the proxy. This model works well for explicit commands — but it has some blind spots. ProxySQL 3.0.8 closes them by using MySQL’s native session-state notifications.

What ProxySQL tracked before

The parser-based workflow is straightforward:

1. The client issues a SET statement.
2. ProxySQL parses the statement and updates its internal session-variable map.
3. If the session later moves to another backend connection, ProxySQL replays the tracked state there.

This is still a strong foundation, and it remains the default behavior in ProxySQL 3.0.8. The gap is that parser-based tracking only sees session changes that arrive on the wire as a parseable SET. Two important cases slip through this model:

1. Variables changed inside stored procedures, functions, or triggers. The client sends a CALL, but the SET happens entirely server-side, with no statement for ProxySQL to parse.

CREATE PROCEDURE switch_tz()
BEGIN
  SET SESSION time_zone = '+09:00';
END;

CALL switch_tz();   -- ProxySQL sees CALL, not the SET inside

2. SET statements with dynamic right-hand sides. ProxySQL sees the SET on the wire but cannot evaluate the right-hand side, because the value is resolved on the backend.

SET @@sort_buffer_size = some_function();
SET @@time_zone        = @user_default_tz;
SET @@max_join_size    = (SELECT max_rows FROM tenant_limits WHERE id = ?);

What changed in 3.0.8

ProxySQL 3.0.8 adds a second tracking signal that complements the parser: MySQL’s native session-state tracking protocol. When mysql-session_track_variables is enabled, backends report session-variable changes back to ProxySQL through the OK packets that are sent after every query. ProxySQL reads those notifications and updates its internal session map with the values the backend actually has. This is the same map the parser writes to, so both signals fuse into a single view of session state.

Result: variables changed inside CALLs and values computed from functions, subqueries, or other variables are picked up from the backend’s report and replayed on the next backend. This helps procedure-heavy applications as well as ORMs and frameworks that use dynamic SET values.

Configuring the feature

The behavior is controlled by a single global variable, mysql-session_track_variables, which supports three modes:

Mode	Value	Behavior
DISABLED	0	Default. Parser-only tracking, no protocol change.
OPTIONAL	1	Native tracking is enabled on backends that support it (MySQL 5.7+). Older backends keep working with parser-only tracking.
ENFORCED	2	Native tracking is required. Backends that don’t support it are excluded from server selection.

Which mode should I use?

• Mixed fleets (some MySQL 5.6 or MariaDB 10.x backends): use OPTIONAL. ProxySQL turns on native tracking where supported and leaves the rest alone.
• Homogeneous MySQL 5.7+ or MariaDB 11.x fleets: use ENFORCED for the strictest guarantee. Note that any non-supporting backend will be excluded from server selection during multiplexing.

Enabling the feature uses the standard ProxySQL admin workflow:

SET mysql-session_track_variables=1;     -- 1 = OPTIONAL, 2 = ENFORCED
LOAD MYSQL VARIABLES TO RUNTIME;
SAVE MYSQL VARIABLES TO DISK;

There is nothing to configure on the MySQL side — ProxySQL takes care of the backend protocol negotiation. The default stays DISABLED, so existing deployments upgrade to 3.0.8 without any behavior change until you opt in.

Bottom line

One of ProxySQL’s biggest strengths is safe connection reuse, but that only works when session state stays consistent across backend swaps. This release improves that precision by surfacing the variable changes the SET parser can’t see — an important step forward for applications that need both aggressive connection reuse and strong confidence in session correctness.

For the full configuration reference, see the MySQL variables documentation. For how this affects backend reuse, see the Multiplexing docs.