title: 坑爹的MySql update in subquery tags:

• mysql
• update
• in
• 子查询
• subquery categories: mysql date: 2017-10-28 16:31:16

背景

最近收到邮件如上，在做allot时发生db超时【前一段时间由于系统负载过大忽略了相关慢sql】

收到如上邮件考虑可能是allot详情太多导致发生超时 经过调查后发现事实并非如此

即使是一个材料某些情况也会发生超时

因此定位了相关代码 一段有趣的代码引起了注意

分析

关于超时在代码层次至少存在如下两个

1. 事务超时
2. mysql查询超时

目前mysql查询超时默认情况为30s【后期将逐渐降低】

事务超时 目前基于mybatis做了事务设置查询超时

@Overridepublic Object intercept(Invocation invocation) throws Throwable {Statement stmt = (Statement) invocation.getArgs()[0];Collection<Object> values = TransactionSynchronizationManager.getResourceMap().values();if (values.size() > 0) {for (Object obj : values) {if (obj != null && obj instanceof ConnectionHolder) {ConnectionHolder holder = (ConnectionHolder) obj;if (holder.hasTimeout()) {int queryTimeOut = holder.getTimeToLiveInSeconds();if (stmt.getQueryTimeout() != 0) {queryTimeOut = queryTimeOut < stmt.getQueryTimeout() ? queryTimeOut : stmt.getQueryTimeout();}stmt.setQueryTimeout(queryTimeOut);}break;}}}return invocation.proceed();}
复制代码

因此考虑该超时是默认30s超时了还是因为事务设置使得查询时间变成某个较小的时间导致呢？

经过调查后发现url基本在30s以上 那么就应该是事务超时了么？

当然这是有可能的！

观察了几封超时邮件后 发现每次超时均出现在同一个地方

直接上代码

<update id="editPartInfoPrice" parameterType="com.air.tqb.model.TmPartInfo">UPDATE tm_part_info_detailSETmodifier = #{modifier}<if test="purchasePrice!=null">,purchase_price=#{purchasePrice}</if><if test="sellPrice!=null">,sell_price=#{sellPrice}</if><if test="transferPrice!=null">,transfer_price=#{transferPrice}</if>,modifiedtime = now()WHEREpk_id=CAST(#{pkId} as unsigned );<include refid="updateChainPrice"/></update><sql id="updateChainPrice"><if test="(chain band @com.air.tqb.model.enums.PartInfoChain@PURCHASE.value) eq @com.air.tqb.model.enums.PartInfoChain@PURCHASE.value and purchasePrice!=null">update tm_part_info_detail SET purchase_price=#{purchasePrice} where info_id in(select info_id from (SELECT info_id FROM tm_part_info_detail WHERE pk_id = #{pkId}) AS temp);</if><if test="(chain band @com.air.tqb.model.enums.PartInfoChain@SELL.value)  eq @com.air.tqb.model.enums.PartInfoChain@SELL.value and sellPrice!=null">update tm_part_info_detail SET sell_price=#{sellPrice} where info_id in(select info_id from (SELECT info_id FROM tm_part_info_detail WHERE pk_id = #{pkId}) AS temp);</if><if test="(chain band @com.air.tqb.model.enums.PartInfoChain@TRANSFER.value)  eq @com.air.tqb.model.enums.PartInfoChain@TRANSFER.value and transferPrice!=null">update tm_part_info_detail SET transfer_price=#{transferPrice} where info_id in(select info_id from (SELECT info_id FROM tm_part_info_detail WHERE pk_id = #{pkId}) AS temp);</if>
复制代码

sql很简单 并且相关地方都是加了索引 看起来都不像是慢的原因。

于是手动执行了该sql

    update  tm_part_info_detail set sell_price=1 where info_id in(select info_id from (SELECT info_id FROM tm_part_info_detail WHERE pk_id ='3398651') AS temp)
复制代码

WTF!耗时10s 这么简单的sql为啥执行花这么久呢？

那看来还是单条sql超时导致！

来查看一下 执行计划

    explain update  tm_part_info_detail set sell_price=1 where info_id in(select info_id from (SELECT info_id FROM tm_part_info_detail WHERE pk_id ='3398651') AS temp);
复制代码

某些sql客户端不支持查询update语句的执行计划 简单方案就是加上explain 然后执行sql

看来确实相当耗时的操作啊！

我们再来看一看select的执行计划

    explain select * from  tm_part_info_detail  where info_id in(select info_id from (SELECT info_id FROM tm_part_info_detail WHERE pk_id ='3398651') AS temp);
复制代码

数据相差实在太大!

来看一下mysql官方的解释

13.2.10.7 Correlated Subqueries

A correlated subquery is a subquery that contains a reference to a table that also appears in the outer query. For example:

SELECT * FROM t1WHERE column1 = ANY (SELECT column1 FROM t2WHERE t2.column2 = t1.column2);
复制代码

Notice that the subquery contains a reference to a column of t1, even though the subquery's FROM clause does not mention a table t1. So, MySQL looks outside the subquery, and finds t1 in the outer query.

Suppose that table t1 contains a row where column1 = 5 and column2 = 6; meanwhile, table t2 contains a row where column1 = 5 and column2 = 7. The simple expression ... WHERE column1 = ANY (SELECT column1 FROM t2) would be TRUE, but in this example, the WHERE clause within the subquery is FALSE (because (5,6) is not equal to (5,7)), so the expression as a whole is FALSE.

Scoping rule: MySQL evaluates from inside to outside. For example:

SELECT column1 FROM t1 AS xWHERE x.column1 = (SELECT column1 FROM t2 AS xWHERE x.column1 = (SELECT column1 FROM t3WHERE x.column2 = t3.column1));
复制代码

In this statement, x.column2 must be a column in table t2 because SELECT column1 FROM t2 AS x ... renames t2. It is not a column in table t1 because SELECT column1 FROM t1 ... is an outer query that is farther out.

For subqueries in HAVING or ORDER BY clauses, MySQL also looks for column names in the outer select list.

For certain cases, a correlated subquery is optimized. For example:

val IN (SELECT key_val FROM tbl_name WHERE correlated_condition)
复制代码

Otherwise, they are inefficient and likely to be slow. Rewriting the query as a join might improve performance.

Aggregate functions in correlated subqueries may contain outer references, provided the function contains nothing but outer references, and provided the function is not contained in another function or expression.

很明显 优化器也是戴有色眼镜看sql的啊……基本相同的sql对于update和select走了不同的执行计划【优化器只能保证尽量快】update就是上文所说的inefficient and likely to be slow

解决方案

因此方案也很简单 update该语句改成inner join 即可

    UPDATE tm_part_info_detail d1INNER JOIN tm_part_info_detail d2 ON d1.info_id = d2.info_idSET d1.sell_price = 1WHEREd2.pk_id = '3398651';
复制代码