Thomas Franz's questions

问题：

1. 您想要/需要使用动态 SQL 在当前数据库之外的其他数据库中创建过程/函数/视图/触发器
2. 你不能在语句中指定数据库名称，CREATE VIEW tempdb.dbo.v_test AS SELECT 1; 将失败并显示错误 166：“CREATE/ALTER VIEW”不允许将数据库名称指定为对象名称的前缀。
3. ( CREATEor ALTER) 语句必须是批处理中的第一个语句，否则您将收到错误 111：“CREATE ...”必须是查询批处理中的第一个语句。. 出于这个原因，你不能简单地写USE <database>在CREATE：

DECLARE @create_sql NVARCHAR(max);
SET @create_sql = CONCAT('USE tempdb', CHAR(13) + CHAR(10),
                         'CREATE VIEW dbo.v_test AS SELECT 1 AS n;'
                        );
EXEC (@create_sql) -- fails
-- or
EXEC sys.sp_executesql @create_sql -- fails too

4. 你不能GO在EXEC()orEXEC sys.sp_executesql
   语句中使用，因为它不在 SQL 标准中（只是在 SSMS 和其他几个 SQL 工具中使用的可配置虚拟词），所以你不能简单地在 USE 和 CREATE 命令之间添加它上面的脚本就像您在创建“正常”部署脚本时在 SSMS 中执行的那样
5. 内部过程sys.sp_executesql存在于每个数据库中，并在其自己的数据库中执行给定的命令，但是可能有很多（例如一百个）数据库，因此您不能真正使用多个IF语句在要执行它的地方“硬编码”

请参阅https://www.brentozar.com/pastetheplan/?id=SyLQIPDtF (SQL 2016 Enterprise)上的执行计划

• 我有一个数据仓库表 peak_reporting_data，它跟踪每天和每小时的活动，每月包含大约 40 亿行，其中包含由 date_key 分区的聚集 columnstoreindex（每天一个分区）
• 在 peak_reporting_monats_peaks 表中，我汇总了该表并按月峰值对其进行排序/排名。有 3 种类型的活动 (kpi_type)，对于每种类型，我每月最多有 24 小时 * 31 天 = 744 行，[monats_peak] 排名从 1 到 744。它具有超过 month_key、kpi_type、monats_peak 的唯一索引。
• 对于最活跃的时间（每个 kpi_type），我需要更多详细信息，因此我编写了以下查询/视图：

    SELECT prmp.month_key
         , prd.*
      FROM mba.peak_reporting_monats_peaks        AS prmp
      LEFT LOOP JOIN (SELECT prd.date_key
                           , prd.hour
                           , prd.kpi_type
                           , prd.is_dr_brand
                           , prd.type_id_usage
                           , prd.product_identifier
                           , SUM(prd.kb) / 1024.0 / 1024.0 AS gb
                           , SUM(CAST(prd.sek AS BIGINT))  AS sek
                           , SUM(prd.anzahl)               AS anzahl
                           , SUM(prd.kb) / 439453125.0     AS gbits
                        FROM db1.mba.peak_reporting_data AS prd 
                       GROUP BY prd.date_key
                              , prd.kpi_type
                              , prd.is_dr_brand
                              , prd.hour
                              , prd.type_id_usage
                              , prd.product_identifier
                      ) AS prd
        ON prd.date_key  = prmp.date_key
       AND prd.hour      = prmp.hour
     WHERE prmp.monats_peak = 1
       AND prmp.month_key = 202107

由于在 peak_reporting_monats_peaks 中每月恰好有 3 行 monats_peak = 1，因此 SQL 服务器执行 3 个嵌套循环和查询/基于 date_key、hour 和 kpi_type 聚合大表是合乎逻辑的（这可能会在 2 秒内完成，正如我用游标测试的那样）。

但遗憾的是，它总是读取整个表（目前为 360 亿行），而 ColumnstoreIndexScan 运算符中没有任何谓词/查找谓词，无论我尝试什么。由于这个原因，查询需要 2-3 分钟才能完成，而不是 2 秒。

如果我使用 INNER LOOP JOIN 而不是 LEFT LOOP JOIN 它会删除过滤器运算符但在 JOIN 之前添加一个惰性表假脱机，通常的 INNER JOIN（没有 LOOP）将导致 HASH JOIN（再次在整个表上）。

