EXISTS 与 IN - MySQL 5.5 和 MySQL 5.7 中哪一个更好？答案

【问题标题】：EXISTS vs IN - which one is better in MySQL 5.5 and MySQL 5.7?EXISTS 与 IN - MySQL 5.5 和 MySQL 5.7 中哪一个更好？
【发布时间】：2018-02-21 13:08:45
【问题描述】：

从性能角度来看，我正在 MySQL 5.7 和 5.5 上测试两种不同的 SQL 方法（EXISTS 与 IN）。作为测试的旁注，两个数据库都在同一台机器上，我为每个测试只激活了其中一个。他们每个人都有 4GB 的内存分配给他们。我在每次测试之前都重新启动了数据库，以确保没有完成缓存（至少不在数据库级别）。

我在 StackOverflow 上看到了很多问题，从 IN 到 EXISTS 的转换在性能方面很有帮助。在大多数线程中，旧 MySQL 版本（ver

另外，我一直在读到 IN 可能在较新的 MySQL 版本中得到了改进，所以我想亲眼看看。

因此，为了更好地了解哪一个更适合我未来的查询，我进行了以下测试：

定义常数：

SET @quantity = 50;

EXISTS 查询：

SELECT SQL_NO_CACHE
    c.c_first_name, c.c_birth_country
FROM
    customer c
WHERE
    EXISTS( SELECT 
            1
        FROM
            store_sales ss
        WHERE
            ss.ss_quantity > @quantity
                AND ss.ss_customer_sk = c.c_customer_sk)
ORDER BY c.c_first_name DESC , c.c_birth_country DESC
LIMIT 1000;

等效的 IN 查询：

SELECT SQL_NO_CACHE
    c.c_first_name, c.c_birth_country
FROM
    customer c
WHERE
    c.c_customer_sk IN (SELECT 
            ss.ss_customer_sk
        FROM
            store_sales ss
        WHERE
            ss.ss_quantity > @quantity)
ORDER BY c.c_first_name DESC , c.c_birth_country DESC
LIMIT 1000;

结果：

MySQL 5.5 - 存在 - 53 秒
MySQL 5.5 - 输入 - 48 秒
MySQL 5.7 - 存在 - 46 秒
MySQL 5.7 - 输入 - 4 秒

如您所见，结果有点令人惊讶：

由于某种原因，EXISTS 替代方案的性能比 MySQL 5.5 的 IN 替代方案差。
对于 MySQL 5.7，IN 的性能似乎比 EXISTS 好得多，尽管 EXISTS 替代方案的 EXPLAIN 比 IN 替代方案“看起来更好”（请参阅下面的 EXPLAIN 输出）。

你能分享一下你的想法吗？

当您准备编写新查询时，您如何在 IN 和 EXISTS 之间进行选择？你将如何指导你的团队？我们每次都可以尝试它们，但这听起来有点可笑，并且在编写复杂的查询时会浪费很多时间。应该有一些指导方针来确定它们何时更好，对于 MySQL 5.6。

我缺少任何来自 MySQL 的文档吗？

只是用所有相关表格结束循环并解释信息 -

带有索引的表创建脚本（您可能还会在此处看到许多无用或冗余的索引，但请忽略它们，因为这是一个测试环境）：

