• WhiteLotus (11/30/2015)


    Actually there is 1 query which confuses me , so I added cover index (non clustered index ( key column is ABC.number with included columns – all columns in SELECT area) and the performance improves a lot ( duration drop to 0 sec from 10 sec ) for particular parameter ( the parameter is ABC.Number )

    But when it uses another parameter. the duration is still 10 secs ( it uses index scan instead of index seek)

    I wonder why this happen as I expect it will behave the same for all parameters / value

    This is the query :

    SELECT ABC.XY_Create_Date XY_Create_Date,

    ABC.ABC_Id ABC_Id,

    dbo.rfn_IdToUserString(ABC.ABC_Id) Ticket_Number,

    ABC.Name Name,

    ABC.Status Status,

    ABC.XY_Create_User XY_Create_User,

    ABC.XY_Edit_User XY_Edit_User,

    ABC.XY_Edit_Date XY_Edit_Date,

    (cast(ABC.XY_Edit_Date as float) + 2) XY_Float_Edit_Date

    FROM ABC ABC

    WITH

    (

    READCOMMITTED

    )

    WHERE 1 = 1

    AND 1 = 1

    AND 1 = 1

    AND 1 = 1

    AND 1 = 1

    AND 1 = 1

    AND 1 = 1

    AND 1 = 1

    AND 1 = 1

    AND 1 = 1

    AND 1 = 1

    AND (ABC.Number LIKE @P1

    AND

    /*CN*/

    Memory increased a lot along with Slowness was reported so they are suppose to be correlated to each other

    Different parameter values will return different sets of rows, so potentially have different execution plans and different performance. That's expected behavior. You just won't get exactly the same performance when returning 1 row as you will when returning 1000. Without seeing the entire query and the different execution plans, it's hard to say for sure what's happening, but it sounds like it might be a case of bad parameter sniffing.

    Yes, a query that results in a scan is going to consume more resources, I/O and memory, than one that does a seek (in general, there are exceptions to this, absolutely), so that's not surprising. You'll need to look to the execution plans and the statistics on the tables involved to understand why one parameter value results in a seek and the other results in a scan. It's entirely possible that for the value in question, a scan is actually more efficient.

    "The credit belongs to the man who is actually in the arena, whose face is marred by dust and sweat and blood"
    - Theodore Roosevelt

    Author of:
    SQL Server Execution Plans
    SQL Server Query Performance Tuning