任何想法，如何（除了带有游标的过程或多行表值函数）我可以“强制”SQL服务器进行3个简单的查找（+聚合）而不是读取大量不相关的数据？

统计数据等是正确的，它确切地知道 peak_reporting_monats_peaks 中将有 3 行，我在大 peak_reporting_data 中添加了 date_key + hour 的显式统计

DDL：

USE tempdb
GO
CREATE SCHEMA [mba] AUTHORIZATION dbo
GO
CREATE PARTITION FUNCTION pf_mba_cdr (INT)
    AS RANGE RIGHT FOR VALUES (20201101 , 20201102 , 20201103 , 20201104 , 20201105 , 20201106 , 20201107 , 20201108 , 20201109 , 20201110 , 20201111 , 20201112 , 20201113 , 20201114 , 20201115 , 20201116 , 20201117 , 20201118 , 20201119 , 20201120 , 20201121 , 20201122 , 20201123 , 20201124 , 20201125 , 20201126 , 20201127 , 20201128 , 20201129 , 20201130 , 20201201 , 20201202 , 20201203 , 20201204 , 20201205 , 20201206 , 20201207 , 20201208 , 20201209 , 20201210 , 20201211 , 20201212 , 20201213 , 20201214 , 20201215 , 20201216 , 20201217 , 20201218 , 20201219 , 20201220 , 20201221 , 20201222 , 20201223 , 20201224 , 20201225 , 20201226 , 20201227 , 20201228 , 20201229 , 20201230 , 20201231 , 20210101 , 20210102 , 20210103 , 20210104 , 20210105 , 20210106 , 20210107 , 20210108 , 20210109 , 20210110 , 20210111 , 20210112 , 20210113 , 20210114 , 20210115 , 20210116 , 20210117 , 20210118 , 20210119 , 20210120 , 20210121 , 20210122 , 20210123 , 20210124 , 20210125 , 20210126 , 20210127 , 20210128 , 20210129 , 20210130 , 20210131 , 20210201 , 20210202 , 20210203 , 20210204 , 20210205 , 20210206 , 20210207 , 20210208 , 20210209 , 20210210 , 20210211 , 20210212 , 20210213 , 20210214 , 20210215 , 20210216 , 20210217 , 20210218 , 20210219 , 20210220 , 20210221 , 20210222 , 20210223 , 20210224 , 20210225 , 20210226 , 20210227 , 20210228 , 20210301 , 20210302 , 20210303 , 20210304 , 20210305 , 20210306 , 20210307 , 20210308 , 20210309 , 20210310 , 20210311 , 20210312 , 20210313 , 20210314 , 20210315 , 20210316 , 20210317 , 20210318 , 20210319 , 20210320 , 20210321 , 20210322 , 20210323 , 20210324 , 20210325 , 20210326 , 20210327 , 20210328 , 20210329 , 20210330 , 20210331 , 20210401 , 20210402 , 20210403 , 20210404 , 20210405 , 20210406 , 20210407 , 20210408 , 20210409 , 20210410 , 20210411 , 20210412 , 20210413 , 20210414 , 20210415 , 20210416 , 20210417 , 20210418 , 20210419 , 20210420 , 20210421 , 20210422 , 20210423 , 20210424 , 20210425 , 20210426 , 20210427 , 20210428 , 20210429 , 20210430 , 20210501 , 20210502 , 20210503 , 20210504 , 20210505 , 20210506 , 20210507 , 20210508 , 20210509 , 20210510 , 20210511 , 20210512 , 20210513 , 20210514 , 20210515 , 20210516 , 20210517 , 20210518 , 20210519 , 20210520 , 20210521 , 20210522 , 20210523 , 20210524 , 20210525 , 20210526 , 20210527 , 20210528 , 20210529 , 20210530 , 20210531 , 20210601 , 20210602 , 20210603 , 20210604 , 20210605 , 20210606 , 20210607 , 20210608 , 20210609 , 20210610 , 20210611 , 20210612 , 20210613 , 20210614 , 20210615 , 20210616 , 20210617 , 20210618 , 20210619 , 20210620 , 20210621 , 20210622 , 20210623 , 20210624 , 20210625 , 20210626 , 20210627 , 20210628 , 20210629 , 20210630 , 20210701 , 20210702 , 20210703 , 20210704 , 20210705 , 20210706 , 20210707 , 20210708 , 20210709 , 20210710 , 20210711 , 20210712 , 20210713 , 20210714 , 20210715 , 20210716 , 20210717 , 20210718 , 20210719 , 20210720 , 20210721 , 20210722 , 20210723 , 20210724 , 20210725 , 20210726 , 20210727 , 20210728 , 20210729 , 20210730 , 20210731 , 20210801 , 20210802 , 20210803 , 20210804 , 20210805 , 20210806 , 20210807 , 20210808 , 20210809 , 20210810 , 20210811 , 20210812 , 20210813 , 20210814 , 20210815 , 20210816 , 20210817 , 20210818 , 20210819 , 20210820 , 20210821 , 20210822 , 20210823 , 20210824 , 20210825 , 20210826 , 20210827 , 20210828 , 20210829 , 20210830 , 20210831 , 20210901 , 20210902 , 20210903 , 20210904 , 20210905 , 20210906 , 20210907 , 20210908 , 20210909 , 20210910 , 20210911 , 20210912 , 20210913 , 20210914 , 20210915 , 20210916 , 20210917 , 20210918 , 20210919 , 20210920 , 20210921 , 20210922 , 20210923 , 20210924 , 20210925 , 20210926 , 20210927 , 20210928 , 20210929 , 20210930 , 20211001 , 20211002 , 20211003 , 20211004 , 20211005 , 20211006 , 20211007 , 20211008 , 20211009 , 20211010 , 20211011 , 20211012 , 20211013 , 20211014 , 20211015 , 20211016 , 20211017 , 20211018 , 20211019 , 20211020 , 20211021 , 20211022 , 20211023 , 20211024 , 20211025 , 20211026 , 20211027 , 20211028 , 20211029 , 20211030 , 20211031 , 20211101 , 20211102 , 20211103 , 20211104 , 20211105 , 20211106 , 20211107 , 20211108 , 20211109 , 20211110 , 20211111 , 20211112 , 20211113 , 20211114 , 20211115 , 20211116 , 20211117 , 20211118 , 20211119 , 20211120 , 20211121 , 20211122 , 20211123 , 20211124 , 20211125 , 20211126 , 20211127 , 20211128 , 20211129 , 20211130 , 20211201 , 20211202 , 20211203 , 20211204 , 20211205 , 20211206 , 20211207 , 20211208 , 20211209 , 20211210 , 20211211 , 20211212 , 20211213 , 20211214 , 20211215 , 20211216 , 20211217 , 20211218 , 20211219 , 20211220 , 20211221 , 20211222 , 20211223 , 20211224 , 20211225 , 20211226 , 20211227 , 20211228 , 20211229 , 20211230 , 20211231 , 20220101 , 20220102 , 20220103 , 20220104 , 20220105 , 20220106 , 20220107 , 20220108 , 20220109 , 20220110 , 20220111 , 20220112 , 20220113 , 20220114 , 20220115 , 20220116 , 20220117 , 20220118 , 20220119 , 20220120 , 20220121 , 20220122 , 20220123 , 20220124 , 20220125 , 20220126 , 20220127 , 20220128 , 20220129 , 20220130 , 20220131 , 20220201 , 20220202 , 20220203 , 20220204 , 20220205 , 20220206 , 20220207 , 20220208 , 20220209 , 20220210 , 20220211 , 20220212 , 20220213 , 20220214 , 20220215 , 20220216 , 20220217 , 20220218 , 20220219 , 20220220 , 20220221 , 20220222 , 20220223 , 20220224 , 20220225 , 20220226 , 20220227 , 20220228 , 20220301 , 20220302 , 20220303 , 20220304 , 20220305 , 20220306 , 20220307 , 20220308 , 20220309 , 20220310 , 20220311 , 20220312 , 20220313 , 20220314 , 20220315 , 20220316 , 20220317 , 20220318 , 20220319 , 20220320 , 20220321 , 20220322 , 20220323 , 20220324 , 20220325 , 20220326 , 20220327 , 20220328 , 20220329 , 20220330 , 20220331 , 20220401 , 20220402 , 20220403 , 20220404 , 20220405 , 20220406 , 20220407 , 20220408 , 20220409 , 20220410 , 20220411 , 20220412 , 20220413 , 20220414 , 20220415 , 20220416 , 20220417 , 20220418 , 20220419 , 20220420 , 20220421 , 20220422 , 20220423 , 20220424 , 20220425 , 20220426 , 20220427 , 20220428 , 20220429 , 20220430 , 20220501 , 20220502 , 20220503 , 20220504 , 20220505 , 20220506 , 20220507 , 20220508 , 20220509 , 20220510 , 20220511 , 20220512 , 20220513 , 20220514 , 20220515 , 20220516 , 20220517 , 20220518 , 20220519 , 20220520 , 20220521 , 20220522 , 20220523 , 20220524 , 20220525 , 20220526 , 20220527 , 20220528 , 20220529 , 20220530 , 20220531 , 20220601 , 20220602 , 20220603 , 20220604 , 20220605 , 20220606 , 20220607 , 20220608 , 20220609 , 20220610 , 20220611 , 20220612 , 20220613 , 20220614 , 20220615 , 20220616 , 20220617 , 20220618 , 20220619 , 20220620 , 20220621 , 20220622 , 20220623 , 20220624 , 20220625 , 20220626 , 20220627 , 20220628 , 20220629 , 20220630 , 20220701 , 20220702 , 20220703 , 20220704 , 20220705 , 20220706 , 20220707 , 20220708 , 20220709 , 20220710 , 20220711 , 20220712 , 20220713 , 20220714 , 20220715 , 20220716 , 20220717 , 20220718 , 20220719 , 20220720 , 20220721 , 20220722 , 20220723 , 20220724 , 20220725 , 20220726 , 20220727 , 20220728 , 20220729 , 20220730 , 20220731 , 20220801 , 20220802 , 20220803 , 20220804 , 20220805 , 20220806 , 20220807 , 20220808 , 20220809 , 20220810 , 20220811 , 20220812 , 20220813 , 20220814 , 20220815 , 20220816 , 20220817 , 20220818 , 20220819 , 20220820 , 20220821 , 20220822 , 20220823 , 20220824 , 20220825 , 20220826 , 20220827 , 20220828 , 20220829 , 20220830 , 20220831 , 20220901 , 20220902 , 20220903 , 20220904 , 20220905 , 20220906 , 20220907 , 20220908 , 20220909 , 20220910 , 20220911 , 20220912 , 20220913 , 20220914 , 20220915 , 20220916 , 20220917 , 20220918 , 20220919 , 20220920 , 20220921 , 20220922 , 20220923 , 20220924 , 20220925 , 20220926 , 20220927 , 20220928 , 20220929 , 20220930 , 20221001 , 20221002 , 20221003 , 20221004 , 20221005 , 20221006 , 20221007 , 20221008 , 20221009 , 20221010 , 20221011 , 20221012 , 20221013 , 20221014 , 20221015 , 20221016 , 20221017 , 20221018 , 20221019 , 20221020 , 20221021 , 20221022 , 20221023 , 20221024 , 20221025 , 20221026 , 20221027 , 20221028 , 20221029 , 20221030 , 20221031 , 20221101 , 20221102 , 20221103 , 20221104 , 20221105 , 20221106 , 20221107 , 20221108 , 20221109 , 20221110 , 20221111 , 20221112 , 20221113 , 20221114 , 20221115 , 20221116 , 20221117 , 20221118 , 20221119 , 20221120 , 20221121 , 20221122 , 20221123 , 20221124 , 20221125 , 20221126 , 20221127 , 20221128 , 20221129 , 20221130 , 20221201 , 20221202 , 20221203 , 20221204 , 20221205 , 20221206 , 20221207 , 20221208 , 20221209 , 20221210 , 20221211 , 20221212 , 20221213 , 20221214 , 20221215 , 20221216 , 20221217 , 20221218 , 20221219 , 20221220 , 20221221 , 20221222 , 20221223 , 20221224 , 20221225 , 20221226 , 20221227 , 20221228 , 20221229 , 20221230 , 20221231);
