March 21, 2013 at 9:45 am
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
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
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/61537March 21, 2013 at 11:42 am
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
Viewing 4 posts - 1 through 3 (of 3 total)
You must be logged in to reply to this topic. Login to reply