處理視圖的MySQL臨時表算法

如果Temp Table算法將被重命名爲Unscalable算法，那將會很好。在視圖定義中看到它時，它可能會給開發人員提供更多的警告 - 類似於在解釋結果中使用臨時表時。大多數情況下，這只是一個唾手可得的要求，但對於不知情的人來說真的可能是災難性的。處理視圖的MySQL臨時表算法

問題是如果你在你的視圖定義中做了某些事情，它會從理性合併算法切換到絕望效率低下的臨時表算法。如果涉及的數據很小，這不是什麼大問題。但是隨着數據的增長，這些將會導致性能下降。

儘管如何處理這個問題呢？這是一個問題，因爲觀點是在5年前實施的，我不知道有什麼努力來解決它。其他常用數據庫系統中是否存在這種問題？

向下滾動，在下面的鏈接，在那裏討論了當合併算法不能用，看看是什麼原因導致的MySQL淪爲使用可怕的臨時表算法： http://mysql2.mirrors-r-us.net/doc/refman/5.1/en/create-view.html

這有什麼不好呢？臨時表算法的工作原理是這樣的：

在視圖定義中運行視圖「原樣」，而不合並查詢的where子句條件。
將生成的數據轉儲到臨時表中。
根據查詢的where子句條件過濾臨時表中的數據 - 這裏也沒有索引。

所以你可以想象這裏所涉及的，當你有一個視圖定義像50萬行的表中的地獄 - 愚蠢的例子，但你明白了吧：

create view last_order_date as 
    select max(order_date) last_date, username from orders group by username;

用戶可能接着寫：

select * from last_order_date where username = 'joejoe22'

2個小時後，結果返回...

那麼如何最好地應對這個局面？

來源

2010-05-28 Khorkrak

編寫一個返回結果集的存儲過程。

DELIMITER $$ 

CREATE PROCEDURE DoViewMyData(Param1 INT) 
BEGIN 
    SELECT 
    field1 as x 
    ,field2 as y 
    FROM table 
    WHERE field1 = Param1; 
END$$ 

DELIMITER ;

現在調用該過程，它將返回select語句的結果集。

CALL DoViewMyData(1); 

OUTPUT: 
+------+-------------------+ 
| x | y     | 
+------+-------------------+ 
| 1 | balabablabla  | 
+------+-------------------+

只要做到CALL，不這樣SELECT CALL不工作。
你也可以用而不是在另一個SELECT語句裏面使用CALL。
你當然可以指示存儲過程把輸出放在一個臨時表中，而不是在另一個SELECT中使用它。

存儲過程將使用正確的索引，並且您的select語句已經準備好。
此外，您可以在前面的語句中準備東西，加快您的時間關鍵型查詢。

你是正確的，雖然： MySQL的訪問量肯定不吸

來源

2011-04-15 17:34:14 Johan

處理視圖的MySQL臨時表算法

回答

相關問題