求助：一个600W数据表查询的速度优化

sundog315

anlinew 发表于 2012-10-10 09:02
对于当前的sql楼上建索引的建议应该是有效的
不过索引的建立需要综合考虑全局的应用场景，或者反过来看SQL ...

这个问题很棘手，开发永远都是以实现功能为第一要务，并不会考虑到效率问题。而且，即使有编码规范，也很难面面俱到，并且，实际完全符合规范的情况还是很少见的。
开发人员的工作经历、项目经验、甚至“师傅”的不同，都可能导致出现千奇百怪的SQL

Yong Huang

>> 不过索引的建立需要综合考虑全局的应用场景
> 这个问题很棘手，开发永远都是以实现功能为第一要务，并不会考虑到效率问题

I agree that "开发永远都是以实现功能为第一要务". But I have to comment that performance cannot be completely ignored when developers work on functionality. Any type of work, not limited to Oracle database, is prioritized by the benefit-to-effort ratio. If great performance gain can be achieved without too much effort, it must be incorporated into the work even though 实现功能 is 第一要务. If too much effort is needed to gain a little in performance, then it's either placed at the low end of the to-do list or discarded altogether. Adding a good index usually brings about tens to thousands of times of performance gain. It's likely to be high on the priority list.

chwp

>> 不过索引的建立需要综合考虑全局的应用场景
> 这个问题很棘手，开发永远都是以实现功能为第一要务，并不会考虑到效率问题
功能与效率对开发来讲应该是同等重要的，在数据库设计阶段就应该考虑到
如果做开发只把实现功能当作自己的目标，那什么时候有软件工程的意识呢，只能一直编码了
dba只是在优化sql，与程序员也没什么区别
如果能从系统的角度综合考虑功能，效率，安全，维护性，人机交互等等，
肯定要多费力，效果会好很多

低调小马哥

我觉得可以从最下面的那个full scan的表开始分析，看看能不能用索引

低调小马哥

600万的数据量，还这么多leftjoin，我觉得可以用物化视图或者存储过程了，如果每次查这些关联估计都卡的要死，如果用物化视图或者存储过程放在一个结果表里，就可以减少很多次执行了。

stevendba

我看到了where 1 = 1，这个查询条件应该是拼装的吧。即使改了这条语句也难免保证其他的查询条件不会生成耗性能的sql,最好从业务出发
1. 这是个订单表，应该有流程的，流程结束的数据分出去
2. 有些计算的活能否在代码中实现，开发总想着什么功能都一句sql搞定

mfkqwyc86

问题就在那张全表扫描的表上面，性能这么差，处理那张表就行了。

jams007

几乎全部是嵌套循环，驱动表的选择可能存在些问题，从内向外的成本几乎没有发生变化。

starhot

No#1:
----
FROM ORDER_COMMODITY A,
               COMMODITY_INFO  B
         WHERE A.SHOP_ID = B.SHOP_ID(+)
           AND A.COMMODITY_CODE = B.COMMODITY_CODE(+)
---针对个子查询，你完全可以不用  COMMODITY_INFO,因为你select的字段中都没有用到B的字段。因你在处理这两个表的过程中使用的是外连接。

如此修改就可以针对ORDER_MAIN 和 ORDER_COMMODITY进行直接连接

NO#2:索引可定是要维护的。如果ORDER_MAIN 这个表的记录两变更频繁，即每天产生的业务量很多，可以考虑分区于字段ORDER_START_TIME上 (OLTP系统上要慎重需要做评估，这个动作对性能的影响是否在允许范围类)。同时可以考虑在这个上建立local index.

sqysl

anlinew 发表于 2012-10-10 09:02
对于当前的sql楼上建索引的建议应该是有效的
不过索引的建立需要综合考虑全局的应用场景，或者反过来看SQL ...

没太仔细看，看了一眼执行计划，每个step的基数都是1，有点奇怪。