union all效率低下,該用預存程序、視圖、暫存資料表哪種方法來解決?

來源:互聯網
上載者:User
union all效率低下,大概union all數十張表,單表select僅需0.0003-0.002秒,但union all後需要0.6秒左右
想改善下效率

這種情況該用預存程序、視圖、暫存資料表哪種方法來解決?


回複討論(解決方案)

很明顯,你的資料群組織的不合理

很明顯,你的資料群組織的不合理

難道從來不會有這種情況發生嗎

組織合理就沒有這種情況

你把同質資料垂直分配在數十個表中,就是不合理

組織合理就沒有這種情況

你把同質資料垂直分配在數十個表中,就是不合理

這些表的結構不完全相同的。當時就是考慮到放在一張表會複雜。所以就分開了。不過後來發現要匯總時,問題就來了。

大家有沒有好的辦法。之前建立的那些表已經應用到一些功能上了。現在改也太大工程了。

你能說一下你的那些表的結構嗎?
既然並不相同,那麼疊加在一起的意義何在?

你能說一下你的那些表的結構嗎?
既然並不相同,那麼疊加在一起的意義何在?
我剛剛查了一下,7個表,分別是
1.銷售憑證、紅字銷售憑證
2.採購憑證、紅字採購憑證
3.收款憑證、付款憑證、轉賬憑證。

其中1組和2組結構是一樣的,1組和2組只有一個欄位不同。
3組中的收款憑證和付款憑證也是只有一欄位不同,轉賬憑證的結構則是被收款憑證和付款憑證所包含。

補充一下,1組和2組各自內部的表結構是一樣的。1組和2組之間只有一個欄位不同。

1組和2組不同的欄位是,
1組有‘銷售單號、客戶編碼‘。
2組有 ’採購單號、供應商編碼’。

1組和2組的表結構是這樣,能合并成一個表嗎?

資料量有多大啊?要達到分表的情況下了。分表的話,這種水平分也不合理吧。

你用 union 這不就對了!
這7個表是平行的,就算要串連也只能是 join

資料量有多大啊?要達到分表的情況下了。分表的話,這種水平分也不合理吧。

其實它們都是描述不同的東西。所以才分表的。

1.銷售憑證、紅字銷售憑證
2.採購憑證、紅字採購憑證
3.收款憑證、付款憑證、轉賬憑證。




你用 union 這不就對了!
這7個表是平行的,就算要串連也只能是 join

將1、2組表結構合并,3組表結構合并,這樣合理麼。

不必了吧?你不是說已經應用到一些功能上了嗎?

不必了吧?你不是說已經應用到一些功能上了嗎?

就是各自的一個增刪查改的功能。我不知道這樣設計,以後會不會有其它不好處理的地方出現。

願意的話,你可以描述一下商務程序

剛剛那7個表是接下來要做的幾個功能的資料來源。

比如,有一個日記賬的功能,這個功能就是要從剛剛那7個表中的記錄搜尋有“銀行存款和現金”這兩個科目存在的明細記錄。要把有這兩個存的的明細都抽出來,然後匯總顯示。

第二個,明細賬功能,這個也是要從剛剛那7個表中搜尋除了“銀行存款和現金”以外的所有科目存在的明細記錄,匯總顯示。

第三個,科目匯總表,這個是在一定時間範圍內,所有憑證按科目匯總。

第四個,總分類賬,就是顯示每個科目發生的所有明細記錄。

可能描述的不是很好。請見諒。

union all 之後還做了order之類? 要不不該差這麼大啊

  • 聯繫我們

    該頁面正文內容均來源於網絡整理,並不代表阿里雲官方的觀點,該頁面所提到的產品和服務也與阿里云無關,如果該頁面內容對您造成了困擾,歡迎寫郵件給我們,收到郵件我們將在5個工作日內處理。

    如果您發現本社區中有涉嫌抄襲的內容,歡迎發送郵件至: info-contact@alibabacloud.com 進行舉報並提供相關證據,工作人員會在 5 個工作天內聯絡您,一經查實,本站將立刻刪除涉嫌侵權內容。

    A Free Trial That Lets You Build Big!

    Start building with 50+ products and up to 12 months usage for Elastic Compute Service

    • Sales Support

      1 on 1 presale consultation

    • After-Sales Support

      24/7 Technical Support 6 Free Tickets per Quarter Faster Response

    • Alibaba Cloud offers highly flexible support services tailored to meet your exact needs.