GO
CREATE PARTITION SCHEME ps_mba_cdr AS PARTITION pf_mba_cdr ALL TO ([PRIMARY]);
GO


CREATE TABLE mba.peak_reporting_data
     (date_key            INT            NOT NULL
    , hour                TINYINT        NOT NULL
    , kb                  DECIMAL(19, 6) NULL
    , msisdn_key          INT            NOT NULL
    , sp_account          SMALLINT       NOT NULL
    , is_dr_brand         BIT            NULL
    , type_id_usage       BIGINT         NOT NULL
    , product_identifier  BIGINT         NOT NULL
    , kpi_service         VARCHAR(15)    NULL
    , kpi_group           VARCHAR(15)    NULL
    , sek                 INT            NULL
    , anzahl              INT            NULL
    , kpi_type            CHAR(1)        NOT NULL
    , anzahl_begonnen     INT            NULL
    , anzahl_geendet      INT            NULL
    , anzahl_durchgaengig INT            NULL
    , anzahl_nur_in_hour  INT            NULL)
    ON ps_mba_cdr(date_key);
GO

ALTER TABLE mba.peak_reporting_data SET (LOCK_ESCALATION = AUTO);
GO
CREATE CLUSTERED COLUMNSTORE INDEX icc_peak_reporting_data ON mba.peak_reporting_data ON ps_mba_cdr(date_key);
GO