CREATE TABLE `customer` (
   `c_customer_sk` int(11) NOT NULL,
   `c_customer_id` char(16) NOT NULL,
   `c_current_cdemo_sk` int(11) DEFAULT NULL,
   `c_current_hdemo_sk` int(11) DEFAULT NULL,
   `c_current_addr_sk` int(11) DEFAULT NULL,
   `c_first_shipto_date_sk` int(11) DEFAULT NULL,
   `c_first_sales_date_sk` int(11) DEFAULT NULL,
   `c_salutation` char(10) DEFAULT NULL,
   `c_first_name` char(20) DEFAULT NULL,
   `c_last_name` char(30) DEFAULT NULL,
   `c_preferred_cust_flag` char(1) DEFAULT NULL,
   `c_birth_day` int(11) DEFAULT NULL,
   `c_birth_month` int(11) DEFAULT NULL,
   `c_birth_year` int(11) DEFAULT NULL,
   `c_birth_country` varchar(20) DEFAULT NULL,
   `c_login` char(13) DEFAULT NULL,
   `c_email_address` char(50) DEFAULT NULL,
   `c_last_review_date` char(10) DEFAULT NULL,
   PRIMARY KEY (`c_customer_sk`),
   KEY `c_fsd2` (`c_first_shipto_date_sk`),
   KEY `c_fsd` (`c_first_sales_date_sk`),
   KEY `c_hd` (`c_current_hdemo_sk`),
   KEY `c_cd` (`c_current_cdemo_sk`),
   KEY `c_a` (`c_current_addr_sk`),
   KEY `customer_index_1` (`c_first_name`,`c_birth_country`),
   CONSTRAINT `c_a` FOREIGN KEY (`c_current_addr_sk`) REFERENCES `customer_address` (`ca_address_sk`) ON DELETE NO ACTION ON UPDATE NO ACTION,
   CONSTRAINT `c_cd` FOREIGN KEY (`c_current_cdemo_sk`) REFERENCES `customer_demographics` (`cd_demo_sk`) ON DELETE NO ACTION ON UPDATE NO ACTION,
   CONSTRAINT `c_fsd` FOREIGN KEY (`c_first_sales_date_sk`) REFERENCES `date_dim` (`d_date_sk`) ON DELETE NO ACTION ON UPDATE NO ACTION,
   CONSTRAINT `c_fsd2` FOREIGN KEY (`c_first_shipto_date_sk`) REFERENCES `date_dim` (`d_date_sk`) ON DELETE NO ACTION ON UPDATE NO ACTION,
   CONSTRAINT `c_hd` FOREIGN KEY (`c_current_hdemo_sk`) REFERENCES `household_demographics` (`hd_demo_sk`) ON DELETE NO ACTION ON UPDATE NO ACTION
 ) ENGINE=InnoDB DEFAULT CHARSET=utf8


CREATE TABLE `store_sales` (
   `ss_sold_date_sk` int(11) DEFAULT NULL,
   `ss_sold_time_sk` int(11) DEFAULT NULL,
   `ss_item_sk` int(11) NOT NULL,
   `ss_customer_sk` int(11) DEFAULT NULL,
   `ss_cdemo_sk` int(11) DEFAULT NULL,
   `ss_hdemo_sk` int(11) DEFAULT NULL,
   `ss_addr_sk` int(11) DEFAULT NULL,
   `ss_store_sk` int(11) DEFAULT NULL,
   `ss_promo_sk` int(11) DEFAULT NULL,
   `ss_ticket_number` int(11) NOT NULL,
   `ss_quantity` int(11) DEFAULT NULL,
   `ss_wholesale_cost` decimal(7,2) DEFAULT NULL,
   `ss_list_price` decimal(7,2) DEFAULT NULL,
   `ss_sales_price` decimal(7,2) DEFAULT NULL,
   `ss_ext_discount_amt` decimal(7,2) DEFAULT NULL,
   `ss_ext_sales_price` decimal(7,2) DEFAULT NULL,
   `ss_ext_wholesale_cost` decimal(7,2) DEFAULT NULL,
   `ss_ext_list_price` decimal(7,2) DEFAULT NULL,
   `ss_ext_tax` decimal(7,2) DEFAULT NULL,
   `ss_coupon_amt` decimal(7,2) DEFAULT NULL,
   `ss_net_paid` decimal(7,2) DEFAULT NULL,
   `ss_net_paid_inc_tax` decimal(7,2) DEFAULT NULL,
   `ss_net_profit` decimal(7,2) DEFAULT NULL,
   PRIMARY KEY (`ss_item_sk`,`ss_ticket_number`),
   KEY `ss_s` (`ss_store_sk`),
   KEY `ss_t` (`ss_sold_time_sk`),
   KEY `ss_d` (`ss_sold_date_sk`),
   KEY `ss_p` (`ss_promo_sk`),
   KEY `ss_hd` (`ss_hdemo_sk`),
   KEY `ss_c` (`ss_customer_sk`),
   KEY `ss_cd` (`ss_cdemo_sk`),
   KEY `ss_a` (`ss_addr_sk`),
   KEY `store_sales_index_1` (`ss_quantity`,`ss_customer_sk`),
   KEY `store_sales_idx_sk_price` (`ss_item_sk`,`ss_sales_price`),
   KEY `store_sales_idx_price_sk` (`ss_sales_price`,`ss_item_sk`),
   CONSTRAINT `ss_a` FOREIGN KEY (`ss_addr_sk`) REFERENCES `customer_address` (`ca_address_sk`) ON DELETE NO ACTION ON UPDATE NO ACTION,
   CONSTRAINT `ss_c` FOREIGN KEY (`ss_customer_sk`) REFERENCES `customer` (`c_customer_sk`) ON DELETE NO ACTION ON UPDATE NO ACTION,
   CONSTRAINT `ss_cd` FOREIGN KEY (`ss_cdemo_sk`) REFERENCES `customer_demographics` (`cd_demo_sk`) ON DELETE NO ACTION ON UPDATE NO ACTION,
   CONSTRAINT `ss_d` FOREIGN KEY (`ss_sold_date_sk`) REFERENCES `date_dim` (`d_date_sk`) ON DELETE NO ACTION ON UPDATE NO ACTION,
   CONSTRAINT `ss_hd` FOREIGN KEY (`ss_hdemo_sk`) REFERENCES `household_demographics` (`hd_demo_sk`) ON DELETE NO ACTION ON UPDATE NO ACTION,
   CONSTRAINT `ss_i` FOREIGN KEY (`ss_item_sk`) REFERENCES `item` (`i_item_sk`) ON DELETE NO ACTION ON UPDATE NO ACTION,
   CONSTRAINT `ss_p` FOREIGN KEY (`ss_promo_sk`) REFERENCES `promotion` (`p_promo_sk`) ON DELETE NO ACTION ON UPDATE NO ACTION,
   CONSTRAINT `ss_s` FOREIGN KEY (`ss_store_sk`) REFERENCES `store` (`s_store_sk`) ON DELETE NO ACTION ON UPDATE NO ACTION,
   CONSTRAINT `ss_t` FOREIGN KEY (`ss_sold_time_sk`) REFERENCES `time_dim` (`t_time_sk`) ON DELETE NO ACTION ON UPDATE NO ACTION
 ) ENGINE=InnoDB DEFAULT CHARSET=utf8

