Suggested answer

Something changed, so I look for the change rather than starting with tuning:

1. Volume growth: Check the object's record count against when the report was fast. Crossing a selectivity threshold is the single most common cause — the optimiser silently stops using an index.
2. Filter changes: Has anyone edited the report? Removing a date filter or adding a NOT IN clause will defeat an index instantly.
3. Query Plan: Run the equivalent query through the Query Plan tool to see whether the optimiser is using an index or scanning, and what it estimates the cost to be.
4. Skew: Check whether the filtered set now concentrates on a small number of parents or owners, which changes sharing evaluation cost for a private model.
5. Sharing complexity: Growth in the role hierarchy, sharing rules, or territory model increases the cost of evaluating record access for every candidate row, independently of the data volume.
6. Then fix: Restore selectivity with an indexed date range, add a custom index if the field is genuinely selective, request a skinny table for a stable hot report, or move the aggregation to a summary object refreshed on a schedule.

Practice content for interview preparation; not an official vendor answer. Verify details against current product documentation.

Community comments (0)

No comments yet.

Sign in or create a free account to add a comment. Comments are moderated before they appear.

Plain text only, 3–2000 characters. A moderator reviews every comment before it is published.