In SQL Server 2005, we can create temp tables one of two ways:
declare @tmp table (Col1 int, Col2 int);
or
create table #tmp (Col1 int, Col2 int);
What are the differences between these two? I have read conflicting opinions on whether @tmp still uses tempdb, or if everything happens in memory.
In which scenarios does one out-perform the other?
For smaller tables (less than 1000 rows) use a temp variable, otherwise use a temp table.
Just looking at the claim in the accepted answer that table variables don't participate in logging.
It seems generally untrue that there is any difference in quantity of logging (at least for
insert
/update
/delete
operations to the table itself though I have since found that there is some small difference in this respect for cached temporary objects in stored procedures due to additional system table updates).I looked at the logging behaviour against both a
@table_variable
and a#temp
table for the following operations.The transaction log records were almost identical for all operations.
The table variable version actually has a few extra log entries because it gets an entry added to (and later removed from) the
sys.syssingleobjrefs
base table but overall had a few less bytes logged purely as the internal name for table variables consumes 236 less bytes than for#temp
tables (118 fewernvarchar
characters).Full script to reproduce (best run on an instance started in single user mode and using
sqlcmd
mode)Results
Another difference:
A table var can only be accessed from statements within the procedure that creates it, not from other procedures called by that procedure or nested dynamic SQL (via exec or sp_executesql).
A temp table's scope, on the other hand, includes code in called procedures and nested dynamic SQL.
If the table created by your procedure must be accessible from other called procedures or dynamic SQL, you must use a temp table. This can be very handy in complex situations.
Quote taken from; Professional SQL Server 2012 Internals and Troubleshooting
TABLE VARIABLES ARE NOT CREATED IN MEMORY
There is a common misconception that table variables are in-memory structures and as such will perform quicker than temporary tables. Thanks to a DMV called sys . dm _ db _ session _ space _ usage , which shows tempdb usage by session, you can prove that’s not the case. After restarting SQL Server to clear the DMV, run the following script to confi rm that your session _ id returns 0 for user _ objects _ alloc _ page _ count :
Now you can check how much space a temporary table uses by running the following script to create a temporary table with one column and populate it with one row:
The results on my server indicate that the table was allocated one page in tempdb. Now run the same script but use a table variable this time:
Which one to Use?
For all of you who believe the myth that temp variables are in memory only
First, the table variable is NOT necessarily memory resident. Under memory pressure, the pages belonging to a table variable can be pushed out to tempdb.
Read the article here: TempDB:: Table variable vs local temporary table
There are a few differences between Temporary Tables (#tmp) and Table Variables (@tmp), although using tempdb isn't one of them, as spelt out in the MSDN link below.
As a rule of thumb, for small to medium volumes of data and simple usage scenarios you should use table variables. (This is an overly broad guideline with of course lots of exceptions - see below and following articles.)
Some points to consider when choosing between them:
Temporary Tables are real tables so you can do things like CREATE INDEXes, etc. If you have large amounts of data for which accessing by index will be faster then temporary tables are a good option.
Table variables can have indexes by using PRIMARY KEY or UNIQUE constraints. (If you want a non-unique index just include the primary key column as the last column in the unique constraint. If you don't have a unique column, you can use an identity column.) SQL 2014 has non-unique indexes too.
Table variables don't participate in transactions and
SELECT
s are implicitly withNOLOCK
. The transaction behaviour can be very helpful, for instance if you want to ROLLBACK midway through a procedure then table variables populated during that transaction will still be populated!Temp tables might result in stored procedures being recompiled, perhaps often. Table variables will not.
You can create a temp table using SELECT INTO, which can be quicker to write (good for ad-hoc querying) and may allow you to deal with changing datatypes over time, since you don't need to define your temp table structure upfront.
You can pass table variables back from functions, enabling you to encapsulate and reuse logic much easier (eg make a function to split a string into a table of values on some arbitrary delimiter).
Using Table Variables within user-defined functions enables those functions to be used more widely (see CREATE FUNCTION documentation for details). If you're writing a function you should use table variables over temp tables unless there's a compelling need otherwise.
Both table variables and temp tables are stored in tempdb. But table variables (since 2005) default to the collation of the current database versus temp tables which take the default collation of tempdb (ref). This means you should be aware of collation issues if using temp tables and your db collation is different to tempdb's, causing problems if you want to compare data in the temp table with data in your database.
Global Temp Tables (##tmp) are another type of temp table available to all sessions and users.
Some further reading:
Martin Smith's great answer on dba.stackexchange.com
MSDN FAQ on difference between the two: https://support.microsoft.com/en-gb/kb/305977
MDSN blog article: http://blogs.msdn.com/sqlserverstorageengine/archive/2008/03/30/sql-server-table-variable-vs-local-temporary-table.aspx
Article: http://searchsqlserver.techtarget.com/tip/0,289483,sid87_gci1267047,00.html#
Unexpected behaviors and performance implications of temp tables and temp variables: Paul White on SQLblog.com