- Newest
- Most votes
- Most comments
Hi,
you should try to run EXPLAIN on your queries with highest latency differences on the 2 engines.
See https://dev.mysql.com/doc/refman/8.0/en/using-explain.html
You can then see if there is a major difference in access strategy leading to this much higher latency and fix it.
This other article gives you some tracks to explore as well: https://repost.aws/knowledge-center/aurora-mysql-slow-select-query
But, it's mostly related to context with high loads. So, I don't think it will match your situation where you seem to be in initial unit testing mode.
Best,
Didier
The answer about analyzing your queries and looking for differences in the query plans is an important strategy -- especially if you are changing engine versions. But additionally in my testing, I saw a substantial performance improvement by selecting the Aurora I/O-Optimized option. If your query plans seem very similar, give this option a try to see if you find the same.
Relevant content
- asked a year ago
- AWS OFFICIALUpdated 3 years ago
- AWS OFFICIALUpdated 2 years ago
- AWS OFFICIALUpdated 4 months ago
(sorry, moving this as a comment, instead of an answer)
Hi Didier
Thanks for your reply.
For most queries, the "EXPLAIN" is giving exactly the same result. Which makes sense - because the mysql engine is identical. Only the hardware is different.
For some large queries, the "EXPLAIN" query is giving very similar result - except the serverless shows the query with "filesort", whereas the provisioned server does not. My guess is that this is because the dataset is not in the RAM in the serverless, whereas the whole query dataset lies in the RAM for provisioned. Would this be correct?
I feel like this is an issue with buffer pool. Serverless v2 keeps evicting the buffer pool during downsizing, whereas the provisioned server does not. So, I don't understand how anyone can use Serverless V2 without making the min ACU so high that it effectively stops the scaling activity altogether, and defeats the purpose of serverless scaling.