Recently, there was a debate when application developers and database developers were in tussle and pointing fingers on each other for a pity performance issue 🙂
Here are few pointers over the debate and little initial development:
- Application Developer: There is poorly performing query when being executed from the application. Database developer’s needs to analyse and fix it.
- Database Developer: The query when executed from database works fine and provides relevant results quickly.
- Database Administrator: Query pulled from the plan cache – goes for a full table scan and parameterized. There are indexes defined on the predicates, but they are not getting picked-up!
This is what developers saw when executing the query from management studio.
This is the execution plan generated when query is executed from application.
Clearly, looking at highlighted operators in the plan, we can figure out that query executed by application goes for a Clustered Index Scan as opposed to Clustered Index Seek.
Why this difference?
It boils down to the parameterization datatypes!!!!
Application developer passed one parameter of “String” type in the filter predicate, which had a column of type VARCHAR. And SQL Server created a parameter of type NVARCHAR by default for any “String” literal. Hence, to match data type on both side of an equivalence operator, the column with VARCHAR datatype is implicitly converted to NVARCHAR. If we hover over the clustered index scan operator, we will see CONVERT_IMPLICIT being used to perform the conversion task (see highlighted below).
On the other hand, when the same query is executed from management studio, query uses Index Seek as no implicit conversion is required.
Possible application fix: Application developers should describe parameter types which gets passed in the query. In NET APIs parameters can be described by using SqlParameter class, that contains not only for parameter name and value, but also for parameter data type, length, precision, and scale.