Loading [MathJax]/jax/output/CommonHTML/config.js
前往小程序,Get更优阅读体验!
立即前往
首页
学习
活动
专区
圈层
工具
发布
首页
学习
活动
专区
圈层
工具
MCP广场
社区首页 >专栏 >做 SQL 性能优化真是让人干瞪眼

做 SQL 性能优化真是让人干瞪眼

作者头像
小小詹同学
发布于 2021-12-13 11:06:01
发布于 2021-12-13 11:06:01
56900
代码可运行
举报
文章被收录于专栏:小詹同学小詹同学
运行总次数:0
代码可运行

很多大数据计算都是用 SQL 实现的,跑得慢时就要去优化 SQL,但常常碰到让人干瞪眼的情况。

比如,存储过程中有三条大概形如这样的语句执行得很慢:

代码语言:javascript
代码运行次数:0
运行
AI代码解释
复制
select a,b,sum(x) from T group by a,b where …;
select c,d,max(y) from T group by c,d where …;
select a,c,avg(y),min(z) from T group by a,c where …;

这里的 T 是个有数亿行的巨大表,要分别按三种方式分组,分组的结果集都不大。

分组运算要遍历数据表,这三句 SQL 就要把这个大表遍历三次,对数亿行数据遍历一次的时间就不短,何况三遍。

这种分组运算中,相对于遍历硬盘的时间,CPU 计算时间几乎可以忽略。如果可以在一次遍历中把多种分组汇总都计算出来,虽然 CPU 计算量并没有变少,但能大幅减少硬盘读取数据量,就能成倍提速了。

如果 SQL 支持类似这样的语法:

代码语言:javascript
代码运行次数:0
运行
AI代码解释
复制
from T    -- 数据来自 T 表
       select a,b,sum(x) group by a,b where …            -- 遍历中的第一种分组
       select c,d,max(y) group by c,d where …            -- 遍历中的第二种分组
       select a,c,avg(y),min(z) group by a,c where …;  -- 遍历中的第三种分组

能一次返回多个结果集,那就可以大幅提高性能了。

可惜, SQL 没有这种语法,写不出这样的语句,只能用个变通的办法,就是用 group a,b,c,d 的写法先算出更细致的分组结果集,但要先存成一个临时表,才能进一步用 SQL 计算出目标结果。SQL 大致如下:

代码语言:javascript
代码运行次数:0
运行
AI代码解释
复制
create table T_temp as select a,b,c,d,
       sum(case when … then x else 0 end) sumx,
       max(case when … then y else null end) maxy,
       sum(case when … then y else 0 end) sumy,
       count(case when … then 1 else null end) county,
       min(case when … then z else null end) minz
group by a,b,c,d;
select a,b,sum(sumx) from T_temp group by a,b where …;
select c,d,max(maxy) from T_temp group by c,d where …;
select a,c,sum(sumy)/sum(county),min(minz) from T_temp group by a,c where …;

这样只要遍历一次了,但要把不同的 WHERE 条件转到前面的 case when 里,代码复杂很多,也会加大计算量。而且,计算临时表时分组字段的个数变得很多,结果集就有可能很大,最后还对这个临时表做多次遍历,计算性能也快不了。大结果集分组计算还要硬盘缓存,本身性能也很差。

还可以用存储过程的数据库游标把数据一条一条 fetch 出来计算,但这要全自己实现一遍 WHERE 和 GROUP 的动作了,写起来太繁琐不说,数据库游标遍历数据的性能只会更差!

只能干瞪眼!

TopN 运算同样会遇到这种无奈。举个例子,用 Oracle 的 SQL 写 top5 大致是这样的:

代码语言:javascript
代码运行次数:0
运行
AI代码解释
复制
select * from (select x from T order by x desc) where rownum<=5

表 T 有 10 亿条数据,从 SQL 语句来看,是将全部数据大排序后取出前 5 名,剩下的排序结果就没用了!大排序成本很高,数据量很大内存装不下,会出现多次硬盘数据倒换,计算性能会非常差!

避免大排序并不难,在内存中保持一个 5 条记录的小集合,遍历数据时,将已经计算过的数据前 5 名保存在这个小集合中,取到的新数据如果比当前的第 5 名大,则插入进去并丢掉现在的第 5 名,如果比当前的第 5 名要小,则不做动作。这样做,只要对 10 亿条数据遍历一次即可,而且内存占用很小,运算性能会大幅提升。

这种算法本质上是把 TopN 也看作与求和、计数一样的聚合运算了,只不过返回的是集合而不是单值。SQL 要是能写成这样:select top(x,5) from T 就能避免大排序了。

