Sql Server query performance

I have a stored procedure on a busy database which constantly come out top in the list of expensive queries (by some way). The query is very simple, it takes a single parameter (@ID, in开发者_如何学Got) which is the primary key of the table, and selects the record that matches that ID. The primary key is an identity field with a clustered index, so I am stumped as to how to optimise this any further?

The query is as follows

CREATE PROCEDURE [dbo].[P_Call_Get]

    @ID int = null

AS

    select ID,
        AppID,
        AgentID,
        AgentLogin,
        Ext,
        VDN,
        VDNName,
        Skill,
        SkillName,
        CallFrom,
        TelNoFrom,
        ParentCallID,
        CallStart,
        ACWStart,
        CallEnd,
        Outcome,
        StageID,
        TxTo,
        TxSuccess,
        ServiceID,
        DiallerID,
        CRC,
        TSCallID,
        CallDirection,
        [Manual],
        CallBackAgent,
        CallBackDateTime,
        Notes
    from P_Call
    where (ID = @ID or @ID is null)

Not sure the best way to post the execution plan - all it shows is that 100% of the operation is taken up by the clustered index scan

I think that by using where (ID = @ID or @ID is null) you are getting a sub optimal plan. Divide this into 2 separate queries so that in the case where @Id is not null it will just look it up directly and you will get a seek rather than a scan appear in the plan. You could maybe create a View with the columns you require to avoid the repetition (i.e. the Query without any where clause)

select ID,
    AppID,
    AgentID,
    AgentLogin,
    Ext,
    VDN,
    VDNName,
    Skill,
    SkillName,
    CallFrom,
    TelNoFrom,
    ParentCallID,
    CallStart,
    ACWStart,
    CallEnd,
    Outcome,
    StageID,
    TxTo,
    TxSuccess,
    ServiceID,
    DiallerID,
    CRC,
    TSCallID,
    CallDirection,
    [Manual],
    CallBackAgent,
    CallBackDateTime,
    Notes
from P_Call

Try cleaning out procedure cache and memory buffers:

DBCC DROPCLEANBUFFERS
DBCC FREEPROCCACHE

Doing so before testing your procedure's performance will prevent the use of cached execution plans and previous results cache.

can you use table partion. it may fixed the issue.

How many rows are in the table? You do realize that a "clustered index scan" = full table scan.