Rails在分區的mySQL表上過多的DESCRIBE和SHOW TABLE

Question

我們在生產中看到大量的SHOW TABLES;和DESCRIBE `table name`;查詢 - 而不僅僅是Rails服務器重新啓動。我們注意到它只用於我們的分區表。這是在Rails 3.1.1上 - 未在其他版本上測試過。

當開發者控制檯測試（與cache_classes = true），我們注意到了分區模型，運行Rails的一個SHOW TABLES;和一個DESCRIBE `table name`;爲每個記錄從任何find方法返回。

例如，如果items劃分，並Item.limit(5)返回5個記錄，MySQL日誌看起來是這樣的（注：SHOW TABLES年代和DESCRIBE的是不包括在Rails日誌）：

SELECT `items`.* FROM `items` LIMIT 5; 
SHOW TABLES; 
DESCRIBE `items`; 
SHOW TABLES; 
DESCRIBE `items`; 
SHOW TABLES; 
DESCRIBE `items`; 
SHOW TABLES; 
DESCRIBE `items`; 
SHOW TABLES; 
DESCRIBE `items`; 

這非常瘋狂。

未分區的模型不會執行任何SHOW TABLES或DESCRIBE，除非啓動Rails服務器。看起來如果一個AR模型沒有意識到它的主鍵，那麼每次該模型的一個對象被實例化時，AR必須得到該模式。

如果cache_classes設置爲true，那麼即使沒有已知主鍵的模型，Rails也會/應該緩存模式。但事實並非如此。

您不會認爲SHOW TABLES和DESCRIBE會對系統產生任何實際影響，但我們發現流量充足時，由於這些額外查詢導致的實際性能問題導致併發讀取。

我們如何擺脫這些疑問？

Answer 1

composite_primary_keys寶石保存了一天。我記得很久以前看過這個寶石，但從未用過它。當我們開始使用這些方法時，gem的預期功能將明確簡化我們的分區模型，但使用gem的副作用更重要：

只要告訴Rails primary_key每個分區表中刪除了所有SHOW TABLES' s和DESCRIBE，這使我們遠低於應急讀取併發閾值和改進的響應時間。