Azure Database for MySQL Flexible Server: sustained CPU doubles despite stable query rates

Question

Azure Database for MySQL Flexible Server: sustained CPU doubles despite stable query rates

Adrian 0

I am investigating a sustained Host CPU increase on Azure Database for MySQL Flexible Server, Standard_B1ms, UK South, running MySQL 8.4.9-azure.

Following a planned restart on 18 October 2026, Host CPU settled at approximately 11–12% with the normal API workload operating.

At 22:34 UTC on 18 October, approximately 5½ hours after the restart, CPU abruptly increased to approximately 22% and remained elevated overnight. This is not the temporary spike during the restart itself.

Our aligned before/after comparison found:

Host CPU: 11.227% → 22.339%.
Queries: 5,259.80 → 5,260.36 per minute.
No matching restart, deployment, configuration change, credit exhaustion, memory pressure or storage I/O increase was identified.

A subsequent five-minute SQL capture compared the elevated state with the earlier low-CPU state:

Queries: 85.9609/sec in the low-CPU state versus 85.8929/sec in the elevated-CPU state.
All 12 known query digests matched, with rates within 0.7%.
Average elapsed query times increased by only 2.8–9.4%. These are elapsed times, not CPU measurements.
The API version, configuration and replica count remained unchanged.

I have reviewed related Q&A discussions 1681370 and 1642061. They describe similar unexplained CPU/credit behaviour, but I could not find a published root cause that establishes whether my case is related. I currently have Basic support. Can a Microsoft moderator advise whether an alternative escalation route is available for reviewing the evidence privately?

What additional diagnostics can distinguish application-related CPU costs from internal MySQL or Azure host activity in this situation, and does the evidence warrant a private Azure MySQL investigation?

Host CPU

Queries

Sustained

0 comments

1 answer

Your answer

Answer 1

Hi Adrian & thx for join me at Q&A platform,

ur comparison is quite convincing. Query rates and all 12 statement digests remain essentially unchanged, while Host CPU nearly doubles and stays elevated. That makes a simple workload increase unlikely. But stable query counts don't necessarily mean stable CPU consumption. The same queries can require more CPU due to different execution plans, buffer pool behavior, or internal MySQL activity.

I'd compare performance_schema statement statistics before and after the increase, particularly rows examined, execution counts, and CPU time where available. Also check SHOW ENGINE INNODB STATUS, background thread activity, buffer pool reads, and InnoDB purge activity. The Standard_B1ms is a small burstable instance, so CPU credit metrics are relevant, but you've already ruled out credit exhaustion. I wouldn't keep focusing on that explanation without new evidence.

The abrupt change at 22:34 UTC, several hours after restart, is worth investigating for scheduled maintenance, backups, or internal server activity. None of those can be confirmed from the metrics alone.

I think your evidence justifies a Microsoft Azure Database for MySQL technical investigation, particularly if the elevated CPU persists without corresponding changes in database workload. Basic Support doesn't normally include technical incident investigation, and Q&A moderators cannot directly access backend telemetry or guarantee a private escalation. A technical support case would be the appropriate route.

Include the exact UTC transition, server resource ID, before/after metrics, query digest comparison, and MySQL version. Ask engineering to correlate the CPU change with internal database and platform activity.

rgds,

Alex

p.s. if my answer is help - pls mark it as an answer