Hi Steve Pugh •,
Welcome to Microsoft Q&A forum.
As I understand, you are experiencing Slowness in execution of queries in Azure MySQL Flexible Server.
Thanks for the detailed explanation with setup in place and measures taken.
Could you please check resource allocation and Server Compute+ Storage if enough to handle workload.
Before analyzing individual queries, you need to define query benchmarks. With this information, you can implement logging functionality on the database server to trace queries that exceed a threshold you specify based on the needs of the application.
Azure Database for MySQL flexible server, it’s recommended to use the slow query log feature to identify queries that take longer than N seconds to run. After you've identified the queries from the slow query log, you can use MySQL diagnostics to troubleshoot these queries.
Before you can begin to trace long running queries, you need enable the slow_query_log
parameter by using the Azure portal or Azure CLI. With this parameter enabled, you should also configure the value of the long_query_time
parameter to specify the number of seconds that queries can run before being identified as “slow running” queries. The default value of the parameter is 10 seconds, but you can adjust the value to address the needs of your application’s SLA.
Monitoring InnoDB garbage collection
When InnoDB garbage collection is blocked or delayed, the database can develop a substantial purge lag that can negatively affect storage utilization and query performance.
The InnoDB rollback segment history list length (HLL) measures the number of change records stored in the undo log. A growing HLL value indicates that InnoDB’s garbage collection threads (purge threads) aren’t keeping up with write workload or that purging is blocked by a long running query or transaction.
Excessive delays in garbage collection can have severe, negative consequences:
- The InnoDB system tablespace will expand, thus accelerating the growth of the underlying storage volume. At times, the system tablespace can swell by several terabytes as a result of a blocked purge.
- Delete-marked records won’t be removed in a timely fashion. This can cause InnoDB tablespaces to grow and prevents the engine from reusing the storage occupied by these records.
- The performance of all queries might degrade, and CPU utilization might increase because of the growth of InnoDB storage structures.
Please refer to the below recommendation if useful in your case:
- Ensure that your database has enough resources allocated to run your queries. At times, you might need to scale up the instance size to get more CPU cores and additional memory to accommodate your workload.
- Avoid large or long-running transactions by breaking them into smaller transactions.
- Configure innodb_purge_threads as per your workload to improve efficiency for background purge operations. Note Test any changes to this server variable for each environment to gauge the change in engine behavior.
- Use alerts on “Host CPU Percent”, “Host Memory Percent” and “Total Connections” so that you get notifications if the system exceeds any of the specified thresholds.
- Use Query Performance Insights or Azure Workbooks to identify any problematic or slowly running queries, and then optimize them.
- For production database servers, collect diagnostics at regular intervals to ensure that everything is running smoothly. If not, troubleshoot and resolve any issues that you identify.
Also, if feasible you may try to move Server region by referring to this tutorial:
https://learn.microsoft.com/en-us/azure/mysql/flexible-server/how-to-move-regions
Reference official Microsoft Documenation:
Let us know if this helped or you have more queries.
Thanks