×

Loading...
Ad by
  • 推荐 OXIO 加拿大高速网络,最低月费仅$40. 使用推荐码 RCR37MB 可获得一个月的免费服务
Ad by
  • 推荐 OXIO 加拿大高速网络,最低月费仅$40. 使用推荐码 RCR37MB 可获得一个月的免费服务

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

.随着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差别也会很大,在没有具体分析前,还是不应该匆忙就下结论.

以上意见,仅供参考.
Report

Replies, comments and Discussions:

  • 工作学习 / IT技术讨论 / 请教高手, 如何提高SQL SEARCH 的速度, 我的TABLE 有十几万的记录, 搜索一次要两个小时, 是不是要用INDEX 的功能???????
    • 妈呀,我这个外行都知道得用Index,您不是在开玩笑吧?
    • 才十几万条记录,你怎么折腾出两个小时来的?
      • 请问该如何提高速度? 洗耳公听........
    • 搜索什么数据呢?说出来分析分析...
      • 谢谢大家的帮助, 详情如下:
        有两个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.
        • 你这个说了和没说没多大区别。
        • 第一点想法, Sort 和 Join是数据库操作中最耗资源的任务, 利用好 Index能极大的提高效率. 具体使用什么 Index (Clustered, non-Clustered) 如何使用需要具体分析
          • 谢谢高手, 请问Clustered, non-Clustered 有啥区别????????
            • 快抓住Raymond,他是真正高手.. :-)
            • Clustered,rows的物理位置与index的一样。
        • 千万不要去“美人风姿”
          • 只许州官放火,不许百姓点灯。
          • 为什么? 是不是因为很多图像都不能显示,所以不值得浪费时间?
          • 是不是怕别人从那把你揪出?嘻嘻,kidding
    • 即使不能索引十几分钟也足可以把表扫描一遍了。你搜索的时侯在干什么?
      • 他不是说了吗,在逛文学城呢。
    • 看来 rolia 有 58万9千条记录, 挺快的嘛.
      • Not that much, I guess. Notice there is a "History Zone"?
        • oooh.. 高手.
    • 盲目加index未必有用,要看你join的条件如何去写啦.
      • IT looks like you are specialized in SQL, xixi. How is your fishing recently ???
        • "Looks like"?嘿嘿.
          • 口气不小, 力气如何??? 嘻嘻 !
            • 嗯.看来遇到牛人啦.退避三舍.哈哈.
              • I know who you are now, You deserve to be a gaoshou
    • write the structure of a & b, as well as the relationship between them.
      • 大姐, 看清楚前四个字再说话 ^_* 这里不是以谁发言最多来定排行榜的.. :-)
        • 哦,不打肿脸冲胖子了
          • 哈哈,左转灯没坏吧?
            • 左转灯是不能坏,也太危险了。我们领导人说了,要警惕右,但更要防止左。《小平文选〉〉XX章,XX页。想起那个时候每个周五下午政治学习,有就充满了美好的会议。
              • ba
    • 可能你的数据库服务器也有问题,十几万的记录要用一二小时,应该不只是SQL语句的问题了,即使用了 IN 都不太可能花这么长时间。大型数据库都会自动建主键INDEX的
      • I think so. check ur sql server monitor, make to what's wrong
    • the SQL statement is wrong! impossible to take more than 2 hours if it's inner join
    • my database got 40GB and only take second to run most queries.
    • 1.没事别join,2.多加限制条件,3.建簇索引.
    • 现在牛人挺多的,本来没好意思发言,但看了半天,有关概念问题又让咱忍不住想插几句.
      .随着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.
      • PFPF, 条条切中要点! 按您的思路去优化,ACCESS也用不了多长时间.
    • 二个表,记录又不多,不应该要这么长的时间。我常将几个有几十万记录的表join,也不会这么慢。如果你将表的结构及你的SQL post 这里,可帮你看一下
      • 将join的两个字段加上索引,保证你效率提高几个数量级。至于是否是cluster,在这个CASE中无所谓。当你的搜索条件中有BETWEEN等, cluster 才显得必须。