想做一个软件，对于数据设计不太懂，怎么可以使数据库开发简洁？有没有这方面的软件 - Sql Server当前位置:& &&&想做一个软件，对于数据设计不太懂，怎么可以使数据想做一个软件，对于数据设计不太懂，怎么可以使数据库开发简洁？有没有这方面的软件&&网友分享于：&&浏览：3次想做一个软件，对于数据设计不太懂，如何可以使数据库开发简洁？有没有这方面的软件？比如一些字段是写在一个表里好，还是写在多个表好。易于软件和数据库的维护。因为数据库的变动会牵动整个的程序，表和字段如何分。------解决方案--------------------
应该没有这方面的软件吧，要是有倒是省不人的事哦数据库的设计 是根据需要来设计 的，不是三言二语说得完的
12345678910
12345678910
12345678910 上一篇：下一篇：文章评论相关解决方案 12345678910 Copyright & &&版权所有> 某个大公司的sql面试题，自己不太会做有没有童鞋指点一上
某个大公司的sql面试题，自己不太会做有没有童鞋指点一上
lhtwqh & &
发布时间： & &
浏览：3 & &
回复：20 & &
悬赏：0.0希赛币
某个大公司的sql面试题，自己不太会做有没有童鞋指点一下
　　自己对sql的理解。用一句俗话说：人有七窍，已经通了六窍，有没有童鞋指点一下
　　问：关系模式：User（userId, userName）， Article（articleId, userId, title,　 content），Vote（articleId, score），User为用户关系，Article为用户发表的文章关系，Vote为文章得票关系，title为文章标题、score为得票数。（1）用SQL语言查询所有没发表过文章的用户名；（2）用SQL语言查询得票数大于100的所有文章标题，按得票数倒序排列；（3）用SQL语言查询出发表文章数大于5，文章平均得票数大于100的用户名，按平均得票数倒序排列；（4）设计这些表的主键、外键和索引，并指出上面三个查询所使用的索引。（5）当用户数超过1000万，文章数超过1亿时，如何考虑存储及性能的改进和优化？
　　1 select * from User where useid
not in(select userid from Article);2 select title from article　 inner
on article.articleid=vote.aritcleid and
vote.score&100 order by vote. 3有点不太会，下面胡乱乱写了一通
　　3 select * from user where userid in(select userid from Article inner join vote on article.articleid = vote.articleid group by userId
having avg(score)&100) group by userid having count(*) &5;
　　4主键外键应该很简单，索引第一个应该是userid,第二个是articleid 和score，第三个应该是articleid和 userid
　　5用户数按照id分割分布式存储，文章类似，还可以用读写分离等策略水平扩展数据库.
　　facade 写道　　查询:　　(1)
SELECT U.USERNAME FROM USER U WHERE NOT EXISTS
(SELECT 1 FROM ARTICLE A
WHERE U.USERID = A.USERID)
帅多，你的这个 1是什么意思呀 没见过，请给分析一下...lhvijake & &
11:58:06 & &
& & （0）（0）引用　　shaobaitou 写道　　 建议count(*)少用,用count(userid)之类的、这种说法似乎是误传...lhw1221 & &
11:58:06 & &
& & （0）（0）引用　　Mrpublic 写道　　lerous 写道　　kakaluyi 写道　　谢谢，第3个题目看来只要自己好好再想想就出来了，exists在写hql和jdbc的时候从来没有用过，据说少量结果集用exists,大量结果集用in，再研究研究如果子查询得出的结果集记录较少，主查询中的表较大且又有索引时应该用in；反之如果外层的主查询记录较少，子查询中的表大，又有索引时使用exists请问： 你说的这个: 主查询中表较大又有索引时应该用In;反之外层主查询记录较少，子查询表大又有索引时用exists是有实践证明 ，还是某本书某个老师说的这种东西基本都是误传。 LhuoqilinG & &
11:58:06 & &
& & （0）（0）引用　　只要查出东西出来就行了吧，考虑用这个用那个累不累啊lhw168 & &
11:58:06 & &
& & （0）（0）引用　　貌似大家都关心些SQL语句去了？还是应该多讨论一下后面两个问题吧...............lhui21 & &
11:58:06 & &
& & （0）（0）引用　　msi110 写道　　貌似大家都关心些SQL语句去了？还是应该多讨论一下后面两个问题吧...............恩，围观中，我只知道根据ID mod 下，然后找到相应的表去取数据，如userid %10 ，如果=1，就放在 user_1表，=2就在user_2中。不过这样做统计之类的话，就比较折腾了，大家有什么好的方案不？LhuoqilinG & &
11:58:06 & &
& & （0）（0）引用　　&div class="quote_title"&kakaluyi 写道&/div&&div class="quote_div"&&p&&span&自己对sql的理解。用一句俗话说：人有七窍，已经通了六窍，有没有童鞋指点一下&img src="" alt=""&&/span&&/p&&p&&span&问：关系模式：User（userId, userName）， Article（articleId, userId, title,　 content），Vote（articleId, score），User为用户关系，Article为用户发表的文章关系，Vote为文章得票关系，title为文章标题、score为得票数。&br&（1）用SQL语言查询所有没发表过文章的用户名；&br&（2）用SQL语言查询得票数大于100的所有文章标题，按得票数倒序排列；&br&（3）用SQL语言查询出发表文章数大于5，文章平均得票数大于100的用户名，按平均得票数倒序排列；&br&（4）设计这些表的主键、外键和索引，并指出上面三个查询所使用的索引。&br&（5）当用户数超过1000万，文章数超过1亿时，如何考虑存储及性能的改进和优化？&/span& &/p&&p& &/p&&p&答： &/p&&p& &/p&&p&&span&1 select * from User where useid
not in(select userid from Article);&br&2 select title from article　 inner
on article.articleid=vote.aritcleid and
vote.score&100 order by vote. &br&3有点不太会，下面胡乱乱写了一通&/span&&/p&&p&&span&3 select * from user where userid in(select userid from Article inner join vote on article.articleid = vote.articleid group by userId
having avg(score)&100) group by userid having count(*) &5;&/span&&/p&&p&&span&4主键外键应该很简单，索引第一个应该是userid,第二个是articleid 和score，第三个应该是articleid和 userid&/span&&/p&&p&&span&5用户数按照id分割分布式存储，文章类似，还可以用读写分离等策略水平扩展数据库.&/span&&/p&&/div&&p& &/p&lhui21 & &
11:58:06 & &
& & （0）（0）引用　　哥们第一个就错了，人要的是& 用户名& shouji01 & &
11:58:06 & &
& & （0）（0）引用　　讨论一下最后一个问题吧shouji01 & &
11:58:06 & &
& & （0）（0）引用　　都没说第五题啊，求解。shoulaji & &
11:58:06 & &
& & （0）（0）引用　　reilost说的难道是BD shoujing & &
11:58:06 & &
& & （0）（0）引用　　not in还是少用，个人感觉很慢... 左连接之后isnull应该比not in会好很多。shoulaji & &
11:58:06 & &
& & （0）（0）引用　　Mrpublic 写道　　finux 写道　　呵呵。。。发下我的想法，不一定正确哦~1. select username from user usrleft join article art on art.userid = user.useridwhere art.可以把On 与 where 在一起用哦？？ 求解我只见过... left join ... on ...没有见过 后面还有一个where, 本人菜鸟，给解... 你试试就知道了，嘻嘻。。。我天天写这样的SQL呀~shoujing & &
11:58:06 & &
& & （0）（0）引用　　我是来关注第五题的，前面的题目没兴趣1、我把3个表合成一个表：Table（userId, userName，articleId,& title,&& content，score）&& 理由：一个userName不占用很多存储空间，空间换取速度，如果有其他属性，可以分成用户表和文章表，甚至可以做一扩展属性表，把不常用的属性放入扩展表，减少查询数据的表连接，userName字段的变动不会很大，即使变Table不一定要跟着变，这样可以知道在发表该文章的时候userName是什么，如果一定要变建立userId的索引，update也是很高效率的。2、根据用户的点击率和、登录频、文章点击率等高使用频率分级存储数据3、建立相关查询的表索引，使用服务器缓存高使用频率的数据shouhuo571 & &
11:58:06 & &
& & （0）（0）引用　　vision2000 写道　　我是来关注第五题的，前面的题目没兴趣1、我把3个表合成一个表：Table（userId, userName，articleId,& title,&& content，score）&& 理由：一个userName不占用很多存储空间，空间换取速度，如果有其他属性，可以分成用户表和文章表，甚至可以做一扩展属性表，把不常用的属性放入扩展表，减少查询数据的表连接，userName字段的变动不会很大，即使变Table不一定要跟着变，这样可以知道在发表该文章的时候userName是什么，如果一定要变建立userId的索引，update也是很高效率的。2、根据用户的点击率和、登录频、文章点击率等高使用频率分级存储数据3、建立相关查询的表索引，使用服务器缓存高使用频率的数据&& 恩面试完了，没有sql的问题。谢谢大家的答复，这个朋友的建议1首先3个表应该不能完全合并的，毕竟用户和文章是一对多的关系，2索引，缓存数据库，分布式确实是第五题的通用解决方法，3还有就是数据库的一些性能调优比如mysql的 table_cache key_buffer_cache，合理利用服务器超强的性能昨天问到一个数据库连接池的设计问题和一些优化设计问题，过段时间再和大家探讨一下 shoujidenglv & &
11:58:06 & &
& & （0）（0）引用　　kakaluyi 写道　　vision2000 写道　　我是来关注第五题的，前面的题目没兴趣1、我把3个表合成一个表：Table（userId, userName，articleId,& title,&& content，score）&& 理由：一个userName不占用很多存储空间，空间换取速度，如果有其他属性，可以分成用户表和文章表，甚至可以做一扩展属性表，把不常用的属性放入扩展表，减少查询数据的表连接，userName字段的变动不会很大，即使变Table不一定要跟着变，这样可以知道在发表该文章的时候userName是什么，如果一定要变建立userId的索引，update也是很高效率的。2、根据用户的点击率和、登录频、文章点击率等高使用频率分级存储数据3、建立相关查询的表索引，使用服务器缓存高使用频率的数据&& 恩面试完了，没有sql的问题。谢谢大家的答复，这个朋友的建议1首先3个表应该不能完全合并的，毕竟用户和文章是一对多的关系，2索引，缓存数据库，分布式确实是第五题的通用解决方法，3还有就是数据库的一些性能调优比如mysql的 table_cache key_buffer_cache，合理利用服务器超强的性能昨天问到一个数据库连接池的设计问题和一些优化设计问题，过段时间再和大家探讨一下 我也感觉3个表合成一个是不合理的。楼主，正确答案没有是么？或者你可以整理一下你的问题，发表一个正确答案来结贴啊。第五个问题，用分区的方式来解决应该可以吧。mysql里面倒是可以的，使用用户的id或者名字来进行分区article 也用分区，也可以使用articleid和userid来分区shouji401 & &
11:58:06 & &
& & （0）（0）引用　　忍不住来叨叨两句，有不对的大家指点哈！第一题：用not in还是not exists快，这要取决于不同数据库不同sql了。就此题来说，在SQL Server中两者是一样快的，正好有现成数据，刚试验了一下，user表跟article表各五万条数据，not in和not exists的写法运行时间均是五秒。分析执行计划也是一样的。主要的时间代价花费到了三个地方：两个表的索引扫描约是55%，多线程的并行分拆及合并11%，哈希匹配14%。看了一下执行计划，SQL Server对这两者皆做了优化，主要工作还是在索引和建立hash关系上，于是就有了第三种写法：　　select count(userida) from(
select a.userid userida,b.userid useridb from user a left join article b on a.userid=b.userid
) aa where useridb is null试了试，跟not in, not exists执行计划基本一致，运行时间也是一样的。在oracle下就复杂多了，RBO还是CBO、表的大小都有可能改变执行计划。在基于规则的RBO优化器下，exists和in的执行计划是一致的，跟 not exists, in ,not in执行计划都不一样，其中exists, not exists使用了不同的hash计算，not in是效率最低的，用的是filter，要做笛卡尔积再用条件过滤，巨慢。不过通过加HINT，可以选择合适的执行计划，这点也是我喜欢oracle不喜欢sql server的一个重要原因，在上百行的复杂sql的优化中很是有用。综上，写not exists是最保险的做法了，基本能保证速度最快。shoujing & &
11:58:06 & &
& & （0）（0）引用　　然后是第三题：平常习惯就不太常用having，跟前面不用in是一样的道理，having的效率总不会比where条件更快。语句如下：　　select userid from(
select a.userid,count(1) articleqty, avg(c.score) scoreavg
from user a,artical b,vote c
where a.userid=b.userid
and b.articleid=c.articleid
group by a.userid
) aa where articleqty&5 and scoreavg&100三表关联会消除没有发表文章的userid，但是为了减少子查询的条数，还可以进一步改进：　　select userid,scoreavg from(
select aa.userid,avg(bb.score) scoreavg
select a.userid,b.articleid,count(1) articleqty
from user a,artical b
where a.userid=b.userid
group by a.userid
) aa,vote bb
where aa.articleid=bb.articleid
and aa.articleqty&5
group by aa.userid
where aaa.scoreavg&100
order by scoreavg desc这样会根据发表文章数大于5做一个初步过滤，减小驱动表的数据量。如果大量存在非活跃用户，这种筛选还是能提速不少的。当然，最外面的一层查询可以改成having。还有一种情况，就是如果没有人评分过的文章就在vote表中添加记录，而且大量存在未评分文章，那么vote表的数量就会比article小很多，可以使用第一个SQL，三表关联，以vote作为驱动表，也应该能提高不少效率。shoulder & &
11:58:06 & &
& & （0）（0）引用　　第四题：主键的话是毫无疑问的，user表里的userid,article表里的articleid，vote表里的articleid。一般来说，在设计主键时，最好采用字符型的．不采用自动递增，在新增记录时，系统生成主键值。而且，主键最好不具有任何实际意义，因为带有实际意义的字段，还是存在被修改的可能性．而对于主键最大的忌讳就是修改主键，这可能会导致非常严重的不可估计的后果。外键的话就是article表里的userid，vote表里的ariticleid。建立索引的时候要注意，复合索引对多条件查询的速度提速是很明显的，但是用不好的话，不但对sql查询的速度没有提升，还会拖慢数据插入的速度。当数据量达到100万的时候，复合索引甚至会成倍的拖慢插入速度。比如article表中，建立(articleid,userid)索引，必须同时使用两列查询条件，才能使用复合索引，用userid关联user表和article表时，就不会走索引。同理，SQL Server里面的聚类索引也要慎用。索引递增插入还好，否则就是悲剧了。唯一性索引是效率最高的。个人认为，user下userid列建立一个索引，article表建立两个索引，一个是articleid，一个是userid，vote建立一个索引，是articleid。shouji401 & &
11:58:06 & &
& & （0）（0）引用　　mark 学习了。~~shoulaji & &
11:58:06 & &
& & （0）（0）引用
本问题标题：
本问题地址：
温馨提示：本问答中心的任何言论仅代表发言者个人的观点，与希赛网立场无关。请对您的言论负责，遵守中华人民共和国有关法律、法规。如果您的言论违反希赛网问答中心的规则，将会被删除。
暂无合适的专家
&&&&&&&&&&&&&&&
希赛网 版权所有 & &&查看: 1069|回复: 8
如下sql帮忙看一下有没有可优化的地方。谢谢!!!!
求职 : 认证徽章论坛徽章:19
SQL&&&select * from table(dbms_xplan.display_cursor(''));
PLAN_TABLE_OUTPUT
----------------------------------------------------------------------------------------------------------------------------------------------------------------
HASH_VALUE&&, child number 0
--------------------------------------
SELECT count(1)& &FROM& && && &ME_CONCLUSION& && & WHERE
ME_CONCLUSION.DELETED_FLAG= :1& && && && && && &AND& && && &&&ME_CONCLUSION.ITEM_CODE = :2& &&&AND& && & ME_CONCLUSION.PARENT_CODE&&IS NULL
OR ME_CONCLUSION.CODE& && && && && &IN& &&&
(SELECT ME_CONCLUSION.PARENT_CODE& && &FROM& && &&&ME_CONCLUSION& && & WHERE EXISTS& && && &
& &&&(SELECT NULL& && && &FROM& && && &&&ME_DTL_CONCLUSION& & WHERE& && && &&&ME_CONCLUSION.ID&&=ME_DTL_CONCLUSION.CONCLUSION_ID& && && &
& && & AND ME_DTL_CONCLUSION.ITEM_CODE= :3& && && & AND& && && & ME_DTL_CONCLUSION.MAIN_FILE_ID = :4
& && &)& && &
& &AND ME_CONCLUSION.ITEM_CODE = :5& && &
Plan hash value:
-----------------------------------------------------------------------------------------------------------------
| Id&&| Operation& && && && && && && & | Name& && && && && && && && && &| Rows&&| Bytes | Cost (%CPU)| Time& &&&|
-----------------------------------------------------------------------------------------------------------------
|& &0 | SELECT STATEMENT& && && && && &|& && && && && && && && && && &&&|& && & |& && & |& & 52 (100)|& && && & |
|& &1 |&&SORT AGGREGATE& && && && && & |& && && && && && && && && && &&&|& &&&1 |& & 28 |& && && && &|& && && & |
|*&&2 |& &FILTER& && && && && && && &&&|& && && && && && && && && && &&&|& && & |& && & |& && && && &|& && && & |
|& &3 |& & TABLE ACCESS FULL& && && &&&| ME_CONCLUSION& && && && && && &| 12266 |& &335K|& & 52& &(0)| 00:00:01 |
|& &4 |& & NESTED LOOPS SEMI& && && &&&|& && && && && && && && && && &&&|& &&&1 |& & 35 |& &&&3& &(0)| 00:00:01 |
|*&&5 |& &&&TABLE ACCESS BY INDEX ROWID| ME_CONCLUSION& && && && && && &|& &&&1 |& & 19 |& &&&2& &(0)| 00:00:01 |
|*&&6 |& && &INDEX RANGE SCAN& && && & | IDX_ME_CONCLUSION_ON_ITEM_CODE |& &&&4 |& && & |& &&&1& &(0)| 00:00:01 |
|*&&7 |& &&&TABLE ACCESS BY INDEX ROWID| ME_DTL_CONCLUSION& && && && &&&|& &&&1 |& & 16 |& &&&1& &(0)| 00:00:01 |
|*&&8 |& && &INDEX RANGE SCAN& && && & | IDX_ME_DTL_FILE_ID& && && && & |& &&&1 |& && & |& &&&0& &(0)|& && && & |
-----------------------------------------------------------------------------------------------------------------
Predicate Information (identified by operation id):
---------------------------------------------------
& &2 - filter(((&ME_CONCLUSION&.&PARENT_CODE& IS NULL AND &ME_CONCLUSION&.&ITEM_CODE&=:2 AND
& && && && &&&&ME_CONCLUSION&.&DELETED_FLAG&=:1) OR&&IS NOT NULL))
& &5 - filter(&ME_CONCLUSION&.&PARENT_CODE&=:B1)
& &6 - access(&ME_CONCLUSION&.&ITEM_CODE&=:5)
& &7 - filter((&ME_DTL_CONCLUSION&.&ITEM_CODE&=:3 AND
& && && && &&&&ME_CONCLUSION&.&ID&=&ME_DTL_CONCLUSION&.&CONCLUSION_ID&))
& &8 - access(&ME_DTL_CONCLUSION&.&MAIN_FILE_ID&=:4)
42 rows selected.
论坛徽章:4
本帖最后由 maoweiting 于
16:36 编辑
&&IN&&换成exists 试试
论坛徽章:78
select& & & & sum(cnt)
from& & & & (
& & & & SELECT& & & & count(1) cnt
& & & & FROM& & & & ME_CONCLUSION
& & & & WHERE& & & & DELETED_FLAG= :1
& & & & AND& & & & ITEM_CODE = :2
& & & & AND& & & & PARENT_CODE&&IS NULL
& & & & union all
& & & & SELECT& & & & count(1) cnt
& & & & FROM& & & & ME_CONCLUSION
& & & & WHERE& & & & CODE in (
& & & & & & & & select& & & & a.PARENT_CODE
& & & & & & & & from& & & & ME_CONCLUSION a
& & & & & & & & where& & & & exists
& & & & & & & & & & & & (select& & & & 1
& & & & & & & & & & & & from& & & & ME_DTL_CONCLUSION b
& & & & & & & & & & & & where& & & & a.ID=b.CONCLUSION_ID
& & & & & & & & & & & & and& & & & b.ITEM_CODE= :3
& & & & & & & & & & & & and& & & & b.MAIN_FILE_ID = :4)
& & & & & & & & and& & & & a.ITEM_CODE = :5
& & & & & & & & )
& & & & and& & & & not (DELETED_FLAG= :1
& & & & & & & & AND& & & & ITEM_CODE = :2
& & & & & & & & AND& & & & PARENT_CODE&&IS NULL)
& & & & )复制代码试试
求职 : 认证徽章论坛徽章:19
udfrog 发表于
SQL& select * from table(dbms_xplan.display);
PLAN_TABLE_OUTPUT
----------------------------------------------------------------------------------------------------------------------------------------------------------------
Plan hash value:
-----------------------------------------------------------------------------------------------------------------------
| Id&&| Operation& && && && && && && && && & | Name& && && && && && && && && &| Rows&&| Bytes | Cost (%CPU)| Time& &&&|
-----------------------------------------------------------------------------------------------------------------------
|& &0 | SELECT STATEMENT& && && && && && && &|& && && && && && && && && && &&&|& &&&1 |& & 13 |& & 63& &(4)| 00:00:01 |
|& &1 |&&SORT AGGREGATE& && && && && && && & |& && && && && && && && && && &&&|& &&&1 |& & 13 |& && && && &|& && && & |
|& &2 |& &VIEW& && && && && && && && && && & |& && && && && && && && && && &&&|& &&&2 |& & 26 |& & 63& &(4)| 00:00:01 |
|& &3 |& & UNION-ALL& && && && && && && && & |& && && && && && && && && && &&&|& && & |& && & |& && && && &|& && && & |
|& &4 |& &&&SORT AGGREGATE& && && && && && & |& && && && && && && && && && &&&|& &&&1 |& & 15 |& && && && &|& && && & |
|*&&5 |& && &TABLE ACCESS BY INDEX ROWID& &&&| ME_CONCLUSION& && && && && && &|& &&&5 |& & 75 |& &&&5& &(0)| 00:00:01 |
|*&&6 |& && & INDEX RANGE SCAN& && && && && &| IDX_ME_CONCLUSION_ON_ITEM_CODE |& & 55 |& && & |& &&&1& &(0)| 00:00:01 |
|& &7 |& &&&SORT AGGREGATE& && && && && && & |& && && && && && && && && && &&&|& &&&1 |& & 37 |& && && && &|& && && & |
|*&&8 |& && &HASH JOIN RIGHT SEMI& && && && &|& && && && && && && && && && &&&|& &&&1 |& & 37 |& & 58& &(4)| 00:00:01 |
|& &9 |& && & VIEW& && && && && && && && && &| VW_NSO_1& && && && && && && &&&|& &&&1 |& & 12 |& &&&5&&(20)| 00:00:01 |
|&&10 |& && &&&NESTED LOOPS& && && && && && &|& && && && && && && && && && &&&|& && & |& && & |& && && && &|& && && & |
|&&11 |& && && &NESTED LOOPS& && && && && &&&|& && && && && && && && && && &&&|& &&&1 |& & 34 |& &&&5&&(20)| 00:00:01 |
|&&12 |& && && & SORT UNIQUE& && && && && &&&|& && && && && && && && && && &&&|& &&&1 |& & 17 |& &&&3& &(0)| 00:00:01 |
|* 13 |& && && &&&TABLE ACCESS BY INDEX ROWID| ME_DTL_CONCLUSION& && && && &&&|& &&&1 |& & 17 |& &&&3& &(0)| 00:00:01 |
|* 14 |& && && && &INDEX RANGE SCAN& && && & | IDX_ME_DTL_FILE_ID& && && && & |& &&&3 |& && & |& &&&1& &(0)| 00:00:01 |
|* 15 |& && && & INDEX UNIQUE SCAN& && && &&&| PK_ME_CONCLUSION& && && && && &|& &&&1 |& && & |& &&&0& &(0)| 00:00:01 |
|* 16 |& && && &TABLE ACCESS BY INDEX ROWID&&| ME_CONCLUSION& && && && && && &|& &&&1 |& & 17 |& &&&1& &(0)| 00:00:01 |
|* 17 |& && & TABLE ACCESS FULL& && && && &&&| ME_CONCLUSION& && && && && && &| 12261 |& &299K|& & 52& &(0)| 00:00:01 |
-----------------------------------------------------------------------------------------------------------------------
Predicate Information (identified by operation id):
---------------------------------------------------
& &5 - filter(&PARENT_CODE& IS NULL AND &DELETED_FLAG&=TO_NUMBER(:1))
& &6 - access(&ITEM_CODE&=:2)
& &8 - access(&CODE&=&PARENT_CODE&)
&&13 - filter(&B&.&ITEM_CODE&=:3)
&&14 - access(&B&.&MAIN_FILE_ID&=TO_NUMBER(:4))
&&15 - access(&A&.&ID&=&B&.&CONCLUSION_ID&)
&&16 - filter(&A&.&ITEM_CODE&=:5)
&&17 - filter(&PARENT_CODE& IS NOT NULL OR &ITEM_CODE&&&:2 OR &DELETED_FLAG&&&TO_NUMBER(:1))
36 rows selected.
论坛徽章:78
tolilong 发表于
SQL& select * from table(dbms_xplan.display);
PLAN_TABLE_OUTPUT
直接执行，不要看cost，或者你把statistics放出来看看
求职 : 认证徽章论坛徽章:19
udfrog 发表于
直接执行，不要看cost，或者你把statistics放出来看看
Statistics
----------------------------------------------------------
& && && & 1&&recursive calls
& && && & 0&&db block gets
& && &&&193&&consistent gets
& && && & 0&&physical reads
& && && & 0&&redo size
& && &&&422&&bytes sent via SQL*Net to client
& && &&&416&&bytes received via SQL*Net from client
& && && & 2&&SQL*Net roundtrips to/from client
& && && & 1&&sorts (memory)
& && && & 0&&sorts (disk)
& && && & 1&&rows processed
求职 : 认证徽章论坛徽章:19
udfrog 发表于
直接执行，不要看cost，或者你把statistics放出来看看
| Id&&| Operation& && && && && && && && && & | Name& && && && && &| Rows&&| Bytes | Cost (%CPU)| Time& &&&|
-----------------------------------------------------------------------------------------------------------
|& &0 | SELECT STATEMENT& && && && && && && &|& && && && && && &&&|& &&&1 |& & 13 |& &110& &(2)| 00:00:02 |
|& &1 |&&SORT AGGREGATE& && && && && && && & |& && && && && && &&&|& &&&1 |& & 13 |& && && && &|& && && & |
|& &2 |& &VIEW& && && && && && && && && && & |& && && && && && &&&|& &&&2 |& & 26 |& &110& &(2)| 00:00:02 |
|& &3 |& & UNION-ALL& && && && && && && && & |& && && && && && &&&|& && & |& && & |& && && && &|& && && & |
|& &4 |& &&&SORT AGGREGATE& && && && && && & |& && && && && && &&&|& &&&1 |& & 15 |& && && && &|& && && & |
|*&&5 |& && &TABLE ACCESS FULL& && && && && &| ME_CONCLUSION& && &|& &&&5 |& & 75 |& & 52& &(0)| 00:00:01 |
|& &6 |& &&&SORT AGGREGATE& && && && && && & |& && && && && && &&&|& &&&1 |& & 37 |& && && && &|& && && & |
|*&&7 |& && &HASH JOIN RIGHT SEMI& && && && &|& && && && && && &&&|& &&&1 |& & 37 |& & 58& &(4)| 00:00:01 |
|& &8 |& && & VIEW& && && && && && && && && &| VW_NSO_1& && && &&&|& &&&1 |& & 12 |& &&&5&&(20)| 00:00:01 |
|& &9 |& && &&&NESTED LOOPS& && && && && && &|& && && && && && &&&|& && & |& && & |& && && && &|& && && & |
|&&10 |& && && &NESTED LOOPS& && && && && &&&|& && && && && && &&&|& &&&1 |& & 34 |& &&&5&&(20)| 00:00:01 |
|&&11 |& && && & SORT UNIQUE& && && && && &&&|& && && && && && &&&|& &&&1 |& & 17 |& &&&3& &(0)| 00:00:01 |
|* 12 |& && && &&&TABLE ACCESS BY INDEX ROWID| ME_DTL_CONCLUSION&&|& &&&1 |& & 17 |& &&&3& &(0)| 00:00:01 |
|* 13 |& && && && &INDEX RANGE SCAN& && && & | IDX_ME_DTL_FILE_ID |& &&&3 |& && & |& &&&1& &(0)| 00:00:01 |
|* 14 |& && && & INDEX UNIQUE SCAN& && && &&&| PK_ME_CONCLUSION& &|& &&&1 |& && & |& &&&0& &(0)| 00:00:01 |
|* 15 |& && && &TABLE ACCESS BY INDEX ROWID&&| ME_CONCLUSION& && &|& &&&1 |& & 17 |& &&&1& &(0)| 00:00:01 |
|* 16 |& && & TABLE ACCESS FULL& && && && &&&| ME_CONCLUSION& && &| 12261 |& &299K|& & 52& &(0)| 00:00:01 |
-----------------------------------------------------------------------------------------------------------
Predicate Information (identified by operation id):
---------------------------------------------------
& &5 - filter(&PARENT_CODE& IS NULL AND TO_NUMBER(&ITEM_CODE&)=11101 AND &DELETED_FLAG&=0)
& &7 - access(&CODE&=&PARENT_CODE&)
&&12 - filter(TO_NUMBER(&B&.&ITEM_CODE&)=11101)
&&13 - access(&B&.&MAIN_FILE_ID&=74433)
&&14 - access(&A&.&ID&=&B&.&CONCLUSION_ID&)
&&15 - filter(TO_NUMBER(&A&.&ITEM_CODE&)=11101)
&&16 - filter(&PARENT_CODE& IS NOT NULL OR TO_NUMBER(&ITEM_CODE&)&&11101 OR &DELETED_FLAG&&&0)
Statistics
----------------------------------------------------------
& && && & 1&&recursive calls
& && && & 0&&db block gets
& && &&&193&&consistent gets
& && && & 0&&physical reads
& && && & 0&&redo size
& && &&&422&&bytes sent via SQL*Net to client
& && &&&416&&bytes received via SQL*Net from client
& && && & 2&&SQL*Net roundtrips to/from client
& && && & 1&&sorts (memory)
& && && & 0&&sorts (disk)
& && && & 1&&rows processed
论坛徽章:78
那原来呢，原来consistent gets应该比较多吧，
求职 : 认证徽章论坛徽章:19
udfrog 发表于
那原来呢，原来consistent gets应该比较多吧，
差不多，没有多少变化.
itpub.net All Right Reserved. 北京皓辰网域网络信息技术有限公司版权所有　　　　
　北京市公安局海淀分局网监中心备案编号：　广播电视节目制作经营许可证：编号（京）字第1149号