CREATE TABLE mba.peak_reporting_monats_peaks
     (month_key           INT            NOT NULL
    , date_key            INT            NOT NULL
    , week_day            VARCHAR(30)    NOT NULL
    , hour                TINYINT        NOT NULL
    , kpi_type            CHAR(1)        NOT NULL
    , gb                  DECIMAL(38, 6) NULL
    , sek                 BIGINT         NULL
    , anzahl              INT            NOT NULL
    , gigabit_pro_sekunde DECIMAL(38, 6) NULL
    , prozent_dr_brand    DECIMAL(9, 6)  NOT NULL
    , tages_peak          TINYINT        NOT NULL
    , monats_peak         SMALLINT       NOT NULL
    , refresh_date        DATETIME2(0)   NOT NULL) ON [PRIMARY];
GO

CREATE UNIQUE CLUSTERED INDEX iuc_peak_reporting_monats_peaks__month_key__kpi_type__monats_peak
    ON mba.peak_reporting_monats_peaks (month_key, kpi_type, monats_peak)
    WITH (DROP_EXISTING = OFF, FILLFACTOR = 98, DATA_COMPRESSION = ROW, SORT_IN_TEMPDB = ON
        , STATISTICS_INCREMENTAL = OFF, ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON)
    ON [PRIMARY];
