记一次mysql慢查询问题：使用in查询

事情是这样，项目上线刚开始是好好的，一切运行正常，大概过了半年左右，突然发现有个查询接口相当的慢，从界面的响应时间看大概5分钟左右。一般用户的忍受程度不能超过3秒的，这响应时间，就是要命啊！于是开始查找原因
由于界面的静态资源和其他的页面接口的响应都比较快，排除了网络以及硬件服务器的问题，初步断定应该是后端的问题，首先想到的应该是sql查询那里出现问题，先看一下sql语句，大致结构是

select id,name from tableA where name in (select project_name from tableB where tag_location =“xx”);

其中子查询select project_name from tableB where tag_location =“xx”tag_location字段加了索引了，这句话查询很快，然后这个子查询的结果集作为父级查询语句的结果集，2条很简单的查询分开来都是很快的，至于为什么通过in合并查询就那么慢呢？我推荐下面这篇文章：
MySQL子查询(IN)碰到的问题，深入分析
其中这篇文章有个概念 Handler_read_rnd_next：此选项表明在进行数据文件扫描时，从数据文件里取数据的次数。文章大概就是说当使用in进行查询时，如果父语句扫描n次，子查询扫描m次，最后这个语句执行完毕就是扫描n*m次，很容易达到百万级别，所以最后必须改变方案，咱不用in来实现了，网上都建议用left join 解决。

select  t2.id,t2.name from tableB as t1 left join tableA as t2 on t1.project_name=t2.name where t1.tag_location =“xx”;

通过执行，发现完美解决，响应时间大大提升。
结论：以后慎用in，除非in里面是有限的字符集，不需要计算的还行。