一个oracle performance 的问题。# Database - 数据库
a*0
1 楼
今天去了downtown boston的一家体检中心做移民体检，填好表格，挨了两针（Measles
,Mumps,Rubella）花了117刀，就结束了！
听说不是都要抽血的吗？
,Mumps,Rubella）花了117刀，就结束了！
听说不是都要抽血的吗？
s*0
2 楼
【 以下文字转载自 tuolaji 俱乐部 】
发信人: snowman10 (雪人), 信区: tuolaji
标 题: 天使的翅膀
发信站: BBS 未名空间站 (Mon Feb 23 17:43:46 2015, 美东)
http://okehero.com/main/play.jsp?id=O7Fs3wF1nOEO
发信人: snowman10 (雪人), 信区: tuolaji
标 题: 天使的翅膀
发信站: BBS 未名空间站 (Mon Feb 23 17:43:46 2015, 美东)
http://okehero.com/main/play.jsp?id=O7Fs3wF1nOEO
m*i
3 楼
oracle 9i。
我有一个大table 叫 TA 吧， 7，8 个million record 吧。
table 有primary key。 由好几个column 组成。就叫 （col1，col2，col3，col4，
col5，col6） 吧。
当我运行如下query 时，非常慢，要十几分钟。
1） select count(*) from TA a where a.col1=601
但当我运行下面的query 是 却非常快，十几秒就行了。
2） select count(*) from TA a where a.col1=601 and a.col2 like 'ABC%'
为什么呢？ 有什么办法可以让 1） 也运行的快点吗？
我有一个大table 叫 TA 吧， 7，8 个million record 吧。
table 有primary key。 由好几个column 组成。就叫 （col1，col2，col3，col4，
col5，col6） 吧。
当我运行如下query 时，非常慢，要十几分钟。
1） select count(*) from TA a where a.col1=601
但当我运行下面的query 是 却非常快，十几秒就行了。
2） select count(*) from TA a where a.col1=601 and a.col2 like 'ABC%'
为什么呢？ 有什么办法可以让 1） 也运行的快点吗？
p*m
4 楼
You were fooled.
c*t
5 楼
check out your execution plan. It seems the first query does full table scan.
【在 m*****i 的大作中提到】
: oracle 9i。
: 我有一个大table 叫 TA 吧， 7，8 个million record 吧。
: table 有primary key。 由好几个column 组成。就叫 （col1，col2，col3，col4，
: col5，col6） 吧。
: 当我运行如下query 时，非常慢，要十几分钟。
: 1） select count(*) from TA a where a.col1=601
: 但当我运行下面的query 是 却非常快，十几秒就行了。
: 2） select count(*) from TA a where a.col1=601 and a.col2 like 'ABC%'
: 为什么呢？ 有什么办法可以让 1） 也运行的快点吗？
【在 m*****i 的大作中提到】
: oracle 9i。
: 我有一个大table 叫 TA 吧， 7，8 个million record 吧。
: table 有primary key。 由好几个column 组成。就叫 （col1，col2，col3，col4，
: col5，col6） 吧。
: 当我运行如下query 时，非常慢，要十几分钟。
: 1） select count(*) from TA a where a.col1=601
: 但当我运行下面的query 是 却非常快，十几秒就行了。
: 2） select count(*) from TA a where a.col1=601 and a.col2 like 'ABC%'
: 为什么呢？ 有什么办法可以让 1） 也运行的快点吗？
a*g
6 楼
你这个体检检的不对，挨的针 也不对。
Measles
【在 a**********0 的大作中提到】
: 今天去了downtown boston的一家体检中心做移民体检，填好表格，挨了两针（Measles
: ,Mumps,Rubella）花了117刀，就结束了！
: 听说不是都要抽血的吗？
Measles
【在 a**********0 的大作中提到】
: 今天去了downtown boston的一家体检中心做移民体检，填好表格，挨了两针（Measles
: ,Mumps,Rubella）花了117刀，就结束了！
: 听说不是都要抽血的吗？
m*i
7 楼
Why?
col1 is part of the primary key, it suppose to be indexed.
scan.
【在 c**t 的大作中提到】
: check out your execution plan. It seems the first query does full table scan.
col1 is part of the primary key, it suppose to be indexed.
scan.
【在 c**t 的大作中提到】
: check out your execution plan. It seems the first query does full table scan.
c*t
8 楼
if there are too many records selected, oracle may choose full scan instead.
【在 m*****i 的大作中提到】
: Why?
: col1 is part of the primary key, it suppose to be indexed.
:
: scan.
【在 m*****i 的大作中提到】
: Why?
: col1 is part of the primary key, it suppose to be indexed.
:
: scan.
c*d
9 楼
单字段的primary key能保证该字段被index
对于复合PK，如果PK是(col1，col2)，没问题，查询可以用Index
如果PK是(col2，col1)，不行，查询不可以用该Index
【在 m*****i 的大作中提到】
: Why?
: col1 is part of the primary key, it suppose to be indexed.
:
: scan.
对于复合PK，如果PK是(col1，col2)，没问题，查询可以用Index
如果PK是(col2，col1)，不行，查询不可以用该Index
【在 m*****i 的大作中提到】
: Why?
: col1 is part of the primary key, it suppose to be indexed.
:
: scan.
i*d
10 楼
对Oracle不懂, 如果是SQL server的话, coolbid说的是对的.
【在 c*****d 的大作中提到】
: 单字段的primary key能保证该字段被index
: 对于复合PK，如果PK是(col1，col2)，没问题，查询可以用Index
: 如果PK是(col2，col1)，不行，查询不可以用该Index
【在 c*****d 的大作中提到】
: 单字段的primary key能保证该字段被index
: 对于复合PK，如果PK是(col1，col2)，没问题，查询可以用Index
: 如果PK是(col2，col1)，不行，查询不可以用该Index
a9
11 楼
想想就是这样的。
【在 i***d 的大作中提到】
: 对Oracle不懂, 如果是SQL server的话, coolbid说的是对的.
【在 i***d 的大作中提到】
: 对Oracle不懂, 如果是SQL server的话, coolbid说的是对的.
y*w
12 楼
这个不绝对的，
【在 c*****d 的大作中提到】
: 单字段的primary key能保证该字段被index
: 对于复合PK，如果PK是(col1，col2)，没问题，查询可以用Index
: 如果PK是(col2，col1)，不行，查询不可以用该Index
【在 c*****d 的大作中提到】
: 单字段的primary key能保证该字段被index
: 对于复合PK，如果PK是(col1，col2)，没问题，查询可以用Index
: 如果PK是(col2，col1)，不行，查询不可以用该Index
B*g
13 楼
顶，coolbid这次说的不对。
【在 y****w 的大作中提到】
: 这个不绝对的，
【在 y****w 的大作中提到】
: 这个不绝对的，
a9
14 楼
那这个是啥原因呢？
【在 B*****g 的大作中提到】
: 顶，coolbid这次说的不对。
【在 B*****g 的大作中提到】
: 顶，coolbid这次说的不对。
B*g
15 楼
信息不全，不知道原因。起码也要看了execution plan，和index才能知道。
【在 a9 的大作中提到】
: 那这个是啥原因呢？
【在 a9 的大作中提到】
: 那这个是啥原因呢？
m*i
16 楼
都在公司电脑里，我不用公司电脑上买买提。明天试着考出来看看。
【在 B*****g 的大作中提到】
: 信息不全，不知道原因。起码也要看了execution plan，和index才能知道。
【在 B*****g 的大作中提到】
: 信息不全，不知道原因。起码也要看了execution plan，和index才能知道。
c*d
17 楼
好，更精确的说：
单字段的primary key能保证该字段被index，但是oracle未必一定使用该Index
对于复合PK，如果PK是(col1，col2)，查询可以用Index，但是oracle未必一定使用该
Index
如果PK是(col2，col1)，oracle查询不用该Index，除非你加入hint
这下大家满意了吧
【在 B*****g 的大作中提到】
: 顶，coolbid这次说的不对。
单字段的primary key能保证该字段被index，但是oracle未必一定使用该Index
对于复合PK，如果PK是(col1，col2)，查询可以用Index，但是oracle未必一定使用该
Index
如果PK是(col2，col1)，oracle查询不用该Index，除非你加入hint
这下大家满意了吧
【在 B*****g 的大作中提到】
: 顶，coolbid这次说的不对。
B*g
18 楼
ding
【在 c*****d 的大作中提到】
: 好，更精确的说：
: 单字段的primary key能保证该字段被index，但是oracle未必一定使用该Index
: 对于复合PK，如果PK是(col1，col2)，查询可以用Index，但是oracle未必一定使用该
: Index
: 如果PK是(col2，col1)，oracle查询不用该Index，除非你加入hint
: 这下大家满意了吧
【在 c*****d 的大作中提到】
: 好，更精确的说：
: 单字段的primary key能保证该字段被index，但是oracle未必一定使用该Index
: 对于复合PK，如果PK是(col1，col2)，查询可以用Index，但是oracle未必一定使用该
: Index
: 如果PK是(col2，col1)，oracle查询不用该Index，除非你加入hint
: 这下大家满意了吧
y*w
19 楼
你确认oracle中即使如select count(*) from tab where col1 = xx 也不会用到如(col2,col1)的索引？
【在 c*****d 的大作中提到】
: 好，更精确的说：
: 单字段的primary key能保证该字段被index，但是oracle未必一定使用该Index
: 对于复合PK，如果PK是(col1，col2)，查询可以用Index，但是oracle未必一定使用该
: Index
: 如果PK是(col2，col1)，oracle查询不用该Index，除非你加入hint
: 这下大家满意了吧
【在 c*****d 的大作中提到】
: 好，更精确的说：
: 单字段的primary key能保证该字段被index，但是oracle未必一定使用该Index
: 对于复合PK，如果PK是(col1，col2)，查询可以用Index，但是oracle未必一定使用该
: Index
: 如果PK是(col2，col1)，oracle查询不用该Index，除非你加入hint
: 这下大家满意了吧
gy
20 楼
ft, 北京MM很picky呀.....哈哈哈
【在 B*****g 的大作中提到】
: 顶，coolbid这次说的不对。
【在 B*****g 的大作中提到】
: 顶，coolbid这次说的不对。
gy
21 楼
赞
【在 c*****d 的大作中提到】
: 好，更精确的说：
: 单字段的primary key能保证该字段被index，但是oracle未必一定使用该Index
: 对于复合PK，如果PK是(col1，col2)，查询可以用Index，但是oracle未必一定使用该
: Index
: 如果PK是(col2，col1)，oracle查询不用该Index，除非你加入hint
: 这下大家满意了吧
【在 c*****d 的大作中提到】
: 好，更精确的说：
: 单字段的primary key能保证该字段被index，但是oracle未必一定使用该Index
: 对于复合PK，如果PK是(col1，col2)，查询可以用Index，但是oracle未必一定使用该
: Index
: 如果PK是(col2，col1)，oracle查询不用该Index，除非你加入hint
: 这下大家满意了吧
B*g
22 楼
from 9i, there is one thing called "Index Skip Scan", oracle may choose this
one over full table scan
col2,col1)的索引？
用该
【在 y****w 的大作中提到】
: 你确认oracle中即使如select count(*) from tab where col1 = xx 也不会用到如(col2,col1)的索引？
one over full table scan
col2,col1)的索引？
用该
【在 y****w 的大作中提到】
: 你确认oracle中即使如select count(*) from tab where col1 = xx 也不会用到如(col2,col1)的索引？
B*g
23 楼
ding
【在 gy 的大作中提到】
: ft, 北京MM很picky呀.....哈哈哈
【在 gy 的大作中提到】
: ft, 北京MM很picky呀.....哈哈哈
y*w
24 楼
;)
如果连这个都不支持，oracle的优化器就没资格称为一个优秀的优化器。
lz那个问题，我怀疑是他的primary key太多列以至于编译器选择table scan了。更新表/索引的详细统计信息，设计小的索引，这些常规手段应该就会有效的，
this
【在 B*****g 的大作中提到】
: from 9i, there is one thing called "Index Skip Scan", oracle may choose this
: one over full table scan
:
: col2,col1)的索引？
: 用该
如果连这个都不支持，oracle的优化器就没资格称为一个优秀的优化器。
lz那个问题，我怀疑是他的primary key太多列以至于编译器选择table scan了。更新表/索引的详细统计信息，设计小的索引，这些常规手段应该就会有效的，
this
【在 B*****g 的大作中提到】
: from 9i, there is one thing called "Index Skip Scan", oracle may choose this
: one over full table scan
:
: col2,col1)的索引？
: 用该
y*w
25 楼
sql server在这种情况还是会积极考虑用索引的， 假如那个索引够简单，取值的选择性也够强，
【在 i***d 的大作中提到】
: 对Oracle不懂, 如果是SQL server的话, coolbid说的是对的.
【在 i***d 的大作中提到】
: 对Oracle不懂, 如果是SQL server的话, coolbid说的是对的.
a9
26 楼
不是特别懂数据库的原理，但是像两键索引。直观感觉上，是按第一个键排序，第一个
键一样才会按第二个键排序，数据库不会建两个索引在上面吧？
择性也够强，
【在 y****w 的大作中提到】
: sql server在这种情况还是会积极考虑用索引的， 假如那个索引够简单，取值的选择性也够强，
键一样才会按第二个键排序，数据库不会建两个索引在上面吧？
择性也够强，
【在 y****w 的大作中提到】
: sql server在这种情况还是会积极考虑用索引的， 假如那个索引够简单，取值的选择性也够强，
y*w
27 楼
那我来解释下吧，很小的一方面： 索引如表一样，是列数据的集合，只是数据结构的
组织不同，还多了对行的引用。如果索引的数据已经足以满足查询的需要，现代的sql
优化器会仔细权衡扫描索引还是扫描表更划算。
换句话说，索引的使用不仅是精确打击，也有类似表扫描的狂轰滥炸用法，只要，这已
经是所有的烂计划中最好的了。
【在 a9 的大作中提到】
: 不是特别懂数据库的原理，但是像两键索引。直观感觉上，是按第一个键排序，第一个
: 键一样才会按第二个键排序，数据库不会建两个索引在上面吧？
:
: 择性也够强，
组织不同，还多了对行的引用。如果索引的数据已经足以满足查询的需要，现代的sql
优化器会仔细权衡扫描索引还是扫描表更划算。
换句话说，索引的使用不仅是精确打击，也有类似表扫描的狂轰滥炸用法，只要，这已
经是所有的烂计划中最好的了。
【在 a9 的大作中提到】
: 不是特别懂数据库的原理，但是像两键索引。直观感觉上，是按第一个键排序，第一个
: 键一样才会按第二个键排序，数据库不会建两个索引在上面吧？
:
: 择性也够强，
s*g
28 楼
If it takes more then 10 minutes, you can try to use dynamic_sampling hint
and set level >= 3 to get the optimal execution plan.
and set level >= 3 to get the optimal execution plan.
v*r
29 楼
”col1 is indexed“ is not a guarantee that index will be used. For example,
if there are many rows equals 601, Oracle will not use index, why? because
full table scan will be considered cheaper/faster in that case (Assuming the
statistics are accurate).
Anyway, a quick diff of two execution plans will tell you why one is slower
and one is faster.
if there are many rows equals 601, Oracle will not use index, why? because
full table scan will be considered cheaper/faster in that case (Assuming the
statistics are accurate).
Anyway, a quick diff of two execution plans will tell you why one is slower
and one is faster.
v*r
30 楼
”col1 is indexed“ is not a guarantee that index will be used. For example,
if there are many rows equals 601, Oracle will not use index, why? because
full table scan will be considered cheaper/faster in that case (Assuming the
statistics are accurate).
Anyway, a quick diff of two execution plans will tell you why one is slower
and one is faster.
if there are many rows equals 601, Oracle will not use index, why? because
full table scan will be considered cheaper/faster in that case (Assuming the
statistics are accurate).
Anyway, a quick diff of two execution plans will tell you why one is slower
and one is faster.
v*r
31 楼
”col1 is indexed“ is not a guarantee that index will be used. For example,
if there are many rows equals 601, Oracle will not use index, why? because
full table scan will be considered cheaper/faster in that case.
Anyway, a quick diff of two execution plans will tell you why one is slower
and one is faster.
if there are many rows equals 601, Oracle will not use index, why? because
full table scan will be considered cheaper/faster in that case.
Anyway, a quick diff of two execution plans will tell you why one is slower
and one is faster.
n*r
32 楼
1. tell us oracle version
2. check statistics, check table row num
3. post the execution plan
most likely it goes either FTS or Index skip scan.
2. check statistics, check table row num
3. post the execution plan
most likely it goes either FTS or Index skip scan.
e*e
33 楼
do the following and post the plan :
1.
explain plan for
select count(*) from TA a where a.col1=601;
2.
set lines 140 pages 1000;
3. check the plan
@?/rdbms/admin/utlxpls;
Do you see full table scan? If so, try this:
1.
explain plan for
select count(*) from TA a where a.col1=601 and a.col2 like 'ABC%'
2. check the plan
@?/rdbms/admin/utlxpls;
Do you see index access path?
If so, use hint to enable index access path used in the second query.
explain plan for
select /*+ index(TA index_name) */ cou
1.
explain plan for
select count(*) from TA a where a.col1=601;
2.
set lines 140 pages 1000;
3. check the plan
@?/rdbms/admin/utlxpls;
Do you see full table scan? If so, try this:
1.
explain plan for
select count(*) from TA a where a.col1=601 and a.col2 like 'ABC%'
2. check the plan
@?/rdbms/admin/utlxpls;
Do you see index access path?
If so, use hint to enable index access path used in the second query.
explain plan for
select /*+ index(TA index_name) */ cou
相关阅读
How popular is Sybase these days?Oracle 11gR2 for x64 windows outDoes anyone know FoxPro Report?免费拿最高600刀 bonus+Discover 12000mile+10刀礼品卡若干（自取）Mysql book急问一个数据库的问题抛砖引玉: 谈谈SQL Server locking and blocking想通过SQL 2008实现random forest 或者adaboost问个关于database developer职业方向的问题Anyone has solutions for T-SQL Challenge 28老印给我的一个ChallengeHelp【招聘】淘宝网请教sql server 2005,怎样在固定时间run stores procedurebackup single tableVista 64bit mdb odbc怎么不好使啊？面世题 请教： How to this query请推荐database的经典书怎么LOAD 大量EXCEL或者CVS DATA?SQL 2000 create index 問題