My ANN_SEARCH queries are absolutely nuking my OLTP performance

I’ve hit a massive wall with our current OceanBase 4.3.x setup (running in MySQL compatibility mode). We are trying to run a mixed workload within a single multi-tenant configuration, which was supposed to be efficient, but instead, it's causing a total resource meltdown during peak hours.

The setup is pretty straightforward: we use the same tenant for our standard real-time OLTP point-queries (basic primary key lookups) and our dense vector similarity searches for our RAG pipeline using the ANN_SEARCH command with a VSAG index. On paper, this should work fine. In reality, as soon as we hit a concurrency spike—around 800 simultaneous vector search requests—the entire tenant falls apart.

The symptoms are brutal. Our simple SELECT ... WHERE id = ? queries, which usually fly through in under 1ms, suddenly start lagging with queueing times exceeding 400ms. It’s not even a latency issue with the data itself; it’s a pure starvation issue.

I did a deep dive into the monitoring using GV$OB_PROCESSLIST to figure out what was actually happening under the hood. It looks like the parallel execution threads being spawned for the graph-based VSAG index traversals are aggressively saturating the entire CPU worker thread pool for that tenant. Basically, the heavy vector math is grabbing every available thread, leaving absolutely nothing for the lightweight transactional queries to breathe.

I tried a few things to fix this, but nothing has stuck:

• Resource Isolation attempt: I tried adjusting the tenant_max_cpu boundaries, but since both the OLTP and the vector workloads are living inside the same tenant, the isolation isn't helping. The CPU is capped at the tenant level, but the "bad actor" (the vector search) is just eating everything within that cap.

What I'm looking for is a way to perform a more granular deployment of resources. Does anyone know if there is a tenant-level session variable or a specific system configuration in OceanBase that can explicitly cap the maximum number of parallel threads allocated specifically for ANN_SEARCH vector graph traversals?

I really need to prevent the vector execution from starving the standard OLTP queries of CPU resources.

I’m trying to avoid the "obvious" solution of spinning up a dedicated second tenant for the vector searches. If I move the vector work to a different tenant, I'll run into cross-tenant network latency and massive data synchronization overhead, especially since we need to perform joined queries across both datasets. We need this to work in a single tenant for the sake of our AI workflow performance.

Has anyone dealt with this kind of thread starvation when running heavy LLM-related vector workloads alongside standard SQL? Any advice on tuning the parallel execution limits would be a lifesaver.