然而非常遗憾,SQL 没有显式的集合数据类型,聚合函数只能返回单值,写不出这种语句!

不过好在全集的 TopN 比较简单,虽然 SQL 写成那样,数据库却通常会在工程上做优化,采用上述方法而避免大排序。所以 Oracle 算那条 SQL 并不慢。

但是,如果 TopN 的情况复杂了,用到子查询中或者和 JOIN 混到一起的时候,优化引擎通常就不管用了。比如要在分组后计算每组的 TopN,用 SQL 写出来都有点困难。Oracle 的 SQL 写出来是这样:

代码语言:javascript
代码运行次数:0
运行
AI代码解释
复制
select * from
       (select y,x,row_number() over (partition by y order by x desc) rn from T)
where rn<=5

这时候,数据库的优化引擎就晕了,不会再采用上面说的把 TopN 理解成聚合运算的办法。只能去做排序了,结果运算速度陡降!

假如 SQL 的分组 TopN 能这样写:

代码语言:javascript
代码运行次数:0
运行
AI代码解释
复制
select y,top(x,5) from T group by y

把 top 看成和 sum 一样的聚合函数,这不仅更易读,而且也很容易高速运算。

可惜,不行。

还是干瞪眼!

关联计算也是很常见的情况。以订单和多个表关联后做过滤计算为例,SQL 大体是这个样子:

代码语言:javascript
代码运行次数:0
运行
AI代码解释
复制
select o.oid,o.orderdate,o.amount
       from orders o
              left join city ci on o.cityid = ci.cityid
              left join shipper sh on o.shid=sh.shid
              left join employee e on o.eid=e.eid
              left join supplier su on o.suid=su.suid
       where ci.state='New York'
              and e.title = 'manager'
              and ...

订单表有几千万数据,城市、运货商、雇员、供应商等表数据量都不大。过滤条件字段可能会来自于这些表,而且是前端传参数到后台的,会动态变化。

SQL 一般采用 HASH JOIN 算法实现这些关联,要计算 HASH 值并做比较。每次只能解析一个 JOIN,有 N 个 JOIN 要执行 N 遍动作,每次关联后都需要保持中间结果供下一轮使用,计算过程复杂,数据也会被遍历多次,计算性能不好。

通常,这些关联的代码表都很小,可以先读入内存。如果将订单表中的各个关联字段预先做序号化处理,比如将雇员编号字段值转换为对应雇员表记录的序号。那么计算时,就可以用雇员编号字段值(也就是雇员表序号),直接取内存中雇员表对应位置的记录,性能比 HASH JOIN 快很多,而且只需将订单表遍历一次即可,速度提升会非常明显!

也就是能把 SQL 写成下面的样子:

代码语言:javascript
代码运行次数:0
运行
AI代码解释
复制
select o.oid,o.orderdate,o.amount
       from orders o
              left join city c on o.cid = c.#       -- 订单表的城市编号通过序号 #关联城市表
              left join shipper sh on o.shid=sh.#     -- 订单表运货商号通过序号 #关联运货商表
              left join employee e on o.eid=e.#      -- 订单表的雇员编号通过序号 #关联雇员表
              left join supplier su on o.suid=su.#     -- 订单表供应商号通过序号 #关联供应商表
       where ci.state='New York'
              and e.title = 'manager'
              and ...

可惜的是,SQL 使用了无序集合概念,即使这些编号已经序号化了,数据库也无法利用这个特点,不能在对应的关联表这些无序集合上使用序号快速定位的机制,只能使用索引查找,而且数据库并不知道编号被序号化了,仍然会去计算 HASH 值和比对,性能还是很差!

有好办法也实施不了,只能再次干瞪眼!

还有高并发帐户查询,这个运算倒是很简单:

代码语言:javascript
代码运行次数:0
运行
AI代码解释
复制
select id,amt,tdate,from T
              where id='10100'
              and tdate>= to_date('2021-01-10', 'yyyy-MM-dd')
              and tdate<to_date('2021-01-25', 'yyyy-MM-dd')
              and …

在 T 表的几亿条历史数据中,快速找到某个帐户的几条到几千条明细,SQL 写出来并不复杂,难点是大并发时响应速度要达到秒级甚至更快。为了提高查询响应速度,一般都会对 T 表的 id 字段建索引:

代码语言:javascript
代码运行次数:0
运行
AI代码解释
复制
create index index_T_1 on T(id)

