Start with the workload
A slow query is a symptom, not a diagnosis. Capture the query, its parameters, frequency, and business impact before changing anything. Establish a representative baseline so that you can compare the same workload after a change.
Follow the work
An execution plan shows how a database expects to access and combine data. Look for expensive scans, unnecessary sorting, mismatches between estimated and actual row counts, and repeated operations. No single operator is automatically bad: the surrounding workload matters.
Make one considered change
Review indexing, filtering, statistics, and data access patterns. An additional index can help reads while increasing write and storage costs. Test with representative data and concurrency, document the result, and retain a rollback path.
Measure beyond one query
A faster isolated query does not guarantee a healthier system. Check resource usage, blocking, application behavior, and the impact on other workloads. Keep monitoring after deployment to ensure the improvement holds.