1 Antwort
- Neueste
- Die meisten Stimmen
- Die meisten Kommentare
0
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
Relevanter Inhalt
AWS OFFICIALAktualisiert vor einem Jahr- AWS OFFICIALAktualisiert vor 3 Jahren
- AWS OFFICIALAktualisiert vor 2 Jahren
- AWS OFFICIALAktualisiert vor einem Jahr
(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.