mysql中 where in 索引吗,MySQL不使用带有WHERE IN子句的索引？

见

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，因为内部表扫描的嵌套循环，甚至当指数可用时。没有优化器是完美的，你应该知道的选项。除了查询计划优化，还需要注意的其他潜在性能问题是锁定。这是在你的问题的范围之外，虽然。