Se agotó el tiempo de espera de las consultas de Ef Linq, pero las mismas consultas menos de 1 segundo en SSMS

Primero probéARITHABORT OFF en SSMS todavía es menos de 1 segundo.

Uso EntityFrameWork: 6.1.3 y Azure Sql S1 tier (lo intentaré con Tier 3 y le haré saber si algo cambia).

Uso EF Profiler para generar sql desde linq. He consultado todos los linq que he compartido, todos son menos de 1 segundo en SSMS.

Tengo 3 millones de recods en la tabla AuditLog. Un cliente con ID 3 tiene 170K registros, el otro cliente con ID 35 tiene 125 registros. Minimizaré el código.

Modelo AuditLog:

 public class AuditLog
  {
    public long? CustomerId { get; set; }

    [ForeignKey("CustomerId")]
    public virtual CustomerSummary Customer { get; set; }

    [Required]
    [Index]
     public DateTime CreatedDate { get; set; }
  }

Primera consulta:

 if (customer != null)
    {
      var customerId = customer.Id;
      var result= Dbset.Where(x => x.CustomerId == customerId).OrderByDescending(x => x.CreatedDate).Skip(0).Take(25).ToList();
    }

Si lo intento con un cliente que tiene 170k filas, da una excepción de tiempo de espera. Si trato con un cliente que tiene 125 registros, está bien.

Segunda consulta: Es lo mismo con el primero, solo incluyo clientes.

if (customer != null)
   {
      var customerId = customer.Id;
      var result= Dbset.Where(x => x.CustomerId == customerId).OrderByDescending(x => x.CreatedDate).Skip(0).Take(25).Include(x => x.Customer).ToList();
    }

El resultado es opuesto a la primera consulta. Si lo intento con un cliente que tiene 170k filas, está bien. Si lo intento con un cliente que tiene 125 registros, da una excepción de tiempo de espera.

Tercera consulta: Es lo mismo con la primera consulta, pero coincidolong? en donde para customerId.

 if (customer != null)
    {
      long? customerId = customer.Id;
      var result= Dbset.Where(x => x.CustomerId == customerId).OrderByDescending(x => x.CreatedDate).Skip(0).Take(25).ToList();
    }

El resultado es opuesto a la primera consulta. Si lo intento con un cliente que tiene 170k filas, está bien. Si lo intento con un cliente que tiene 125 registros, da una excepción de tiempo de espera.

Cuarta consulta: Es lo mismo con la segunda consulta, pero coincidolong? en donde para customerId.

 if (customer != null)
    {
      long? customerId = customer.Id;
      var result= Dbset.Where(x => x.CustomerId == customerId).OrderByDescending(x => x.CreatedDate).Skip(0).Take(25).Include(x => x.Customer).ToList();
    }

El resultado es opuesto a la segunda consulta. Si lo intento con un cliente que tiene 170k filas, da una excepción de tiempo de espera. Si trato con un cliente que tiene 125 registros, está bien.

Estoy realmente confundido. ¿Por qué unirse internamente o cambiar el parámetro del partido along? están cambiando los resultados? ¿Y por qué todas estas consultas se ejecutan en menos de 1 segundo en SSMS y dan error en ef linq?

Error:

{System.Data.SqlClient.SqlException (0x80131904): Tiempo de espera expirado. El tiempo de espera transcurrido antes de la finalización de la operación o el servidor no responde. ---> System.ComponentModel.Win32Exception (0x80004005): La operación de espera expiró en System.Data.SqlClient.SqlConnection.OnError (excepción SqlException, boolean breakConnection, Action`1 wrapCloseInAction)

Actualización (19/04/2016):

DespuésIvan Stoev sugerencia de comentarios.

¿Has probado (solo por el bien de la prueba) usando 3 y 35 codificados en lugar decustomerId ¿variable?

No recibí ningún error y las consultas son más rápidas que en SSMS.

Actualización (20/04/2016): El verdadero problema esOlfateo de parámetros. Cuando incluí o cambié el parámetro a anulable, en realidad he creado otras consultas y otros planes de consulta. Creé algunos planes con un cliente que tiene 125 registros, y otros con un cliente que tiene 170k registros de estas 4 consultas. Por eso obtuve resultados diferentes.

Respuestas a la pregunta(1)

Su respuesta a la pregunta