Query Analyzer v3.16.4

🚧 INSIGHTS IN DEVELOPMENT 🚧

Some insights show LIVE data, BETA insights are work in progress (might have false positives), others display placeholder content.

🔍 Index Performance Issues

Inefficient Index ScansLive

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 TimesLive

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-UsageLive

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-ScanBeta

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 QueriesBeta

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 DetectedLive

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 TimesBeta

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 QueriesLive

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 ClausesLive

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

Complex JOIN OperationsDev

0 JOIN queries are taking an average of 0 seconds each, with 0% showing suboptimal join patterns.

💡 Consider denormalizing frequently joined data Learn more

Inefficient LIKE OperationsLive

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

SELECT * UsageLive

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 StreamingLive

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 QueriesLive

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 QueriesBeta

Concurrent Query ConflictsDev

0 queries show evidence of resource contention, with execution times varying by more than 0% during peak hours.

💡 Review query scheduling and resource allocation 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

Users by Query Count

Index Usage Count

Statement Type

Query State

Index Scan Consistency