问题定义
经常听到有人说LIMIT影响SQL查询性能,其实单纯的LIMIT子句不会影响SQL性能,如果有影响,也是好的影响,特别是子查询中limit语句,可以限制中间结果集的大小,从而为减少后续处理的数据量。本文来讨论如何对LIMIT子句进行下推优化。
和谓词下推优化类似,Limit子句下推优化通过尽可能地下压Limit子句,提前过滤掉部分数据, 减少中间结果集的大小,减少后续计算需要处理的数据量, 以提高查询性能。
譬如如下的案例,在外查询有一个Limit子句,可以将其下推至内层查询执行:
select *
from (select c_nationkey nation, 'C' as type, count(1) num
from customer
group by c_nationkey
union
select s_nationkey nation, 'S' as type, count(1) num
from supplier
group by nation) as nation_s
order by nation limit 20, 10
重写之后的SQL如下:
select *
from (
(select customer.c_nationkey as nation, 'C' as `type`, count(1) as num
from customer
group by customer.c_nationkey
order by customer.c_nationkey limit 30)
union
(select supplier.s_nationkey as nation, 'S' as `type`, count(1) as num
from supplier
group by supplier.s_nationkey
order by supplier.s_nationkey limit 30)) as nation_s
order by nation_s.nation limit 20, 10
适用条件
- 外查询有一个`LIMIT`子句
- 外查询没有`GROUP BY`子句
- 外查询的`FROM`只有一个表引用,且是一个子查询
- 子查询为单个查询或是`UNION/UNION ALL`连接的多个子查询
性能验证
1、优化前的执行计划
2、优化后的执行计划
3、优化过程解析
从优化后的执行计划我们可以看到,在UNION操作之前两个子查询分别新增了一个LIMIT节点,限制了中间结果的返回行数为30行(offset + limit), 对上下游节点都有性能提升的影响。
- 对于下游节点,譬如节点#10(优化前为节点#8), 原来需要完成全部的236914行的索引扫描,执行时间为114ms;而优化后由于限制了30行,所以可以扫描了7967行后就可以提前结束,扫描时间也减少到2.99ms,提升了38倍。
- 对于上游节点(节点#4),原来需要对38806行数据进行去重;而在优化后,只需要对60行数据进行去重;执行时间从43.3ms减少到0.1ms,提升了433倍。
单纯由于LIMIT子句下推,整体的执行时间从176.93ms减少为3.54ms,整体性能提升了4898.02%。
PawSQL对于LIMIT子句的优化
PawSQL针对所有数据库默认开启LIMIT子句下推优化,
- 自动优化:用户输入待优化SQL后,PawSQL对其进行自动化优化,案例SQL的优化详情如下。
- 当然你也可以在创建优化任务时随时关闭或开启此优化。
关于PawSQL
本文所使用的执行计划可视化工具为PawSQL Explain Visualizer , 支持MySQL、PostgreSQL、openGauss等数据库。
PawSQL专注数据库性能优化的自动化和智能化,支持MySQL,PostgreSQL,Opengauss等,提供的SQL优化产品包括
- PawSQL Cloud,在线自动化SQL优化工具,支持SQL审查,智能查询重写、基于代价的索引推荐,适用于数据库管理员及数据应用开发人员,
- PawSQL Advisor,IntelliJ 插件, 适用于数据应用开发人员,可以IDEA/DataGrip应用市场通过名称搜索“PawSQL Advisor”安装。
- PawSQL Engine, 是PawSQL系列产品的后端优化引擎,可以以docker镜像的方式独立安装部署,并通过http/json的接口提供SQL优化服务。