大规模CROSS JOIN在SQL Server 2005

StackOverflow https://stackoverflow.com/questions/354981

题

我移植其中创建了两个表的大规模CROSS JOIN的处理。结果表包含15米记录（貌似过程使得有2600行表和12000行的表30米交叉连接，然后做一些分组必须劈成两半吧）。该行是相对较窄 - 只是6列。它已经运行了没有完成的迹象5小时。我才刚刚注意到之间的计数差异的已知良好和我期望的交叉连接，所以我的输出不分组或重复数据删除，这将减半决赛桌 - 但这仍然好像不是去完成任何它不久的时间。

首先，我要看看，以消除如果在所有可能的过程中这个表 - 显然可以通过参加这两个表单独更换，但现在我没有洞察其他任何地方使用它<。 / p>

但鉴于现有流程做它（在更短的时间，一个不那么强大的机器上，使用聚焦语言），是否有改善大CROSS JOINs在SQL Server中的表现（2005年）任何选项（硬件是不是真的一种选择，该盒是一个64位的8路，32-GB的RAM）？

详细说明：

这是写在FOCUS这样（我试图产生相同的输出，这是一个跨在SQL JOIN）：

JOIN CLEAR *
DEFINE FILE COSTCENT
  WBLANK/A1 = ' ';
  END
TABLE FILE COSTCENT
  BY WBLANK BY CC_COSTCENT
  ON TABLE HOLD AS TEMPCC FORMAT FOCUS
  END

DEFINE FILE JOINGLAC
  WBLANK/A1 = ' ';
  END
TABLE FILE JOINGLAC
  BY WBLANK BY ACCOUNT_NO BY LI_LNTM
  ON TABLE HOLD AS TEMPAC FORMAT FOCUS INDEX WBLANK

JOIN CLEAR *
JOIN WBLANK IN TEMPCC TO ALL WBLANK IN TEMPAC
DEFINE FILE TEMPCC
  CA_JCCAC/A16=EDIT(CC_COSTCENT)|EDIT(ACCOUNT_NO);
  END
TABLE FILE TEMPCC
  BY CA_JCCAC BY CC_COSTCENT AS COST CENTER BY ACCOUNT_NO
  BY LI_LNTM
  ON TABLE HOLD AS TEMPCCAC
  END

因此所需的输出真的是一个交叉连接（它接合从每一侧上的空白列）。

在SQL：

CREATE TABLE [COSTCENT](
       [COST_CTR_NUM] [int] NOT NULL,
       [CC_CNM] [varchar](40) NULL,
       [CC_DEPT] [varchar](7) NULL,
       [CC_ALSRC] [varchar](6) NULL,
       [CC_HIER_CODE] [varchar](20) NULL,
 CONSTRAINT [PK_LOOKUP_GL_COST_CTR] PRIMARY KEY NONCLUSTERED
(
       [ID] ASC
)WITH (PAD_INDEX  = OFF, STATISTICS_NORECOMPUTE  = OFF, IGNORE_DUP_KEY
= OFF, ALLOW_ROW_LOCKS  = ON, ALLOW_PAGE_LOCKS  = ON) ON [PRIMARY]
) ON [PRIMARY]

CREATE TABLE [JOINGLAC](
       [ACCOUNT_NO] [int] NULL,
       [LI_LNTM] [int] NULL,
       [PR_PRODUCT] [varchar](5) NULL,
       [PR_GROUP] [varchar](1) NULL,
       [AC_NAME_LONG] [varchar](40) NULL,
       [LI_NM_LONG] [varchar](30) NULL,
       [LI_INC] [int] NULL,
       [LI_MULT] [int] NULL,
       [LI_ANLZ] [int] NULL,
       [LI_TYPE] [varchar](2) NULL,
       [PR_SORT] [varchar](2) NULL,
       [PR_NM] [varchar](26) NULL,
       [PZ_SORT] [varchar](2) NULL,
       [PZNAME] [varchar](26) NULL,
       [WANLZ] [varchar](3) NULL,
       [OPMLNTM] [int] NULL,
       [PS_GROUP] [varchar](5) NULL,
       [PS_SORT] [varchar](2) NULL,
       [PS_NAME] [varchar](26) NULL,
       [PT_GROUP] [varchar](5) NULL,
       [PT_SORT] [varchar](2) NULL,
       [PT_NAME] [varchar](26) NULL
) ON [PRIMARY]

CREATE TABLE [JOINCCAC](
       [CA_JCCAC] [varchar](16) NOT NULL,
       [CA_COSTCENT] [int] NOT NULL,
       [CA_GLACCOUNT] [int] NOT NULL,
       [CA_LNTM] [int] NOT NULL,
       [CA_UNIT] [varchar](6) NOT NULL,
 CONSTRAINT [PK_JOINCCAC_KNOWN_GOOD] PRIMARY KEY CLUSTERED
(
       [CA_JCCAC] ASC
)WITH (PAD_INDEX  = OFF, STATISTICS_NORECOMPUTE  = OFF, IGNORE_DUP_KEY
= OFF, ALLOW_ROW_LOCKS  = ON, ALLOW_PAGE_LOCKS  = ON) ON [PRIMARY]
) ON [PRIMARY]

