我有一些流程需要在开始之前采取不同的步骤。例如：
禁用对外键的检查约束：
select 'alter table '+fk.table_schema+'.'+fk.table_name
+' NOCHECK CONSTRAINT '+fk.CONSTRAINT_NAME
from SAProduct.information_schema.table_constraints fk
join SAProduct.information_schema.tables t
on t.table_schema = fk.table_schema
and t.table_name = fk.table_name
WHERE constraint_type='FOREIGN KEY'
这将产生一个很大的语句列表，我只复制 3 个：
use saproduct
go
alter table dbo.tblProdClassificationCode NOCHECK CONSTRAINT FK_tblProdClassificationCode_tblProdClassification
alter table dbo.tblProdClassificationCodeDescr NOCHECK CONSTRAINT fk_ProdClassificationCodeDescr_ProdClassificationCode
alter table dbo.tblProdClassificationCodeGenerate NOCHECK CONSTRAINT fk_ProdClassificationCodeGenerate_ProdClassification
如果我要一次性运行它，我将如何找到我的位置？我正在处理哪张桌子，下一张是哪一张？
删除也是一样的：
select 'DELETE FROM '+table_schema+'.'+table_name
from saproduct.information_schema.tables
where table_name like 'tbl%'
上面的脚本将生成以下语句集：
use saproduct
go
DELETE FROM dbo.tblBLanguage
DELETE FROM dbo.tblBLgCategoryXRef
DELETE FROM dbo.tblBLgSegmentXRef
DELETE FROM dbo.tblProdClassification
DELETE …背景：每天都会创建几个临时表，用于计算各种不同的聚合值。它们都包含相同的唯一标识符（我将在其上创建 PRIMARY KEY 的字段）。每个表大约有 10 万行，只有 2-8 列。然后在临时表上完成几个 JOIN 和 UNION ALL。使用所有临时表中的每个字段。此外，大多数时候每一行都被使用——最坏的情况是，一半的行在某处使用，另一半在其他地方使用。查询完成后，结果将保存在磁盘上，以便个人可以访问当天剩余时间的数据。
问题：以下哪种方法应该是最好的最快的：
• 临时表上没有索引。
• 在所有临时表上都有一个聚集索引（通过唯一标识符上的 PRIMARY KEY 声明）。
• 在唯一标识符上有一个非聚集索引，同时包括所有临时表上的其余列。
• 最后两个要点放在一起。
想法：同时运行所有四个选项时，每个选项的查询成本为 25%（相对于批处理）；然而，当第一个要点运行时，执行计划（在 SELECT 查询上）指出我应该在唯一标识符上创建一个非聚集索引，同时包括每个临时表的剩余列。
我对此有些困惑。如果我有效地使用所有临时表中的每个字段和行，为什么会建议这样做？堆或聚集索引不是更好吗？
对我来说，堆可以最大限度地减少创建索引和排序数据的开销；因为我基本上需要每一行，所以进行表扫描没有坏处。
另一方面，聚集索引应该改进通过在其他两个临时表上的 JOIN 创建的临时表，并改进依赖于 JOIN 和 UNION ALL 的最终 SELECT 查询。
相关说明：在一个有 400 列和 70M 行的大表上——不要问我为什么我们有一个荒谬的列——当使用不相关的非聚集索引时，只获取 PRIMARY KEY 的查询快 50 倍聚集索引。
如果有人有任何见解，我将不胜感激。
sql-server nonclustered-index sql-server-2014 temporary-tables
我们刚刚从 SQL Server 2008 升级到 2014。除了我们在空间索引上遇到的问题之外，它进行得相当顺利。在这张桌子上，我们收到错误
无法在具有唯一索引“lu_unit__geolocation”的对象“sys.extended_index_1527780600_384000”中插入重复的键行。- 重复键值：(0x20330a3504, 95469304)。
空间索引不能有唯一约束，有问题。
我认为更安全的方法是重建索引。我做了一些实验，我发现在 160 万行上重建索引大约需要 50 秒。生产表大约有 550 万行，由于无法在线构建空间索引，因此在无法访问基表时至少需要 3 分钟。
有没有人有在最短的停机时间内重建空间索引的经验？我们可以用 30 秒但不能用 3 分钟。
我们最近在 SQL Server 2014 HADR 环境中遇到了一个问题，其中一台服务器用完了工作线程。得到消息：
AlwaysOn 可用性组的线程池无法启动新的工作线程，因为没有足够的可用工作线程
虽然我们能够通过将可用性组之一移动到另一台服务器来“解决”问题，但我想知道是否可以查看哪些查询在哪个调度程序（或工作程序或任务）上运行。
通过以下查询，我可以看到有多少工人可用、正在使用和等待资源：
declare @max int
select @max = max_workers_count from sys.dm_os_sys_info
select
@max as 'TotalThreads',
sum(active_Workers_count) as 'CurrentThreads',
@max - sum(active_Workers_count) as 'AvailableThreads',
sum(runnable_tasks_count) as 'WorkersWaitingForCpu',
sum(work_queue_count) as 'RequestWaitingForThreads' ,
sum(current_workers_count) as 'AssociatedWorkers'
from
sys.dm_os_Schedulers where status='VISIBLE ONLINE'
通过以下查询，我可以看到哪些工作人员正在哪个 CPU（核心）上运行：
SELECT *
FROM sys.dm_os_Schedulers s --> Prozessoren Kerne
JOIN sys.dm_os_workers w ON w.scheduler_address = s.scheduler_address
JOIN sys.dm_os_tasks t ON t.task_address = w.task_address
WHERE s.status = 'VISIBLE ONLINE'
AND s.cpu_id = 2
有什么方法可以找到哪个 …
我有以下查询，我希望老化配置文件显示为新列我的老化配置文件为 0-30、31-60、61-90、91-120、121-180、181-365、365+
我基本上希望结果出现在网络到期时出现在适当的老化支架中。
BU 0-30 31-60 61-90 91-120 121-180 181-365 365+
--------------------------------------------------------------
A
B
C
询问：
select
BU,
Ageing,
sum(NetDue) as Netdue
from [dbo].[vw_FACT_CONSOL_CREDITORS]
where date = @date
Group by BU, Ageing
Order by BU ;
我是 SQL 的新手，只是想学习所以很抱歉，因为这是基本的东西谢谢
在SQL服务器2014的基数估算白皮书说：
但是，新的 CE 使用更简单的算法，该算法假定大表和小表之间存在一对多连接关联。这假设大表中的每一行都与小表中的一行完全匹配。该算法返回较大输入的估计大小作为连接基数。
但它没有说明 SQL Server 如何确定什么是“大表”和“小表”以进行优化。
这些标准是否记录在任何地方？它是一个简单的阈值（例如“小表”必须低于 10,000 行）、百分比（例如“小表”必须小于“大表”中行的 5%），还是一些更复杂的函数？
此外，是否有跟踪标志或查询提示强制使用此优化进行特定连接？
最后，这个优化是否有一个可以用于进一步谷歌搜索的名称？
我问是因为我希望在主/明细表的连接中使用这种“使用大表的基数”基数估计行为，但是我的“小表”（主）是 1M 行，而我的“大表”（细节）是 22M 行。因此，我正在尝试了解有关此优化的更多信息，以查看是否可以调整我的查询以强制使用它。
我有一个关于这个查询计划的问题。
我们在测试环境中有一个表 Order_Details_Taxes，它有 11,225,799 行。该表有一个列 OrdTax_PLTax_LoadDtl_Key，它在每一行上都是 NULL。此测试环境的配置方式使此列始终为 NULL。此列上有一个索引。
我使用列的 NULL 值对该表运行了一些查询。NULL INNER JOIN 永远不会产生任何结果。
declare @Keys table (KeyValue decimal(15,0))
insert into @Keys (KeyValue) values (null)
select OrdTax_PLTax_LoadDtl_Key
from @Keys
inner join Order_Details_Taxes
on OrdTax_PLTax_LoadDtl_Key = KeyValue
select *
from @Keys
inner join Order_Details_Taxes
on OrdTax_PLTax_LoadDtl_Key = KeyValue
这些是查询计划中的第一个查询。第一个select从亿行表开始并连接到@Keys。第二个select从@Keys 开始，但它对这个表进行聚集索引扫描。
我知道在大多数情况下临时@Tables 是有问题的，所以我将查询更改为使用临时 #Table：
if object_id ('tempdb..#Keys') is not null
drop table #Keys
create table #Keys (KeyValue decimal(15,0))
insert into #Keys (KeyValue) values (null)
select OrdTax_PLTax_LoadDtl_Key …我正在使用 SentryOne 计划浏览器。
当我右键单击 SSMS 中的执行计划窗格时，第一个选项是
使用 SentryOne 计划浏览器查看
单击它会启动计划资源管理器的实例并打开执行计划。
如果我让计划资源管理器保持打开状态，然后在 SSMS 中运行另一个查询并右键单击“执行计划”窗格并再次单击“使用 SentryOne 计划资源管理器查看”，则不会发生任何事情。我原以为会打开一个新选项卡或 Plan Explorer 的新实例，或者在已经运行的实例中打开一个新选项卡？
我做错了什么还是这是一个功能？
我有一个内部 Web 应用程序正在运行，每次用户转到“搜索”视图时，它都会查询数据库中的三个不同表，以生成视图中三个下拉列表的值。
它基本上运行一个
SELECT DISTINCT (PortName)
FROM Ports
ORDER BY PortName ASC
但是该表包含约 10'000'000 行，并且负载非常重，这意味着页面的加载时间（由于加载数据下拉列表）可能会超过 10-15 秒。
那么，有没有更好的方法来做到这一点，例如以特定时间间隔运行一些脚本并在不同位置创建一个表/视图/任何内容，以便卸载查询大表，只是为了从 10'000 返回 80 行'000 在主表中？
昨天我遇到了一种情况，我的索引被重建，数据库大小增加了一倍（新大小的 50% 未使用）。Sort intempdb设置为 off，我的印象是这种重建导致了它（索引重建不在 中tempdb）。
重建过程是否有理由在完成/潜在故障后保留磁盘空间？
index sql-server maintenance sql-server-2014 index-maintenance
sql-server ×10
sql-server-2014 ×10
t-sql ×2
case ×1
dmv ×1
index ×1
join ×1
maintenance ×1
monitoring ×1
null ×1
optimization ×1
pivot ×1
spatial ×1
ssms ×1
sum ×1