关于SQL最大值查询语句的记录

这几天在项目上遇到一个问题,说是一个业务列表的查询很慢。记得之前这个功能并没有遇到这个情况,而且根据客户的描述,是最近一段时间开始变慢的。于是从后台拿出了不知道是谁写的sal语句,检查了一下,发现其中的一个子查询语句是这样的:
SELECT
	BSNUM,
	STATE AS FILE_STATE
FROM
	file_record r
WHERE
	EXISTS(
		SELECT
			BSNUM,
			STATE
		FROM
			(
				SELECT
					BSNUM,
					MAX(STATE) AS STATE
				FROM
					file_record
				GROUP BY
					BSNUM
			) x
		WHERE
			r.BSNUM = x.BSNUM
		AND r.STATE = x.STATE
	)


简单的看了一下这个语句,应该是想查出这个表中state值最大的业务对应的bsnum和state这两个字段的值。但是用原有的方法未免太麻烦,而且效率低下,于是优化了一下sql语句,改成这样的:
SELECT
	bsnum,
	STATE AS FILE_STATE
FROM
	FILE_RECORD r
WHERE
	STATE =(
		SELECT
			MAX(STATE)
		FROM
			FILE_RECORD
		WHERE
			bsnum = r.bsnum
	);
将修改前后的两个语句在数据量大的生产环境分别执行一下,发现查询时间差距居然如此之大:

之前只是知道,用第一种这样的蠢蠢的查询方式,效率很低,但是没有想到二者差距这么大。为什么之前这里没有发现问题呢?因为一开始的时候数据量不是很大,所以倒是也没有太影响系统使用。不过随着数据量慢慢的变多,到现在已经有几十万条数据了,所以查询速度自然就变得慢下来了。



  • 0
    点赞
  • 1
    收藏
    觉得还不错? 一键收藏
  • 打赏
    打赏
  • 0
    评论
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

小白码上飞

你的鼓励将是我创作的最大动力

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付:¥1
获取中
扫码支付

您的余额不足,请更换扫码支付或充值

打赏作者

实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值