Suppose a query was running, and suddenly it starts taking a long time to execute. What could have gone wrong with the query source?

When a query that previously ran quickly suddenly slows down, several factors may be at play:

1. Data Growth – The underlying tables may have increased in size, turning a previously efficient index scan into a full table scan.
2. Missing or Stale Statistics – The optimizer relies on statistics to estimate row counts. If statistics are outdated, it may choose a suboptimal plan.
3. Index or Partition Changes – Dropping or altering indexes/partitions can remove the optimizer’s ability to prune data.
4. Data Skew or Corruption – Uneven distribution of key values can cause certain nodes to process far more data.
5. Resource Contention – Concurrent queries or background jobs can consume CPU, memory, or I/O, increasing latency.
6. Query Plan Changes – A change in the query itself (e.g., added joins, changed predicates) can alter the execution path.

Debug Steps:

• Run EXPLAIN to compare the current plan with the previous one.
• Check table statistics and refresh them if needed.
• Verify indexes/partitions exist and are healthy.
• Monitor system metrics (CPU, I/O, memory) during execution.
• Look for long-running sub‑queries or scans in the plan.

Addressing the root cause often involves updating statistics, adding or rebuilding indexes, rewriting the query for better cardinality, or scaling resources.