×

Loading...
Ad by
  • 最优利率和cashback可以申请特批，好信用好收入offer更好。请点链接扫码加微信咨询，Scotiabank -- Nick Zhang 6478812600。
Ad by
  • 最优利率和cashback可以申请特批，好信用好收入offer更好。请点链接扫码加微信咨询，Scotiabank -- Nick Zhang 6478812600。

@Calgary

现在牛人挺多的,本来没好意思发言,但看了半天,有关概念问题又让咱忍不住想插几句.

yangn(Raymond)
.随着normalization1,2,3级的进行,table 之间的join在一般的OLTP系统中是很常见的也是很难避免的.不能说"没事别join". 在OLAP中由于要进行大量的summarization,我们才做denormalization以减少join 数.

query需时的多少并不一定和table的大小成正比.它往往取决于
(1)record的长度. record越长,需要search的data page就越多,相应的时间也就越长;
(2) join时有没有specify join的条件.象本例中的两个table join,如果忘了写join的条件,实际进行的将是cross join ,此时search的record 数是两个table cross join的结果 -- 十几万乘以几千 = 上亿 ---
(3) 有没有对join的colomn作index,如果没有,此时的join属hash join,速度也会受很大影响.
(4)作query时有没有其他的transaction在进行,从而导致query被block.打开sql profile,看一下实际情况.
(5)从hardware上讲,memory够不够,看看performance monitor中的cache hit ratio是不是远远低于90%
(6)database file 放在HARD DRIVE 的什么RAID ARRAY上,不同的RAID Level SEEK SPEED不一样,query的performance 也会受到影响.

总之 系统不同,即使很小的database差别也会很大,在没有具体分析前,还是不应该匆忙就下结论.