使用的SQL代码：

INSERT  INTO [JOINCCAC]
       (
        [CA_JCCAC]
       ,[CA_COSTCENT]
       ,[CA_GLACCOUNT]
       ,[CA_LNTM]
       ,[CA_UNIT]
       )
       SELECT  Util.PADLEFT(CONVERT(varchar, CC.COST_CTR_NUM), '0',
                                     7)
               + Util.PADLEFT(CONVERT(varchar, GL.ACCOUNT_NO), '0',
                                       9) AS CC_JCCAC
              ,CC.COST_CTR_NUM AS CA_COSTCENT
              ,GL.ACCOUNT_NO % 900000000 AS CA_GLACCOUNT
              ,GL.LI_LNTM AS CA_LNTM
              ,udf_BUPDEF(GL.ACCOUNT_NO, CC.COST_CTR_NUM, GL.LI_LNTM, 'N') AS CA_UNIT
       FROM   JOINGLAC AS GL
       CROSS JOIN COSTCENT AS CC

根据如何该表随后被使用，它应该能够从该工艺中除去，通过简单地连接到两个用于构建它的原始表。然而，这是一个非常大的移植工作，我可能无法找到表一段时间的使用，所以我在想，如果有任何技巧，CROSS JOINing及时（特别是考虑到大表像，现有的工艺焦点是能够做到这一点更迅速）。这样，我可以验证我的替代查询建筑的正确性，然后后来与意见或任何因素吧。

我也在考虑分解出UDF和字符串操作和执行CROSS JOIN第一打破过程了位。

<强>的结果为止：

事实证明，所述的UDF确实有助于很多（负）的性能。但是，也似乎是15米排交叉连接和30米的行交叉连接之间有很大的区别。我没有SHOWPLAN权限（呜呼），所以我不能告诉它使用计划是否更改索引后更好或更坏。我还没有重构它，但我期待整个表在短期内消失。

有帮助吗？

解决方案

检查该查询仅示出了一个从一个表中使用列，并且仅两个来自其他表中使用的列。由于列的所使用的非常低的数字，这个查询可以很容易地与覆盖索引增强：

CREATE INDEX COSTCENTCoverCross ON COSTCENT(COST_CTR_NUM)
CREATE INDEX JOINGLACCoverCross ON JOINGLAC(ACCOUNT_NO, LI_LNTM)

下面是我的问题，进一步优化：

当你把查询分析器查询和重击“显示估计的执行计划”按钮，将显示它会做的图形表示。

联接类型：应该有一个嵌套循环在那里加入。 （其他选项是合并联接和哈希联接）。如果你看到嵌套循环，然后确定。如果你看到合并联接或哈希联接，让我们知道。

表访问顺序：一路走的顶部和滚动一路的权利。第一步应访问的表。这表是和使用什么方法（索引扫描，聚簇索引扫描）？什么方法用于访问其他表？

并行：你应该看到小箭头jaggedy几乎所有的图标，指示正在使用并行计划。如果你没有看到这一点，有一个最大的问题！

这udf_BUPDEF涉及我。它与其他表看？ Util.PADLEFT我关注较少，但仍..是什么呢？如果它不是一个数据库对象，然后考虑使用此来代替：

RIGHT('z00000000000000000000000000' + columnName, 7)

有没有对任何JOINCCAC触发器？如何索引？随着插入这个大的，你要删除所有触发器和索引表上的。

其他提示

继续对别人包含其在选择总是让我的查询速度极慢使用的查询一个说法，DB功能。了我的头顶部，相信我不得不在45秒内执行查询，然后我除去函数，然后结果是0秒：）

因此，检查udf_BUPDEF没有做任何疑问。

细分查询，以使它成为一个普通的简单交叉连接。


   SELECT  CC.COST_CTR_NUM, GL.ACCOUNT_NO
              ,CC.COST_CTR_NUM AS CA_COSTCENT
              ,GL.ACCOUNT_NO AS CA_GLACCOUNT
              ,GL.LI_LNTM AS CA_LNTM
-- I don't know what is BUPDEF doing? but remove it from the query for time being
--              ,udf_BUPDEF(GL.ACCOUNT_NO, CC.COST_CTR_NUM, GL.LI_LNTM, 'N') AS CA_UNIT
       FROM   JOINGLAC AS GL
       CROSS JOIN COSTCENT AS CC

请参阅简单的横有多好加入？ （不施加于它的任何功能）

许可以下： CC-BY-SA 和 归因
不隶属于 StackOverflow
scroll top