说明 - MySQL 5.7 - EXISTS 替代方案 -

1   PRIMARY c       index       customer_index_1    124     1000    100.00  Using where; Using index
2   DEPENDENT SUBQUERY  ss      ref ss_c,store_sales_index_1    ss_c    5   tpcds.c.c_customer_sk   32  50.00   Using where

说明 - MySQL 5.7 - IN 替代方案 -

1   SIMPLE  ss      range   ss_c,store_sales_index_1    store_sales_index_1 5       1395022 100.00  Using where; Using index; Using temporary; Using filesort; Start temporary
1   SIMPLE  c       eq_ref  PRIMARY PRIMARY 4   tpcds.ss.ss_customer_sk 1   100.00  End temporary

说明 - MySQL 5.5 - EXISTS 替代方案 -

1   PRIMARY c   index       customer_index_1    124     1000    Using where; Using index
2   DEPENDENT SUBQUERY  ss  ref ss_c,store_sales_index_1    ss_c    5   tpcds.c.c_customer_sk   14  Using where

说明 - MySQL 5.5 - IN 替代方案 -

1   PRIMARY c   index       customer_index_1    124     1000    Using where; Using index
2   DEPENDENT SUBQUERY  ss  index_subquery  ss_c,store_sales_index_1    ss_c    5   func    14  Using where

【问题讨论】：

注意：IN 和 EXISTS 之间存在细微的语义差异（wrt 处理 NULL）。选择正确的而不是最快的。
@wildplasser，谢谢。在这个特定的问题和测试中，我忽略了这种差异，因为在许多情况下 NULL 是无关紧要的。
就性能而言，您可以尝试使用 INNER JOIN 吗？我一直听说它更好。
@DanielE。内部联接的问题在于，由于联接的笛卡尔性质，在许多情况下它会返回不同的结果。因此，它将需要某种技巧，例如应用 DISTINCT 来减少返回的结果数量（这可能会减慢查询速度）。因此，在这个测试中，我将重点放在 IN 与 EXISTS 上，也许将来我会将测试扩展到内连接。
" SELECT SQL_NO_CACHE c.c_first_name, c.c_birth_country FROM customer c INNER JOIN (SELECT ss.ss_customer_sk FROM store_sales ss WHERE ss.ss_quantity > @quantity) t ON t.ss_customer_sk = c.c_customer_sk ORDER BY c.c_first_name DESC , c.c_birth_country DESC " 会返回不同的结果吗？

标签： mysql sql performance database-performance

【解决方案1】：

这个问题没有终极真理。如果in 的性能总是比exists 差，那么优化器可以采取的第一步就是简单地将每个in 重写为exists。

