在做查詢報表的時候，經常有一些資料是需要關聯的，比如 品類集合。
比如銷售報表、采購報表、庫存報表等，都經常需要關聯這個品類集合，那么我之前都是在每個查詢報表中，把品類集合插入到臨時表后進行關聯的。如果我把這個品類集合做成一個視圖，后續的報表直接關聯這個視圖，查詢效率會提高嗎？
哪種方法比較好？或者有無更好的方法推薦一下？謝謝
uj5u.com熱心網友回復：
具體情況 具體分析吧！但我傾向于臨時表！
uj5u.com熱心網友回復：
up一下~~uj5u.com熱心網友回復：
如果是確定數目的資料，我傾向視圖如果是不確定數目的大量資料，我傾向臨時表
比如，從一個800萬資料的表中篩選出的記錄約10萬，參與到另一個表的關聯查詢，用臨時表比較好
簡單來說，子查詢復雜的，會對查詢計劃造成阻礙的，用臨時表
uj5u.com熱心網友回復：
可能我才疏學淺，視圖就是SQL只是封裝了一下，對效率沒有半點提高uj5u.com熱心網友回復：
在視圖中可以指定參考的索引，有時候自動計劃的索引并不合適，這個時候用視圖固定下索引比較好
嗯，個人見解
uj5u.com熱心網友回復：
加到 200，推薦置頂。歡迎大家討論！
uj5u.com熱心網友回復：
應該是臨時表效率高uj5u.com熱心網友回復：
對于報表來說， 關聯比較多， 邏輯復雜， 資料量大， 這種情況只有臨時表是最合適的。但臨時表， 最好也加一下索引， 便于提高效率。
至于視圖中強制用索引， 有用處， 但對報表來說改善并不明顯。 何況也普通sql也是可以指定索引的。
而且指定索引會帶來一些問題， 比如索引的洗掉，修改就會造成原有查詢出錯， 所以不建議在查詢寫死索引。
uj5u.com熱心網友回復：
總體上臨時表要快些uj5u.com熱心網友回復：
兩者是不同的東西，其實我覺得沒啥可比性，都有自己的應用場景。但是樓主說的這種情況，要說這倆哪個更好，推薦臨時表。
uj5u.com熱心網友回復：
其實自己算算就明白了假如有兩個表，表A500萬資料，表B800萬資料，這兩個表都有各自的篩選條件，然后關聯查詢
在一般情況下，執行計劃都是先關聯，也就是產生遍歷了，最大資料量變成了500萬*800萬，然后在用關聯條件匹配，然后執行兩個條件
如果用臨時表，先把各自的條件執行了存入到臨時，這個時候資料量就會小很多很多，自然效率就上來了
uj5u.com熱心網友回復：
可以看看，學習學習uj5u.com熱心網友回復：
在這里好好學習一下uj5u.com熱心網友回復：
在這里好好學習一下uj5u.com熱心網友回復：
根據經驗是臨時表比視圖快。uj5u.com熱心網友回復：
還是要看應用場景，不能一概而論1、如果你對同一批資料進行多次查詢，那肯定就是臨時表了，畢竟臨時表只需要查一次所有資料，把多張大表關聯變成一張小表，之后的多次查詢都不用再去動大表，這種情況下肯定是臨時表了
2、臨時表需要手動維護，維護時要寫入，如果資料量大時，本身插入臨時表就吃了大量的資源，而且使用的次數還不多，可能你插入這批資料，只使用一兩次，這時候可以選擇視圖，畢竟你查詢臨時資料時，可能就已經把資料查出來了，又只使用一兩次，何必再寫臨時表？
所以不能一概而論的，要看你準備干啥
uj5u.com熱心網友回復：
可以看看，學習學習uj5u.com熱心網友回復：
可以看看交流交流
學習
uj5u.com熱心網友回復：
視圖吧 感覺視圖效果會更好些uj5u.com熱心網友回復：
好好學習一下uj5u.com熱心網友回復：
哪個快用哪個，這個還用說嘛，環境不同結果肯定也不同uj5u.com熱心網友回復：
資料多用臨時表！uj5u.com熱心網友回復：
實際使用時臨時表多些uj5u.com熱心網友回復：
000000看看uj5u.com熱心網友回復：
學習學習下~~uj5u.com熱心網友回復：
視圖就是sql的封裝，方便的是操作，對性能沒有提高uj5u.com熱心網友回復：
select * from(select * from b
left join (
select * from a where xxx) c on b.xx =c.xx) d
left join f on xxx 這樣寫個視圖 不行么
uj5u.com熱心網友回復：
我認為效率問題值得討論。效率高低， 我認為只有放在特定context下討論才有意義。它取決于SQL選取的執行計劃，索引的建立，表關系，資料量級以及企業Reporting的具體需求
我認為視圖的貢獻在于模塊化，便于企業中其他人使用。視圖在實際操作中，我記得是直接查找底層表的。不過，要注意在建立視圖時不要偷懶，要列明table.columns并添加shema binding和check option以防止不可預期的insert and delete破壞資料完整性
最有可能優化的地方是如何聯接各表 / 聯接各表的順序。 哪些表要放在左側 以及是否有相關查詢，是否可以使用開窗函式 是優化的重點。
uj5u.com熱心網友回復：
必須是臨時表快啊，視圖這玩意就圖個方便，資料量大了不能搞視圖。 如果資料量很小，且固定不會增長，視圖確實方便uj5u.com熱心網友回復：
我覺得還是臨時表好些吧uj5u.com熱心網友回復：
臨時表好些哦uj5u.com熱心網友回復：
選邊站：臨時表uj5u.com熱心網友回復：
也可以用 CTE 啊uj5u.com熱心網友回復：
臨時表比較快。uj5u.com熱心網友回復：
臨時表，資料已經在記憶體中；視圖，只是減少了查詢陳述句的檢查時間。uj5u.com熱心網友回復：
如何賺取積分，求版主告訴我uj5u.com熱心網友回復：
視圖效率更高uj5u.com熱心網友回復：
根據資料量和應用場景，具體情況具體分析。看樓主表達的一些情況，估計用臨時表更好，建議兩個方法使用對比下，測驗下結果。uj5u.com熱心網友回復：
視圖的設計就是為了查詢放便，將你經常查詢的資料，放在一張虛擬表中，并不占用記憶體。而你自己去建立一張臨時表，這是沒必要的。你可以了解一下視圖的定義。它就是為了查詢放便產生的。uj5u.com熱心網友回復：
臨時表效率高一點吧uj5u.com熱心網友回復：
如果非要比效率的話，肯定臨時表快。視圖只是一個資料的整理，并沒有額外存盤，不能建立索引，只能用原表的索引，我的理解就是資料視窗，從這個視窗看資料而已。
臨時表是將結果存盤起來的，可以額外建立索引，資料大了有合適索引肯定快。
但是如果你每次都是select * 就沒區別了。而且臨時表，就是臨時用的嘛。一般生命周期就只是一個小流程，一個存盤程序中。視圖則是永久的一個視窗。
uj5u.com熱心網友回復：
視圖贊同于直接把視圖陳述句直接放到你的查詢中臨時表意味著你改變了執行程序，先把視圖的查詢結果放到臨時表，再基于臨時表做查詢
所以兩者通常沒有可比性，因為它們的執行程序已經不同了，應該根據實際情況選擇
簡單地說
create view v as select * from tb where id=1;
go
select * from v where a=1;
它等同于：
select * from tb where id=1 and a=1;
而用臨時表，意味著一定是先 id=1的結果存到臨時表，再基于臨時表取 a=1
如果你的表資料量很大，id=1 并不能有效過濾資料，那么這個時候視圖肯定更優勢
但如果你的查詢非常復雜，那么用視圖無法簡化查詢，這個時候的查詢方案可能會非常多，那么選擇的查詢方案可能不是最優的，這個時候用臨時表干預一下可能會獲得列好的效果
個人的看法是除非明確知道臨時表能提升性能，否則直接用視圖
當然，這里的視圖指的是普通視圖，索引視圖的情況而又不同，索引視圖在一定程度上相當于臨時表了，對于資料變化幅度小，視圖結果重復使用率多的情況，索引視圖應該優先考慮
uj5u.com熱心網友回復：
真的很好，謝謝了。真的很好，謝謝了。真的很好，謝謝了。uj5u.com熱心網友回復：
支持一下支持一下，非常有用，感謝好像
uj5u.com熱心網友回復：
開始學時用過視圖，后來都用臨時表了！學習中！多謝分享！uj5u.com熱心網友回復：
要看對表的查詢頻率，如果頻率高，建議使用視圖，否則使用臨時表就可以。uj5u.com熱心網友回復：
視圖吧，個人認為uj5u.com熱心網友回復：
臨時表要高一些uj5u.com熱心網友回復：
具體情況具體分析被uj5u.com熱心網友回復：
視圖更多是一種多模塊間共享的資料標準，臨時表是內部自定義的，放一塊兒比效率不合適吧非要比的話支持臨時表會在一些特定環境下高一些，大多數情況下差別不大。
uj5u.com熱心網友回復：
視圖吧～～～～uj5u.com熱心網友回復：
版主大大寫的都很精彩。應當說，各有妙用。只是要如何發揮最大效率，就看你的手段了。
存在便是道理。學習了
uj5u.com熱心網友回復：
視圖吧，視圖優化了效率uj5u.com熱心網友回復：
哈哈哈零時表uj5u.com熱心網友回復：
過來學習學習uj5u.com熱心網友回復：
視圖更多是一種多模塊間共享的資料標準，臨時表是內部自定義的。非要比的話支持臨時表會在一些特定環境下高一些，大多數情況下差別不大。
uj5u.com熱心網友回復：
在這里好好學習一下uj5u.com熱心網友回復：
啃你 rect.width = 100;System.out.println(rect.width);
rect.height = 200;
System.out.println(rect.height = 200);
Rectangle rect2 = new Rectangle();
rect2.width = 10;
System.out.println(rect2.width);
rect2.height =20;
System.out.println(rect2.height);
uj5u.com熱心網友回復：
public void onNoButtonClick(View view){
TextView textView = (TextView) findViewById(R.id.mainTextView1);
textView.setText("Wrong!");
}
uj5u.com熱心網友回復：
具體情況具體分析uj5u.com熱心網友回復：
這個看情況吧uj5u.com熱心網友回復：
視圖最好，因為物理視圖效率比較高。uj5u.com熱心網友回復：
個人感覺臨時表快uj5u.com熱心網友回復：
具體情況具體分析。我習慣用視圖。uj5u.com熱心網友回復：
一個查詢寫不出來嗎？我很少在專案中用臨時表，當然你說的視圖我也很少用。即使很復雜的動態報表，感覺也能一個存盤程序搞定！uj5u.com熱心網友回復：
臨時表比較好uj5u.com熱心網友回復：
事實上，臨時表和視圖都很有用
比如一個無限級分類，如果想獲得某一個分類的完整路徑，用sql查詢當然可以，但每次都寫一遍很麻煩，而且，不是很標準，當結構略有調整，需要修改的地方就太多了，這個時候通常用視圖來代替大部分查詢指令
另一個就是在很大的資料量上查詢，比如300萬資料，查詢正文中包含某個關鍵字的內容，且滿足其他條件，由于表結構相對欄位較多，用復合了很多欄位的索引肯定不合適，這個時候一般都是用臨時表，將符合關鍵字的主鍵值扔到臨時表后，再inner join原始表查詢，效率比一個指令寫下所有查詢高出太多了，沒有可比性了都
uj5u.com熱心網友回復：
每次都寫一遍有點搞笑哈，如果經常用到結構性的東西就不是視圖和臨時表的討論了，為什么不直接一個表？你要明白臨時表是用之前要寫，用完要處理掉，如果不處理的或者長期保存的為什么要這樣？
還有一點我表達的主要是實際的情況，如果經常視圖，臨時表代替查詢的，我只能說sql寫得很low.確實見過，比如一個存盤程序上千行的東西，但是讓別人改造一下，一個查詢搞定！一個查詢在索引的使用方面我感覺比臨時表要好，因為用的就是原生，你非要用臨時表寫資料，建索引，再查詢，再銷毀，我感覺很累！干脆就建個表得了！
再說一個視圖吧，其實微軟也推薦了視圖的一些主要的應用場景，比如欄位權限，開窗。或者對于維護性的東西不原意改表建表，這們確實省很大部作業。系統對接，開放表結構用視圖確實比較方便。
但是用來純為了當成子查詢，我認為沒有什么優化的效果。
uj5u.com熱心網友回復：
好吧，來個實際點的命題
資料庫中存在文章表（50萬），產品表（300萬），企業表（10萬），綜合搜索，查詢出包含特定關鍵字的內容（關鍵字不可預知），以上3個表資料約40Gb以上，并發頻率約200次/秒，問怎么設計資料庫查詢效率較高，其中三個原始資料表的表結構不可變動，可以使用存盤程序、冗余表，觸發器等一些列你認為可以提高效率的東西
uj5u.com熱心網友回復：
這個叫臨時表?
我假設你全部都要查詢，這種如果不考慮換其他型別資料庫，用空間換時間，提前把關鍵詞提取出來，我認為這種就是永久臨的表了。
但是我可以說你這個資料一點都不多。按你上面的回答是想提取關鍵字，寫入臨時表，再來查哦？
uj5u.com熱心網友回復：
問題在于，關鍵字不可預知，我在實際使用中，每天檢索的關鍵字超過幾萬個，你不可能為每個關鍵字建立永久性冗余表，那樣冗余資料的結構就算再簡單，資料量也會超過千億級別，效率不一定有提高再一個就是，即便你建立了永久臨時表，即冗余表，維護這個冗余資料也是一個很占用資源的事情，每次修改以前的資訊，再按照幾十萬的關鍵字從新更新一遍永久臨時表，不太現實
當然，我這里是小成本，僅僅一個資料庫服務器的情況，如果你要用多組服務器，或者其他什么增加成本的方式解決，那就當我沒問
uj5u.com熱心網友回復：
我一般是固定格式的用視圖，否則用臨時表uj5u.com熱心網友回復：
很多報表,多個存盤程序都會用到 品類集合， 把 品類集合 建成視圖相比于臨時表， 只是減少SQL代碼的重寫， 對效率提高不會有幫助uj5u.com熱心網友回復：
結貼吧，就像高鐵和飛機哪個運輸效率高一樣，永遠沒有絕對的答案。uj5u.com熱心網友回復：
臨時表比較快，把需要的資料提取出來再去關聯uj5u.com熱心網友回復：
111同求，同詢問。。。。
uj5u.com熱心網友回復：
可能我才疏學淺，視圖就是SQL只是封裝了一下，對效率沒有半點提高轉載請註明出處，本文鏈接：https://www.uj5u.com/shujuku/8390.html
標籤：應用實例
上一篇：SQL字符截取問題