mysql in查询优化

mysql in的数量过多优化

哎呀，让我告诉你一件事。
去年，我正在为一个电子商务平台开发订单处理系统，我的 MySQL 查询非常慢。
IN 语句有太多的条件，令人生畏。
如果您在一张表中检查数百个产品 ID，您将会陷入困境。
接下来发生了什么？让我告诉你。

查了半天，发现IN有上百个ID，解析数据库确实很困难。
我想我是否可以进入而不需要调整那么多ID。
不，用户选择了太多。
那我就一口气把这一切都做完。
例如，如果您想一次检查1 00个项目，请使用循环并在后端构建一个接口。
请求多了几个，但是每个查询都快了很多，总时间也更短了。
这招确实管用。
我测试过。
起初只需要不到一秒，但批处理后需要 3 00 毫秒。

还有一件事，有些人使用 JOIN 而不是 IN。
那是什么场景？ IN 列出来自另一个表的用户行为数据。
我一看，好吧，为什么不尝试使用 JOIN 呢？我尝试更改它并将 IN 更改为 LEFT JOIN 以连接用户表。
嘿，你知道吗？在用户表中的用户ID上添加索引后，我的查询速度立刻提高了！ JOIN实际上可以使用索引，而且效率要高得多。

后来我尝试了一个技巧，先将IN中的数据扔到临时表中。
当时，我正在检查促销活动的产品 ID。
它们有数百个，而且每次都会发生变化。
创建一个新的临时表，将此 ID 插入其中，添加索引，并将其与基表连接。
结果比直接 IN 快得多。
虽然建临时表、插入数据有点繁琐，但是提高了查询效率，减少了用户的等待时间，这让你的老板很高兴。

最后，索引确实是一条生命线。
在我当时的表中，我必须向 IN 条件中的列添加索引。
想一想。
数百个身份证，全部在没有索引的情况下进行扫描。
不会有生命危险吗？然而，我也见过愚蠢的同事，他们到处添加索引，并且写 INSERT 的速度非常慢，以至于最终不得不删除它们。
因此，应该给关键列添加索引，不要盲目添加。

简而言之，太多的 IN 会降低速度。
批量签入、更改 JOIN、使用临时表和添加索引。
这些都是我从诱捕中学到的技巧。
去年的项目也是这样完成的，成绩明显提高。
请注意，不要走我走过的路。

MySQL查询优化如何使用IN查询获取更好的性能mysql中in中查询

让我告诉你一件事。
我在一家电子商务公司从事后端工作。
当时我用MySQL数据库已经快秃头了。
如果使用得当，IN 查询可以是一个神奇的工具，但如果使用不当，它们可能会降低性能。

我记得有一年夏天，我的系统突然疯狂崩溃。
我查看了后台，发现有一个使用IN查询的特定接口，里面填写了数千个ID。
想一想。
MySQL需要一一匹配，需要多长时间？整个服务器CPU暴涨9 0%以上，用户请求超时，导致老板被骂。

我在想，我该怎么办？您想更改为 JOIN 吗？将IN条件分开并使用JOIN将它们与其他表连接起来。
具体是什么表我记不太清了，但它是一个可以过滤掉大部分未使用的ID的表。
进行更改后，性能立即好多了。
以前，我们必须在几秒钟内打开它，但一旦进行编辑，我们就可以在数百毫秒内看到结果。

在另一个支付对账场景中，数据量非常大。
我用IN来检查用户的订单ID。
其中包含了数百条数据，直接拖慢了数据库的速度。
我建议稍后添加索引，但您可以通过将索引直接添加到订单表中的 ID 字段来完成此操作。
添加索引后，我再次运行 IN 查询。
速度要快得多。
您需要根据自己的表结构来执行此操作。
索引是个好东西，但也不能乱加。

让我告诉你另一个秘诀。
如果 IN 有很多值，您实际上可能会考虑批量查询它们。
例如，一个 IN 查询仅包含 1 00 个 ID，然后运行两个查询来合并结果。
我之前在一个项目中尝试过这种方法，它对我来说非常有效，防止我在单个查询中用太多数据填充内存。

我以前用过 EXISTS，但不经常使用。
这个想法是，“如果存在，那就是合理的。
”在检查某些内容时，我们使用 EXISTS 来查看另一个表中是否存在匹配项。
在某些情况下，它比 IN 更有效。
例如，在检查用户的订单时，如果要检查用户是否存在某种状态，则使用 E​​XISTS 可能比 IN 更快。

总的来说，IN 查询是个好东西，但是使用时需要小心。
如果值很小也没关系。
如果值较高，则应考虑优化。
你应该尝试这些技巧：JOIN、子查询、批量查询、索引等。
我当时犯了一个错误，没有添加索引。
结果，整个系统运行缓慢，客户投诉几乎铺天盖地。

看看你的场景，IN中有多少个值？表结构是什么？是否添加了索引？我们先来看看这个基本情况。
我以前没接触过这个，不敢乱说。

浅析mysql in查询的语法和常见限制

请求中，这个东西用起来很方便，就像选课一样，写个数字就可以了。
但如果使用过多，则必须小心。

首先，IN后面的值太多。
我曾经举办过一次活动，必须检查数千个产品 ID。
直 IN（1 、2 、3 ...几千）会导致死牌或活牌。
后来我把它分成三四个IN状态，连接到OR，结果一闪就出来了。
这个和你电脑的内存有关系。
如果该值大于 1 ，MySQL 必须在内存中构建一个哈希表。
当值太多的时候，桌子就太大了，卡肯定会卡住。

其次，IN中不能有重复值。
有一次写代码的时候，手抖了一下，输入IN(1 ,2 ,2 ,3 )，发现多了一行重复的2 ，当时我就一头雾水，花了好久才弄清楚到底是怎么回事。
所以在写IN条件之前，简单排序一下，或者用Set去掉重复就省事了。

第三，IN不能为空。
例如，IN() 没有任何内容，检查时结果为空。
我尝试在旧版本的MySQL中使用空IN，直接报错。
因此，要么确保 IN 中至少有一个值，要么不使用 IN 并使用其他条件。

第四，IN中的值类型必须与正在检查的列类型匹配。
一旦我检查了订单表，该列的类型为 INT。
我写成IN('1 ','2 ')但是报错。
我当时也想知道，为什么数字前面要加引号呢？后来简单地改写为IN(1 ,2 )。
你必须记住这一点，类型必须严格匹配。

第五，不要混用IN和NOT IN。
我曾经编写过一个查询，需要 IN(1 ,2 ,3 ) 和 NOT IN(4 ,5 )。
结果效率非常低。
切换成NOT EXISTS或者写成WHERE an IN (1 ,2 ,3 ) AND a != 4 后，速度立刻就快了。
这个和指数有关系。
当混合时，MySQL可能无法使用索引。

说实话，IN如果使用得当的话是非常方便的，但是如果使用得不正确的话真的会阻塞数据库。
尤其是大厂家的上亿数据的表，当IN状态扩展时，后台就惨了。
因此，在编写SQL时，必须根据数据量和类型灵活选择方法。