핵심 요약
- Top SQL ranks queries by CPU consumption, which is usually the fastest route from “everything is slow” to one offending query.
- Map each tenant to a resource group so every query carries a tenant label and a quota.
- Runaway query rules catch a noisy tenant automatically: kill, deprioritize, or move its heaviest queries to a smaller group.
- Review Top SQL on a schedule. Tenant workloads drift slowly worse as their data grows, long before an alert fires.
One tenant running an unindexed query in a loop can degrade response times for every other tenant sharing that cluster, and without the right tools, the first sign of trouble is a wave of unrelated-looking complaints. This guide covers finding that tenant fast with 티DB‘s built-in diagnostics, then keeping it from happening again. If you haven’t chosen an isolation model yet, start with the multi-tenant architecture guide.
How Do You Diagnose a Noisy Tenant in a Multi-Tenant TiDB Deployment?
Start with Top SQL, which ranks SQL statements by CPU consumption across TiDB and TiKV instances, to find the query doing the damage. Attribute it to a tenant through the database user or resource group that issued it. Then use the slow query log and EXPLAIN ANALYZE to see where that statement spends its time, and Continuous Profiling if the cost sits inside TiDB or TiKV rather than in the query itself.
Resource Isolation With Resource Groups
TiDB separates compute from storage, so isolating tenants doesn’t require running separate infrastructure for each one. The mechanism that makes this work at the tenant level is resource control. Each resource group gets a quota in Request Units (RUs), an abstract measure of the CPU, I/O, and network a statement consumes. When a group exhausts its quota, TiDB queues that group’s requests rather than letting them take capacity from everyone else.
The simplest mapping gives each tenant its own database user and binds that user to a group:
CREATE RESOURCE GROUP rg_tenant_acme RU_PER_SEC = 2000 PRIORITY = MEDIUM;
ALTER USER 'acme_app'@'%' RESOURCE GROUP rg_tenant_acme;
Example quota only. Size RU_PER_SEC from observed usage, and adjust it with ALTER RESOURCE GROUP, which takes effect immediately.
Shared-schema applications that pool connections under one database user can bind a group per session with SET RESOURCE GROUP, or per statement with a hint:
SELECT /*+ RESOURCE_GROUP(rg_tenant_acme) */ * FROM orders WHERE tenant_id = 'acme';Two more settings shape how groups compete. PRIORITY decides which group TiKV schedules first when resources run short. BURSTABLE lets a group borrow idle capacity beyond its quota, useful while you are still learning a tenant’s real usage and risky once you rely on the quota to protect everyone else.
Isolation and monitoring work together rather than as substitutes. A quota limits the blast radius of a noisy tenant, but it does nothing about that tenant’s own queries degrading its own performance. See resource control for the full set of options.
How TiDB’s Top SQL Solves the Noisy-Neighbor Problem
The noisy-neighbor problem is specific: one tenant’s heavy or poorly optimized query consumes a disproportionate share of cluster resources, degrading performance for every other tenant on the same infrastructure, even though those tenants did nothing wrong.
Top SQL, in TiDB Dashboard, solves the identification half. It surfaces which SQL statements are consuming the most CPU across the cluster, ranked by statement pattern rather than buried in an aggregate metric. With tenants mapped to users or resource groups, the top-ranked statement points straight at a tenant.
Finding the query is not the same as knowing the fix. Each diagnostic tool answers a different question:
- Slow query log and statement summary tables: break a statement’s time into processing, waiting, and backoff, which separates a missing index from lock contention.
- EXPLAIN ANALYZE: shows actual row counts and time per operator, so you can see where the plan went wrong.
- Continuous Profiling: records CPU and memory profiles of TiDB and TiKV internals over time, so you can look back at the exact moment of a spike when the cost sits inside the database rather than in the query.
The answer decides the fix: an index, a tighter quota, a runaway query rule, or moving that tenant to isolated placement.
Build one habit in: review Top SQL rankings on a schedule instead of waiting for a complaint. A tenant’s query pattern can drift slowly worse over weeks as its own data volume grows, well before it becomes the kind of spike that triggers an alert, and catching that drift early costs far less than diagnosing it after tenants start noticing.
Automate the Response With Runaway Query Rules
Diagnosis after the fact still means someone got paged. Runaway query rules let a resource group act on its own. You define what counts as a runaway query, using execution time (EXEC_ELAPSED), keys processed (PROCESSED_KEYS), or RUs consumed (RU), and what TiDB should do when a query crosses that line:
- DRYRUN: record the match and take no action, for calibrating thresholds.
- COOLDOWN: drop the query to the lowest priority so it keeps running without crowding anyone out.
- KILL: terminate the query.
- SWITCH_GROUP: move the query to a smaller resource group built for heavy work.
ALTER RESOURCE GROUP rg_tenant_acme
QUERY_LIMIT = (EXEC_ELAPSED = '60s', ACTION = COOLDOWN, WATCH = SIMILAR DURATION = '10m');
The WATCH clause is what makes this a noisy-neighbor control rather than a timeout. Once one query trips the rule, TiDB matches later statements with the same pattern (SIMILAR ignores literal values) and applies the action immediately for the watch duration, instead of letting each copy run for 60 seconds first.
Start every new rule in DRYRUN mode and watch what it would have caught before switching it to COOLDOWN or KILL. For one-off problems, QUERY WATCH adds a specific statement or digest spotted in Top SQL to the watch list by hand. See runaway queries for the full syntax.
Catch the Noisy Tenant Before It Becomes an Incident
Top SQL turns “something is slow” into a specific query and a specific tenant. Resource groups and runaway query rules contain the next one before anyone has to go looking.
Start a free TiDB Cloud Starter cluster to try Top SQL against your own multi-tenant workload.
Multi-Tenant TiDB Performance FAQs
How Do I Identify Which Tenant Is Causing a Performance Problem?
- Use Top SQL to rank statements by CPU consumption across the cluster.
- Trace the top statement to its tenant through the user or resource group that issued it.
- Use the slow query log and EXPLAIN ANALYZE to see where the time goes.
- Tagging queries with a tenant ID in application code speeds this up further.
Can One Tenant’s Workload Affect Other Tenants in TiDB?
- Yes, if tenants share compute and storage without quotas.
- Resource groups cap each tenant’s RU consumption and queue it past the limit.
- Placement policies can pin a tenant’s data to dedicated TiKV nodes.
- Top SQL and runaway query rules catch what slips through.
How Do Resource Groups Stop a Noisy Tenant?
- Each group gets an RU quota; requests queue once the quota runs out.
- PRIORITY decides which group TiKV schedules first under pressure.
- Runaway query rules kill, deprioritize, or reroute queries that cross a threshold.
- Bind groups per user, per session, or per statement with a hint.
Can TiDB Show Resource Usage per Tenant?
- TiDB has no built-in tenant concept.
- Map one resource group per tenant, and TiDB tracks RU consumption per group.
- Top SQL shows per-statement CPU, which maps to tenants through users or groups.
- Tenant IDs in query comments or connection attributes fill any remaining gaps.