记录5.5.59 mysql版本 in 语法的坑_mysql in支持的版本-CSDN博客

本文链接：https://blog.csdn.net/weixin_40263855/article/details/103409934

本文记录了在MySQL 5.5.59版本中使用IN语句遇到的性能问题，以及通过视图、UNION、EXISTS等尝试优化的过程。最终，作者提出了通过拆分SQL和利用流式编程实现翻页的解决方案，以避免多次查询带来的性能影响。

摘要由CSDN通过智能技术生成

需求描述：

需求（同一数据表）：查询重复ip，重复地标二维码，重复（A字段+B字段+C字段+n字段）的数据信息集合，数据信息集合要求唯一（附加字段查询条件，分页查询 [生产环境的mysql 版本正好式5.5.59版本]）

实现思路

博主思路：最初思路（一个sql 完成）拆分：拆分三个重复，查询重复ip ,根据重复二维码，重复字段获取 id 然后union 三个select 加子查询嵌套
（三个类似这样的子查询，查询出重复数据）

    select cncdev_ip,count(cncdev_ip) count from cims_cncdev b GROUP BY b.cncdev_ip HAVING count(b.cncdev_ip) > 1

这样获取了重复的ip,二维码，字段后，需要以此结果作为条件查询获取id，因此博主首先想到的就是用 in 和 union 拼接，拼接方式如下：

 select * from cims_cncdev where cncdev_ip in(select cncdev_ip from cims_cncdev GROUP BY cncdev_ip HAVING count(cncdev_ip) > 1)  union select ......union select .......

这步获取id (用到 in 博主非常痛恨：因为 in 在 5.5版本MySQL 中查询时，如果结果时未知结果（不是已知结果时）数据量稍微大点查询效率非常非常低，其他版本待测 ) sql 执行时间高达150多秒以上，这是博主万万不能接受的。

因为这个原因：博主只能另辟蹊径：网上说把in 更改为 exists 是一种优化。然后博主抱着希望再去测试，发现结果令人气愤：

select * from cims_cncdev a where  exists (select cncdev_ip from cims_cncdev b GROUP BY b.cncdev_ip HAVING count(b.cncdev_ip) > 1  and  a.cncdev_ip = b.cncdev_ip);

耗时更长，5.5版本。5.7 也要10多秒，果断又放弃 exists 查询。

这种情况只能优化sql ,尝试一下连接查询吧：

SELECT * from (SELECT a._id,a.cncdev_ip,COUNT(*) devCount from cims_cncdev a LEFT JOIN cims_cncdev b on a.cncdev_ip = b.cncdev_ip group BY a._id) c WHERE c.devCount >1

发现还是要10秒如果把三个这样的select union 也是要30多秒。果断又放弃。