MySQL使用cron作業創建表或使用視圖

我有許多複雜的查詢，其結果存儲在MySQL視圖中。問題在於MySQL的觀點在性能方面受到影響。MySQL使用cron作業創建表或使用視圖

我成立了一個cron作業來填充標準表具有相同數據的看法填入：

DROP TABLE user_reports; 
CREATE TABLE user_reports 
    SELECT col1, col2, col3 FROM 
    /** COMPLEX QUERY **/ 
;

現在，有關cron填充user_reports表進行查詢時，查詢幾乎拿與同等視圖相比，查詢的時間的十分之一。

這是一種常用的方法嗎？顯然每次運行CRON作業時服務器都會有一些負擔，這意味着數據不可用live。採取

時間查詢user_reports =0.002秒
查詢view_user_reports =0.018秒

所需的時間這一切說，也許一個查詢，需要0.018秒運行應該從應用程序代碼運行，而不是存儲在視圖中？雖然我認爲它不會像Cron驅動的方法那樣好。

來源

2011-05-06 dianovich

讓我來澄清一下 - 你有一個基本上是多個表的各種聯接的產物的視圖。然後，你查詢視圖，它需要18毫秒，這不令人滿意，所以你決定做什麼？創建一個充滿來自哪裏的數據的新表？你怎麼填他們的？您是否對說明中的查詢運行了EXPLAIN，以查看瓶頸是什麼？查詢連接表總是比查詢具有複雜WHERE子句的單個錶慢。 – 2011-05-06 13:51:24

其中在被存儲在MySQL視圖

哦親愛的結果。 MySQL視圖不要存儲數據。

DROP TABLE user_reports;

CREATE TABLE user_reports

...什麼問題....

TRUNCATE TABLE user_reports;

？

我不認爲它會擴展以及cron的驅動方法

只有只要在cron作業的查詢並不需要很長時間來運行 - 當它你需要開始考慮將數據逐步添加到預處理結果集中。但在0.018秒時，這只是過早的優化。

來源

2011-05-06 14:35:20 symcbean

感謝所以用這種方式預處理數據是很常見的。很高興你評論了0.018秒，因爲我不認爲這是特別密集的。這對我在很多項目中都會有用。 – dianovich 2011-05-10 09:20:59

在大多數情況下，18 ms的數據庫搜索不會對性能產生負面影響。如果是這樣，那麼通常使用某種緩存。如果你需要能夠對數據進行搜索，並且沒有問題，如果數據太舊了，那麼你的方法是好的。

如果您不需要能夠搜索數據，那麼可以將緩存直接存儲在內存或文件中，最好採用與傳送到客戶端相同的格式。

來源

2011-05-06 13:45:19

MySQL使用cron作業創建表或使用視圖

回答

相關問題