fix(mysql): improve compatibility with ProxySQL

[neoeinstein]

Joins the MySQL connection setup statements into a single statement to prevent issues with ProxySQL, which requires special handling of connections that might be shared between multiple backends.

Original:

Splits the MySQL connection setup statements into discrete executions to
prevent issues with proxies, such as ProxySQL, which may need to balance
and share connections between different backends.

Fixes #422

Signed-off-by: Marcus Griep marcus@griep.us

[mehcode]

That's unfortunate. As these are ran on every new connection I'd prefer to keep the single execute when we can. Can you conditionally do this based on the server supporting multiple statements?

Something like

if conn.stream.capabilities.contains(Capabilities::MULTI_STATEMENTS) {
  // can send all statements at once
} else {
  // need to send them one at a time
}

[neoeinstein]

I'll check to see what capabilities are being returned.

[neoeinstein]

I threw in a log statement to check out what capabilities were being advertised:

Jun 20 10:13:02.571 INFO sqlx_core::mysql::connection: Capabilities: FOUND_ROWS | CONNECT_WITH_DB | PROTOCOL_41 | TRANSACTIONS | SECURE_CONNECTION | MULTI_STATEMENTS | MULTI_RESULTS | PS_MULTI_RESULTS | PLUGIN_AUTH

With MULTI_STATEMENTS in there, that won't work, and in fact the issue is not with multi-statements in general, but with SETs in multi-statements.

I considered adding a new option to the MySQL builder, but I think the more prudent course would be to have a build feature, so I've updated the PR to use that instead.

[mehcode]

I did some digging. It does look like ProxySQL is mostly behaving correctly. There just isn't a capability to show "hey we support multiple non-CRUD statements".

However SET supports multiple assignment within one expression because of that. SET x=y, z=w, a=2.

See: https://dev.mysql.com/doc/refman/5.6/en/set-variable.html#set-variable-multiple-assignments

Can you try tweaking the statement to be formed like that and see if ProxySQL is okay with it?

[neoeinstein]

I did some tweaks as recommended, and am currently doing a long-run to verify that I'm not getting any errors.

I did notice that, if I don't include one semicolon at the end, ProxySQL didn't seem to be preserving the session variables (the sql_mode fell empty, and time_zone stayed on SYSTEM). I ran a few test queries, like SELECT DATE('0000-00-00') and SELECT CURRENT_TIMESTAMP() to see whether this was just an artifact or ProxySQL actually not preserving the variables. These tests confirmed that this wasn't an artifact.

Including the semicolon at the end triggers ProxySQL to still consider it a "multi-select" statement and lock the connection, but it does properly preserve the session variables and function as expected. This does cause a warning to be emitted by ProxySQL, but since there isn't actually another statement after the semicolon, I'm not getting a "bad SQL" error back.

I'll update the PR with the new single-statement connection setup.

[mehcode]

Thank you for investigating and fixing this. This seems to improve support for older versions of MySQL as well. 👍