小编Joh*_*hnG的帖子

这是一个我似乎无法找到答案的简单问题。

在性能方面，如果我有一个WHERE条款，例如a=0 and b=0 and ... z=0，如果我用 替换该条件，我会获得任何性能a+b+...+z=0吗？

换句话说，通过替换以下内容是否有任何性能提升

Select * 
From MyTable 
Where A=0 and B=0 and C=0 and D=0...

和

Select * 
From MyTable 
Where A+B+C+D=0...

我知道它可以依赖于索引，但为此目的，我们只说不存在索引。算术运算符 (+) 的性能是否比“OR”或“AND”逻辑运算符更好？

我的印象是加法比使用 AND 或 OR 的多个条件表现得更好。

检测结果

在 420 万行的表上

返回行其中 A=0 B=0 和 C=0 -> 351748 行

添加 (A+B+C=0) 需要 5 秒，而逻辑条件 A=0 和 B=0 和 C=0 需要 11 秒。

另一方面

返回行 其中 A<>0 B<>0 或 C<>0 -> 3829750 行 58 秒

返回行 …

在触发器中，我试图创建一个唯一的表名（使用NEWID()），我可以存储在插入和删除的表中找到的数据。

Declare @NewID varchar(50) = Replace(convert(Varchar(50),NEWID()),'-','')
Declare @SQLStr varchar(8000)
Set @SQLStr= 'Select * into [TMPIns' + @newID + '] from inserted'
Exec (@SQLStr)

我收到以下错误：无效的对象名称“插入”

我知道我可以做到：

Select * into #inserted from inserted
Set @SQLStr= 'Select * into [TMPIns' + @newID + '] from #inserted'
Exec (@SQLStr)

但是我不想使用 TempDB，因为这些表会变得很大，而且我也觉得它是多余的。有没有办法避免创建#inserted？

有人知道如何让 DBCC CheckDB 产生错误吗？我正在测试一个脚本，需要 DBCC Checkdb 以最简单的模式返回错误，同时尝试修复和尝试进入单用户模式......

我使用的简单 dbcc checkdb 命令是批处理文件的一部分，如下所示：

OSQL -S MYPC -E -d MyDB -l 10 -Q "DBCC CHECKDB(AG_DB_STORESQL)" -b -o c:\MyFolder\MSSQL_DB_CHECK.Log

如果没有发现错误，脚本结束。如果发现错误，脚本会尝试使用 REPAIR_REBUILD 选项修复它们，如果失败，脚本会尝试使用 REPAIR_ALLOW_DATA_LOSS 选项修复它们。显然，在尝试修复之前，脚本尝试将数据库置于单用户模式（这也是错误捕获的）

所以我正在寻找一种导致 DBCC CheckDB 返回错误的方法。

我的项目是在不延长事务的情况下审计我们系统中的 5 到 10 个现有表。无论使用什么方法，它都必须适用于 SQL Server Express 2005 到（最终）2016。

我已经完成了关于变更数据捕获 (CDC) 和变更跟踪的研究。更改跟踪不捕获特定更改，CDC 仅在企业版中可用。

然后我偶然发现了 Service Broker。我对 Service Broker 很感兴趣，所以我开始创建一个原型。Service Broker 工作正常，但在我的其他两个帖子中收到的答案让我相信这可能不是正确的方法。太复杂了，没什么。我仍处于分析阶段并尝试不同的事情作为我分析的一部分。

现在服务代理的结果并不令人信服……将 105000 个项目批量更新到价格表需要 38 秒，而队列（审计部分）的处理需要 17 秒……但 38 秒包括插入到 2#temp 表中的双重处理，然后用于插入到 TMPins 和 TMPdel。所以我想我可以把它减半......我现在质疑服务代理的使用......从逻辑上讲，触发器可能只需要将信息直接插入审计表中就需要相同的时间...... .

澄清一下，当我说批量插入时，它不是“批量插入”功能。我说的是一次性插入或更新的大量数据。在更新价格表中的 105000 件商品时，我想审核发生的更改。当我说发生的变化时，我决定在审计表中插入新值（如果它是插入或更新）或插入所有其他字段为空的主键（对于已删除的记录）......所以是的！它可以在数据加载后但我不想丢失任何审计（我不希望交易无序传递）

