我有一个接收参数的过程，并根据这些参数进行动态声明。该语句始终返回一个数值。如何返回该值，或将其传递给变量？
例如以下：
DECLARE VAR1_INPUT INT;
DECLARE SQLSTRING VARCHAR(5000);
DECLARE OUTPUTVAR INT;
SET VAR1_INPUT = 5;
SET SQLSTRING = 'select next value into :OUTPUTVAR for MYSCHEMA.MYSEQUENCE_'||CAST(VAR1_INPUT AS VARCHAR(25))||' from sysibm.sysdummy1';
EXECUTE IMMEDIATE SQLSTRING;
我想我可以使用游标，但这将执行很多并且需要轻量级，我宁愿避免使用游标。并且不要专注于上面的无意义的动态 SQL，这只是一个示例。:)
编辑：原始问题从表中选择一个值作为问题。答案与此相符，因此我将其标记为正确答案。后来我意识到序列的工作方式不同，所以我编辑了这个问题。这部分我一直想不通。
我们有一个场景，我们需要向不同的表添加多行，获取生成的主键 ID，然后使用 FK 引用先前生成的 ID 等创建更多插入。在 SQL Server 上，您可以只使用 OUTPUT 子句来存储插入的行和生成的 ID，然后引用它们。但显然在 db2 上，除了选择之外，您不能将 FINAL TABLE 结果用于任何内容。
因此，我们希望将 excel 表中的一堆数据插入到表A中，然后将生成的 ID 匹配到 excel 数据集中，并在表B、C等上插入更多行。
是否有另一种方法可以以可用的格式存储插入的记录。最好没有需要编译程序的东西，这样我们就可以一次运行执行脚本吗？下面是一个准代码示例，这显然行不通。
DECLARE GLOBAL TEMPORARY TABLE SESSION.TEMP
(ITEM_IDENTIFIER,
TABLE1_ID INT)
ON COMMIT PRESERVE ROWS;
INSERT INTO SESSION.TEMP (ITEM_IDENTIFIER, TABLE1_ID)
SELECT IDENTIFIER, ID
FROM FINAL TABLE
(INSERT INTO MYSCHEMA.MYTABLE (IDENTIFIER, ID /*...other columns*/)
SELECT *
FROM
(SELECT 'asd123' IDENTIFIER /*...other columns*/ FROM SYSIBM.SYSDUMMY1
UNION
SELECT 'bsb234' /*...other columns*/ FROM SYSIBM.SYSDUMMY1
UNION
SELECT 'dasd654_' /*...other columns*/ FROM SYSIBM.SYSDUMMY1
/* etc.. */) s
);
似乎很难在系统版本化的时态表和旧选项（例如 DB 触发器和 CDC）之间找到比较。我目前没有时间在 SQL Server 2016 上编写扩展测试，所以我想我会在这里问一下。
基本上，触发器的典型优势是它们在独立和集群/alwaysOn 环境中更易于管理，可以实时同步，并且可以访问用户 ID 等会话数据。
另一方面，CDC 虽然需要更多的管理并且是异步的，但要轻得多，因此性能要好得多。因此，如果有任何疑问，由触发器引起的瓶颈可能会成为一个问题，CDC 基本上将是更好的解决方案。在硬件要求方面，由于使用日志和 cdc 审计表来跟踪更改，CDC 对额外空间的要求可以忽略不计。
问题：时态表与上述两个相比如何？在速度、性能、存储空间使用方面。何时应该使用临时表而不是触发器或 CDC？我什么时候不应该？
我理解任何像数据库审计背后的业务需求和技术限制这样潜在复杂的事情都不会有一个简单的答案，因为它在很大程度上取决于项目的需求和范围。但是，任何能更清楚地说明上述问题的事情都将不胜感激。谢谢！
（注意，我在 2021 年回到了这个问题，并添加了我所学到的知识作为对原始问题的答案。你会在下面找到它。）
所以我最近才在始终在线的 AG 上启用 CDC。虽然许多消息来源声称在 alwaysON AG 上启用 CDC 就像在任何独立服务器上一样容易，但事实证明并非如此。正如MS所说：
您应该在故障转移之前在所有可能的故障转移目标上创建[CDC capture & cleanup]作业，并将它们标记为已禁用，直到主机上的可用性副本成为新的主副本。当本地数据库成为辅助数据库时，也应禁用在旧主数据库上运行的 CDC 作业。要禁用和启用作业，请使用 sp_update_job (Transact-SQL) 的 @enabled 选项。有关创建 CDC 作业的详细信息，请参阅 sys.sp_cdc_add_job (Transact-SQL)。
事实证明，在我们在主副本上启用 CDC 后，辅助副本上绝对没有发生任何事情。因此，按照 MS 的建议，我进行了手动故障转移，并在那里创建了作业，然后又进行了一次故障转移回原来的主服务器。
显然，正如上面引用中所暗示的那样，CDC 应该与 alwaysOn AG 完全兼容，它完全无法确定它当前是在主副本还是在辅助副本上运行。
那么，在不影响背景的情况下，让我们来回答我的问题：您如何保证在当前主副本上始终启用 CDC 作业？并且总是在辅助节点上禁用（以免产生错误）？
显然，alwaysOn AG 中的一个重要点是，您不需要在主服务器因任何原因出现故障时手动到那里，因为辅助服务器将填补空缺并保持系统在线，我认为它应该只是创建每个副本上的作业，不断地轮询它们的状态并改变 CDC 作业的状态？
如果这是正确的，您对如何进行此操作、具体脚本或指南等有任何具体建议吗？因为对于在全球范围内显然应该是一个相当普遍的困境，我不得不在每个副本上手动创建一个新的 TSQL 作业只是为了执行 CDC 与 alwaysOn AG 的基本基本基本功能，这似乎很奇怪.
这似乎不太可能，这就是我问的原因。还是我误会了什么？谢谢！
我们有一个带有 DBO 的登录/用户到单个数据库，现在我们正在添加一个查询，该查询提供一些基本的监控信息，需要将权限稍微扩展到系统管理员端。
基本上，查询需要能够运行（只读）以下命令：
DBCC SQLPERF(logspace)
EXEC master..xp_fixeddrives
dbo.sysfiles
sys.master_files
tempdb.sys.database_files
tempdb.sys.dm_db_file_space_usage
sys.dm_exec_requests
sys.dm_tran_locks
sys.partitions
sys.indexes
sys.dm_os_waiting_tasks
sys.dm_os_tasks
sys.dm_exec_sessions
sys.dm_exec_sql_text
其中大部分内容都需要诸如查看服务器状态、查看任何定义等权限，所有这些都可以用于授予所需的权限，而无需进入系统管理员服务器角色。但是我们只想将这些权限限制在这个单一的查询中。
所以我们正在寻找的是选项。我最后的首选选项是向登录名/用户添加各种权限，因为这样它就可以访问超出其需要的权限（sysadmin 服务器角色的各种子权限），所以我尝试使用 EXECUTE AS 创建一个过程子句，显然只是因为内部的动态 SQL（我们需要将 DBCC SQLPERF 的结果输出到表变量中），所有权链接变得困难。即便如此，允许使用边界系统管理员凭据执行过程似乎也很棘手。
我浏览了更多关于这个主题的内容，但我无法理解，但我仍然无法让它发挥作用。基本上，你们能告诉我如何在不产生安全漏洞的情况下做到这一点吗？
只是一个运行这个查询的批处理，只能由系统管理员更改，并且可以被任何有权运行它的人读取/执行？谢谢！
编辑：
我目前正在研究创建代理登录和/或使用证书签署程序的可能性。似乎是一个很有趣的选项。
我刚刚注意到一些奇怪的事情。我们在一个具有只读辅助副本的环境中使用 AlwaysOn 可用性。但是，检查辅助副本的 .mdf / .ldf 文件，它显示了几个月前的修改时间。同样，在辅助副本中使用sp_helpdb 'DBNAME'，它声称空间明显小于主节点中的空间。
尽管如此，数据库在 SSMS 对象资源管理器中显示为已同步，并且在读取数据库中的数据时，很明显最新数据已正确复制。
这不是问题，我只是想了解发生了什么，因为我似乎无法通过谷歌搜索找到这些信息。为什么空间使用情况似乎没有正确更新？是权限问题，还是只读模式本身的症状，还是什么？
谢谢！
正如主题所说，我想知道你们是否对大规模更新期间 Always On 可用性的潜在问题有任何建议？
我们需要进行几项大规模的数据模型更改、删除和添加表以及移动大量数据（大约 300+ GB），包括创建和重建数百个索引和统计信息，这个过程将花费 24 小时以上在使数据库重新联机之前，总计和计划时间不能超过 30 小时。而且我不确定始终可用模式的同步是否是将这些更改复制到其他可用性组的最佳选择。在更改完成后备份更改，将其恢复到其他组并从那里重新启用同步会更好吗？
就像我说的，我真的没有使用它的经验，所以这是一个悬而未决的问题。对于这里的任何误解或误解，再次表示歉意，因为我的经验有限。请在适当的地方纠正我。:)
谢谢！
为了简单起见：
根据MSDN（链接）以及其他来源，您可以使用以下 TSQL 位获取 tempdb 中当前可用空间的数量：
-- MSDN version
SELECT SUM(unallocated_extent_page_count) AS [free pages],
(SUM(unallocated_extent_page_count)*1.0/128) AS [free space in MB]
FROM sys.dm_db_file_space_usage;
-- The "other" version
SELECT SUM(unallocated_extent_page_count) AS [free pages],
(SUM(unallocated_extent_page_count)*1.0/128) AS [free space in MB]
FROM tempdb.sys.dm_db_file_space_usage;
现在，我们正在使用一个预定的脚本，它可以动态地做它可以做的事情，而不会过度使用空间。在今天之前，MSDN 版本在使用集群 SQL Server 2008 的环境中运行良好，但今天我发现我们使用 SQL Server 2012 和 AlwaysOn 可用性组的新环境之一表现不同。
在那里，“MSDN 版本”几乎没有返回可用空间，而“其他”版本正确显示了 tempdb 中的可用空间。
谁可以给我解释一下这个？在所有 AlwaysOn 副本组之间是否存在共享 tempdb，因此默认情况下，未专门定义 tempdb 以某种方式默认为 tempdb 的某个本地版本，或者这里到底发生了什么？我可以相信针对数据库运行的查询实际上是利用 tempdb.sys.dm_db_file_usage_space 而不是常规的 sys.dm_db_file_usage_space 所指出的？
我正在尝试自己了解更多有关此问题的信息，但我们非常迫切地需要一个答案，所以我在这里询问只是为了确定。谢谢！
我需要将 XML 从文件解析为表，同时通过自定义生成的 ID 值保留它们的关系。
例如，如果我有以下 XML：
<root>
<construction>
<constructionName>randomname1</constructionName>
<project>
<projectname>another randomname</projectname>
<businesspartners>
<partnername>bilbo bagginses</partnername>
</businesspartners>
<employees>
<employee>
<empname>frodo</empname>
<empaddress>etc...</empaddress>
</employee>
</employees>
</project>
<info>
<randElement></randElement>
</info>
<constructionType>houses</constructiontype>
</construction>
<construction>
<...(etc, same as above, times n^10)/>
</construction>
</root>
从那，我需要为下表生成数据：
CONSTRUCTION (CONSTRUCTION_ID INT PRIMARY KEY
, CONSTRUCTIONNAME VARCHAR..
, CONSTRUCTIONTYPE VARCHAR.. )
PROJECT (PROJECT_ID INT PRIMARY KEY
, CONSTRUCTION_ID INT FOREIGN KEY REFERENCES CONSTRUCTION
, PROJECTNAME VARCHAR.., )
BUSINESSPARTNERS (BUSINESSPARTNERS_ID INT PRIMARY KEY
, PROJECT_ID INT FOREIGN KEY REFERENCES PROJECT
, PARTNERNAME VARCHAR..)
etc...
基本上，这个想法是构造具有完整引用的表来表示 XML。表结构已存在，无法更改以适应此脚本。这只是一个能够执行相同类型的 XML 解析然后将数据添加到表中同时生成正确的引用 ID 值的问题，就像我们之前在集成中所做的那样。仅使用 SQL Server 专门执行此操作，而不使用 SSIS。
现在，实际情况和有问题的文件相当庞大，所以我绝不期待一个完整的答案。只是关于从哪里开始寻找的提示。我对处理 XML 非常缺乏经验。
目前，我首选的解决方案是使用 导入数据OPENROWSET，然后使用动态 SQLOPENXML将文档解析到表格中，基本上一次循环一个元素及其子元素。但这似乎比其他一些更聪明的方法更麻烦。
ID 值是如何生成的？
这是问题的一部分。目前，他们不是。这个想法是每个CONSTRUCTION元素将被分配一个ID从 1 开始增加的值。然后所有的子元素都CONSTRUCTION将引用ID分配给父元素的相同元素，依此类推。基本上，它只是将 XML 中的数据分成多个表，同时保持引用完整性不变。
使用标识列作为主键我不会有任何问题，只要关系不会因此而混淆。我不知道该怎么做，所以我假设必须以某种方式手动定义创建 ID 的逻辑，而不是身份？
由于我们的一个表超出了 INT 的范围，这是在生成数据库时没有预料到的，我们需要将 PK 字段改为 BIGINT。
然而，在处理该表时，我们在第一步就遇到了有关 tempdb 空间使用的问题：尝试删除它的主键约束，以便我们可以更改它。我们的测试环境中没有一个为 tempdb 保留超过 50 GB 的空间，而该表目前占用了大约 120 GB 的空间。该表只有 5 列，它们仅包含其他 INT 和一些短 varchar。
在涉及 tempdb 和 logfile 的地方，你们中的任何人有更好的、或许更轻的建议来做同样的改变吗？该表只有几列，所有列都包含很少的数据。下面的示例，尽可能简单。
ALTER TABLE OURTABLE DROP CONSTRAINT OURTABLE_PK
ALTER TABLE OURTABLE ALTER COLUMN OURTABLE_ID BIGINT NOT NULL
ALTER TABLE OURTABLE ADD CONSTRAINT OURTABLE_PK PRIMARY KEY CLUSTERED (OURTABLE_ID)
谢谢！
我一直在考虑创建一个具有相同定义的新表和一个 BIGINT 作为批量插入，然后在删除旧表的同时重命名它。但我不确定这是否会被证明是更好的解决方案，因为无论如何都必须在之后加入约束。
场景相当简单：作业在生产中失败，发出错误“ALTER INDEX 失败，因为以下 SET 选项的设置不正确：'QUOTED_IDENTIFIER' ...”。
问题是，为什么这个问题会出现在生产环境中，而不是出现在我们的任何测试环境中？检查 DBCC USEROPTIONS，结果在所有数据库中完全相同。此外，脚本本身根本不包含引号。它只是重建一些索引并使用全扫描更新一些统计信息。
在任何其他数据库上使用完全相同的作业，我可以将 QUOTED_IDENTIFIER 设置为 ON 或 OFF，或者根本不设置它并让它在连接默认值上运行。无论如何，它总是有效的。但在生产中，它似乎必须设置为 ON 或 OFF。
我问这个是因为时间方面我负担不起每天测试一次，我需要知道为什么会发生这个错误以及如何预测需要哪个设置以及何时需要。测试和生产数据库之间唯一明显的区别是排序规则，但即使创建测试数据库以匹配生产中的排序规则，无论 QUOTED_IDENTIFIER 设置如何，作业仍然有效。
谢谢！
这个问题比较简单。我需要计算 3 列，其中中间结果是巨大的小数，而且我很早就遇到了一个问题，SQL Server 基本上舍入小数，而不管任何转换/转换。
例如，让我们做一个简单的除法为 1234/1233。计算器将产生 1,00081103000811。但是当我在 SQL Server 上执行此操作时，我们得到以下信息：
-- Result: rounded at 1.000811000... with trailing zeroes up until the 37 precision
SELECT CAST(CAST(1234 AS DEC(38,34))/CAST(1233 AS DEC(38,34)) AS DEC(38,37))
-- Result: rounded at 1.000811
SELECT CONVERT(DECIMAL(38,32), 1234)/CONVERT(DECIMAL(38,32),1233)
-- Correct result at 1,00081103000811
-- But this requires the zeroes to be put in manually when you don't
-- even know the precision of the end result
SELECT 1234.0/1233.00000000000000
为什么会发生这种自动舍入？当您无法确定一个数字（int 或 dec 部分）有多大时，计算超长十进制值的最佳方法是什么，因为该表可以包含各种不同的值？
谢谢！
只是一个快速的问题。我有一个存储过程，它接受两个参数，一个 varchar（表名）和一个 tabletype（主键 ID 值的范围），并使用它们返回所有 FK 连接到表的所有 FK 连接以获取提供的 ID。
虽然使用起来很棘手，因为您实际上需要声明表类型，选择 ID，然后执行如下过程：
DECLARE @IDVALS SearchObjRef_Type
INSERT INTO @IDVALS
SELECT TOP 10 RAND_ID FROM RANDTABLE
EXEC usp_SearchObjRef @TABLENAME = 'RANDTABLE', @IDRANGE = @IDVALS
这工作得很好，但我想找到一种更舒适、更快速、更简单的方法来在标准选择中使用该过程。假设甚至可以在一个命令中完成所有这些，那么最好的方法是什么？
对于一个显然不起作用的逻辑示例，我想做的是以下形式：
EXEC usp_SearchObjRef @TABLENAME = 'RANDTABLE',
@IDRANGE = (SELECT TOP 10 RAND_ID FROM RANDTABLE)
这可能是一个有点奇怪的问题：
我们项目的数据模型有多个表和多个列，其中任何一个都可以用来连接一个设置表。这里的问题是如何获取用于连接到 OR 连接中的设置表的列的名称？
例如，假设查询如下所示：
SELECT FIRST.ID, SEC.ID, TRD.ID, FRTH.ID, SETS.ID, SETS.VALUE
FROM ROOTTABLE FIRST
LEFT JOIN SECONDTABLE SEC ON SEC.SECDONTABLE_ID = FIRST.SECONDTABLE_ID
LEFT JOIN THIRDTABLE TRD ON TRD.THIRDTABLE_ID = FIRST.THIRDTABLE_ID
LEFT JOIN FOURTHTABLE FRTH ON FRTH.FOURTHTABLE_ID = TRD.FOURTHTABLE_ID
-- etc...
LEFT JOIN SETTINGTABLE SETS
ON (SETS.ID = FIRST.ONESETTING_ID OR SETS.ID = FIRST.SECONDSETTING_ID
OR SETS.ID = FIRST.THIRDSETTING_ID OR SETS.ID = TRD.RANDSETTING_ID
OR SETS.ID = FRTH.ONESETTING_ID
-- etc...
)
现在，这是真正发生的事情的一个非常经过分析的例子。我们可能有几十个表，每个表都有几个连接列到 SETTINGTABLE。
显然，仅对每个 table.column 进行单独的连接就会显示所使用的列。或者，您可以在选择中使用 CASE 子句。但任何一个都很棘手，需要大量的手动输入。即使只是在选择中使用所有连接的 ID 列也可以让您比较 ID，但由于结果需要非技术人员可读，所以这不会有太大帮助。
那么有没有一种方法可以使用一些 sys 对象或类似的对象来简单地返回实际用于连接到 SETTINGTABLE 的列名？设计就是这样，不会改变。所以我只是想找到最好的方法来处理我们现有的东西。这将显着加快我们对某些脚本、查询和数据的诊断速度。
谢谢！
最近我们对我们的生产数据库运行了一个脚本，该脚本将动态删除并重新创建数百个索引作为过滤索引。虽然此脚本在之前的所有其他测试中运行良好，但在这次测试之后，SQL Server 查询计划缓存表现异常。
执行计划器显示错误使用了错误的索引，返回了数百万行，而实际上只有少数应该匹配。当索引正确时，执行计划显示 SQL Server 决定使用索引 Scan 而不是索引 Seek 提供远低于最佳结果的索引。在适当的位置使用 WITH(INDEX(indexname)) 或 WITH(FORCESEEK) 之类的表格提示，可以更正此问题。INNER LOOP JOIN 也修复了其中的一些问题。
然而，问题在于，即使像以前一样删除并重新创建这些新的过滤索引，查询计划仍然保持不变。查询计划缓存已被清除，数据库已恢复到不同的环境，统计数据已更新，显然索引已重建，因此它们不会碎片化。
目前这是一个关键问题，没有人知道如何解决。虽然我们可以强制 SQL Server 使用正确的计划，但它根本不是解决必须使用它更新的大量软件的方法，而且显然需要手动指出如何处理查询的数据库不是一个选项.
因此，我们将不胜感激任何帮助。
编辑： 我们设法修复了一个查询，方法是删除索引，重新创建过滤后的索引，然后使用 FULLSCAN 运行 UPDATE STATISTICS 表名。这解决了一些问题，并且两个连接正常工作。在此之后，我们必须对原始索引脚本中完全没有涉及的多列索引进行单独的更改，以包括连接中使用的列之一。这两个更改一起使查询计划器能够解决使用 Seek 而不是 Scan 的正确索引。
现在的理论是，由于较早的崩溃，数据库显然是通过删除底层数据库然后从备份创建一个新数据库来恢复的，而不是像以前那样仅使用 REPLACE。这会以某种方式断开 masterdb 的元数据，例如执行计划、所有缓存以及来自数据库的诸如此类的东西，从而导致新的海量数据库没有现有的计划来处理查询。这与新创建的索引上明显失败的统计信息更新组合在一起，会产生这样一种情况，即 SQL Server 不知道如何解决它被轰炸的各种查询。
然而，我不相信这仍然足够，因为一些行为，例如必须改变多列索引，以及在过去的任何先前测试环境中都不需要统计更新的事实 2几个月的测试，似乎表明还有其他地方出了问题。
几天前我们发生了一系列崩溃和恢复，之后，SQL Server 数据库一直表现得很奇怪。我们知道故障转移集群存在一些问题，因此我们不得不再次启动服务器以最终让数据库看起来正常工作。
随之而来的问题之一是，我们运行了一个大脚本，该脚本动态删除现有索引并重新创建它们，唯一的区别是它们现在使用 WHERE 列 NOT NULL 进行过滤。然而，出于某种原因，当我从 SSMS Object Explorer 中选择 SCRIPT INDEX -> CREATE TO -> NEW QUERY WINDOW 时，它提供了基本的索引创建脚本，其中索引未被过滤。当我们拥有完全权限的客户执行相同操作时，创建脚本会正确显示它已被过滤。
这可能是权限问题（在 Google 上找不到任何此类问题），还是有可能在脚本正确记录更改时，节点或查询优化器或任何不同步的东西？
类似地，以前执行良好的几个查询（并且在作为此数据库副本的不同数据库中仍然执行良好），现在通过执行计划显示它们的行为有所不同。例如，其中之一有以下问题：
这些问题的原因可能是什么以及如何开始诊断问题？如前所述，数据库是彼此的副本。唯一的区别是问题数据库在数据库被移动到故障转移集群然后再次返回到正确的节点时崩溃了。索引没有碎片化，统计数据刚刚更新，SQL Server 的查询计划器似乎负载过大。
我真的很感激一些专家的建议，关于可能的原因以及我将如何诊断实际问题，谢谢。
我们的项目运行一个非常大、非常复杂的数据库。所以大约一个月前，我们注意到包含空值的索引列所使用的空间变得太大了。作为对此的回应，我编写了一个脚本，该脚本将动态搜索包含超过 1% 的空值的所有单列索引，然后在值不为 NULL 的情况下删除并重新创建这些索引作为过滤索引。这将在整个数据库中删除并重新创建数百个索引，通常会释放整个数据库所用空间的近 15%。
现在我有两个问题：
A) 以这种方式使用过滤索引的缺点是什么？我会假设它只会提高性能，但是否存在任何性能风险？
B) 我们在删除和重新创建索引时收到错误（“无法删除索引 XYZ，因为它不存在或您没有权限”），即使事后检查时，一切都完全按预期进行。这怎么会发生？
谢谢你的帮助！
编辑：回应@Thomas Kejser
嗨，谢谢，但事实证明这是一场灾难。当时我们不明白几件事，例如：
最后，这些更改被恢复了。所以过滤索引是一个强大的工具，但您需要真正了解从这些列中提取的数据到底是什么。除了空间问题之外的普通索引很容易应用，过滤索引代表了非常定制的解决方案。它们当然不是常规索引的替代品，而是在需要它们的特殊情况下对它们的扩展。
我为自己开发的另一个工具，关于在包含数百个表的大型数据库中更轻松地创建各种 DML 操作，是一个漂亮的用户定义函数，可以轻松显示有关列的几乎所有相关信息。运行该函数将显示类型、长度、潜在的键约束（FK 或 PK）、潜在的索引以及与该列相关的潜在触发器。
代码发布在下面的答案中。可能会出现功能不起作用的情况，这取决于某些数据库设置或我们项目中不存在的功能。但它应该是相对动态的。
同样，如果您有任何类似的有用提示或建议，请不要犹豫，与我们分享！
由于我是新手而且我从未分享过，但我每天都需要一些有用的脚本，所以我认为我应该这样做。
作为一名新的 DBA，当我有一个模板时，一些数据修复 DML 操作和简单的业务逻辑分析会快得多，我可以使用该模板检查包含数百个表的非常大的数据库中的约束。Pinal Dave 的脚本（来源发布在下面的答案中）在我开始时提供了很大的帮助，但从那时起我对其进行了一些扩展以包括在相关表中搜索引用 ID 的可能性。
我希望这对你们中的一些人有用！
这是一个更普遍的问题。为什么不能在与最初添加新列相同的事务范围内添加过滤索引？解决方案当然很简单，只需进行两个事务，如果第一个事务返回错误，您可以手动取消对第一个事务所做的更改。
但同样，我对这种现象背后的技术推理很感兴趣，尤其是考虑到我以前做过这件事。我是否在 SSMS 上激活了一些有趣的过度检查？下面的示例代码，谢谢！
--CREATE TABLE TEST_TABLE (ID INT IDENTITY(1,1) PRIMARY KEY)
BEGIN TRY
BEGIN TRAN
IF NOT EXISTS (SELECT * FROM sys.columns WHERE name = 'NEWCOL_ID'
AND OBJECT_NAME(object_id) = 'TEST_TABLE')
BEGIN
ALTER TABLE TEST_TABLE
ADD NEWCOL_ID INT NULL
CREATE NONCLUSTERED INDEX NEWCOL_ID_IDX
ON TEST_TABLE (NEWCOL_ID ASC) WHERE NEWCOL_ID IS NOT NULL
END
COMMIT TRAN
END TRY
BEGIN CATCH
BEGIN
ROLLBACK TRANSACTION
PRINT(ERROR_MESSAGE())
END
END CATCH;