gpt4 book ai didi

sql - 每一行都调用1 = 2的地方吗?

转载 作者:行者123 更新时间:2023-12-04 20:23:54 24 4
gpt4 key购买 nike

我有一些需要临时表的存储。为了不对列类型(某些长度的varchar)进行硬编码,因此在引用表模式更改(即字段变长)时不必更改声明,而是这样做(而不是创建表调用):

select orderId
into #sometmptbl
from orders
where 1=2

但是,当您对此执行显示计划时,实际上似乎要转到表/索引:

QUERY PLAN FOR STATEMENT 1 (at line 1).

STEP 1
The type of query is CREATE TABLE.

STEP 2
The type of query is INSERT.
The update mode is direct.

FROM TABLE
orders
Nested iteration.
Index : orders_idx1
Forward scan.
Positioning at index start.
Index contains all needed columns. Base table will not be read.
Using I/O Size 2 Kbytes for index leaf pages.
With LRU Buffer Replacement Strategy for index leaf pages.
TO TABLE
#sometmptbl
Using I/O Size 2 Kbytes for data pages.

Total estimated I/O cost for statement 1 (at line 1): 632082.



这是否意味着对索引中的每个条目都会评估1 = 2?有没有办法在固定时间内做到这一点?

更新:

这是执行后的实际I/O成本,因此看起来实际的读取数确实为0,因此对性能没有影响:
Table: orders scan count 0, logical reads: (regular=0 apf=0 total=0), physical reads: (regular=0 apf=0 total=0), apf IOs used=0
Table: #sometmptbl_____00002860018595346 scan count 0, logical reads: (regular=1 apf=0 total=1), physical reads: (regular=0 apf=0 total=0), apf IOs used=0
Total actual I/O cost for this command: 2.
Total writes for this command: 3
0 row(s) affected.

最佳答案

如果将统计信息设置为开,则逻辑和物理读取应为零。
它可能会创建一个计划来扫描索引,但似乎并未实际使用它。

我建议不要在大量生产环境中以这种方式创建临时表。存在系统表锁定问题以及轻微的性能下降(您的行驶里程可能会有所不同)。 (列的标识属性也将被带到临时表中)。

作为快捷方式-我将1 = 2放入显式的tempdb..MyScratchTable中,然后使用RapidSQL(或某些其他工具)从该临时表生成DDL。

如果它是一个varchar,则不应有任何理由为什么不能在最大值上标准化列长度,而只能在任何地方使用它。

关于sql - 每一行都调用1 = 2的地方吗?,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/3229884/

24 4 0
Copyright 2021 - 2024 cfsdn All Rights Reserved 蜀ICP备2022000587号
广告合作:1813099741@qq.com 6ren.com