Always discard mysql multi-statement results

[jhawthorn]

We never want to connect or reconnect here, we just need to drop any results from a multi-statement query and that only makes sense to do on the same connection we'd already used for the query.

Previously when a query was run which hit the query cache on a fresh, non-sticky connection, the connection would perform its verfiy! before calling next_result, resulting in a network round trip.

https://gist.github.com/jhawthorn/a7210ff40d947b5f6c776045a2a8c59c

cc @byroot @matthewd

[byroot]

So that makes sense however:

• Don't we have a race condition by re-acquiring the lock
• Don't we have an issue with Async queries?

This makes me think we should instead pass some sort of parameter to select, so that it is the one that calls next_result with the lock etc.

[matthewd]

Ah, yeah, it looks I "handled" this for mysql2 by just wrapping everything and grabbing the connection ahead of schedule:

rails/activerecord/lib/active_record/connection_adapters/mysql2/database_statements.rb

Lines 10 to 17 in a17aa63

	with_raw_connection do |conn|
	result = if ExplainRegistry.collect? && prepared_statements
	unprepared_statement { super }
	else
	super
	end
	conn.abandon_results!
	end

... which may or may not have its own async worries, and surely has other disadvantages like missing the log rescue's set_query.

some sort of parameter to select

Hmmm... is there actually any time we wouldn't want to drain more_results_exist?/similar? 🤔

[composerinteralia]

which may or may not have its own ... worries

Indeed ec7f5a1 (although GitHub-specific at least at the time)

[jhawthorn]

Hmmm... is there actually any time we wouldn't want to drain more_results_exist?/similar? 🤔

I can't find any, so let's try that as that solves both this and the two existing issues Jean points out.

[jhawthorn]

Backported to 7-2-stable as 229308d