查询语句：
select associated_id from proc where proc_id in(6446 , 6447 , 6450) and associated_id = '外查询结果.stage_id';
这就是个坑。我相信，每个写出上面这种 sql 的程序员都不会想到 MySql 会对其这样执行，这是大家不想看到的结果。
怎么办？
Uncorrelated subqueries treated as DEPENDENT by MySQL 提出了同样的问题但是却没有给出解决方案。
MySql 官方给出的解决方案是：
If you have a slow 'correlated' subquery with IN, you can optimize it with a join to get around the bug described by Ryan and Stephen. After the optimization the execution time is no longer O(M×N).
于是我们的 update 语句改写为：
update mer_stage m join proc p on m.stage_id = p.associated_id set m.editable = 1
where p.proc_id =6446 or p.proc_id =6447 or p.proc_id =6450;
它的执行计划是：
执行这个 update，用时 0.047s，意料之中。搞定。
有趣的是，我们来做一个尝试，把该 update 改为 select：
select * from mer_stage where stage_id in (select associated_id from proc where proc_id in (6446 , 6447 , 6450));
它的执行时间是 0.053 s，毫秒级。
该 sql 的执行计划是：
同样的写法，唯一不同的是一个 update 另一个 select，差别咋就那么大呢？看来优化器并不总是那么靠谱的，它在这里就对 update 那条 sql 的子查询优化的很糟糕。