|
|
1
8
我相信这几乎完全取决于表变量和临时表的性能。 表变量针对只有一行进行了优化。当查询优化器选择一个执行计划时,它是在假定表变量只有一行(通常为false)的情况下执行的。 我找不到一个好的来源,但至少在这里提到: http://technet.microsoft.com/en-us/magazine/2007.11.sqlquery.aspx 其他相关来源: http://connect.microsoft.com/SQLServer/feedback/ViewFeedback.aspx?FeedbackID=125052 http://databases.aspfaq.com/database/should-i-use-a-temp-table-or-a-table-variable.html |
|
|
2
4
同时运行set statistics io on和set statistics time on。每次运行6-7次,丢弃两种情况下的最佳和最差结果,然后比较两次平均值。 我怀疑区别主要来自冷缓存(第一次执行)和热缓存(第二次执行)。统计IO的输出会给出这样的情况,因为运行之间的物理读取存在很大的差异。 并确保您有测试的“实验室”条件:没有其他正在运行的任务(没有锁争用)、数据库(包括tempdb)和日志预增长到所需的大小,这样您就不会遇到任何日志增长或数据库增长事件。 |
|
|
3
2
这并不少见。表变量可以比临时表慢(在很多情况下也是如此)。原因如下:
|
|
4
1
我不是100%认为这是原因,但是表var将没有任何统计信息,而临时表将有。 |
|
|
5
1
select into是一个未记录的操作,这可能解释了大部分性能差异。insert为每个操作创建一个日志条目。 此外,select into正在创建表作为操作的一部分,因此SQL Server自动知道它没有约束,这可能会影响到它。 |
|
|
6
1
如果将7000条记录插入临时表(持久性或变量)需要一整分钟的时间,那么性能问题几乎肯定出现在填充它的select语句中。
你跑了吗?
|
|
John D · 需要为NULL或NOT NULL的WHERE子句 1 年前 |
|
Marc Guillot · 记录值时忽略冲突 1 年前 |
|
|
Fachry Dzaky · 正确使用ROW_NUMBER 1 年前 |
|
|
TriumphTruth · 从满足特定条件的数据集中选择1行 1 年前 |