我有这个非常古老的SLOW查询,我正在尝试优化,但我不确定我可以做什么,但在WHERE,JOIN和ORDER BY中涉及的列上添加更多索引。
查询:
SELECT TOP 400 jobticket.jobnumber, jobticket.typeform, jobticket.filename, jobticket.req_number, jobticket.reqd_del_date, jobticket.point_of_contact, jobticket.status, jobticket.DapsDate, jobticket.elpod, job_info.IDOrderMaskedStatus, job_info.job_status, job_info.SalesID, job_info.location, job_info.TOMetadataID
FROM jobticket WITH (NOLOCK)
INNER JOIN job_info WITH (NOLOCK) ON job_info.jobnumber = jobticket.jobnumber
WHERE
(
NOT(
(jobticket.status = 'Complete' OR jobticket.status = 'Completed')
and (job_info.job_status = 'Actualized' OR job_info.job_status = ''
OR job_info.job_status = 'Actualized Credit Billed'
OR job_info.job_status = 'DWAS Actualized' OR job_info.job_status = 'DWAS Actualized Credit Billed'
)
)
or
((SELECT COUNT(job_status) AS Expr1 FROM tblConsolidatedBilling AS tblConsolidatedBilling_1 WITH (NOLOCK)
WHERE (job_status <> 'Actualized'
AND job_status <> 'Actualized Credit Billed')
AND (master_jobnumber = jobticket.jobnumber)) > 0)
)
and (jobticket.status != 'Waiting Approval' or (jobticket.status = 'Waiting Approval' and jobticket.DPGType is null))
and jobticket.typeform <> 'todpg'
and ((job_info.isHidden <> 1 or job_info.isHidden is null) and job_info.isInConcurrentRelease is null)
and job_info.deleted != '1'
and jobticket.status != 'New Job'
and jobticket.status != 'PRFYCLSFD'
ORDER BY
job_info.expediencyLevel DESC,
jobticket.jobnumber DESC
老实说,我不知道如何处理这个问题。
我应该在WHERE JOIN和ORDER BY中涉及的所有列上添加单个非聚簇索引吗?
这些表上有很多索引,但我不确定它们是否对此查询有帮助:
答案 0 :(得分:1)
看看这个SQL,我真的没有看到任何用于获取行的明确标准。看起来它只是用不同的标准排除了很多行。我的猜测是门票通常最终处于大多数行的状态,结果中不包括这些票?
问题在于,它确实没有明确的标准,并且它有很多不同的规则,这就是为什么它最终进行聚簇索引扫描+所有行的键查找。扫描从jobinfo开始,但我不确定如果从jobticket开始它会有什么不同。
删除大多数索引可能是一个很好的起点,但它根本不会加速选择。
查询看起来很复杂,所以我的猜测是你不能创建一个包含这些数据的索引视图。这可能有助于假设经常执行此查询并且数据没有那么多改变(并且已经删除了维护大量索引的开销),但这可能是不可能的。
另一个想法是在排除行时调查规则,并且是否有可能有更明确的规则,因此可以通过在表中添加持久计算列来对其进行索引。
你还没有提到它实际需要多长时间,以及表格中有多少行,所以一切都基本上只是猜测。将更多数据+统计数据包含在问题中可能有所帮助。
PS。除非在特殊情况下,否则我个人不建议使用NOLOCK,因为它可能导致难以解决的问题,例如多次读取相同数据或完全跳过行。
答案 1 :(得分:1)
一个简单的解决方法是使job_info和tblConsolidatedBilling上的索引覆盖,因为那里的密钥查找花费了大量时间。这应该给出一个整数因子加速。如果这还不够,我们需要进一步调查。