在数据库中,用索引查找单个帐户的速度很快,但并发很多时就会明显变慢。原因还是上面提到的 SQL 无序理论基础,总数据量很大,无法全读入内存,而数据库不能保证同一帐户的数据在物理上是连续存放的。硬盘有最小读取单位,在读不连续数据时,会取出很多无关内容,查询就会变慢。高并发访问的每个查询都慢一点,总体性能就会很差了。在非常重视体验的当下,谁敢让用户等待十秒以上?!

容易想到的办法是,把几亿数据预先按照帐户排序,保证同一帐户的数据连续存储,查询时从硬盘上读出的数据块几乎都是目标值,性能就会得到大幅提升。

但是,采用 SQL 体系的关系数据库并没有这个意识,不会强制保证数据存储的物理次序!这个问题不是 SQL 语法造成的,但也和 SQL 的理论基础相关,在关系数据库中还是没法实现这些算法。

那咋办?只能干瞪眼吗?

不能再用 SQL 和关系数据库了,要使用别的计算引擎。

开源的集算器 SPL 基于创新的理论基础,支持更多的数据类型和运算,能够描述上述场景中的新算法。用简单便捷的 SPL 写代码,在短时间内能大幅提高计算性能!

上面这些问题用 SPL 写出来的代码样例如下:

一次遍历计算多种分组

A

B

1

A1=file("T.ctx").open().cursor(a,b,c,d,x,y,z)

2

cursor A1

=A2.select(…).groups(a,b;sum(x))

3

//定义遍历中的第一种过滤、分组

4

cursor

=A4.select(…).groups(c,d;max(y))

5

//定义遍历中的第二种过滤、分组

6

cursor

=A6.select(…).groupx(a,c;avg(y),min(z))

7

//定义遍历中的第三种过滤、分组

8

//定义结束,开始计算三种方式的过滤、分组

用聚合的方式计算 Top5

