标签: query-performance

我仍然是查询优化的新手，我有一个存储过程，它使用游标遍历表中的每一行，并执行以下操作：

1. 计算每行之间的时间差
2. 计算每行之间的距离
3. 如果距离 < 5 AND TimeDifference > 3 分钟，则添加到 TEMP 表

我尝试将此 Cursor 转换为 WHILE 循环，但性能下降。所以我需要帮助将其转换为SET BASED方法而不是Procedural Based方法

所以 Cursor 执行这个逻辑：

-- READ Current Row into Cursor Variables
FETCH NEXT FROM crAssetIgnitionOnOff INTO
              @current_iVehicleMonitoringID
            , @current_iAssetID
            , @current_dtUTCDateTime
            , @current_sptGeoLocationPoint
            , @current_fLatitude
            , @current_fLongitude
            , @current_fAngle
            , @current_fSpeedKPH 
            , @current_sIgnitionStatus
            , @current_eEventCode
            , @current_sEventCode

IF(@current_iAssetID = @prev_iAssetID)
    BEGIN

        ---- Calculate Time Difference from previous Point
    DECLARE @diffInSeconds INT
        SET @diffInSeconds = DATEDIFF(SECOND, @prev_dtUTCDateTime, @current_dtUTCDateTime) …

我有一个标量函数，它返回一个大的 XML，它是通过一堆发票创建的。

可以使用几种不同的方法计算要提供给函数的确切发票列表，但函数每次都是相同的。出于这个原因，我声明了一个用户定义的表类型来包含表中的主键eInvoice.Header并将其传递给函数。这样我就可以有几个不同的函数来决定要处理哪些发票，并且只有一个函数可以实际生成 XML：

create function eInvoice.GetRelevantLinesInOneWay()
returns table ...

create function eInvoice.GetRelevantLinesInAnotherWay()
returns table ...

create function eInvoice.GetXML(@lines eInvoice.InvoicePrimaryKeys readonly)
returns xml
as
begin
    declare @x xml;

    with xmlnamespaces(N'important namespace' as pro)
    select @x = (
        select
            ...
        from
            eInvoice.Header h
            inner join @lines l on h.ST_PRIMARY = l.invoice_row_id
        for xml path(N'pro:Import'), type
    );

    return @x;
end;

不幸的是，这种设置已被证明是非常脆弱的。

通常@lines包含大约 150 行（大约1min eInvoce.Header）。正确的执行计划是在 上使用索引查找ST_PRIMARY，当我将 的主体eInvoice.GetXML作为临时查询执行时，总是会发生这种情况。

然而，当我将它存储为一个函数时，它会按预期工作一段时间，然后发生了一些事情（太多行@lines，比如大约300 …

我有大约 150 万条记录。此查询适用于较小的数据，但每几十万条记录就会慢一秒。对于 150 万，查询明显困难。

我模拟了一个全新的 Code First 项目来验证问题与我的实现无关，并提供以下示例查询：

    SELECT TOP 1 Widgets.*
    FROM [WidgetSandbox].[dbo].[Widgets] Widgets
    INNER JOIN [WidgetSandbox].[dbo].[Status] Statuses ON Widgets.StatusId = Statuses.Id
    INNER JOIN [WidgetSandbox].[dbo].[Colors] Colors ON Widgets.ColorCode = Colors.ColorCode
    INNER JOIN [WidgetSandbox].[dbo].[Sizes] Sizes ON Widgets.SizeId = Sizes.Id
    WHERE Statuses.Name = 'Available'
    AND Colors.Name = 'Red'
    ORDER BY Sizes.DiameterInches

DiameterInches 是一个int, 作为我实际代码中“PriorityLevel”的隐喻。

如果我注释掉ORDER BY Sizes.DiameterInches，它会立即返回，但如果我想找到“最小的可用红色小部件”，它就会爬行。

有没有更好的办法？

执行计划 XML：https : //gist.github.com/RobertBaldini/57c8b61d135cc5c84c38b2da243611ad

DDL：https : //gist.github.com/RobertBaldini/3740c7bb85eea47d7fe63cb8602ac2d6

回购（数据加载器需要几分钟）：https : //github.com/RobertBaldini/WidgetSandbox

环境信息

• 操作系统：Windows Server 2012 R2（64 位）
• 内存：16.00GB
• CPU : Intel(R) Xeon(R) CPU E5-2609 @ 2.40GHz
• SQL：Windows SQL Server 2012 标准版

简要数据库数据信息

• 10多张表中，其中一张有varbinary(max)类型的列
• 该表有超过1m的记录，每列都有缩略图数据，大约占20k

简表规格

• 表名：注册缩略图
• 列名：UserId、ThumbData、已创建、已更新
• 列类型：int、varbinarymax、datetime、datetime
• 已用空间信息：行：1,034,300 | 保留：34,092,160 KB | 数据：34,054,872 KB | 索引大小：31040 KB | 未使用：6248 KB

询问

