Please start any new threads on our new
site at https://forums.sqlteam.com. We've got lots of great SQL Server
experts to answer whatever question you can come up with.
| Author |
Topic |
|
AskSQLTeam
Ask SQLTeam Question
0 Posts |
 Posted - 2004-01-07 : 12:39:16
|
| This article comes to us from Bill Richmond. Bill writes "The general rule is to avoid using temp tables, usually in favor of derived tables or table variables, but there are times when it seems that nothing else will do the job. Or, maybe we just inherit complex code that already makes extensive use of temp tables. Frequently, query performance against large temp tables can benefit from adding a few well-chosen indexes" Article Link. |
|
|
richmondata
Starting Member
3 Posts |
Posted - 2004-01-07 : 13:59:53
|
| Note from the author.Much to my regret, when executed, the short code examples included in the article don't actually have the problem I'm trying to address. However, I have recently had to use this technique to solve this very problem in a production SQL 2000 Enterprise Edition / sp3 environment, so I think this hint should still be relevant. |
 |
|
|
Marios Philippopoulos
Starting Member
1 Post |
Posted - 2009-06-18 : 10:40:48
|
| Hi,Thanks for the very informative article. Does this apply as well to SQL Server 2005/2008? |
|
|
|
crokusek
Starting Member
1 Post |
Posted - 2012-06-30 : 03:12:13
|
| The optimizer in SQL Server 2008 Express seems to favor a primary key defined within the temp table. I have a case where it ignores a unique clustered index created after the temp table had been populated.http://dba.stackexchange.com/questions/20195/why-are-runtimes-different-for-a-table-including-a-primary-key-versus-a-table-wi |
|
|
|
|
|
|
Article: Optimizing Performance / Indexes on Temp Tables