There was a recent fix for an optimiser bug for MySql Server in a recent patch 8.0.33 released in April 2023. This is the bug in question:
When the MySQL 5.7 Optimizer has two choices for an index to filter rows, one primary and one secondary, it picks a range scan on the secondary index because it uses more key parts. MySQL 8.0 did not use this logic, instead choosing the primary index to filter rows with WHERE clause filtering. Primary key use is not suitable in such cases due to the presence of LIMIT and due to the nature of data distribution. The secondary index was not considered while resolving order by due to constant elimination. This resulted in much different query plans in MySQL 5.7 and MySQL 8.0 for the same query.
We solve this issue in MySQL 8.0 by skipping the constant key parts of the index during order-by evaluation only if the query is constant-optimized, which can be done at this time, but not during LIMIT analysis. (Bug #34291261)
My project currently is running several MySql server version as we transition to MySql 8 Flexible servers. We initially notice an optimiser bug in MySql 8 servers that had a dramatic impact compared to the performance of the same query on the MySql 5 servers. We've implemented a workaround, but it comes at a cost in complexity and development costs.
Does anyone know if there are any plans to upgrade the MySql Flexible servers to 8.0.33 and when that minor upgrade might take place?