见
How MySQL Uses Indexes。
还验证在您向user_metrics表中添加另外2000行或更多行后,MySQL是否仍然执行full table scan。在小表中,索引访问实际上比表扫描更昂贵(I / O方面),MySQL的优化器可能会考虑这一点。
与我以前的文章相反,事实证明MySQL也是using a cost-based optimizer,这是一个很好的消息 – 也就是说,只要你运行你的ANALYZE至少一次,当你相信数据量中的数据量代表未来的日子天使用。
在处理基于成本的优化器(Oracle,Postgres等)时,您需要确保在各种表上定期运行ANALYZE,因为它们的大小增加了超过10-15%。 (默认情况下,Postgres将为您自动完成此操作,而其他RDBMS将为DBA(即您)保留此责任。)通过统计分析,ANALYZE将帮助优化器更好地了解I / O(以及其他关联在各种候选执行计划之间进行选择时将涉及诸如CPU所需的例如用于排序的资源)。无法运行ANALYZE可能导致非常糟糕的,有时是灾难性的规划决策(例如毫秒查询,有时,小时,因为JOIN上的错误嵌套循环)。
如果在运行ANALYZE后性能仍然不能令人满意,那么您通常可以使用提示(例如, FORCE INDEX,而在其他情况下,你可能已经绊倒了一个MySQL错误(例如这个older one,这可能会咬你,你使用Rails的nested_set)。
现在,由于您在Rails应用程序中,使用提示发出自定义查询(而不是继续使用ActiveRecord生成的查询)会很麻烦(并且无法实现ActiveRecord的目的)。
我已经提到,在我们的Rails应用程序中,所有SELECT查询在切换到Postgres后都会下降到100ms以下,而由ActiveRecord生成的一些复杂连接偶尔会占用多达15s或更多的MySQL 5.1,因为内部表扫描的嵌套循环,甚至当指数可用时。没有优化器是完美的,你应该知道的选项。除了查询计划优化,还需要注意的其他潜在性能问题是锁定。这是在你的问题的范围之外,虽然。