Feature: Optimize MySQL connection handling: avoid per-connection thread and runtime creation

[yufan022]

Summary

Problem

Based on v1.2.636-rc8.6 code, if I understand correctly, every new MySQL connection creates:

1. A dedicated OS thread
   

   databend/src/query/service/src/servers/mysql/mysql_session.rs

   Line 56 in f74b30b

   Thread::spawn(move || {

   • thread::spawn() is called for each incoming connection
   • Thread creation/destruction overhead is significant under high concurrency

2. A dedicated Tokio runtime
   

   databend/src/query/service/src/servers/mysql/mysql_session.rs

   Lines 54 to 55 in f74b30b

   	let query_executor =
   	Runtime::with_worker_threads(1, Some("mysql-query-executor".to_string()))?;

   • Runtime::with_worker_threads(1, "mysql-query-executor") is created per connection
   • Each runtime has its own thread pool and scheduler overhead
   • Memory and CPU resources cannot be shared across connections

Impact (AI-generated)

• High memory consumption under concurrent connections
• Poor resource utilization due to isolated runtimes
• Potential resource exhaustion with many simultaneous connections
• Unnecessary thread context switching overhead

Suggested Solution (AI-generated)

• Use a shared Tokio runtime (or the global runtime) for all MySQL connections
• Replace thread::spawn() with tokio::spawn() to leverage async task scheduling
• Consider using a connection pool or worker pool pattern for better resource management

[TCeason]

Good catch. The observation is correct, and we already have the right pattern in the codebase.

HTTP handler does it right:

// http_query.rs:836
GlobalQueryRuntime::instance().runtime().spawn(async move { ... });

MySQL handler does it wrong:

// mysql_session.rs:145-148
let query_executor = Runtime::with_worker_threads(1, ...)?; // per-connection runtime
Thread::spawn(move || { // per-connection OS thread
futures::executor::block_on(query_executor.spawn(async move { ... }));
});

The fix should be straightforward - MySQL handler can simply use GlobalQueryRuntime like HTTP does:

GlobalQueryRuntime::instance().runtime().spawn(async move {
let interactive_worker = InteractiveWorker::create(...);
match (tls, use_ssl) {
(Some(config), true) => secure_run_with_options(...).await,
_ => plain_run_with_options(...).await,
}
// cleanup...
});

The only thing to verify: whether opensrv-mysql has any blocking operations that would require isolation. A quick scan of InteractiveWorker suggests it's fully async, so this should work.

Would you like to submit a PR for this?