全集 Top5(多线程并行计算

A

1

=file("T.ctx").open()

2

=A1.cursor@m(x).total(top(-5,x), top(5,x))

3

// top(-5,x)计算出 x 最大的前 5 名,top(5,x) 是 x 最小的前 5 名。

分组 Top5(多线程并行计算)

A

1

=file("T.ctx").open()

2

=A1.cursor@m(x,y).groups(y;top(-5,x), top(5,x))

用序号做关联的 SPL 代码:

系统初始化

A

2

>env(city,file("city.btx").import@b()),env(employee,file("employee.btx").import@b()),...

3

//系统初始化时,几个小表读入内存

查询

A

1

=file("orders.ctx").open().cursor(cid,eid,…).switch(cid,city:#;eid,employee:#;…)

2

=A1.select(cid.state='New York' && eid.title=="manager"…)

3

//先序号关联,再引用关联表字段写过滤条件

高并发帐户查询的 SPL 代码:

数据预处理,有序存储

A

B

1

=file("T-original.ctx").open().cursor(id,tdate,amt,…)

2

=A1.sortx(id)

=file("T.ctx")

3

=B2.create@r(#id,tdate,amt,…).append@i(A2)

4

=B2.open().index(index_id;id)

5

//将原数据排序后,另存为新表,并为帐号建立索引

帐户查询

A

B

1

=T.icursor(;id==10100 && tdate>=date("2021-01-10") && tdate<date("2021-01-25") && …,index_id).fetch()

2

//查询代码非常简单

除了这些简单例子,SPL 还能实现更多高性能算法,比如有序归并实现订单和明细之间的关联、预关联技术实现多维分析中的多层维表关联、位存储技术实现上千个标签统计、布尔集合技术实现多个枚举值过滤条件的查询提速、时序分组技术实现复杂的漏斗分析等等。

本文参与 腾讯云自媒体同步曝光计划,分享自微信公众号。
原始发表:2021-12-11,如有侵权请联系 cloudcommunity@tencent.com 删除

本文分享自 小詹学Python 微信公众号,前往查看

如有侵权,请联系 cloudcommunity@tencent.com 删除。

本文参与 腾讯云自媒体同步曝光计划  ,欢迎热爱写作的你一起参与!

评论
登录后参与评论
暂无评论
推荐阅读
编辑精选文章
换一批
做 SQL 性能优化真是让人干瞪眼
很多大数据计算都是用 SQL 实现的,跑得慢时就要去优化 SQL,但常常碰到让人干瞪眼的情况。 比如,存储过程中有三条大概形如这样的语句执行得很慢:
石臻臻的杂货铺[同名公众号]
2022/03/24
4280
做 SQL 性能优化真是让人干瞪眼
SPL比SQL更难了还是更容易了?
SPL作为专门用于结构化和半结构化数据的处理技术,在实际应用时经常能比SQL快几倍到几百倍,同时代码还会短很多,尤其在处理复杂计算时优势非常明显。用户在看到这些应用效果后对SPL往往很感兴趣,但又担心掌握起来太难,毕竟SPL的理念和语法都跟SQL有较多不同,这要求用户需要重新了解一些概念和学习新的语法,用户可能会心生疑虑。
石臻臻的杂货铺[同名公众号]
2022/11/16
8530
ClickHouse 挺快,esProc SPL 更快
开源分析数据库ClickHouse以快著称,真的如此吗?我们通过对比测试来验证一下。
叶秋学长
2022/10/31
6320
ClickHouse 挺快,esProc SPL 更快
比SQL还好用,又一门国产数据库语言诞生了「建议收藏」
  数据库这个软件,名字中有个“库”字,会让人觉得它主要是为了存储的。其实不然,数据库实现的重要功能有两条:计算、事务!也就是我们常说的 OLAP 和 OLTP,数据库的存储都是为这两件事服务的,单纯的存储并不是数据库的目标。   我们知道,SQL是目前数据库的主流语言。那么,用SQL做这两件事是不是很方便呢?
全栈程序员站长
2022/11/08
4380
比SQL还好用,又一门国产数据库语言诞生了「建议收藏」
SQL后计算的利器SPL
现代应用开发中,通常只用SQL实现简单的数据存取动作,而主要的计算过程和业务逻辑直接在应用程序中实现,主要原因在于:
灰小猿
2022/09/02
1.2K0
解放数据科学家的神器
数据科学家几乎都会用 SQL 做探索分析,SQL 看上去很简单,也有一定的交互性,做数据探索分析似乎很不错。
朱迪
2024/11/29
940
写着简单和跑得快是一回事,SQL 为什么不可能跑得快?
我们讨论过代码编写的难和繁的原理问题,现在关注性能问题,运行速度当然是非常重要的事情。 我们知道,软件不能改变硬件的性能,CPU 和硬盘该多快就多快。不过,我们可以设计出低复杂度的算法,也就是计算量更小的算法,计算机执行的动作变少,自然也就会快了。本来要做 1 亿次运算,如果有个好算法能把计算量降低到 100 万次,那快出 100 倍就不奇怪了。但是,光想出算法还不够,还要把这个算法实实在在地用某种程序语言写出来,否则计算机不会执行。 然而,如果采用的程序语言不给力,就有可能真地写不出来,这时候就干瞪眼忍受低速度。
朱迪
2024/05/11
1140
这样理解关联是不是耳目一新
SQL 对关联的定义过于简单,关联就是两个表做笛卡尔积后再过滤,在语法上写成 A JOIN B ON …的形式。Python 关联基本上是延用 SQL 的方式,概念和方法都差不多。
朱迪
2025/05/28
790
SQL 嵌套 N 层太长太难写怎么办?
我们工作中写SQL处理数据是家常便饭,不管是应用内数据处理还是临时查询分析都可以用SQL完成,相对其他技术(如Java等高级语言)也更简单。不过,SQL的简单只限于简单需求,有些复杂计算场景SQL写起来却很难,嵌套N层以至于达到几百上千行,说SQL代码长度时通常不会以行计而是以KB计。这种情况并不少见,相信经常写SQL的小伙伴并不陌生。
磊哥
2023/02/01
6560
怎样做多数据源的混合计算
早期应用通常只会连接一个数据库,计算也都由数据库完成,基本不存在多数据源混合计算的问题。而现代应用的数据源变得很丰富,同一个应用也可能访问多种数据源,各种 SQL 和 NoSQL 数据库、文本 /XLS、WebService/Restful、Kafka、Hadoop、…。多数据源上的混合计算就是个摆在桌面需要解决的问题了。
朱迪
2023/12/21
2370
不用 SQL 的数据仓库
当前绝大部分数据仓库都会采用 SQL,SQL 发展了几十年已经成为数据库界的标准语言,用户量巨大,所以支持 SQL 对于数据仓库来讲也是很正常的。但是,在当代大数据背景下,业务复杂度节节攀升,在以计算为主要任务的数据仓库场景下,SQL 似乎越来越不够用了。典型表现是一些数据仓库开始集成 Python 的能力,将 Python 这样的非 SQL 语言融入到数据仓库中。且不论两种风格迥异的开发语言是否能很好融合互补,单看这样的趋势已经足够表现出业界对 SQL 能力的一些质疑。
搜云库技术团队
2023/10/21
2350
不用 SQL 的数据仓库
查询计算移出数据库用 Java 太慢咋办
很多现代应用会把数据计算和处理任务从数据库移出来采用 Java 实现,这样能获得架构上的好处,而且 Java 有完善过程处理能力,应对日益复杂的业务逻辑比 SQL 更得心应手(虽然代码不短)。不过,我们常常会发现,这些 Java 代码计算和处理数据的性能不如人意,赶不上数据库里的 SQL。 按说,作为编译型语言的 Java,性能虽然赶不 C++,但总该比解释型的 SQL 更有优势才对,但事实却并不是。
朱迪
2024/10/22
1470
查询计算移出数据库用 Java 太慢咋办
Java 开源 SPL 横空出世!
现代Java应用架构越来越强调数据存储和处理分离,以获得更好的可维护性、可扩展性以及可移植性,比如火热的微服务就是一种典型。这种架构通常要求业务逻辑要在Java程序中实现,而不是像传统应用架构中放在数据库中。
Java技术栈
2021/12/29
7980
SQLite 的挑战者
很多小微型应用程序也需要一些数据处理和计算能力,如果集成一个数据库就显得太沉重了,这种情况下 SQLite 是一个不错的选择,它架构简单,集成方便,可持久化存储数据,并提供 SQL 实现计算能力。
朱迪
2024/12/04
1430
SQLite 的挑战者
开源SPL助力JAVA处理公共数据文件(txt/csv/json/xml/xsl)
在 JAVA 应用中经常要处理 txt\csv\json\xml\xls 这类公共格式的数据文件,直接用 JAVA 硬写会非常麻烦,通常要借助一些现成的开源包,但这些开源包也都有各自的不足。
石臻臻的杂货铺[同名公众号]
2022/09/07
1.2K0
开源SPL助力JAVA处理公共数据文件(txt/csv/json/xml/xsl)
JVM 上数据处理语言的竞争:Kotlin, Scala 和 SPL
  Kotlin的设计初衷是开发效率更高的Java,可以适用于任何Java涉及的应用场景,除了常见的信息管理系统,还能用于WebServer、Android项目、游戏开发,通用性比较好。Scala的设计初衷是整合现代编程范式的通用开发语言,实践中主要用于后端大数据处理,其他类型的项目中很少出现,通用性不如Kotlin。SPL的设计初衷是专业的数据处理语言,实践与初衷一致,前后端的数据处理、大小数据处理都很适合,应用场景相对聚焦,通用性不如Kotlin。
陈哈哈
2022/11/02
2.6K0
ClickHouse 在什么场景下才管用?
ClickHouse 是近年来分析型数据库的热点,一向以快著称,很多其它以性能为卖点的分析型数据库也常常会用它作为一个对比标杆。很多用户碰到数据库运算性能问题时,也会考虑转向求助于 ClickHouse 解决 ClickHouse 确实是有过人之处,它的列式宽表速度很快,估计是压缩做得非常好。然而,除此之外,再无长处。希望用 ClickHouse 解决数据库计算性能问题的用户,大概率会失望的。
朱迪
2024/04/22
3590
另类却不罕见的聚合运算
标准 SQL 中提供了五种最常用的聚合运算:SUM/COUNT/AVG/MIN/MAX,都是对集合计算出单值。
朱迪
2025/03/11
1310
比SQL还好用,又一门国产数据库语言诞生了
数据库这个软件,名字中有个“库”字,会让人觉得它主要是为了存储的。其实不然,数据库实现的重要功能有两条:计算、事务!也就是我们常说的OLAP和OLTP,数据库的存储都是为这两件事服务的,单纯的存储并不是数据库的目标。
呆呆敲代码的小Y
2022/04/11
4420
没有RDB也敢揽SQL活的开源金刚钻SPL
SQL语法接近自然语言,上手学习门槛低,再加上先发优势的加成,很快就在数据库厂商和用户间流行开来。经过多年的发展,SQL已经成为应用最广、用户最多、最成熟的结构化数据计算语言。
IT咸鱼
2025/05/20
930
没有RDB也敢揽SQL活的开源金刚钻SPL
相关推荐
做 SQL 性能优化真是让人干瞪眼
更多 >
领券
问题归档专栏文章快讯文章归档关键词归档开发者手册归档开发者手册 Section 归档
本文部分代码块支持一键运行,欢迎体验
本文部分代码块支持一键运行,欢迎体验