SQL優化

arecaiz 2012-06-22 01:37:08
select 
wdj.wip_entity_id,
wdj.organization_id,
wdj.primary_item_id,
bso.operation_code
,sum(prl.quantity_delivered*pla.unit_price) ,sum(prl.quantity*pla.unit_price)
from
po.po_requisition_lines_all prl,
po.po_distributions_all pda,
po.po_lines_all pla,
wip.WIP_OPERATION_RESOURCES wor ,
wip.wip_discrete_jobs wdj,
wip.wip_operations wo,
bom.bom_standard_operations bso
where
prl.line_location_id=pda.line_location_id
and pda.po_line_id=pla.po_line_id
and wo.operation_seq_num=wor.operation_seq_num
and wo.wip_entity_id=wor.wip_entity_id
and wo.organization_id=wor.organization_id
and wo.department_id=bso.department_id
and wo.description=bso.operation_description
and wo.organization_id=bso.organization_id
and wor.wip_entity_id=prl.wip_entity_id
and pda.wip_operation_seq_num=wor.operation_seq_num
and wor.wip_entity_id=wdj.wip_entity_id
and wor.organization_id=wdj.organization_id
and wdj.status_type in(3,6)
and wor.autocharge_type=4
and wdj.class_code in ('TJ1補料','TJ1重工','TJ2補料','TJ2重工')
group by wdj.wip_entity_id,wdj.primary_item_id,wdj.organization_id ,bso.operation_code


現在跑出來要一分鐘左右,
高手給看一下如何優化一下。
...全文
263 18 打赏 收藏 转发到动态 举报
写回复
用AI写文章
18 条回复
切换为时间正序
请发表友善的回复…
发表回复
zhulong1111 2012-06-26
  • 打赏
  • 举报
回复
亲。。请用视图+left/right join
这一站_IT 2012-06-26
  • 打赏
  • 举报
回复
1.这个SQL看起来太累了吧,你那么多的条件,多做几次子查询,效率就会快很多了。当然这种只是简单的处 理,只能将效率提高很多,但代码段会增加。

2.最好的还是用iner join、left join来进行相应的连接。然后查询就快了。当然如果数据量太大的话。

3.也可以考虑用存储过程,毕竟exec一个存储过程比表要快很多很多。
Jack123 2012-06-26
  • 打赏
  • 举报
回复
不优化不行啊。
qxyywy 2012-06-26
  • 打赏
  • 举报
回复
[Quote=引用 1 楼 的回复:]

笛卡尔积是很“扯淡”的。

尽管sql server数据库会自动对笛卡尔积做优化,但是有点基础的程序员,应该写 inner join, left join 等关联语句,而不是这种。

写成iner join、left join之后,你可以看看每一个表达式右边的那个字段,有没有索引。如果没有,那么通常就要加上索引。
[/Quote]

虽然P哥常批评人 但这次楼主的SQL写法真的该被P个批

你的class_code的长度是多少 建议对这个字段建立索引
arecaiz 2012-06-26
  • 打赏
  • 举报
回复
[Quote=引用 6 楼 的回复:]

先将and wdj.class_code in ('TJ1補料','TJ1重工','TJ2補料','TJ2重工')
中的子查询先处理到临时表中,再来联接查询,这样要检索的数据要小得多
[/Quote]

這個已經做過,效果不大。
主要還是因為出現 笛卡尔积

這是Oracle ERP數據庫。
這個查詢只是我需求的一個子查詢。實際SQL要比這個多太太多了。一下粘不出所有SQL
那一笑的凄凉 2012-06-26
  • 打赏
  • 举报
回复
多楼主你这表查询写的真是...比如每张有50W以上的数据笛卡尔下来都不敢想象,难怪你会卡,你可以先分析要查询出什么,建议用left join on筛选数据,要查询的数据量有多大,分析每张表的数据,调整好表关联的顺序,尽量前面的关联就筛选出大部份无用的数据,where 条件也是前面的条件就过滤出大部分不符合条件的数据,具体方法自己根据表数据量多做测试了,写出一个最佳语句。
H_Gragon 2012-06-26
  • 打赏
  • 举报