in 允许优化器利用 several different execution paths，这是一般 exists 子查询无法做到的。它尤其可以将in 作为exists 执行（反之亦然）。因此，如果您想要一个通用的指导方针，您可以尽可能使用in，因为它可以很容易地重写为exists，让您可以选择（和编译器）以任何方式执行此操作。如果测试表明 MySQL 选择了错误的路径，您可以简单地切换到 exists，强制优化器做同样的事情。

如果优化器选择采用这些新可用的执行计划之一，它们可能会变得更快 - 或者不会。对于优化器做出的许多决策来说都是如此：它基本上是根据它对您的数据所拥有的一些有限信息进行猜测的，并且可能会猜错。告诉优化器探索不同路径的直接方法是使用Optimizer Hints。稍微改变一下查询（例如，将in 切换为exists）也可以使优化器选择不同的执行计划（例如，因为其他执行计划不再可用），因此您可能会将其视为间接提示，尽管它是比实际提示更难控制。

这些结果可能会为您提供更快的结果 - 或者，出于同样的原因，相反。这通常取决于您的实际数据和情况。您只需针对您的具体情况进行测试并选择更快的那个是正确的。但请记住，情况可能会发生变化（如果您的数据分布发生变化），因此您可能需要重新测试并可能在某个时候重写您的查询。

但它不会普遍适用 - 正如您已经意识到的那样，对于您的具体情况，您的假设“对于旧 MySQL 版本，EXISTS 比 IN 更好” 不成立，而它似乎对您查看的大多数问题都这样做（这可能是也可能不是有偏见的选择）。

在一般性介绍之后（你想听听一些想法，所以你得到了一些）：

in for 5.7 表现如此出色的原因是 MySQL 在可能的执行计划中发现了一种非常适合您的特定数据分布的方式。

假设您只有一位客户ss_quantity > @quantity。由于您在ss_quantity 上有一个索引，因此查询的最快答案是简单地使用此索引，查找具有该数量的客户，您就完成了。拥有数量价值的客户越多，效果就越差。例如。假设每个客户都满足数量条件，那么支持您的order by（因此是limit）的索引是更可取的 - 这是 MySQL 5.5 通过选择利用索引customer_index_1 的执行计划计划来决定做的事情。

将 exists 更改为 in 使 MySQL 找到该路径。优化器在 5.5 之间变得更好。和 5.7.，所以这不仅仅是随机运气。但是如果你的数据分布超出了临界点，而 MySQL 仍然会走这条路，它会变得更慢。在您达到收支平衡点的地方，将会有大量客户。你显然是站在好的一边。

对此进行测试的一种方法是将@quantity 设置为较低的值。您可能会找到一个值，其中in 将像exists 一样执行，甚至可能是一个exists 比in 快的值。另一个因素是limit 的值。 limit 1 应该（假设您的查询返回多于几行）像当前的 exists 一样执行，因此您可能会发现一些数量和限制参数，其中 in 将比 exists 慢。如果 MySQL 确实将 in 的执行计划更改为与 exists 相似，那么 limit 将有一些值而不是它没有的（我们知道至少对于值 1000）。您可能会发现in 再次比exists 慢的值。

但再次延伸一点：它并不普遍适用。这些值将取决于您的数据，并且情况可能会随之改变。如果你例如获得越来越多的客户，1000 的限制可能会变得越来越不相关，并且您可能会在未来达到in 比exists 更糟糕的临界点（MySQL 没有意识到这一点），并且可能不得不改变你的查询。

【讨论】：

感谢您的回复，非常感谢。我不明白为什么 MySQL 5.7 中的 IN 查询性能更好，因为有很多客户拥有这个数量（不仅仅是 1 / 少数）。此外，更重要的是，我不确定我是否了解您将来如何处理此类情况 - 您是否会为每个查询测试两个选项？如果您在一个查询中有多个 IN / EXISTS 子查询怎么办？每次都测试所有选项变得非常麻烦。我希望对特定因素（a，b，c）有一些想法，这些因素对于 IN 和 (d,e,f) 是最优的，对于 EXISTS 是最优的......
嗯，MySQL 选择的执行计划是使用“1”-scenario（你可以看到它使用store_sales_index_1-index 来检索客户列表：它“以 ss并将来自 c 的 1 个客户加入其中”）。究竟有多少并不重要，事实证明它更快，“1”只是为了说明为什么它可以更快。在某些客户中，额外的文件排序会减慢速度，我不知道在您的特定情况下该数字是多少（例如，使用数量 0 进行测试）。
正如我试图说明的那样（我显然没有，我可能会重写那部分）：首选方法是使用“in”，让 MySQL 可以选择执行它“存在”。如果不是，则没有一般规则（那时，MySQL 可以在优化器阶段使用此规则本身，您可以再次使用“in”）。在某些情况下，MySQL 会选择错误。然后您可以尝试使用“存在”，它可能有帮助，也可能没有帮助。同样的提示，例如“强制索引” - 理想情况下，MySQL 会自己找到它，有时它不会。但是如果你“强制索引”（或“存在”），如果你的数据发生变化，它就不擅长了。

