這個Rails查詢和它看起來一樣糟糕嗎？

我是來自RoR土地的全新品牌，來自20年來的非動態語言，並致力於一款我沒有創作的應用程序，並且仍然試圖讓我的頭腦在所有通過約定發生的事情（即「神奇」直到你知道是什麼導致它）並嘗試調試問題。這個Rails查詢和它看起來一樣糟糕嗎？

我的問題不是特定於我追蹤的問題，而是想知道這一點;這個調試輸出真的告訴我，10個獨立的調用正在發生在SQL？

Processing OwnersController#stest (for 127.0.0.1 at 2011-06-20 11:08:26) [GET] 
    Parameters: {"action"=>"stest", "controller"=>"owners"} 
User Columns (4.8ms) SHOW FIELDS FROM `users` 
User Load (0.4ms) SELECT * FROM `users` WHERE (`users`.`id` = 45241) LIMIT 1 
Owner Columns (4.8ms) SHOW FIELDS FROM `users` 
Provider Load (121.6ms) SELECT * FROM `providers` WHERE (`providers`.owner_id = 45241) LIMIT 1 
Provider Columns (4.1ms) SHOW FIELDS FROM `providers` 
FeedItem Load (43.2ms) SELECT * FROM `feed_items` WHERE (((4 & item_id) > 0)) AND ((feed_items.created_at >= '2011-06-13 15:08:27') AND (feed_items.event = 5)) GROUP BY initiator_type, initiator_id ORDER BY id ASC 
Rendering template within layouts/front_end 
Rendering owners/stest 
FeedItem Columns (2.0ms) SHOW FIELDS FROM `feed_items` 
User Load (0.4ms) SELECT * FROM `users` WHERE (`users`.`id` = 45268) 
Parent Columns (4.7ms) SHOW FIELDS FROM `users` 
Rendered feed_items/_user_saved_provider_search (23.4ms) 
User Load (0.4ms) SELECT * FROM `users` WHERE (`users`.`id` = 45269) 
Rendered feed_items/_user_saved_provider_search (4.3ms) 
User Load (0.4ms) SELECT * FROM `users` WHERE (`users`.`id` = 45236) 
Rendered feed_items/_user_saved_provider_search (3.7ms) 
InHome Columns (3.7ms) SHOW FIELDS FROM `providers` 
ZipCode Load (32.5ms) SELECT * FROM `zip_codes` WHERE (`zip_codes`.`city` = 'Plano') LIMIT 1 
City Columns (3.1ms) SHOW FIELDS FROM `cities` 
City Load (0.4ms) SELECT * FROM `cities` WHERE (`cities`.`name` = 'Plano') LIMIT 1 
CACHE (0.0ms) SELECT * FROM `zip_codes` WHERE (`zip_codes`.`city` = 'Plano') LIMIT 1 
CACHE (0.0ms) SELECT * FROM `cities` WHERE (`cities`.`name` = 'Plano') LIMIT 1 
Rendered layouts/_extra_links (1.7ms) 
Completed in 552ms (View: 81, DB: 230) | 200 OK [http://0.0.0.0/owners/stest]

來源

2011-06-20 renegade

是的，它**真的是**。 – meagar

看起來像正常輸出給我。你應該儘量保持sql查詢的最小限度，但有時候看起來像這樣。習慣它:) – Mirko

我敢打賭，在開發模式之外，它會在第一次使用每個AR模型時執行「SHOW FIELDS」查詢。 –

我的數據有8個查詢，7個描述和2個緩存查詢。

如果您處理實際上受數據庫查詢瓶頸的應用程序，有幾種方法可以優化生成的查詢數。設置範圍和使用包含可以減少跨關係提取模型時的查詢數量。

Rails通常也不會發出兩次相同的查詢，而是緩存它，因此爲什麼這些行以最後兩個查詢的CACHE開始。

來源

2011-06-20 15:25:44 Cluster

感謝大家的意見。很高興聽到在釋放條件下事情可能會更加優化。 – renegade

這個Rails查詢和它看起來一樣糟糕嗎？

回答

相關問題