Su código en SSMS no es el mismo código que ejecuta en su aplicación. Esta línea en su aplicación agrega un parámetro NVARCHAR:
ada.SelectCommand.Parameters.AddWithValue("@clientID", ClientID);
mientras que en el script SSMS lo declaras como VARCHAR:
declare @clientID varchar(200)
Debido a las reglas de precedencia del tipo de datos, Where client_id = @clientID expresión en su consulta no es compatible con SARG donde @clientID es de tipo NVARCHAR (estoy haciendo un acto de fe y asumo que client_id columna es de tipo VARCHAR). Por lo tanto, la aplicación fuerza un escaneo de la tabla donde la consulta SSMS puede realizar una búsqueda rápida de claves. Este es un problema bien conocido y entendido con el uso de Parameters.AddWithValue y se ha discutido en muchos artículos antes, por ejemplo. consulte Cómo el código de acceso a datos afecta el rendimiento de la base de datos. Una vez que se entiende el problema, las soluciones son triviales:
-
agregue parámetros con el constructor que acepta un tipo:
Parameters.Add("@clientID", SqlDbType.Varchar, 200)(y hacer pase la longitud explícita para evitar la contaminación de la memoria caché, consulte Problemas de rendimiento de consultas y planificación de la memoria caché cuando la longitud del parámetro no se especifica correctamente -
o emita el parámetro en el texto SQL:
where client_id = cast(@clientID as varchar(200)).
La primera solución es superior porque resuelve el problema de la contaminación del caché además del problema de la capacidad SARG.
También le recomendaría leer ¿Lento en la aplicación, rápido en SSMS? Comprender los misterios del rendimiento
