MySQL大极限数与无极限

Question

我想知道什么会更快，使用一个查询或另一个查询的权衡是什么？

SELECT * FROM table WHERE somecolumn = 'something' LIMIT 999;

与

SELECT * FROM table WHERE somecolumn = 'something';

现在，考虑到查询的结果不会返回超过几百行，使用LIMIT 999是否会对性能产生一些显著的影响？

我正在查看这个选项，就像在我的项目中一样，我将为用户提供某种选项来限制他想要的结果，他可以将限制保留为空来显示所有内容，所以我更容易将限制部分保留在查询中，然后只更改数字。

现在，这个表真的很大，从几十万到几百万行不等。确切的问题看上去像是：

SELECT  SUM(revenue) AS cost,
        IF(ISNULL(headline) OR  headline = '', 'undefined', headline
           ) AS headline
    FROM  `some_table`
    WHERE  ((date >= '2017-01-01')
       AND  (date <= '2017-12-31')
           )
      AND          -- (sic)
    GROUP BY  `headline`
    ORDER BY  `cost` DESC 

正如我前面说过的，这个查询不会返回超过100行。

Answer 1

• 磁盘I/O (如果有的话)是查询中最昂贵的部分。
• 取每一行排在第二位。
• 其他的几乎一切都是微不足道的。

但是，如果LIMIT的存在可以改变优化器所做的事情，那么可能会有显著的差异。

• 在大多数情况下，包括您提供的查询，过大的LIMIT都不会产生影响。
• 在某些子查询中，LIMIT将防止消除ORDER BY。根据定义，子查询是一个集合，而不是一个有序集。因此，LIMIT是一种防止去除ORDER BY的优化方法。
• 如果有一个包含WHERE、GROUP BY和ORDER BY所需的所有列的复合索引，那么当到达LIMIT时，优化器可以停止。其他情况则通过针对GROUP BY和ORDER BY的tmp表和排序，并且只能针对一组完整的行执行LIMIT。

到目前为止，评论中提到了两个隐藏处。

• “查询缓存”--这记录了准确的查询及其结果集。如果它是打开的，如果它适用，那么查询将“立即”返回。通过“确切”，我包括了LIMIT的存在和价值。
• 为了加速所有查询，数据和索引块在内存中被“缓存”(参见innodb_buffer_pool_size)。这避免了运行类似(不一定准确)的查询时的磁盘I/O。见上面我的第一句话。