GO
CREATE NONCLUSTERED INDEX inc_peak_reporting_monats_peaks__date_key
    ON mba.peak_reporting_monats_peaks (date_key, kpi_type, tages_peak)
    WITH (DROP_EXISTING = OFF, FILLFACTOR = 99, DATA_COMPRESSION = PAGE, SORT_IN_TEMPDB = ON
        , STATISTICS_INCREMENTAL = OFF, ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON)
    ON [PRIMARY];
GO

我添加了 DDL 并使用通常的 INNER JOIN 没有任何提示，这需要 2 分钟，因为它在扫描后添加了过滤器，但这次它做了一个嵌套循环。

如果我强制使用 HASH JOIN，我现在会得到一个新计划： https ://www.brentozar.com/pastetheplan/?id=HyLDWiPFt该计划不再有过滤器运算符，但只运行 11 秒，因为它会消除段（只有 44 43k 读取）。它还说该表已分区，但它使用了 0 个分区（错误，否则我将没有结果）。悬而未决的问题仍然是：为什么将它用作嵌套循环的过滤器。

我知道您无法获得 Columnstore Index Seek，但如果表是分区的，它至少可以将 SEEK Predicate（通常是分区）添加到 Columnstore Index Scan 运算符。

众所周知，SSMS（或者可能是 SQL Server，但我猜更多的 SSMS）会延迟PRINT消息，直到缓冲区中收集了几行（40），然后才真正打印到 SSMS 中的消息窗口（例外：打印出其他内容，例如受 UPDATE 影响的行数或批处理完成）。

所以我通常使用RAISEERROR(<text>, 0, 0) WITH NOWAIT立即打印出来。这适用于前 500 行，在此 SSMS 似乎再次开始缓冲它们之后（50 行，从 1000 行开始，缓冲区似乎增加到 1000）。

有谁知道，我如何防止这种“缓冲功能”（例如，如果我通过使用 Ola Hallengreens 维护解决方案手动运行统计更新，我更想知道它目前真正做了什么而不必使用 sp_whoisactive 等。 ）。

