Query Analyzer v3.29.1

🔍 Index Performance Issues

Inefficient Index Scans

0 queries (0%) scan an average of 0 index entries but returned back an avg 0 records per query or a selectivity of 0% (excluding aggregate functions like COUNT(), AVG(), MIN(), MAX(), and mutation statements (MERGE, DELETE, INSERT, UPDATE, UPSERT).

💡 Consider creating more selective indexes to reduce scan overhead Learn more

Slow Index Scan Times

0 total indexes:

0 indexes with an avg scan time between 2-10 seconds

0 indexes with an avg scan time of 10+ seconds

0 #primary indexes with an avg scan time of 2+ seconds

To see identified index(es) go to the "Index/Query Flow" tab.

💡 Check kernel time on index nodes - high kernel time may indicate resource contention Learn more

💡 Index returning millions of records? Create more selective compound indexes Learn more

Primary Index Over-Usage

Primary indexes on avg are scanning 0 items with an avg scan time of 0ms. These could benefit from secondary indexes.

💡 Review your indexing strategy - create selective secondary indexes Learn more

⚠️ Avoid primary indexes in production—use targeted secondary indexes instead Learn more

ORDER BY / LIMIT / OFFSET Index Over-Scan

0 queries (0%) with `ORDER BY` + `LIMIT ` + `OFFSET ` scanned an Avg of 0 items from the index(es).

💡 Consider an index that satisfies the ORDER BY to only scan needed rows/items Learn more

⚡ Resource Utilization Issues

High Kernel Time in Queries

0 queries (0%) whose average percentage of sum of their core execTime ⓘ / kernTime is 0%.

What high kernTime means: kernTime is time spent waiting to be scheduled on CPU. If it dominates ServiceTime and/or Execution Time (e.g., ~99%), the node is CPU-bound and the query spends most of its life paused, not doing useful work. Look for high request.active.count, cpu.user.percent, or gc.pause.percent. Actions: reduce concurrency, add query nodes, or separate services.

💡 Is the Query Service co-located with other services? Learn more

High Memory Usage Detected

0 queries (0%) are using avg 0GB of memory each, indicating potential memory optimization opportunities.

💡 Consider increasing query memory limits or optimizing queries Learn more

Slow Parse/Plan Times

0 queries (0%) have parse or plan times greater than 1ms with avg parse: 0ms and avg plan: 0ms, which may indicate high CPU utilization or kernel time wait issues.

💡 Check CPU utilization and consider reducing query concurrency Learn more

Slow USE KEY Queries

0 USE KEY queries (0%) with avg query time of 0ms, suggesting potential KV service bottlenecks.

💡 Is the Data Service and/or Query Service co-located with other services? Learn more

🔄 Query Pattern Analysis

Missing WHERE Clauses

0 queries (0%) lack WHERE clauses, potentially scanning entire collections unnecessarily. possibly a query with `USE KEYS()`

Complex JOIN Operations

0 queries (0%) with JOIN operations detected, with 0 (0%) flagged as complex. Average JOIN phase time: 0s.

Request Date	Flags	JOIN Time	Statement (unique)

Flag Legend:

🔴 Critical: A = Primary Scan, B = Cartesian Product, D = Severe Explosion (10x+)
🟡 High: C = Data Explosion (2x-10x), E = Slow JOIN (≥2s), F = High Doc Count (≥100K), H = JOIN Time Dominant (≥30%)
🟠 Medium: G = Multiple JOINs (4+)

💡 Hover over flags in the table above for detailed metrics
ℹ️ JOIN Time shows "N/A" when Couchbase doesn't report a separate join phase (query may be optimized)

💡 Review JOIN optimization strategies and flag meanings Learn more

Inefficient LIKE Operations

0 queries (0%) use LIKE operations with leading wildcards (%text), preventing index usage and causing full scans.

SELECT * Usage

0 queries (0%) use SELECT * which returns entire documents and can increase network I/O and memory. Prefer selecting only needed fields.

🚀 Performance Optimization Opportunities

Large Payload Streaming

0 queries (0%) with avg size: 0MB with 0% of the time of the query was streaming data out to the application.

💡 Consider implementing pagination for large result sets Learn more

Large Result Set Queries

0 queries (0%) return result sets with avg size of 0MB, which can consume significant memory and network resources.

💡 Large result sets can impact performance and resource usage Learn more

Timeout-Prone Queries

Concurrent Query Conflicts

0 queries (0%) show evidence of resource contention with service-level performance degradation.

🔍 Service Pressure Breakdown:

Request Date	Flags	Parse+Plan	Fetch/Doc	Scan Rate	Kern%	Statement (unique)

Flag Legend:

🔴 Critical: B = Parse+Plan >10ms (Query Service critically overloaded), D = Fetch >10ms/doc (KV critically slow), F = Scan <1K/sec (Index critically slow), H = System-Wide (multiple services under pressure)
🟡 High: A = Parse+Plan >1ms (Query Service pressure), C = Fetch >5ms/doc (KV pressure), E = Scan <5K/sec (Index slow), G = Kernel >30% (CPU contention)

💡 Hover over flags in the table above for detailed metrics

💡 Review service pressure indicators and optimization strategies Learn more

Search:

Bucket:

Scope:

Collection:

Sort By:

Total Indexes: 0

Buckets: 0

Scopes: 0

Collections: 0

Primary Indexes: 0 Primary Only

Used/Total Indexes: 0/0 Used Only

Without/With Replica: 0/0 No Replicas Only

Index Type: All Indexes GSI Only FTS Only

Never Scanned Indexes: 0 Never Scanned Only

Sync Gateway Indexes: 0 Exclude Mobile Indexes

No Index Data Loaded

To analyze indexes, run this query in your Couchbase Query Workbench and paste the results in the second textarea above:

SELECT 
    s.name,
    s.id,
    s.metadata,
    s.state,
    s.num_replica,
    s.`using` AS indexType,
    CONCAT("CREATE INDEX ", s.name, " ON ", k, ks, p, w, ";") AS indexString
FROM system:indexes AS s
LET bid = CONCAT("", s.bucket_id, ""),
    sid = CONCAT("", s.scope_id, ""),
    kid = CONCAT("", s.keyspace_id, ""),
    k = NVL2(bid, CONCAT2(".", bid, sid, kid), kid),
    ks = CASE WHEN s.is_primary THEN "" ELSE "(" || CONCAT2(",", s.index_key) || ")" END,
    w = CASE WHEN s.condition IS NOT NULL THEN " WHERE " || REPLACE(s.condition, '"', "'") ELSE "" END,
    p = CASE WHEN s.`partition` IS NOT NULL THEN " PARTITION BY " || s.`partition` ELSE "" END;

Steps:
1. Copy the query above
2. Run it in Couchbase Query Workbench
3. Copy the JSON results
4. Paste into the second textarea ,on the right, at the top
5. Click "Parse JSON" again

Query Duration Distribution

Index Type Usage

Query Pattern Features

Statement Type

Query State

Index Scan Consistency

Users by Query Count

Index Usage Count