另外两篇文章将有助于了解我正在尝试做的事情和我尝试过的事情的背景：

• 触发器创建要发送给服务代理的变量表
• 触发器 - 在动态 SQL 中使用插入/删除的表

我重视每一个想法。

我正在使用 SQL Server 2019 并发现了一个奇怪的行为。研究并没有让我走得更远。

有人可以解释这种行为吗？

SET QUOTED_IDENTIFIER ON; 
if ((256 & @@options) = 256) print '1- quoted_identifier is on' else print '1- quoted_identifier is off';
BEGIN TRY 
    if ((256 & @@options) = 256) print '2- quoted_identifier is on' else print '2- quoted_identifier is off';
END TRY 
BEGIN CATCH
    if ((256 & @@options) = 256) print '3- quoted_identifier is on' else print '3- quoted_identifier is off';
    -- SET QUOTED_IDENTIFIER OFF
    -- if ((256 & @@options) = 256) print '4- quoted_identifier …

尝试创建一个大型测试数据库时，我创建了一个 SP，它使用预定义的表列表（我感兴趣的 35 个）并将每个表中的数据相乘。

换句话说，一张表有一个商店的数据。我将相同的数据插入到该表中，但具有不同的商店编号（这给了我 2 个商店）。然后我调用将 2 个商店数据乘以 4 个商店的同一个 SP，依此类推。上周末，我开始对 SP 进行 6 次后续调用，认为当我周一回来时，我的数据库将拥有 64 家商店的数据。不幸的是，事实并非如此......

当我周一来时，我发现数据高清已满，但该过程从未崩溃并且似乎已暂停。我的数据库处于简单恢复模式，我通过移动文件和缩小 TempDB（通过 SSMS 中的缩小文件选项）来腾出空间，并在外部驱动器上创建了一个初始大小为 100GB 的额外 ndf 文件......进程仍在运行（腾出空间后超过 24 小时）。

spid 的任务状态显示暂停，等待类型为 PAGEIOLATCH_EX，但等待时间很短（低于 100 毫秒），这让我相信进程仍在运行。

35 个表中有 34 个大小合适，乘法速度足够快... 该过程已将所有表中的 1 个数据存储乘以 8 个存储，并且仍在完成数据从 8 个存储到 16 个存储的乘法过程......它似乎正在处理的一张桌子是所有桌子中最大的......

将这个表的 8 个存储区的数据乘以 16 个存储区的实际过程是从 4 亿条记录中插入 4 亿条记录，该表有 200 列所有不同类型。

我是在浪费时间等待吗？恐怕杀死进程需要几天时间才能回滚......我应该等待吗？它变成了一个 Phantom 过程吗？我怎么知道它在做什么？

任何意见/想法将不胜感激。

谢谢

我有一个在全球安装的应用程序，它使用从 SQL Server 2008 Express 到 SQL Server 2017 Enterprise 版的 SQL 版本。

我尝试了几种方法在一个大表上创建索引（3 列，包含 3 列），其中数据库通常处于简单恢复模式，但可以作为完整恢复模式......硬件可能因客户而异其他：

1. 更改表创建索引...
2. 使用新索引创建一个 tmp 表，并使用“插入”复制数据，然后复制原始表的删除表，并重命名 tmp 表以替换原始表。
3. 使用新索引创建一个 tmp 表，并使用 PowerShell 脚本复制数据，然后是原始表的删除表，并重命名 tmp 表以替换原始表。

3 个中最快的是第一个选项（创建非聚集索引的传统方法），它花费了 1 小时 15 分钟来处理超过 1.06 亿条记录（该表有 200 列……不理想，但这是我正在使用的） ) 其他选项花费了三倍甚至更多的时间)

不幸的是，我无法使用在线功能，因为有多种 SQL Server 版本，并且在线仅适用于企业版。

在我的实验室中 1 小时 15 分钟太长了，我想尝试找到另一种方法来减少它，特别是在我们下一次应用程序更新中，我们将需要创建 23 个索引......而我没有' t 看到需要 5-6 小时的更新，客户也不想等待 5-6 小时来更新软件。

此外，更新过程中不需要对数据库进行任何活动。

我正在寻找的只是我可以尝试在合理的时间内创建索引的想法。没有代码！只需要理论的想法。

任何想法将不胜感激。