<rt id="bn8ez"></rt>
<label id="bn8ez"></label>

  • <span id="bn8ez"></span>

    <label id="bn8ez"><meter id="bn8ez"></meter></label>

    黑豆熊——BlogJava

    面對(duì)挑戰(zhàn),我告訴自己:面對(duì)是勇氣,積極面對(duì)是態(tài)度,堅(jiān)持積極面對(duì)是毅力!

    常用鏈接

    統(tǒng)計(jì)

    積分與排名

    最新評(píng)論

    千萬級(jí)sql優(yōu)化

    這幾天在開發(fā)一個(gè)模塊的時(shí)候,遇到一個(gè)棘手的問題:海量數(shù)據(jù)的查詢效率問題,在下面的sql語句中,sf02表的數(shù)據(jù)在七千萬左右,sf01表的數(shù)據(jù)在三千萬左右,并且兩個(gè)表有關(guān)聯(lián):

    select a.tcol2, a.departcode, a.sendtime, sum(a.mainamount) mainamount
      from sf02 a
     where a.ksdm = '11019204'
      and exists
     (select policyno
      from sf01 b
      where b.businessnature = '531'
      union all select policyno from sf01 b where b.businessnature = '532'
      and a.policyno = b.policyno)
      and (a.kindcode = 'R21' or a.kindcode = 'R29')
      and a.insert_time <= to_date('2011-09-05', 'yyyy-MM-dd')
      and a.insert_time >= to_date('2000-08-25', 'yyyy-MM-dd')
     group by a.tcol2, a.departcode, a.sendtime
     
    由于數(shù)據(jù)庫是分公司的,創(chuàng)建臨時(shí)表不是太好使,這個(gè)問題一直沒有太好的解決辦法,不知道各位有沒有好的思路,希望各位留下寶貴的意見,由于這個(gè)帖子放在提問區(qū)一直沒有人瀏覽,不得已放在首頁,還請(qǐng)blogJava對(duì)該帖放行,非常感謝。

    posted on 2011-09-06 12:18 黑豆熊 閱讀(2916) 評(píng)論(22)  編輯  收藏

    評(píng)論

    # re: 千萬級(jí)sql優(yōu)化 2011-09-06 15:47 @joe

    看看執(zhí)行計(jì)劃啥情況?  回復(fù)  更多評(píng)論   

    # re: 千萬級(jí)sql優(yōu)化 2011-09-06 16:03 黑色幽靈

    上面的sql是在oracle上面模擬的(沒有那么大的數(shù)據(jù)量),實(shí)際上應(yīng)該是放在informix數(shù)據(jù)庫上執(zhí)行的,但是在informix,我還不會(huì)使用執(zhí)行計(jì)劃之類的,哪位仁兄能告知一下。

    另外附加一個(gè)問題?。?
    七千萬條數(shù)據(jù),執(zhí)行查詢,響應(yīng)時(shí)間在多少,用戶是可以接受的?  回復(fù)  更多評(píng)論   

    # re: 千萬級(jí)sql優(yōu)化 2011-09-06 16:19 @joe

    七千萬條其實(shí)都應(yīng)該從業(yè)務(wù)上來處理了,如果你給用戶返回一個(gè)幾萬頁得數(shù)據(jù),用戶也不會(huì)去都翻頁看了。首先從業(yè)務(wù)上只返回有用的數(shù)據(jù)。
    返回時(shí)間,要看什么用戶了,如果是專業(yè)用戶如果時(shí)間有等待,最好界面上提示正在處理數(shù)據(jù),一般我覺得一個(gè)非主要業(yè)務(wù)的查詢超過15秒估計(jì)都不行了。
    如果是面向一般用戶,返回超過10秒估計(jì)都沒人看了。

    大數(shù)據(jù)量處理一般用在統(tǒng)計(jì)分析上,不會(huì)去實(shí)時(shí)查看詳細(xì)數(shù)據(jù)。做分區(qū)處理吧,縮小查詢范圍,適當(dāng)使用位圖索引。informix我也不會(huì),呵呵,但是還是建議業(yè)務(wù)上考慮一下。  回復(fù)  更多評(píng)論   

    # re: 千萬級(jí)sql優(yōu)化 2011-09-06 16:21 @joe

    建兩個(gè)表模擬一下,看看計(jì)劃。  回復(fù)  更多評(píng)論   

    # re: 千萬級(jí)sql優(yōu)化 2011-09-06 16:32 黑色幽靈

    實(shí)際上這條SQL查詢到的數(shù)據(jù),不會(huì)直接展示給用戶,而是與其他數(shù)據(jù)庫取到的數(shù)據(jù)做比較處理以后,存放到一個(gè)臨時(shí)表中,用戶看到的數(shù)據(jù)都是從這個(gè)臨時(shí)表中取到的,現(xiàn)在執(zhí)行查詢,要80秒左右,不知道這個(gè)時(shí)間是否是一個(gè)正常的時(shí)間。  回復(fù)  更多評(píng)論   

    # re: 千萬級(jí)sql優(yōu)化 2011-09-06 16:39 @joe

    80秒非常正常了。  回復(fù)  更多評(píng)論   

    # re: 千萬級(jí)sql優(yōu)化 2011-09-06 16:45 黑色幽靈

    非常感謝你的回復(fù),呵呵  回復(fù)  更多評(píng)論   

    # re: 千萬級(jí)sql優(yōu)化 2011-09-06 17:20 信息

    這明顯可以做成一個(gè)batch job嘛  回復(fù)  更多評(píng)論   

    # re: 千萬級(jí)sql優(yōu)化 2011-09-06 17:55 黑色幽靈

    8樓這位仁兄,能否介紹的詳細(xì)一些?  回復(fù)  更多評(píng)論   

    # re: 千萬級(jí)sql優(yōu)化[未登錄] 2011-09-06 20:13 YY

    select a.tcol2, a.departcode, a.sendtime, sum(a.mainamount) mainamount
    from sf02 a
    where
    exists
    (
    select 1 from sf01 b
    where (b.businessnature = '531') or (b.businessnature = '532'
    and a.policyno = b.policyno))
    and (a.kindcode = 'R21' or a.kindcode = 'R29')
    and a.insert_time <= to_date('2011-09-05', 'yyyy-MM-dd')
    and a.insert_time >= to_date('2000-08-25', 'yyyy-MM-dd')
    and a.ksdm = '11019204'
    group by a.tcol2, a.departcode, a.sendtime  回復(fù)  更多評(píng)論   

    # re: 千萬級(jí)sql優(yōu)化[未登錄] 2011-09-06 22:15 大鵬

    最好給出表結(jié)構(gòu),能看出表之間的關(guān)系,還有索引之類的,能更好的做優(yōu)化。  回復(fù)  更多評(píng)論   

    # re: 千萬級(jí)sql優(yōu)化 2011-09-07 10:56 黑色幽靈

    10樓的這位仁兄,好像是把內(nèi)層的嵌套查詢由union all改成or了,但是,我感覺應(yīng)該是union all的效率更高一些把,完全是個(gè)人意見,歡迎討論。  回復(fù)  更多評(píng)論   

    # re: 千萬級(jí)sql優(yōu)化[未登錄] 2011-09-07 15:00 roger

    用到了sum、exists、union all、group by,還有多個(gè)select語句,即使80秒能夠返回?cái)?shù)據(jù)的話,是否會(huì)影響其他查詢的訪問呢?是否會(huì)lock table呢?問題太多了

    個(gè)人建議:
      1,對(duì)sql進(jìn)行拆分
      2,為了性能,創(chuàng)建索引表
      3,即使sql優(yōu)化了,關(guān)系型數(shù)據(jù)庫的數(shù)據(jù)達(dá)到了7千萬也會(huì)存在查詢緩慢的問題,請(qǐng)考慮其他方式進(jìn)行數(shù)據(jù)的存儲(chǔ),比如Mongodb
      4,使用搜索(lucene、sphinx)來進(jìn)行查詢獲取結(jié)果

    總之,數(shù)據(jù)量達(dá)到這種程度了,應(yīng)該考慮從架構(gòu)的角度解決問題,sql上可優(yōu)化的實(shí)在有限  回復(fù)  更多評(píng)論   

    # re: 千萬級(jí)sql優(yōu)化 2011-09-08 19:09 jacklondon chen

    union all 的前后都用 from sf01 b, 能不能用兩個(gè)不同的別名 b1, b2 ? 看不出你后面的 a.policyno = b.policyno 里用的 b 是前后哪一個(gè)。

    and (a.kindcode = 'R21' or a.kindcode = 'R29') 可以改成:
    and (a.kindcode in ( 'R21' , 'R29') )

    在 sf02 表上建索引:
    索引1, ksdm
    索引2, ksdm + insert_time
      回復(fù)  更多評(píng)論   

    # re: 千萬級(jí)sql優(yōu)化 2011-09-08 19:11 jacklondon chen

    要看 where 條件中,哪個(gè)字段分散性好,在它上面建立索引。  回復(fù)  更多評(píng)論   

    # re: 千萬級(jí)sql優(yōu)化 2011-09-09 08:24 tbw

    恩 不錯(cuò)  回復(fù)  更多評(píng)論   

    # re: 千萬級(jí)sql優(yōu)化[未登錄] 2011-09-09 10:39 evemalloc

    我也遇到這樣的問題,希望樓主有什么好的解決方案拿出來分享  回復(fù)  更多評(píng)論   

    # re: 千萬級(jí)sql優(yōu)化 2011-09-09 15:32 楊明

    這個(gè)問題不用從優(yōu)化Sql的角度去考慮,你的查詢條件,查詢了十年的數(shù)據(jù),這種問題顯然是統(tǒng)計(jì)分析的問題,需要從數(shù)據(jù)倉庫的角度去考慮。建立一個(gè)匯總表。每天增量維護(hù)匯總表。如果一天只有一條數(shù)據(jù)你想還會(huì)慢嗎?  回復(fù)  更多評(píng)論   

    # re: 千萬級(jí)sql優(yōu)化[未登錄] 2011-09-15 11:36 小米

    @roger
    oralce 中 查詢是不會(huì)鎖表的  回復(fù)  更多評(píng)論   

    # re: 千萬級(jí)sql優(yōu)化 2011-09-18 17:10 DB Compare Tool

    相同的語句在不同的DB上執(zhí)行情況通常是不一樣的,你informix的在oracle上試驗(yàn),恐怕沒什么效果吧  回復(fù)  更多評(píng)論   

    # re: 千萬級(jí)sql優(yōu)化 2011-09-21 18:31 呂彥

    如果原文sql沒貼錯(cuò)的話,看簡(jiǎn)化為:
    select a.tcol2, a.departcode, a.sendtime, sum(a.mainamount) mainamount
    from sf02 a
    where a.ksdm = '11019204'
    and a.kindcode in ( 'R21', 'R29')
    and a.insert_time <= to_date('2011-09-05', 'yyyy-MM-dd')
    and a.insert_time >= to_date('2000-08-25', 'yyyy-MM-dd')
    group by a.tcol2, a.departcode, a.sendtime
      回復(fù)  更多評(píng)論   

    # re: 千萬級(jí)sql優(yōu)化 2011-09-23 11:02 wuzhongxing

    and a.insert_time <= to_date('2011-09-05', 'yyyy-MM-dd')
    and a.insert_time >= to_date('2000-08-25', 'yyyy-MM-dd')

    是否可以直接傳值,不用函數(shù)。或者先計(jì)算處理,然后賦值。查詢里面帶上函數(shù)會(huì)影響效率,除非做函數(shù)索引。   回復(fù)  更多評(píng)論   


    只有注冊(cè)用戶登錄后才能發(fā)表評(píng)論。


    網(wǎng)站導(dǎo)航:
    博客園   IT新聞   Chat2DB   C++博客   博問  
     
    主站蜘蛛池模板: 国产亚洲精品高清在线| 亚洲福利在线视频| 精品国产呦系列在线观看免费| 久久伊人久久亚洲综合| 在线观看H网址免费入口| AV激情亚洲男人的天堂国语| 亚洲精品无码午夜福利中文字幕| av免费不卡国产观看| 黄页网站在线免费观看| 日韩精品亚洲人成在线观看 | 在线观看免费中文视频| 亚洲av永久无码天堂网| 亚洲国产精品无码一线岛国| 插B内射18免费视频| 国产在线一区二区综合免费视频| 亚洲高清有码中文字| 亚洲国产精品一区第二页 | 无遮挡国产高潮视频免费观看| 亚洲AV无码精品色午夜果冻不卡 | 亚洲va久久久久| 日韩亚洲人成在线综合日本| 日韩免费a级在线观看| 久久精品免费观看国产| 黄页网址在线免费观看| 亚洲色偷偷综合亚洲av78 | 亚洲熟妇久久精品| 亚洲AV无码一区二区三区DV| 国产精品久久免费视频| 91精品免费在线观看| 18禁在线无遮挡免费观看网站| 国产亚洲成在线播放va| 33333在线亚洲| 亚洲人成影院在线| 亚洲中文久久精品无码ww16| 日本一线a视频免费观看| 波多野结衣中文字幕免费视频| 最近更新免费中文字幕大全| 噜噜噜亚洲色成人网站| 中国亚洲呦女专区| 亚洲日本va在线观看| 亚洲欧洲日本天天堂在线观看|