为什么这个 MySQL 查询在条件组合时很慢，但在条件分离时却很快？答案

【问题标题】：Why is this MySQL query slow when conditions are combined, but fast when they are separated?为什么这个 MySQL 查询在条件组合时很慢，但在条件分离时却很快？
【发布时间】：2017-06-24 22:41:08
【问题描述】：

所以假设我有这个查询：

select * from tablea where budget > 100 and users > 1000

单独的查询：

select * from tablea where budget > 100

和

select * from tablea where users > 1000

0.01~秒完成

但是，当组合条件时，查询需要 1-2 秒才能完成。

我在两列（预算、用户）上都有一个索引。

SOF 上有没有聪明人知道为什么会发生这种情况，以及在这种情况下如何优化？

补充说明：

运行第一个查询时，有 100000 行，100000 行用于第二个查询，合并查询时为 3 行
该表有超过 100 万行
EXPLAIN 显示使用了复合索引（budget, user）：EXPLAIN EXTENDED 显示有 1477594 行，大约 50% 被过滤

【问题讨论】：

您的缓冲区缓存可能太低，因此连接迭代正在生成 IO。不过，这不太可能。你要不要展示一下扩展计划？
将其添加到问题中
您的 tablea 中有多少列？
只有查询中的 2 个
我指的是实际的桌子。一些信息很有趣，比如缓冲区、临时、使用索引、使用位置等。

标签： mysql performance indexing query-optimization

【解决方案1】：

EXPLAIN 并不知道，所以它说的正好是 50%。不要相信那个。

您使用了LIMIT，并且在表格的前面有很多符合单一条件的行。

但它必须扫描整个表才能找到组合过滤器的 3 行。

没有索引可用于两个范围 (budget > 100 and users > 1000)，但其中任何一个都会有所帮助：

INDEX(budget, ...)
INDEX(users, ...)

... 可以是任何东西，也可以什么都不是。 可以使用一个索引，但仅限于第一列。

有可能同时使用这两个索引。这与“索引合并”工具有关。如果使用了，那么过程就是从budget索引中拉出100K ids，从user索引中拉出100K行，然后找到两者中的3个id，最后查找行（* ) 为他们。根据“50%”或“100K”或月相，优化器认为不值得。

由于 10% 的表满足单一标准，优化器可能决定扫描表比在索引和数据之间来回跳动更快。请提供SHOW CREATE TABLE和EXPLAIN SELECT。

【讨论】：