PS：您可以使用以下“脚本”来模拟此行为

DECLARE @i INT = 0

WHILE @i < 10000
BEGIN
    SET @i += 1
    RAISERROR('Step %i', 0, 0, @i) WITH NOWAIT
    --PRINT @i
    WAITFOR DELAY '00:00:01.0' -- wait 1 second, feel free to decrease
END

当我创建一个 COLUMNSTORE 索引时，我可以COMPRESSION_DELAY = x [minutes]在 CREATE-Statement 中指定。它延迟了封闭段中的行从增量存储到压缩列存储的移动。这样做的理由：您的导入过程不仅仅是一个简单的 INSERT，而且还有一些 UPDATE 和 DELETE。

有没有办法在不重新创建整个索引的情况下设置这个值（这在我们的大表上需要很长时间）？

COMPRESSION_DELAY我已经测试了 REBUILD 和REORGANIZE ，但他们都不理解WITH().

我有一个存储过程，它查询链接服务器上的视图。

这在 prod 上运行良好，但我们的开发服务器有一些防火墙限制，这会阻止编译。这在数据方面没有问题（因为它在开发上不是很重要），但我什至无法更改开发服务器上的过程，因为当我尝试编译它/检查语法/使用的列名等时更改程序（我收到超时）。

有没有一种方法（选项、跟踪标志等）可以用来防止这种语法检查并在开发服务器上编译过程（类似于过程中使用的表不存在时，SQL Server 只抛出一个警告）？

是否有博客/网页/信息（我没有找到任何东西），如果它具有性能优势，如果我为我的 SQL Server 使用更新的 Windows Server 版本？

示例：我在 Windows Server 2012 上运行 SQL 2016。除了那些不受支持的生命周期主题之外，将此服务器更新到 Windows Server 2016 或即将推出的 Windows Server 2019 是否有意义？如果我在 Windows Server 2016 或 Windows Server 2019 上安装新的 SQL Server 2019（如果它已退出），它会有什么不同吗？

PS：我发现这个主题的唯一一点是 - 如果我想使用 NVDIMM，我应该使用 Windows Server 2016 以获得更好的支持。

本周，我们在 SQL2014 SP2 CU11 服务器上的数据库开始在 FETCH 代码语句上抛出致命错误（严重性 20），这可以减少为：

DECLARE @dummy int
DECLARE CurName CURSOR LOCAL FOR
        SELECT TOP (1) t.id FROM dbo.t_table AS t;
OPEN CurName;

WHILE 1 = 1
BEGIN
    FETCH NEXT FROM CurName INTO @dummy;
    IF @@fetch_status <> 0 BREAK;
    PRINT @dummy
END;

DBCC CHECKTABLE 和 DBCC CHECKDB 没有发现任何问题，服务器重启也没有帮助（因为它同时发生在同一数据库的多个版本上，所以这是数据库结构问题的可能性很小）。

在具有 SQL2014 SP2 和仅 CU6 的开发服务器上，相同的语句运行没有问题（在 SQL2017 服务器上也可以）。

桌子

• 大约有 4 行 mio
• 由整数列分区
• 在两列上有一个聚类 PK（分区列加上一个 bigint）
• 有 25 个索引（我想，我应该稍微清理一下 :-)）

我需要帮助完成以下任务（几个小时后放弃）

CREATE TABLE #cities (cityId INT, city VARCHAR(100));
INSERT INTO #cities (cityId, city) 
VALUES (1, 'Metropolis A'),
       (2, 'Town B'),
       (3, 'Village C');

CREATE TABLE #assignements (assignmentID INT, cityId INT, desciption VARCHAR(100));
INSERT INTO #assignements (assignmentID, cityId, desciption)
VALUES (1, 1, 'Test Alpha Metropol'),
       (1, 2, 'Test Alpha Town'),
       (1, 3, 'Test Alpha Village'),
       (2, 1, 'Test Beta Metropol');

INSERT INTO #assignements (assignmentID, cityId, desciption)
VALUES (2, 3, 'Test Beta Village');  

我需要一个查询，返回所有加入#cities 的 assignmentID（简单 :-)），但只列出那些在 ALL assignmentID 中使用的城市。

在上面的例子中，我应该INSERT只在第一个之后返回

