B*****g
发帖数: 34098 | 1 请看附件。谢谢
TAB_A 8M records
TAB_B 0.2M records
subquery TAB_B will return 1-5 rows for most of records in TAB_B(except
around 20).
现在我要用 IN，即使sub里面只有一个return，至少１０分钟还没有结束。要是用 =，
只要几秒钟。试过各种hint，都没能成功。暂时我把SQL改成了PL／SQL（loop
subquery 里面），想知道只用SQL砸搞。
Note： 由于公司政策，table／column名字不能公开。 |
c*****d
发帖数: 6045 | 2 能用Join就不用subquery
【在 B*****g 的大作中提到】
: 请看附件。谢谢
: TAB_A 8M records
: TAB_B 0.2M records
: subquery TAB_B will return 1-5 rows for most of records in TAB_B(except
: around 20).
: 现在我要用 IN，即使sub里面只有一个return，至少１０分钟还没有结束。要是用 =，
: 只要几秒钟。试过各种hint，都没能成功。暂时我把SQL改成了PL／SQL（loop
: subquery 里面），想知道只用SQL砸搞。
: Note： 由于公司政策，table／column名字不能公开。
|
B*****g
发帖数: 34098 | 3 我试join不行, 给个提示吧。
【在 c*****d 的大作中提到】
: 能用Join就不用subquery
|
c**t
发帖数: 2744 | 4 did you check the difference of execution plans?
【在 B*****g 的大作中提到】
: 请看附件。谢谢
: TAB_A 8M records
: TAB_B 0.2M records
: subquery TAB_B will return 1-5 rows for most of records in TAB_B(except
: around 20).
: 现在我要用 IN，即使sub里面只有一个return，至少１０分钟还没有结束。要是用 =，
: 只要几秒钟。试过各种hint，都没能成功。暂时我把SQL改成了PL／SQL（loop
: subquery 里面），想知道只用SQL砸搞。
: Note： 由于公司政策，table／column名字不能公开。
|
c**t
发帖数: 2744 | |
B*****g
发帖数: 34098 | 6 不明白
【在 c**t 的大作中提到】
: did you check the difference of execution plans?
|
B*****g
发帖数: 34098 | |
c**t
发帖数: 2744 | 8 check your execution plan, see why the IN operator is slow
【在 B*****g 的大作中提到】
: 不明白
|
S*********t
发帖数: 78 | 9 the plan was attached.
Full index scan took a long time, that part needs to be tuned.
【在 c**t 的大作中提到】
: check your execution plan, see why the IN operator is slow
|
B*****g
发帖数: 34098 | 10 zan.
俺没搞出来, 水平的不行.
【在 S*********t 的大作中提到】
: the plan was attached.
: Full index scan took a long time, that part needs to be tuned.
|
|
|
c*****d
发帖数: 6045 | 11 上午在telnet下面没注意到你贴了执行计划
用subquery应该可以提高效率,不过要在tab_b上创建函数索引
另外可以试试加一个使用tab_b作为驱动表的hint,这个应该更方便
【在 B*****g 的大作中提到】
: zan.
: 俺没搞出来, 水平的不行.
|
f********n
发帖数: 33 | 12 “现在我要用 IN，即使sub里面只有一个return，至少１０分钟还没有结束。要是用 =，
只要几秒钟。试过各种hint，都没能成功。”
我以前做过优化，是Oracle 8，9，现在的产品都不是很清楚了，所以我的想法，楼主
仅当建议听听。“至少１０分钟还没有结束”可能是执行了全表搜索之类的费时操作（
即使你是用PLSQL之类优化过了），一种方法是对关键字做索引，但这种方法对于很大
的table可能还是有问题，即使你看了执行计划里面，仍然会有这种情况。那么另一种
情况就是优化你的语句，我记得Oracle里面有个设置是可以设置每次系统一次可以读取
多少数据记录块，如果默认的数值相对太少了，也会导致检索的时候频繁读盘，最后是
系统强制全表搜索的情况，你可以设置这个参数。另外一个方案就是把大表拆散分散存
储，不过貌似你的情况还没有到这种地步。还有一种可能，是你的SQL语句书写的问题
，一般上从关系代数（不记得具体名字了）上检查一下优化一下，也是可能的，我就有
碰到过要查询1小时的SQL，优化过只要5分钟不到的情况。
祝你顺利。 |
t*********i
发帖数: 217 | 13 try this one?
select a.a_col0 from tab_A a, (select to_char(B.B_col1) as col3 from tab_B B
where B.B_col2 in (to_number(:variable_0, '9999999'))) c
where a.a_col4=c.col3
and a.a_col1='P'
and a.col2 = 'U'
and a.col3 between to_date (....) |
B*****g
发帖数: 34098 | 14 我现在就是在优化sql，搞不定
=，
【在 f********n 的大作中提到】
: “现在我要用 IN，即使sub里面只有一个return，至少１０分钟还没有结束。要是用 =，
: 只要几秒钟。试过各种hint，都没能成功。”
: 我以前做过优化，是Oracle 8，9，现在的产品都不是很清楚了，所以我的想法，楼主
: 仅当建议听听。“至少１０分钟还没有结束”可能是执行了全表搜索之类的费时操作（
: 即使你是用PLSQL之类优化过了），一种方法是对关键字做索引，但这种方法对于很大
: 的table可能还是有问题，即使你看了执行计划里面，仍然会有这种情况。那么另一种
: 情况就是优化你的语句，我记得Oracle里面有个设置是可以设置每次系统一次可以读取
: 多少数据记录块，如果默认的数值相对太少了，也会导致检索的时候频繁读盘，最后是
: 系统强制全表搜索的情况，你可以设置这个参数。另外一个方案就是把大表拆散分散存
: 储，不过貌似你的情况还没有到这种地步。还有一种可能，是你的SQL语句书写的问题
|
B*****g
发帖数: 34098 | 15 我连with都试过了，没用。
B
【在 t*********i 的大作中提到】
: try this one?
: select a.a_col0 from tab_A a, (select to_char(B.B_col1) as col3 from tab_B B
: where B.B_col2 in (to_number(:variable_0, '9999999'))) c
: where a.a_col4=c.col3
: and a.a_col1='P'
: and a.col2 = 'U'
: and a.col3 between to_date (....)
|
B*****g
发帖数: 34098 | 16 hint用tab＿b驱动试过了，各种join也试过了。没有权限create index，有了也不行。
俺门公司只让用b-tree, 其它一概不许用.
【在 c*****d 的大作中提到】
: 上午在telnet下面没注意到你贴了执行计划
: 用subquery应该可以提高效率,不过要在tab_b上创建函数索引
: 另外可以试试加一个使用tab_b作为驱动表的hint,这个应该更方便
|
t*********i
发帖数: 217 | 17 现在我要用 IN，即使sub里面只有一个return，至少１０分钟还没有结束。要是用 =，
只要几秒钟。
****************************************************************************
which 'in' are you talking about?
1) where B.B_col2 in (to_number(:variable_0, '9999999'))?
2) and a.a_col4 in (select ... |
B*****g
发帖数: 34098 | 18 please look the attached image.
**
【在 t*********i 的大作中提到】
: 现在我要用 IN，即使sub里面只有一个return，至少１０分钟还没有结束。要是用 =，
: 只要几秒钟。
: ****************************************************************************
: which 'in' are you talking about?
: 1) where B.B_col2 in (to_number(:variable_0, '9999999'))?
: 2) and a.a_col4 in (select ...
|
c*****d
发帖数: 6045 | 19 不用create index
只是用tab_b做驱动表,能把执行计划贴一下吗?
【在 B*****g 的大作中提到】
: hint用tab＿b驱动试过了，各种join也试过了。没有权限create index，有了也不行。
: 俺门公司只让用b-tree, 其它一概不许用.
|
c*****d
发帖数: 6045 | 20 又一个没看到附件的
=，
【在 f********n 的大作中提到】
: “现在我要用 IN，即使sub里面只有一个return，至少１０分钟还没有结束。要是用 =，
: 只要几秒钟。试过各种hint，都没能成功。”
: 我以前做过优化，是Oracle 8，9，现在的产品都不是很清楚了，所以我的想法，楼主
: 仅当建议听听。“至少１０分钟还没有结束”可能是执行了全表搜索之类的费时操作（
: 即使你是用PLSQL之类优化过了），一种方法是对关键字做索引，但这种方法对于很大
: 的table可能还是有问题，即使你看了执行计划里面，仍然会有这种情况。那么另一种
: 情况就是优化你的语句，我记得Oracle里面有个设置是可以设置每次系统一次可以读取
: 多少数据记录块，如果默认的数值相对太少了，也会导致检索的时候频繁读盘，最后是
: 系统强制全表搜索的情况，你可以设置这个参数。另外一个方案就是把大表拆散分散存
: 储，不过貌似你的情况还没有到这种地步。还有一种可能，是你的SQL语句书写的问题
|
|
|
B*****g
发帖数: 34098 | 21 *****本贴有附件*****
Hope I use hint correctly.
*****本贴有附件*****
我看谁还看不到附件，哈哈
【在 c*****d 的大作中提到】
: 不用create index
: 只是用tab_b做驱动表,能把执行计划贴一下吗?
|
c*****d
发帖数: 6045 | 22 试一下这个
select /*+ first_rows */ a.a_col0
...
或者这个
select /*+ use_nl(tab_b) */ a.a_col0
【在 B*****g 的大作中提到】
: *****本贴有附件*****
: Hope I use hint correctly.
: *****本贴有附件*****
: 我看谁还看不到附件，哈哈
|
B*****g
发帖数: 34098 | 23 use_nl(b), use_nl(b a) 都试过了，不灵。
just try first＿rows，不灵。
结论:
1. sql不是万能的，必要时pl／sql更好。
2. table statistic 有问题
3. 用telnet的人很多。
【在 c*****d 的大作中提到】
: 试一下这个
: select /*+ first_rows */ a.a_col0
: ...
: 或者这个
: select /*+ use_nl(tab_b) */ a.a_col0
|
S*********t
发帖数: 78 | 24 试过之后 plan 有变化吗？
【在 B*****g 的大作中提到】
: use_nl(b), use_nl(b a) 都试过了，不灵。
: just try first＿rows，不灵。
: 结论:
: 1. sql不是万能的，必要时pl／sql更好。
: 2. table statistic 有问题
: 3. 用telnet的人很多。
|
c*****d
发帖数: 6045 | 25 嗯,这也是我想问的
能贴一下exec plan
【在 S*********t 的大作中提到】
: 试过之后 plan 有变化吗？
|
c*****d
发帖数: 6045 | 26 那连接方法呢?是用nestloop了还是hash
【在 B*****g 的大作中提到】
: use_nl(b), use_nl(b a) 都试过了，不灵。
: just try first＿rows，不灵。
: 结论:
: 1. sql不是万能的，必要时pl／sql更好。
: 2. table statistic 有问题
: 3. 用telnet的人很多。
|
B*****g
发帖数: 34098 | 27 USE_NL(b) and USE_NL(b a) 一样, 见附件
first_rows 基本一样，就多一hint
【在 c*****d 的大作中提到】
: 嗯,这也是我想问的
: 能贴一下exec plan
|
w*r
发帖数: 2421 | 28 bitmap index on the tablea?
also function based index on tableb..
【在 B*****g 的大作中提到】
: 请看附件。谢谢
: TAB_A 8M records
: TAB_B 0.2M records
: subquery TAB_B will return 1-5 rows for most of records in TAB_B(except
: around 20).
: 现在我要用 IN，即使sub里面只有一个return，至少１０分钟还没有结束。要是用 =，
: 只要几秒钟。试过各种hint，都没能成功。暂时我把SQL改成了PL／SQL（loop
: subquery 里面），想知道只用SQL砸搞。
: Note： 由于公司政策，table／column名字不能公开。
|
B*****g
发帖数: 34098 | 29 only b-tree allowed
【在 w*r 的大作中提到】
: bitmap index on the tablea?
: also function based index on tableb..
|
m****d
发帖数: 372 | 30 tab_b subquery 需要花费一定时间，但这个不是主要问题，所以在table b上新建inde
x 帮助不大。 主要问题是join上花费太大了，具体来说。
1.tab_b 的statistic 有问题，前面你说了tab_b 返回也就几行，但execution plan 返
回 70多万行。这个是oracle 下一步xecution plan 选择错误的原因。
2.tab_b 返回只有几行，但oracle 基于前面的错误，选择了nest join（ table a 作为
outer table) 或者 hash jon（在你用了ordered之后)。
你可以试着加加hint /*+ ordered use_nl(a) */ 或者/*use_nl(a)*/，再查看executi
on plan,直到oracle 把 table b作为nested join的 outer table 为止
你用“=”之所以会很快出来，是应为oracle把他作为一个filter,所以用不着nest joi
n/hash join,你看一下execution plan就知道了。
【在 B*****g 的大作中提到】
: only b-tree allowed
|
