MySQL慢查询优化之查询计划优化
以下图第一个SQL为例（ explain {SQL}）
结果为
具体线程意义参考官方文档：
https://dev.mysql.com/doc/refman/5.5/en/general-thread-states.html
（PC端复制链接打开）
MySQL的profile最多只能显示100个线程状态（在MySQL5.5的官方文档中也没有找到能改变显示个数的配置项），虽然看不全也可以看到MySQL的线程状态一直在executing、copying to tmp table、 sending data循环。性能一直消耗在从硬盘中取数据、复制到临时表运算，返回结果的过程中。
得到结论：最大的性能瓶颈在于存在嵌套子查询
知道了性能瓶颈，就有了问题的解决方案：在符合业务场景下，改写这句SQL，使用连接替代嵌套子查询，并结合上面提到的优化SQL的常用手段。
优化后的SQL语句：
这句话的查询执行过程是先将对user_org表做处理，查询出符合条件的userId，这里用到了in操作, 但是当in的数量超过1000时不能使用索引，所以进行了全表扫描，把结果存放到内存中临时表中，连接其他两张表时也都使用到了索引。在不分解联接下，比较难优化了。
再查看下这句SQL语句的线程执行过程：
以下图第一个SQL为例（ explain {SQL}）
结果为
具体线程意义参考官方文档：
https://dev.mysql.com/doc/refman/5.5/en/general-thread-states.html
（PC端复制链接打开）
MySQL的profile最多只能显示100个线程状态（在MySQL5.5的官方文档中也没有找到能改变显示个数的配置项），虽然看不全也可以看到MySQL的线程状态一直在executing、copying to tmp table、 sending data循环。性能一直消耗在从硬盘中取数据、复制到临时表运算，返回结果的过程中。
得到结论：最大的性能瓶颈在于存在嵌套子查询
知道了性能瓶颈，就有了问题的解决方案：在符合业务场景下，改写这句SQL，使用连接替代嵌套子查询，并结合上面提到的优化SQL的常用手段。
优化后的SQL语句：
这句话的查询执行过程是先将对user_org表做处理，查询出符合条件的userId，这里用到了in操作, 但是当in的数量超过1000时不能使用索引，所以进行了全表扫描，把结果存放到内存中临时表中，连接其他两张表时也都使用到了索引。在不分解联接下，比较难优化了。
再查看下这句SQL语句的线程执行过程：