【解决方案2】：

这样比较公平吗？

EXISTS 是“半连接”——也就是说，它执行类似连接的查找，但在找到单行时停止。

IN 表示查找所有行。您的IN 测试是否在SELECT 中的IN 中至少有一百个值？

EXISTS 和 IN 的速度取决于可用的索引。例如，WHERE ss.ss_quantity > @quantity AND ss.ss_customer_sk = c.c_customer_sk) 需要INDEX(ss_customer_sk, ss_quantity) 按此顺序。在没有任何索引的情况下，EXISTS 的速度取决于在表中找到第一个匹配行的位置！如果是在最后，就会像IN一样慢！由于您的索引不太好（相反的顺序），EXISTS 的效率取决于此线程中不可见的一些分布。

ORDER BY c.c_first_name DESC , c.c_birth_country DESC LIMIT 1000;——如果你没有INDEX(c_first_name, c_birth_country)，那么就会有排序和表扫描——这些会影响基准。也就是说，您比EXISTS 与IN 对这些事情的时间安排更多。

由于上述差异，

EXISTS固有地比IN 快。你可以从EXPLAIN 看到IN 是否被安全地变成EXISTS。不需要基准。

好的，所以对于IN，5.7 更快。从EXPLAIN 注意到它正在使用创建临时表的优化。同样，我怀疑临时表的大小/结构/等可能会影响基准测试是否公平。

使用不同的LIMIT，这样的临时表可能成本更高而不是有益。我怀疑您发现了 IN 优化击败“半连接”的情况，但也可能存在相反的情况。

我刚刚发现了另一个不公平之处——一个公式需要INDEX(customer, quantity)，另一个需要相反的顺序。你有一个受益 IN (store_sales_index_1)。我怀疑这就是为什么EXISTS 没有在 5.5 中击败IN！请使用两个索引重新运行您的基准测试。

【讨论】：

感谢您提供的信息，非常感谢。您正确地认为索引以正确的顺序丢失。一旦添加了正确的索引，EXISTS 在所有情况下都表现得更好/与 IN 一样。作为参考，我添加的索引是 INDEX(ss_customer_sk, ss_quantity)。
在另一个注意事项 - 如果 NULL 不重要，您将如何选择 IN 与 EXISTS？您提到“EXISTS 本质上比 IN 快” - 根据您的经验，情况总是如此吗？什么时候我们应该注意到它不是这种情况并在编写查询时使用 IN？
（我的意思是建议从列名的开头删除 ss_ ——它会在没有提供有用信息的情况下变得混乱。）
@TomShir - 在我的经验中，EXISTS 永远不会慢。但是，您发现了针对IN 的新优化。这让我重新思考我的立场。我确实怀疑外部LIMIT 计数和IN 中的项目数会影响IN 是否与您的示例一样有效。也就是说，这两个计数都可能导致IN 比EXISTS 更好或。而且很难预测是哪一个。
谢谢。将继续尝试以了解更多信息。顺便说一句，列名中的ss_ 前缀是由标准 TPCDS 数据库预定义的，通常用于性能测试。我只是在使用它:)

【解决方案3】：

我猜想 IN 变体在 5.7 中表现如此出色的主要原因是，您只会查看满足数量条件的销售，并在找到 1000 个不同的客户时停止。使用 EXISTS，您将不得不为许多不满足此条件的客户进行所有销售。此外，IN 的查询计划使用 store_sales 表上的覆盖索引，并将使用 PRIMARY 键查找客户表，而 EXISTS 的计划将使用二级索引。特别是当需要从磁盘读取数据时，二级索引的效率会更低。

对于 5.6 及更高版本，您应该更喜欢 IN，因为优化器可以使用半连接。半连接可以颠倒两个表的顺序。（在 5.5 中，外查询的表总是需要在子查询的表之前处理。） semijoin 有几种可选的执行策略；其中之一模仿 EXISTS 的执行方式。因此，只要优化器的成本估算正确，IN 至少应该与 EXISTS 一样好。

在 5.6 之前，IN 被转换为 EXISTS，因此两个变体应该执行相同的操作。

【讨论】：