回复
[Quote=引用楼主 的回复:]
SQL code

select
wdj.wip_entity_id,
wdj.organization_id,
wdj.primary_item_id,
bso.operation_code
,sum(prl.quantity_delivered*pla.unit_price) ,sum(prl.quantity*pla.unit_price)
from
po.po_re……
[/Quote]
楼主真是人才啊!
Name_456 2012-06-26
  • 打赏
  • 举报
回复
select
wdj.wip_entity_id,
wdj.organization_id,
wdj.primary_item_id,
bso.operation_code
,sum(prl.quantity_delivered*pla.unit_price) ,sum(prl.quantity*pla.unit_price)
from
po.po_requisition_lines_all prl
left join wip.wip_discrete_jobs wdj
on prl.XXX=wdj.XXX
left join bom_standard_operations bso
onprl.XX=bso.XX
where

group by
IT修补匠 2012-06-26
  • 打赏
  • 举报
回复
用 连接(左联,右联) 把条件放在连接条件上 试试看!
No4000 2012-06-26
  • 打赏
  • 举报
回复
LZ, 你这SQL语句不好维护啊
yzf86211861 2012-06-26
  • 打赏
  • 举报
回复
[Quote=引用 12 楼 的回复:]

亲。。请用视图+left/right join
[/Quote]
这是第1个。
把每组需要管理的字段加 非聚集索引
cs_esharp 2012-06-22
  • 打赏
  • 举报
回复
先将and wdj.class_code in ('TJ1補料','TJ1重工','TJ2補料','TJ2重工')
中的子查询先处理到临时表中,再来联接查询,这样要检索的数据要小得多
csdn_风中雪狼 2012-06-22
  • 打赏
  • 举报
回复
用 left join 在form 后面进连接吧
shoppo0505 2012-06-22
  • 打赏
  • 举报
回复
楼主的code是sql2000的吧?2005以后就不这么用了。
就像1楼说的尽量使用join进行关联,where中的条件也尽量在关联的时候就限定,表格大的话,会快很多。越大越明显。
  • 打赏
  • 举报
回复
我敢打赌,在一个正规产品中sql语句中写笛卡尔积的程序员,没有上过学。
  • 打赏
  • 举报
回复
笛卡尔积是很“扯淡”的。

尽管sql server数据库会自动对笛卡尔积做优化,但是有点基础的程序员,应该写 inner join, left join 等关联语句,而不是这种。

