我们在生产中看到了大量的SHOW TABLES;和DESCRIBE `table name`;查询 - 而不仅仅是在Rails服务器重启上。我们注意到它只适用于我们的分区表。这是在Rails 3.1.1上 - 未在其他版本上测试过。
在开发者控制台（使用cache_classes = true）进行测试时，我们注意到对于分区模型，Rails为返回的每条记录}运行一个SHOW TABLES;和一个DESCRIBE `table name`;任何找到方法。
例如，如果items已分区，Item.limit(5)返回5条记录，则mySQL日志如下所示（注意：SHOW TABLES的AND和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`;
那太疯狂了。
除了启动Rails服务器之外，非分区模型不会执行任何SHOW TABLES和DESCRIBE。看起来如果AR模型不知道它的主键，AR必须在每次实例化该模型的对象时获取模式。
如果将cache_classes设置为true，您会认为即使没有已知主键的模型，Rails也会/应该缓存架构。但事实并非如此。
您不会认为SHOW TABLES和DESCRIBE会对系统产生任何实际影响，但我们发现有足够的流量，由于这些额外的查询导致一个分区表上的并发读取真正的性能问题。
我们如何摆脱这些疑问？
答案 0 :(得分：0)
composite_primary_keys宝石节省了一天。我记得很久以前见过这颗宝石，但从未使用它。当我们开始使用这些方法时，gem的预期功能肯定会简化我们的分区模型，但使用gem的副作用更为重要：
告诉Rails每个分区表的primary_key删除了所有SHOW TABLES和DESCRIBE，这使我们远远低于爆炸 - 应阅读 - 并发阈值和改进的响应时间。