sql 使CPU使用100%，棘手！

myfriend2010

大牛！终于来了！谢谢关注

原帖由 diablo2 于 2007-12-13 14:35 发表
你们继续。
看着那么多字符，头痛中……

askgyliu

原帖由 myfriend2010 于 2007-12-13 18:39 发表
不可意料不会吧!

看你的sql怎么写!我的业务逻辑就是要求FULL OUTER JOIN的

现 在 我 可 以 确 信 的 是 ：

1) LZ的 版 本 和 我 的 版 本 最 终 结 果 是 一 样 的 ， 除 了 LZ的 会 在 某 些 数 据 下 会 有 多 行 。

2) 那 最 终 结 果 呢 ？ 是 在 GROUP_ID+PRE_M_ARPU_D上唯 一 吗 ？ 若 是 的 话 ， 那 LZ的 头 就 大 了 ， 还 得 在 来 最 后 一 个 GROUP BY。

3) 我 很 是 相 信 最 终 要 的 是 在 GROUP_ID+PRE_M_ARPU_D是 唯 一 的 。 因 为 不 然 的 话 我 很 难 了 解 LZ会 怎 样 处 理 那 些 重 复 但 有 不 同 数 值 的 结 果 。

4) 再 仔 细 看 看 我 的 版 本 。 再 对 照 一 下 LZ所 要 的 业 务 逻 辑 ， 再 仔 细 想 想 是 不 是 真 的 要 FULL OUTER JOIN。我 相 信 自 己 是 在 了 解 了 LZ所 想 要 的 逻 辑 之 后 才 写 这 个 SQL的 。 唯 一 的 意 外 就 是 最 终 的 行 数 会 因 为 数 值 而 不 同 。

askgyliu

还 有 一 点 ， 是 UNIQUE 就 要 勇 敢 地 让 DB2 知 道 ， 在 DDL 中 表 现 出 来 。

askgyliu

原帖由 askgyliu 于 2007-12-13 19:39 发表


唯 一 的 意 外 就 是 最 终 的 行 数 会 因 为 数 值 而 不 同 。

唯 一 的 意 外 就 是 LZ 版 本 最 终 的 行 数 会 因 为 数 值 的 不 同 而 不 同 。

[ 本帖最后由 askgyliu 于 2007-12-13 20:32 编辑 ]

myfriend2010

原帖由 askgyliu 于 2007-12-13 19:39 发表


现 在 我 可 以 确 信 的 是 ：

1) LZ的 版 本 和 我 的 版 本 最 终 结 果 是 一 样 的 ， 除 了 LZ的 会 在 某 些 数 据 下 会 有 多 行 。

2) 那 最 终 结 果 呢 ？ 是 在 GROUP_ID+PRE_M_ARPU_D上唯 一 吗 ？ 若 是 的 话 ， 那 LZ的 头 就 大 了 ， 还 得 在 来 最 后 一 个 GROUP BY。

3) 我 很 是 相 信 最 终 要 的 是 在 GROUP_ID+PRE_M_ARPU_D是 唯 一 的 。 因 为 不 然 的 话 我 很 难 了 解 LZ会 怎 样 处 理 那 些 重 复 但 有 不 同 数 值 的 结 果 。

4) 再 仔 细 看 看 我 的 版 本 。 再 对 照 一 下 LZ所 要 的 业 务 逻 辑 ， 再 仔 细 想 想 是 不 是 真 的 要 FULL OUTER JOIN。我 相 信 自 己 是 在 了 解 了 LZ所 想 要 的 逻 辑 之 后 才 写 这 个 SQL的 。 唯 一 的 意 外 就 是 最 终 的 行 数 会 因 为 数 值 而 不 同 。

可以确定地说：GROUP_ID+PRE_M_ARPU_D是不唯一的！

这段代码只是存储过程中的一部份，这段代码的后边的部分，就是根据这2个字段进行group by的！

下来的代码有一部分是根据GROUP_ID来回总的，有一部分是根据PRE_M_ARPU_D和GROUP_ID来汇总的！

我这边之所以这么写，是因为为后边的代码做铺垫！后边的代码执行速度回好点！

业务很复杂！赫赫！

myfriend2010

这不是意外！在我看来这是必然！

原帖由 askgyliu 于 2007-12-13 19:44 发表


唯 一 的 意 外 就 是 LZ 版 本 最 终 的 行 数 会 因 为 数 值 的 不 同 而 不 同 。

myfriend2010

明天把后边的代码发上来，大家可以看看！今天太忙了！IBM的人过来给我们培训！！

没有来得及把执行计划贴上来，对不住各位啦！明天就贴上来！

[ 本帖最后由 myfriend2010 于 2007-12-13 20:40 编辑 ]

askgyliu

我 现 在 尝 试 把 我 从 LZ 的 SQL 中 理  解 的 整 理 一 下 ， 看 是 不 是 LZ 想 要 的 ：

1) LZ有 三 个 TABLES： CUST_CHURN_INFO_200710，  CUST_CCP_INFO_200710，  AR_CUST_CUST_GRP_ASSOC_200710， 是 1： 1： M 的 关 系 。

2) LZ 要 的 数 据 是 CUST_CHURN_INFO_200710 中 ， LEAVE_DATE<='3000-11-30 00:00:00'， 或 是 on_net_time=4， 或 是 CUST_ID 已 经 在 V_PRE_EXP_GROUP_CUST1中 的 。 这 三 个 条 件 可 能 会 有 OVERLAPPING(互 相 覆 盖 )。

3) 从 CUST_CHURN_INFO_200710 拿 到 所 要  的 CUST_ID 后 ， 再 通 过 CUST_ID 到 CUST_CCP_INFO_200710 中 拿 到  其 他 的 数 据 (m/CLV/)。

4) 再 从 PAR_CUST_CUST_GRP_ASSOC_200710 中 拿 到 每 个 CUST_ID 所 属 的 CUST_GROUP_ID。

5) 最 后 把 这 些 INFORMATION 在 GROUP_ID 和 PRE_M_ARPU_D 这 个 层 次 上 做 AGGREGATION。

有 所 异 同 吗 ？

askgyliu

原帖由 myfriend2010 于 2007-12-13 20:38 发表
这不是意外！在我看来这是必然！

问 题 是 ， 这 是 LZ 想 要 的 吗 ？ 若 是 同 组 GROUP_ID+PRE_M_ARPU_D 在 V_HML_EAL_tem 中 出 现 多 次 ， LZ 会 怎 么 处 理 ？还 是 在 你 现 在 的 数 据 中 还 没 出 现 这 种 情 况 ？

askgyliu

原帖由 myfriend2010 于 2007-12-13 20:37 发表



这段代码只是存储过程中的一部份，这段代码的后边的部分，就是根据这2个字段进行group by的！

下来的代码有一部分是根据GROUP_ID来回总的，有一部分是根据PRE_M_ARPU_D和GROUP_ID来汇总的！

若 是 这 些 就 是 LZ 的 要 求 ， 那 LZ 的 结 果 跟 我 的 版 本 的 结 果 就 真 的 没 什 么 差 别 了 。

再 仔 细 想 想。