写成iner join、left join之后,你可以看看每一个表达式右边的那个字段,有没有索引。如果没有,那么通常就要加上索引。
更优更快 人工智能自动SQL优化----------http://www.sina.com.cn 2001/12/12 17:48 中国电脑教育报文/SQL爱好者  所谓SQL,就是指Structured Query Language(结构化查询语言),它是目前使用最广泛的数据库语言,用来和数据库打交道,从数据库中得到用户需要的数据。但是要想熟练使用SQL语句,也不是一件简单的事,有些语句使用起来也比较麻烦。如果我们对SQL语句进行优化,那么用户使用起来 就会方便许多。  简单来说,SQL语句的优化就是将性能低下的SQL语句转换成达到同样目的的性能优异的SQL语句。人工智能自动SQL优化就是使用人工智能技术,自动对SQL语句进行重写,找到性能最好的等效SQL语句。  人工智能自动SQL 优化  随着人工智能技术的发展和在数据库优化领域应用的深入,在20世纪90年代末终于出现了突破性的进展——人工智能自动SQL优化。目前在商用数据库领域LECCO TechnologyLimited(灵高公司)拥有该技术并提供使用该技术的自动优化产品——LECCO SQL Expert,其支持Oracle、Sybase、MS SQLServer和IBMDB2数据库平台。该产品针对数据库应用的开发和维护阶段提供了几个特别的模块:SQL语法优化器、PL/SQL集成化开发调试环境(IDE)、扫描器、数据库监视器等。图1 人工智能自动SQL优化示意图  其核心模块之一“SQL语法优化器”的工作原理大致如下(如图1):  一条源SQL语句输入→“人工智能反馈式搜索引擎”对输入的SQL语句结合检测到的数据库结构和索引进行重写,产生N条等效的SQL语句输出→产生的N条等效SQL语句再送入“人工智能反馈式搜索引擎”进行重写,直至无法产生新的输出或搜索限额满→对 输出的SQL语句进行过滤,选出具有不同执行计划的SQL语句(即不同的执行效率)→对得到的SQL语句进行批量测试,找出性能最好的SQL语句。图2 优化前的SQL语句  自动优化实例  假设我们从源代码中抽取出这条SQL语句(如图2):  SELECTCOUNT(*)FROMEMPLOY-EE WHEREEXISTS(SELECT'X'FROM DEPARTMENTswheresEMP_DEPT=DPT_IDAND DPT_NAME LIKE'AC%')AND EMP_IDIN(SELECT SAL_EMP_IDFROM EMP_SAL_HISTB WHERESAL_SALARY>70000)   按“优化”按钮后,经过十几秒,SQL Expert就完成了优化的过程,从优化细节中可以看到,它在十几秒的时间内重写产生了2267条等价的SQL语句,其中136条SQL语句有不同的执行计划(如图3)。图3 优化结果  接下来我们可以对自动重写产生的136条具有不同执行计划的SQL语句进行批运行测试,以选出性能最佳的等效SQL语句。按下“批运行”按钮,在“终止条件”页选择“最佳运行时间SQL语句”(如图4),按“确定”。图4 测试条件  经过几分钟的测试运行后,我们可以发现SQL124的运行时间和反应时间最短。运行速度约有22.75倍的提升(源SQL语句运行时间为2.73秒,SQL124运行时间为0.12秒,如图5)。图5 测试结果  我们把SQL124放入源代码中,结束一条SQL语句的优化工作。从上例可以看到,LECCO SQL Expert的自动重写技术使原来需要几小时才能完成的SQL语句的优化工作,缩减到几分钟之内就可以完成。数据库管理员和开发人员可以从繁重的SQL语句优化工作中解脱出来。  边做边学式训练  LECCO SQL Expert不仅能够找到最佳的SQL语句,而且提供的“边做边学式训练”还能够教会开发人员和数据库管理员如何写出性能最好的SQL语句。LECCO SQL Expert的“SQL比较器”可以标明源SQL和待选SQL之间的不同之处。LECCO SQL Expert详尽的上下文敏感帮助系统可以指出执行计划的深层含义。图6 源语句与SQL124的比较  以上面优化的结果为例,为了查看源SQL语句和SQL124在写法上的不同,我们可以按下“比较器”按钮,对SQL124和源SQL语句进行比较。如果选择“双向比较”复选框,“SQL比较器”可以将两条互相间的不同之处以蓝色表示。当然,你也可以从 源语句和重写后的SQL语句中任选两条进行比较(如图6)。  从比较的结果可以看到,重写得到的SQL124把第一个Exists改写成了In;在字段DPT_ID上进行了合并空字符串的操作以诱导数据库先执行子查询中的(SELECTDPT_ID||'FROMDEPART-MENTWH
本书是Inside Microsoft SQL Server 2005系列四本著作中的一本。它详细介绍了T-SQL的内部体系结构,包含了非常全面的编程参考,提供了使用Transact-SQL(T-SQL)的专家级指导,囊括了非常全面的编程参考,揭示了基于集合的查询的强大威力,并包含大量来自专家们的参考和建议。本书适合专业数据库开发者、BI开发者、DBA和以SQL Server作为后台数据库的一般应用程序开发者,读者可以通过书中的最佳实践、高级技巧和代码示例来掌握这门复杂的编程语言,以切合实际的方案来解决复杂的实际问题。   深入理解T-SQL体系结构,充分利用高级T-SQL查询技术。   本书深入介绍了T-SQL的内部体系结构,揭示了基于集合的查询的强大威力,并包含大量来自专家们的参考和建议。通过本书提供的最佳实践和示例代码,数据库开发人员和管理员完全可以掌握这门复杂的编程语言,以切合实际的方案来解决复杂的实际问题。通过本书,你将学习到如何:理解逻辑和物理的查询处理;使用方法论优化查询;在查询中用TOP选项修改数据;用递归逻辑、具体化路径或嵌套集合解决方案查询特殊的数据结构;通过逻辑难题提高你的逻辑能力并掌握查询问题的核心等。   你将学习到如何:   理解逻辑和物理的查询处理;   使用方法论优化查询;   解决关系分区问题;   使用CTE和排名函数简化及优化解决方案;   用各种技术聚合数据,包括附加属性、旋转、直方图和分组因子;   在查询中用TOP选项修改数据;   用递归逻辑、具体化路径或嵌套集合解决方案查询特殊的数据结构;   通过逻辑难题提高你的逻辑能力并掌握查询问题的核心; 内容简介 本书是Inside Microsoft SQL Server 2005系列四本著作中的一本。本书及其续篇——《Microsoft SQL Server 2005技术内幕:T-SQL程序设计》介绍了SQL Server 2005中高级T-SQL查询、查询优化及编程相关的知识。这两本书侧重于解决实践中的常见问题,并讨论了解决这些问题的方法。它们将向你揭示基于集合(set-based)查询的强大威力,并解释为什么它比使用游标的过程化编程(procedural programming)更具优势。同时,它还会教你识别使用基于游标解决方案与基于集合解决方案的优劣。   书中还讲述了其他几种争议较多的构造(camstruct)——如临时表、动态执行、XML和.NET集成——它们在具有强大功能的同时,也具有极大的风险。   本书适合于需要编写或检查T-SQL代码的有经验的T-SQL程序员和数据库专业人员。读者可从中学到大量精湛的技巧,这些技巧会充实您的工具箱和编码技能,并让您顺利地开发出高效的解决方案。 作者简介 Itzik Ben-Gan是Solid Quality Learning的首席导师和创始人。他从1999年开始便一直是SQL Server方面的Microsoft MVP,在世界各地讲授 T-SQL查询、编程和查询优化相关的课程,并提供相关咨询服务。他在SQL Server Magazine和MSDN上发表了多篇文章,并被邀请在许多专题会议上做过报告,包括TechEd、DevWeek、PASS和SQL Server Connections。 目录 序 前言 致谢 引言  本书的组织  系统要求  安装示例数据库  更新  代码示例  本书支持 第1章 逻辑查询处理  逻辑查询处理中的各个阶段   逻辑查询处理阶段简介  Customers/Orders场景下的示例查询  逻辑查询处理步骤详解   步骤1:执行笛卡尔乘积(交叉联接)   步聚2:应用ON筛选器(联接条件)   步骤3:添加外部行(Outer Row)   步骤4:应用WHERE筛选器   步骤5:分组   步骤6:应用CUBE或ROLLUP选项   步骤7:应用HAVING筛选器   步骤8:处理SELECT列表   步骤9:应用DISTINCT子句   步骤10:应用ORDER BY子句   步骤11:应用TOP选项  SQL Server 2005中新的逻辑处理阶段   表运算符   OVER子句   集合操作  结论 第2章 物理查询处理  查询处理期间的数据流  编译   Algebrizer   优化   使用查询计划   更新计划  结论   致谢 第3章 查询优化  本章用到的示例数据  优化方法论   分析实例级的等待   联系等待和队列   确定方案   细化到数据库/文件级别   细化到进程级别   优化索引/查询  查询优化工具   syscacheobjects   清空缓存   动态管理对象   STATISTICS IO   测量查询的运

62,269

社区成员

发帖
与我相关
我的任务
社区描述
.NET技术交流专区
javascript云原生 企业社区
社区管理员
  • ASP.NET
  • .Net开发者社区
  • R小R
加入社区
  • 近7日
  • 近30日
  • 至今
社区公告

.NET 社区是一个围绕开源 .NET 的开放、热情、创新、包容的技术社区。社区致力于为广大 .NET 爱好者提供一个良好的知识共享、协同互助的 .NET 技术交流环境。我们尊重不同意见,支持健康理性的辩论和互动,反对歧视和攻击。

希望和大家一起共同营造一个活跃、友好的社区氛围。

试试用AI创作助手写篇文章吧