当我执行涉及3个表的SQL语句时,我遇到严重的性能问题:
表A< ---- ----表B>表C
特别是,这些表位于数据仓库中,中间的表是维度表,而其他表是事实表。 TableA有大约9百万的记录,而TableC大约有300万。维度表(TableB)只有74条记录。
查询的语法非常简单,正如您所看到的,TableA被称为_PG,TableB等于_MDT而Table C被称为_FM:
SELECT _MDT.codiceMandato as Customer, SUM(_FM.Totale) AS Revenue,
SUM(_PG.ErogatoTotale) AS Paid
FROM _PG INNER JOIN
_MDT
ON _PG.idMandato = _MDT.idMandato INNER JOIN
_FM
ON _FM.idMandato = _MDT.idMandato
GROUP BY _MDT.codiceMandato
实际上,我从未见过这个查询的结尾:-( _PG在idMandato和相同的_FM表上有一个非聚集索引 _MDT表在idMandato
上有一个聚簇索引,执行计划如下
正如您所看到的,瓶颈是由于Stream Aggregate(成本的33%)和Merge Join(成本的66%)。特别是,流聚合突出了大约400亿个估计行! 我不知道原因,我不知道如何处理以解决这个不好的问题。 我使用安装了Windows Server 2012 Standard的虚拟服务器的SQL Server 2016 SP1,带有4个Cpu内核和32 GB RAM,1,5TB在专用卷上组成带有SSD缓存的SAS磁盘。 我希望有人能帮助我理解。
提前致谢
答案 0 :(得分:0)
最可能的原因是因为您从两个维度获得笛卡尔积。这会不必要地增加行数。解决方案是在执行// Parent Component
import { Thing } from '../thing'
export default class SomeParent extends React.Component<Props, {}> {
public render() {
return (
<Prem
Thing={Thing}
/>
)
}
}
// Prem file
export interface Props {
Thing: What goes here?
}
export default class Prem extends React.Component<Props, {}>{
// Do stuffs
public render() {
return (
<Thing>
<div> herp derp </div>
</Thing>
)
}
}
之前进行聚合。
您还没有提供样本数据,但这是个主意:
join
我并非100%确定这会解决问题,因为您的数据结构不明确。
答案 1 :(得分:0)
您可以尝试在TableA和TableC之间执行子查询而不进行聚合,然后将此子查询与TableB连接并应用GROUP BY:
SELECT _MDT.codiceMandato, SUM(A.Totale) AS Revenue, sum( A.ErogatoTotale)
AS Paid
FROM ( SELECT m.idMandato, _FM.Totale, _PG.ErogatoTotale FROM _PG
INNER JOIN _FM
ON _FM.idMandato = _MDT.idMandato ) A
INNER JOIN _MDT ON A.idMandato = _MDT.idMandato
GROUP BY _MDT.codiceMandato