时间:2021-05-23
1、问题描述
朋友遇到一个怪事,一个用子查询的DELETE,执行效率非常低。把DELETE改成SELECT后执行起来却很快,百思不得其解。
下面就是这个用了子查询的DELETE了:
[yejr@imysql.com]mydb > EXPLAIN delete from trade_info where id in (select id from (select a.id from trade_info a, order_info b, user c whereb.buyer = c.id and c.itv_account='90000248′ and a.order_id = b.id) temp)\G几个表的DDL是这样的:
上面这个SQL的执行耗时是:31.74秒
Query OK, 5 rows affected (31.74 sec)
如果我们把DELETE改写成SELECT的话,执行耗时仅是:0秒,来对比看下执行计划:
可以看到,trade_info 表从的全表扫描(type=ALL)变成了基于主键的等值查询(type=eq_ref),计划扫描数据量也从571万变成了1条,而且还可以避免回表,这2个SQL对比代价相差巨大。
2、优化思路
既然这个SQL把DELETE改成SELECT后执行效率就可以获得很大提升,除此外没特别区别,可能是查询优化器方面有些不足,导致无法直接优化,就得另想办法了。
我们的思路是把基于子查询的DELETE简化改写成多表JOIN后DELETE(一般来说,子查询效率比较低的话,可以考虑改写成JOIN),多表DELETE的语法课参考:https://dev.mysql.com/doc/refman/5.7/en/delete.html#idm140469624466800,例如这样的:
DELETE t1 FROM t1 LEFT JOIN t2 ON t1.id=t2.id WHERE t2.id IS NULL;
参照上面的形式,改写之后的SQL变成了下面这样:
DELETE trade_infoFROMtrade_info,(SELECTa.idFROMtrade_info aJOIN order_info b ON a.order_id = b.idJOIN user c ON b.buyer = c.idWHEREc.itv_account = ‘90000248') t2 where trade_info.id = t2.id;可以看到新的SQL执行效率相对就高很多了,不需要再扫描571万条记录,执行耗时只需:0.01秒。
Query OK, 5 rows affected (0.01 sec)
3、其他建议
虽然MySQL 5.6及以上的版本对子查询做了优化,但从本案例的结果来看,在一些情况下还是不如意。
因此,如果发现有些子查询SQL效率比较差的话,可以尝试改写成JOIN形式,看看是否有所提升。此外,也要勇于怀疑查询优化器个别情况下存在不足,想办法绕过这些坑。
声明:本页内容来源网络,仅供用户参考;我单位不保证亦不表示资料全面及准确无误,也不保证亦不表示这些资料为最新信息,如因任何原因,本网内容或者用户因倚赖本网内容造成任何损失或损害,我单位将不会负任何法律责任。如涉及版权问题,请提交至online#300.cn邮箱联系删除。
mysql的子查询的优化一直不是很友好,一直有受业界批评比较多,也是我在sql优化中遇到过最多的问题之一,你可以点击这里,这里来获得一些信息,mysql在处理子
本文实例讲述了mysql关联子查询的一种优化方法。分享给大家供大家参考,具体如下:很多时候,在mysql上实现的子查询的性能较差,这听起来实在有点难过。特别有时
正儿八经mysql优化!mysql数据量少,优化没必要,数据量大,优化少不了,不优化一个查询10秒,优化得当,同样查询10毫秒。这是多么痛的领悟!mysql优化
优化器(TheOptimizer)这篇描述MySQL查询优化器的工作原理。MySQL查询优化器主要为执行的查询决断最有效的路线(routine,走向)。一。源代
MySQL性能优化MySQL性能优化就是通过合理安排资源,调整系统参数使MySQL运行更快、更节省资源。MySQL性能优化包括查询速度优化、更新速度优化、MyS