Your question correctly identifies that this is not a problem of "how can I even do this?", but rather one of "how do I do this while conforming to microservice standards?". To that end, we must investigate how this conflicts with microservice standards.
It wouldn't be incorrect to consider my answer as an attempt to "lawyer" you into accepting your approach as a valid one. I've used a few different arguments here to support the notion that it may be valid to separate the api and worker without necessarily violating the core goal of a microservice architecture.
...the database only belongs to MicroServiceA
Correct, it is generally advised for microservices to be sole owner of their own datastore, as not doing so inherently infringes on the independent and scalable nature of the microservice.
a Microservice that is working as an API sometimes needs to do something resource intensive to change something in its own database.
A possible solution could be to spin up a worker
If MicroserviceA is the sole owner of DatabaseA, then any and all A-related work needs to be under the purview of MicroserviceA. Anything different would inherently mean that MicroserviceA is no longer the sole owner of that database.
That is the theory. However, in reality we often have to make compromises when presented with technical implementation challenges that stem from the purely theoretical (elegant) model.
There is no technical reason why you couldn't subdivide the API and worker into separate applications. But in order to retain the microservice way of doing things, this means having to accept some consequences from doing so
The two applications will have to share a life cycle, and should be versioned and deployed together. When one of the applications causes a change in the data model, the other application needs to inherently account for that.
In order to avoid these kinds of issues, I would err on the side of always versioning both, even when you know that a change in one does not impact the other, simply to ensure that these applications are always kept in line, easy to upgrade, and don't slowly grow apart.
In principle, this kind of "joined deployment" of logically separate modules is precisely what microservices aim to avoid. However, as long as the scope of your A-related application is small and very closely tied together; the impact of coupling them together is minimal. It would functionally be impossible to couple them any looser anyway; as the only alternative would be to merge them into a single application, which would be an even tighter coupling.
Remember when I said "the independent and scalable nature of the microservice"? If these applications had separate life cycles, you would be infringing on that. However, if you lump the two applications into a single life cycle, I can reasonably agree that you've maintained the independent nature of "the A service" (which is comprised of two deployed applications).
Really, what it all boils down to is that you architecturally speak of "the A service" as if its a single homogenous blob; whereas the technical implementation details will entail having two separately built applications to deploy.
The reason for splitting these two applications is purely for crossing an otherwise technical hurdle (runtime performance impact) and it should be architecturally irrelevant in your microservice domain.
At no point should any high level architectural decision need to account for, or be blocked by, the consequences of having to account for the separately deployed A-related applications. If you can accept these consequences, then I see no reason to consider your additional worker as something to avoid.
Or, to explain it using your words:
A possible solution could be to spin up a worker .. this would be problematic as the database only belongs to MicroServiceA
If you take this approach, you need to separate "the api" from "the microservice". Right now, you are thinking of the api as exactly being the microservice in and of itself, which is no longer true if you also have a worker.
At its core, "the microservice" is what you consider architecturally. It has a single lifecycle, and it is considered to be a homogenous blob for versioning and deployment purposes.
Concretely, "the mircroservice" actually consists of "the api" and "the worker", who could theoretically reside in a single runtime but for practical purposes are better served separately - but this separation is intentionally abstracted and hidden in the architecture. The api and worker are the silent vassals of the microservice. They make no demands of their own and cannot (and should not) override what "the microservice" should do in its lifecycle.
A more straightforward justification that I can use here is that your two applications would effectively represent the read/write components of your A service.
It is generally considered acceptable to split these out so they can be scaled independently, since a "write once, read many" approach tends to avoid concurrency issues while at the same time maximizing read capability which is commonly the only real bottleneck.
Would it be better to then also split out the underlying database in a separate read and write store? From a theoretical and elegant perspective, I agree; but here we again strike on the possibility of practical compromises (YAGNI, overengineering, no meaningful performance improvement based on current requirements).
As long as you keep it reasonably open to future maintenance whereby the read/write stores may be split off; I would consider this approach valid in the right context.