Sql Server Performance

  • Hi,

    If we create Temporay Tables in a Stored Procedure will degrade the performance of the query?

    Ex:

    CREATE TABLE #TempTable

    (id int,name varchar(50))

    INSERT INTO #TempTable

    SELECT id,name FROM Employee

    How to improve the performance of stored procedure while using temporary tables?

    Thanks,

    Suresh

  • suresh0534 (1/18/2012)


    Hi,

    If we create Temporay Tables in a Stored Procedure will degrade the performance of the query?

    Maybe, or maybe it'll improve the performance due to been able to process smaller chunks of data. You should probably only use them when they do improve things

    Gail Shaw
    Microsoft Certified Master: SQL Server, MVP, M.Sc (Comp Sci)
    SQL In The Wild: Discussions on DB performance with occasional diversions into recoverability

    We walk in the dark places no others will enter
    We stand on the bridge and no one may pass
  • suresh0534 (1/18/2012)


    Hi,

    If we create Temporay Tables in a Stored Procedure will degrade the performance of the query?

    Ex:

    CREATE TABLE #TempTable

    (id int,name varchar(50))

    INSERT INTO #TempTable

    SELECT id,name FROM Employee

    How to improve the performance of stored procedure while using temporary tables?

    Thanks,

    Suresh

    I have gotten 4+ orders of magnitude performance improvement by adding temporary table(s) to a stored procedure. I have also gotten 4+ orders of magnitude performance improvement by REMOVING temporary table(s) from a sproc. There is no right answer and doing this type of refactoring/tuning isn't something that can be covered in a few forum posts. Sorry...

    Best,
    Kevin G. Boles
    SQL Server Consultant
    SQL MVP 2007-2012
    TheSQLGuru on googles mail service

  • Hi,

    You can also use table variables for better performance but it has some limitations like,

    1. Transaction logs are not recorded for the table variables. Hence, they are out of scope of the transaction mechanism

    2. Any procedure with a temporary table cannot be pre-compiled, while an execution plan of procedures with table variables can be compiled in advance.

    3. Table variables exist only in the same scope as variables

  • deepkt (1/20/2012)


    1. Transaction logs are not recorded for the table variables. Hence, they are out of scope of the transaction mechanism

    Half true. They are out of transaction scope, but that does not mean that they are unlogged. They are logged like any other operations

    2. Any procedure with a temporary table cannot be pre-compiled, while an execution plan of procedures with table variables can be compiled in advance.

    Stored procedures are never pre-compiled. Execution plans are created on first execution only and remain until invalidated or removed from cache. In SQL 2000 temp tables did always cause recompiles, not the case in 2005 or above.

    You also neglected to mention the severe performance implication (in a bad way) from the lack of statistics on table variables. They should be avoided if the correct costing of execution plans is even a consideration.

    Gail Shaw
    Microsoft Certified Master: SQL Server, MVP, M.Sc (Comp Sci)
    SQL In The Wild: Discussions on DB performance with occasional diversions into recoverability

    We walk in the dark places no others will enter
    We stand on the bridge and no one may pass
  • If you are doing a lot of Temp table operations. You can improve performance by moving the TempDB files to a different drive and Create multiple files as oppose to one.

    This is not a direct answer but it will help on a large scale.

Viewing 6 posts - 1 through 5 (of 5 total)

You must be logged in to reply to this topic. Login to reply