Hay otras discusiones de stackoverflow sobre este mismo tema (enlaces en la parte inferior). Como se señaló en los comentarios anteriores, podría tener algo que ver con los índices y el optimizador que se confunde y usa el incorrecto.
Lo primero que pensé es que está haciendo una selección de ID de servicio superior desde (seleccione *....) y el optimizador puede tener dificultades para enviar la consulta a las consultas internas y hacer uso del índice.
Considere reescribirlo como
select top 10 ServiceRequestID
from big_table_1
inner join big_table_2 cap2
on cap1.servicerequestid = cap2.customerreferencenumber
and big_table_1.statusid = 2
En su consulta, la base de datos probablemente esté tratando de fusionar los resultados y devolverlos y LUEGO limitarlo a los 10 principales en la consulta externa. En la consulta anterior, la base de datos solo tendrá que recopilar los primeros 10 resultados, ya que los resultados se fusionan, lo que ahorra mucho tiempo. Y si servicerequestID está indexado, seguramente lo usará. En su ejemplo, la consulta busca la columna servicerequestid en un conjunto de resultados que ya se ha devuelto en un formato virtual sin indexar.
Espero que tenga sentido. Si bien, hipotéticamente, se supone que el optimizador toma cualquier formato en el que coloquemos SQL y descubra la mejor manera de devolver valores cada vez, la verdad es que la forma en que juntamos nuestro SQL realmente puede afectar el orden en que se realizan ciertos pasos en el DB.
SELECT TOP es lento, independientemente de ORDEN POR
¿Por qué es lento hacer un top(1) en una columna indexada en SQL Server?