assignmentID  city
1             'Metropolis A'
2             'Metropolis A'

因为 Town 和 village 只使用一次（但存在两个不同的 assignmentID）

第二次后INSERT它应该返回

assignmentID  city
1             'Metropolis A'
2             'Metropolis A'
1             'Village C'
2             'Village C'

因为 C 村现在也分配给了两个 assignmentID。

当我会

INSERT INTO #assignements (assignmentID, cityId, desciption)
VALUES (3, 2, 'Test Gamma Town');  

查询不应返回任何行，因为没有城市被分配给所有三个 assignmentID（Alpha、Beta 和 Gamma）。

当然这个例子被简化了，实际上可能有任意数量的城市被分配给（当前）最多 11 个 assignmentID

任何想法，为什么以下查询中的第一个返回带有 -1，NULL 的行，尽管它有一个WHERE 1=2？

只有当我将查询放在另一个子查询中时，它才能正常工作（并返回一个空结果集）。

在 Microsoft SQL Server 2014 和 2016 上测试

DECLARE @i INT = 1

SELECT @i i, MAX(sub.id) mid
  FROM (SELECT TOP(@i) x.id
          FROM (VALUES(1), (2), (3), (4)) x(id)
         WHERE x.id > 2 + @i
         ORDER BY x.id) sub
WHERE 1 = 2

SELECT s1.i, s1.mid
  FROM (
        SELECT @i i, MAX(sub.id) mid
          FROM (SELECT TOP(@i) x.id
                  FROM (VALUES(1), (2), (3), (4)) x(id)
                 WHERE x.id > 2 + @i
                 ORDER BY x.id) sub
       ) s1
WHERE 1 = 2

我有一个临时表#termin，其中包含 3 行

当我执行以下查询时

SELECT t.termin, ttw.tourid, twt.va_nummer_int
  FROM #term AS t
 INNER JOIN plinfo.t_touren_werbeflaechentermine AS ttw
     ON ttw.termin = t.termin
  INNER JOIN wtv.t_werbeflaechentermine AS twt 
     ON twt.jahr   = t.jahr
    AND twt.termin = t.termin
    AND twt.ID_Wt  = ttw.id_wt
    GROUP BY t.termin, ttw.tourid, twt.va_nummer_int

我将得到以下执行计划：

每个表都使用匹配的索引连接。两个表都由 ps_termin(termin) 分区。

对于第一个表 (t_touren_werbeflaechentermine)，它会进行分区消除并只读取行的一个子集，而对于第二个表 (t_werbeflaechentermine)，它会扫描整个索引 ( jahr, termin, id_wt include (va_nummer_int))。

所以我的问题是：为什么它是索引扫描（而不是搜索），为什么它不消除第二个表的分区。

PS：在WITH (FORCESEEK)第二个表上使用时，它会在执行计划中切换两个表，并对第一个表进行全索引扫描...

PPS：执行计划可以在这里找到

我有一个非常复杂的查询（谁没有:-)）。在这个查询中是一个像这样的表的连接（当然原始表有更多的列）：

CREATE TABLE dbo.tbl_detail (id bigint PRIMARY key, 
                   descr varchar(300), 
                   txt varchar(MAX),
                   descr_p varchar(300)
                  );

查询中有两个连接到此表：

• LEFT JOIN dbo.tbl_detail td1 ON td1.id = main.detail_id
• LEFT JOIN dbo.tbl_detail td2 ON td2.id = main.second_id
• 查询返回约 20 万行。
• td1 输出所有列
• td2 输出除 [txt] ( varchar(max))之外的所有列

问题：

• td2 使用 HASH JOIN
• 但 td1 使用 NESTED LOOKUP（超过 200k 行；没有统计问题，因为估计是正确的）
• 当我从 td1 输出中删除 [txt] 列时，它也使用 HASH JOIN
• 当我将列更改为 VARCHAR(5000)（或更小）时，它使用 HASH JOIN
• 当我将列更改为 VARCHAR(8000) 时，它再次使用 NESTED LOOKUP
• OPTION (HASH JOIN)或者LEFT HASH JOIN会工作，但会产生一个极慢的查询计划

问题： 为什么不总是使用HASH JOIN？是否有长度限制（每列或所有输出列的总和）？

PS：Microsoft SQL Server 2014 (SP2) 开发者版