以上意见,仅供参考.
(#590664@0)
Last Updated: 2002-6-20
This post has been archived. It cannot be replied.
Report

Replies, comments and Discussions:

  • 工作学习 / IT技术讨论 / 请教高手, 如何提高SQL SEARCH 的速度, 我的TABLE 有十几万的记录, 搜索一次要两个小时, 是不是要用INDEX 的功能??????? -winnie-new(winnie); 2002-6-20 (#589596@0)
    • 妈呀，我这个外行都知道得用Index，您不是在开玩笑吧？ -lmx(流氓兔); 2002-6-20 (#589598@0)
    • 才十几万条记录,你怎么折腾出两个小时来的? -guest101(guest); 2002-6-20 (#589603@0)
      • 请问该如何提高速度? 洗耳公听........ -winnie-new(winnie); 2002-6-20 (#589618@0)
    • 搜索什么数据呢?说出来分析分析... -decentboy(黄金重装甲骑士); 2002-6-20 (#589610@0)
      • 谢谢大家的帮助, 详情如下: -winnie-new(winnie); 2002-6-20 {260} (#589642@0)
        有两个TABLE A & B,
        A 有十几万个记录
        B 有几千个记录,
        A & B 是JOINED !!!
        每次要SEARCH 这两个JOINED TABLES, ALWAYS TAKES 2-3 HOURS,
        请问高手有何高见??????????

        PS: EVERYTIME I DO THE SEARCH, I JUST SURF THE WWW.WENXUECITY.COM FOR INTERESTING NEWS, XIXI
        • show us the structures please. -kiwi(Kiwi); 2002-6-20 (#589647@0)
        • 你这个说了和没说没多大区别。 -guestagain(guest again); 2002-6-20 (#589650@0)
        • 第一点想法, Sort 和 Join是数据库操作中最耗资源的任务, 利用好 Index能极大的提高效率. 具体使用什么 Index (Clustered, non-Clustered) 如何使用需要具体分析 -decentboy(黄金重装甲骑士); 2002-6-20 (#589677@0)
          • 谢谢高手, 请问Clustered, non-Clustered 有啥区别???????? -winnie-new(winnie); 2002-6-20 (#589710@0)
            • 快抓住Raymond,他是真正高手.. :-) -decentboy(黄金重装甲骑士); 2002-6-20 (#589715@0)
            • Clustered，rows的物理位置与index的一样。 -guestagain(guest again); 2002-6-20 (#589721@0)
        • 千万不要去“美人风姿” -win(秋天的菠菜); 2002-6-20 (#589694@0)
          • 只许州官放火，不许百姓点灯。 -lilyba(Sunshine); 2002-6-20 (#589705@0)
          • 为什么? 是不是因为很多图像都不能显示,所以不值得浪费时间? -decentboy(黄金重装甲骑士); 2002-6-20 (#589706@0)
          • 是不是怕别人从那把你揪出？嘻嘻，kidding -rabbitbug(兔八哥); 2002-6-20 (#589711@0)
    • 即使不能索引十几分钟也足可以把表扫描一遍了。你搜索的时侯在干什么？ -miketany(MIKE老狼); 2002-6-20 (#589613@0)
      • 他不是说了吗，在逛文学城呢。 -lmx(流氓兔); 2002-6-20 (#589726@0)
    • 看来 rolia 有 58万9千条记录, 挺快的嘛. -kiwi(Kiwi); 2002-6-20 (#589621@0)
      • Not that much, I guess. Notice there is a "History Zone"? -bloor(不老); 2002-6-20 (#589625@0)
        • oooh.. 高手. -kiwi(Kiwi); 2002-6-20 (#589628@0)
    • 盲目加index未必有用,要看你join的条件如何去写啦. -yangn(Raymond); 2002-6-20 (#589663@0)
      • IT looks like you are specialized in SQL, xixi. How is your fishing recently ??? -winnie-new(winnie); 2002-6-20 (#589681@0)
        • "Looks like"?嘿嘿. -yangn(Raymond); 2002-6-20 (#589687@0)
          • 口气不小, 力气如何??? 嘻嘻 ! -winnie-new(winnie); 2002-6-20 (#589695@0)
            • 嗯.看来遇到牛人啦.退避三舍.哈哈. -yangn(Raymond); 2002-6-20 (#589701@0)
              • I know who you are now, You deserve to be a gaoshou -winnie-new(winnie); 2002-6-20 (#589723@0)
    • write the structure of a & b, as well as the relationship between them. -lilyba(Sunshine); 2002-6-20 (#589667@0)
      • 大姐, 看清楚前四个字再说话 ^_* 这里不是以谁发言最多来定排行榜的.. :-) -decentboy(黄金重装甲骑士); 2002-6-20 (#589690@0)
        • 哦，不打肿脸冲胖子了 -lilyba(Sunshine); 2002-6-20 (#589699@0)
          • 哈哈，左转灯没坏吧？ -win(秋天的菠菜); 2002-6-20 (#589729@0)
            • 左转灯是不能坏，也太危险了。我们领导人说了，要警惕右，但更要防止左。《小平文选〉〉XX章，XX页。想起那个时候每个周五下午政治学习，有就充满了美好的会议。 -lilyba(Sunshine); 2002-6-20 (#589762@0)
              • ba -win(秋天的菠菜); 2002-6-20 (#589846@0)
    • 可能你的数据库服务器也有问题，十几万的记录要用一二小时，应该不只是SQL语句的问题了，即使用了 IN 都不太可能花这么长时间。大型数据库都会自动建主键INDEX的 -rabbitbug(兔八哥); 2002-6-20 (#589719@0)
      • I think so. check ur sql server monitor, make to what's wrong -bjduck(北京烤鸭); 2002-6-20 (#589841@0)
    • the SQL statement is wrong! impossible to take more than 2 hours if it's inner join -nice2002(floater); 2002-6-20 (#589934@0)
    • my database got 40GB and only take second to run most queries. -decathlete(Mulberry); 2002-6-20 (#589939@0)
    • 1.没事别join,2.多加限制条件,3.建簇索引. -antmm(xiao ant); 2002-6-20 (#590546@0)
    • 现在牛人挺多的,本来没好意思发言,但看了半天,有关概念问题又让咱忍不住想插几句. -yangn(Raymond); 2002-6-20 {1014} (#590664@0)
      .随着normalization1,2,3级的进行,table 之间的join在一般的OLTP系统中是很常见的也是很难避免的.不能说"没事别join". 在OLAP中由于要进行大量的summarization,我们才做denormalization以减少join 数.

      query需时的多少并不一定和table的大小成正比.它往往取决于
      (1)record的长度. record越长,需要search的data page就越多,相应的时间也就越长;
      (2) join时有没有specify join的条件.象本例中的两个table join,如果忘了写join的条件,实际进行的将是cross join ,此时search的record 数是两个table cross join的结果 -- 十几万乘以几千 = 上亿 ---
      (3) 有没有对join的colomn作index,如果没有,此时的join属hash join,速度也会受很大影响.
      (4)作query时有没有其他的transaction在进行,从而导致query被block.打开sql profile,看一下实际情况.
      (5)从hardware上讲,memory够不够,看看performance monitor中的cache hit ratio是不是远远低于90%
      (6)database file 放在HARD DRIVE 的什么RAID ARRAY上,不同的RAID Level SEEK SPEED不一样,query的performance 也会受到影响.

      总之 系统不同,即使很小的database差别也会很大,在没有具体分析前,还是不应该匆忙就下结论.

      以上意见,仅供参考.
      • 呵呵,牛人呀,PFPF:D 您的意见很对很专业,我就不班门弄斧了.我也很久没整数据库了,具体建议也提不上来了.看他那两张表数据数量差很远,应该是没什么联系的两张表.感觉最好是不要JOIN,可以使用其他的方法避免JOIN.that's all. -antmm(xiao ant); 2002-6-20 (#590691@0)
      • PFPF, 条条切中要点! 按您的思路去优化,ACCESS也用不了多长时间. -cleveland(alex); 2002-6-22 (#594337@0)
    • 二个表，记录又不多，不应该要这么长的时间。我常将几个有几十万记录的表join，也不会这么慢。如果你将表的结构及你的SQL post 这里，可帮你看一下 -ludouya(绿豆牙); 2002-6-21 (#592932@0)
      • 将join的两个字段加上索引，保证你效率提高几个数量级。至于是否是cluster,在这个CASE中无所谓。当你的搜索条件中有BETWEEN等， cluster 才显得必须。 -ron2000(ron); 2002-6-22 (#593828@0)

More Topics

  • 现在社区游泳池招救生员巡逻，过一会还要不停的点人头，这工作是否很快就被AI代替了，装一个摄像头后面是AI处理系统，这样只招一个等着救人就行了，人头沉下水一定时间立马强光照射，还可以分析水下人的状况来判断是否溺水等
  • 新冠疫苗引发心肌炎? 最新研究这样看
  • 这道几何题有解吗?
  • SAM 2 Demo
  • 如何在 AWS EC2 实例上构建 WordPress 应用程序?
    • 枫下论坛主坛 /  工作学习 /  IT技术讨论