Two people run the exact same query on the same table, but one of them takes far longer than the other. How could that happen?

Several factors can cause identical queries to run at different speeds: 1) Caching – The first run may populate a buffer cache; subsequent runs hit the cache and finish faster. 2) Statistics & Indexes – If one session has up‑to‑date statistics or a different index hint, the optimizer may choose a different plan. 3) Parameter Sniffing – In stored procedures, the first execution can lock the plan based on the first parameter set; later executions may use a suboptimal plan. 4) Session Settings – Options like SET ANSI_PADDING, SET ARITHABORT, or SET CONCAT_NULL_YIELDS_NULL can change the plan. 5) Resource Contention – CPU, I/O, or memory pressure can slow one session. 6) Data Skew – If the query uses a hash join, the distribution of hash buckets can differ if the table has changed between runs. 7) Network Latency – For distributed databases, network hops can add latency. Diagnosing involves comparing execution plans, checking cache status, and ensuring consistent session settings.