我对前几年的数据进行了以下查询,用了 3 个小时,今年用了 13 天。我不知道为什么会这样。任何帮助将非常感激。
我刚刚测试了旧 SQL 服务器中的查询,它可以在 3 小时内运行。因此,问题一定与我创建的新 SQL 服务器有关。你有什么想法可能是什么问题吗?
查询:
USE [ABCJan]
CREATE INDEX Link_Oct ON ABCJan2014 (Link_ref)
GO
CREATE INDEX Day_Oct ON ABCJan2014 (date_1)
GO
UPDATE ABCJan2014
SET ABCJan2014.link_id = LT.link_id
FROM ABCJan2014 MT
INNER JOIN [Central].[dbo].[LookUp_ABC_20142015] LT
ON MT.Link_ref = LT.Link_ref
UPDATE ABCJan2014
SET SumAvJT = ABCJan2014.av_jt * ABCJan2014.n
UPDATE ABCJan2014
SET ABCJan2014.DayType = LT2.DayType
FROM ABCJan2014 MT
INNER JOIN [Central].[dbo].[ABC_20142015_days] LT2
ON MT.date_1 = LT2.date1
具有以下数据结构:
ABCJan2014(7000 万行 - 没有唯一标识符 - Link_ref 和 date_1 一起是唯一的)
Link_ID nvarchar (17)
Link_ref int
Date_1 smalldatetime
N int
Av_jt int
SumAvJT decimal(38,14)
DayType nvarchar (50)
LookUp_ABC_20142015
Link_ID nvarchar (17) PRIMARY KEY
Link_ref int INDEXED
Link_metres int
ABC_20142015_days
Date1 smalldatetime PRIMARY KEY & INDEXED
DayType nvarchar(50)
这似乎是查询的这一部分需要很长时间。
再次感谢您的帮助,我正在拔头发。
原文由 hc91 发布,翻译遵循 CC BY-SA 4.0 许可协议
如果您查看执行计划,则时间在实际更新中
查看日志文件
日志文件是否在快速磁盘上?
日志文件是否在同一个物理磁盘上?
日志文件是否需要增长?
将日志文件大小调整为数据文件大小的 1⁄2
至于索引测试和调整这个
如果连接列被索引在这里没有太多可做的
从顶部 (1000) 开始以使更新调整正常工作
对于笑容,请尝试一下
请发布此查询计划
(不要向 ABCJan2014 link_id 添加索引)
如果 LookUp_ABC_20142015 未激活,则添加 nolock
nvarchar (17) PK 对我来说很奇怪
为什么 n - 你真的有一些 unicode 吗?
为什么不只是 char(17) 并让它分配空间?