SELECT * FROM RegisteredThumbnail WHERE UserId = 512315

此查询需要大约 6:45 分钟才能获取预期的行。

为了克服这个问题，索引是我唯一的选择吗？

通过将二进制数据替换为图像 url 作为字符串数据来更改图像数据的存储方式会有很大帮助吗？

由于这是当前的操作系统，因此更改列并不是一个好主意。

任何想法将不胜感激。

尚未配置索引。

1. SET TRANSACTION ISOLATION LEVEL READ UNCOMMITTED 位于“BEGIN”的不同部分。以下两个查询的行为是否相同？

2. 视图 viewOne 和 viewTwo 会继承脏读吗？或者视图需要有一个明确的“NOLOCK”

查询 1

set transaction isolation level read uncommitted
begin    
    select col1 from viewOne
    select * from viewTwo
    select * from table1
end

查询 2

begin    
    set transaction isolation level read uncommitted
    select col1 from viewOne
    select * from viewTwo
    select * from table1     
end

我正在尝试对一些外部空间表执行查询，这比在普通空间表上运行的时间长几个数量级，因为没有使用索引。

索引似乎正在处理非空间查询。

这是应该工作的东西还是不受支持？

有什么办法可以优化FOR XML PATH语句吗？或者也许我应该使用另一种方法？

目前的方法根本不可接受。这需要几分钟。我知道视图是一个非常大的联盟，需要时间来消耗它，但也许是另一种方式......

这是查询：

SELECT t.serialNumber as TVM
  ,[issuanceDate] as transactionDate
  ,ioy.tvmTransactionId as TVM_TRANS_ID
  ,STUFF((SELECT ', ' + stv.carrierSN
    FROM HERMES.wts.v_SaleTransactionView as stv
    WHERE stv.tvmTransactionId = ioy.tvmTransactionId
    and stv.serialNumber = 'M040'
    FOR XML PATH ('')), 1, 2, '') as [serial_numbers]
  FROM [hermes].[wts].[IOYLog] ioy
  left join Hermes.hermes.Terminals t on ioy.tp_terminalId = t.tp_terminalId
  left join hermes.hermes.POS p on t.tp_POSId = p.tp_POSId
  left join [Hermes].[wts].[IOUPaymentStatus] [is] on [is].[tp_paymentStatusId] = ioy.status
  WHERE [is].includeInReports = 1 
  and (issuanceDate BETWEEN '2017/09/01' AND '2017/09/08') …

我有迟钝。

任何人都可以查看此计划(PasteThePlan) 并告诉我需要优化的内容吗？这是实际的计划。

这是从应用程序获取客户信息的过程的一部分。在跟踪中我发现查询需要很长时间。大约需要 14 秒，而在另一个 POS 中则不到 1 秒。

我使用的是 SQL Server 2016 - Express Edition

我有 2 个虚拟机：

• VM1 - 8 核 32GB 内存

• VM2 - 8 核 64GB 内存

我使用 SSIS 目录在两个 VM 上同时运行相同的进程，所有进程都在它自己的 VM 上执行，因此没有信息通过网络传输..Aaa我发现这些进程的加载时间在 VM2 上相当慢。

加载：

• VM1- 15m

• VM2- 45m

我检查了一些性能指标并进行了一些基本测试...在加载期间我可以看到 Network I/O Waits

• VM1- 600 毫秒/秒

• VM2- 750 毫秒/秒

我假设这个网络 I/O 等待来自 SSIS，因为 SSIS 正在对 SQL Server 执行查询，然后批量插入信息，等待统计告诉我这两种情况的等待类型都是 ASYNC_NETWORK_IO。

我还使用 SP_SPACEUSED 进行了测试，以查看同时插入两个表中的行数，结果不是非常准确，但 VM1 几乎使插入的行数翻了一番......

我错过了任何进一步的测试吗？你想到的其他检查吗？

我有以下存储过程需要将近一个小时才能完成。结果集大约有 20 万台机器。

我所做的只是从链接服务器中提取一组 id，在本地服务器中删除这些 id，然后从远程服务器中提取这些 id 的所有详细信息并插入它们。INSERT 占 90%，DELETE 表占 9%，SELECT INTO 占 1%。

id 是主键/聚集索引。

    DECLARE @ProcessDate DATETIME
    SET @ProcessDate = CONVERT(VARCHAR(10), DATEADD(DAY, -3,
                                                    GETDATE()), 111)

    SELECT  DISTINCT id
    INTO    #temp_machines
    FROM    remote_server.db.dbo.table1
    WHERE   dt_modify >= @ProcessDate

    DELETE  FROM local_server.db.dbo.table2
    WHERE   id IN ( SELECT id  FROM  #temp_machines )

    INSERT  INTO local_server.db.dbo.table2
    SELECT  *
    FROM    remote_server.db.dbo.table1
    WHERE   id IN ( SELECT id  FROM  #temp_machines )

有什么关于提高性能的建议吗？