【问题标题】:Improve the performance of this query (SQL-SERVER)提高此查询的性能 (SQL-SERVER)
【发布时间】:2019-03-20 21:52:21
【问题描述】:

我不知道我还能做些什么来提高这个查询的速度。我创建了非聚集索引,但结果是一样的。我有很多数据,Azure 给我带来了一些 DTU 问题。

您会推荐什么索引?

SELECT 
    SUM(t.total_amount) as SumaAmount,
        COUNT(t.id) as TotalTransaccions
FROM 
    rtv_turnover_transaction as t 
    INNER JOIN tills as till ON till.ID=t.till_id
    INNER JOIN rtv_trans_articles as ta ON t.transaction_id=ta.transaction_id
    INNER JOIN articles as art ON art.id=ta.article_id
    INNER JOIN groups ON groups.id=art.group_a_id
    INNER JOIN Clients as s ON s.id=t.cliente_id
    INNER JOIN rtv_transactions as tr ON tr.id=t.transaction_id
    INNER JOIN Ubicacion as u ON t.ubicacio_id=u.id 
    INNER JOIN Operadores as o ON t.operador_id=o.ID
where 
    tr.card_num IS NULL 
    and t.trans_date >= '2018-08-01' and t.trans_date >= '2018-09-01' 

希望你能帮助我。我是数据库新手。

【问题讨论】:

  • 你有什么索引(CLUSTEREDNONCLUSTERED)?请也包括他们的 DDL。
  • 你能上传一个实际的执行计划到这个网站吗? brentozar.com/pastetheplan
  • 将您的查询计划的输出提供给我们会有所帮助:stackoverflow.com/questions/7359702/…
  • 您可能需要检查您的 WHERE 子句:and t.trans_date >= '2018-08-01' and t.trans_date >= '2018-09-01'
  • 为什么需要所有这些连接?摆脱那些没有用处的东西。

标签: sql-server select sum


【解决方案1】:

@talendguy,首先告诉我们您的要求。为什么只需要加入这么多表才能从一个表中获取计数和总和。

仔细修改是每个表都需要的。

从您的查询看来,大多数表都与rtv_turnover_transaction 相关。

在连接条件中使用的所有 rtv_turnover_transaction 列上创建非聚集索引。

你可以留下那些属于小表的列。

如果您的查询仍然很慢,则定义PK-FK relationshipTrusted Check 约束。

这样就不需要创建那么多索引了。Trusted relationship帮助优化器

当主键和外键被定义为约束时 数据库模式,服务器可以使用该信息来创建最佳的 执行计划。

Further Reading

创建单独的Non Clustered Index on trans_date

在表 rtv_transactions 上创建非聚集索引 card_num

另外,如果READ UNCOMMITTED 数据没有问题或没有READ UNCOMMITTED 数据的机会,那么您可以安全地在所有表中使用WITH (NOLOCK) 提示。

rtv_turnover_transaction WITH (NOLOCK)

注意:我并不是要你盲目地使用WITH (NOLOCK) 提示,但如果情况允许,它会非常高效。

您可以阅读Benefit and Limitation of Nolock

【讨论】:

  • 我认为 where 子句是拼写错误
  • FK 如何消除对索引的需求?那是错的。你为什么建议他们使用 NOLOCK?这简直是​​个糟糕的建议,尤其是对于一个似乎正在处理某种金钱的系统。该提示不是没有成本的性能工具。它可以并且将随机返回丢失和/或重复的行以及许多其他“功能”。 blogs.sentryone.com/aaronbertrand/bad-habits-nolock-everywhere
  • 我稍后会回复 FK 否定索引的需要,因为解释需要时间。我从来没有说过要立即使用 WITH (NOLOCK)。仔细阅读我的声明。在某些情况下,nolock 并不总是坏事它可以非常安全地使用。
  • NOLOCK 偶尔非常很有用。永远不要关心结果的准确性。你建议使用它并且没有提供任何关于它有多糟糕的警告。并且发布的索引内容是完全错误的。也许是语言障碍,但它的阅读方式不正确。
猜你喜欢
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 2011-03-03
  • 1970-01-01
  • 2015-08-01
  • 1970-01-01
  • 2015-02-18
相关资源
最近更新 更多