The latest from the MySQL community

Over the period, we have witnessed how MySQL versioning evolved from 8.0 to 9.7 LTS, and now it has entered a new era: a calendar-based model.

Let’s first take a brief look at how MySQL versioning has evolved over time.

• Phase 1 – MySQL 8.0 (2018–2026) used a traditional single-track release model, with all new features and bug fixes rolled into the same 8.0 release line.
• Phase 2 – Oracle launches an Innovative/LTS dual-track model (Mid 2023). Innovation releases focus on new features and changes to short-lived performance on a quarterly basis. The LTS (Long Term Stable) release is steadier and has a long lifespan, with a cycle of 5 years of Premier Support + 3 years of Extended Support, and it typically launches every 2 years.
• Phase 3 – There are chains of Innovation releases following (8.1, …

By now you have probably heard about the MySQL thread pool plugin and API, but you may not have fully processed the details. Here’s the quick summary:  With the new thread pool plugin, there is now an alternative way to handle connection threads in MySQL Enterprise Edition.  With the plugin, MySQL connection threads are shared like an extraordinarily well managed timeshare in Hawaii.  When one connection is “idle”, asking nothing of and expecting nothing from the database, another connection can use that same thread for its database requests.  Threads are released by each connection as soon as the request is completed and  go back into the pool for re-use – just like the theoretical timeshare is up for grabs on the weeks you are not there.

In the older, and still default connection thread model, threads are dedicated to a single client  for the life of the connection and there are as many …

Since few weeks I was working on patching the MySQL 5.1 with libevent support to have thread pooling in server end as it is needed by few properties where they do not need a persistent connection and needed to scale server with thousands of connections as each call just does a simple query execution by connecting and disconnecting and pooling seemed to be a right choice.

When I brought this idea to Monty; he pointed me to 6.0 where it is in preliminary stage. Now I took the same design and implemented in 5.1 to be compatible with how its working in 6.0; and things so far seems to be running fine, except few misc glitches that am trying to solve now.

It uses the same thread_handling=one-thread-per-connection (default) and new thread_handling=pool_of_threads and thread_pool_size controls how many will be initialized and kept at the …