Post reply

@Table vs #Table

  • March 21, 2013 at 9:45 am

    #104191

    I'll start by saying that I am a C# developer, not a DBA. When it comes to performance tweaks and making the Procs I write run the fastest they can, I trust the DBAs.

    My last job, I was told by more that one DBA that table variables run in RAM and do not access the hard drive. I worked with the DBAs for over six years and came to trust & value what they told me. I used Table Variables when ever possible and didn't use Temp Tables.

    While reworking a (messy) stored procedure at my current job the DBA told me "That is a common misconception. Table Variables and Temp Tables both access TempDB. Therefore, IO hard drive access."

    Which DBA is correct?

  • March 21, 2013 at 9:51 am

    #1599458

    The one you work with now. However, it is possible that one or both will access tempdb or that one or both will reside completely in memory. It all depends on the amount of data and the query.

    The biggest thing to remember is the table variables do not have statistics and will be treated by the optimizer as if they have one row, regardless of the actual number of rows they have. I have heard differently at times, but my experience seems to hold this to be true. Best to test for yourself.

  • March 21, 2013 at 10:42 am

    #1599478

    There's an excellent article here[/url]

    ____________________________________________________

    Deja View - The strange feeling that somewhere, sometime you've optimised this query before

    How to get the best help on a forum

    http://www.sqlservercentral.com/articles/Best+Practices/61537

  • March 21, 2013 at 11:42 am

    #1599504

    http://sqlinthewild.co.za/index.php/2010/10/12/a-trio-of-table-variables/

    The 'table variables are memory only' is an all-too-common misconception. Both temp tables and table variables are allocated space in TempDB and added to the tempDB system tables. They may however not actually be on disk, SQL will try to keep them both in memory as much as possible because it's very likely that those pages will be needed again shortly.

    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

Viewing 4 posts - 1 through 3 (of 3 total)

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