一个困扰了我三天的SQL优化问题。(多条数据取最近的数据)

2024-09-04 19:58

本文主要是介绍一个困扰了我三天的SQL优化问题。(多条数据取最近的数据),希望对大家解决编程问题提供一定的参考价值,需要的开发者们随着小编来一起学习吧!

            由于优化的方向不对,一个SQL困扰了我好几天,物化视图什么之类的,全部都试过了,还是没有解决。今天,在看这个问题的时候,灵光一现,咦,好像是这里有问题,然后改了一下,终于解决了。这个SQL,从最初的16秒,后面换了各种方法,有180秒,150秒,60多秒,试过了各种SQL,终于,优化到了0.3秒。好了,现在说下问题。

           这个SQL总共涉及了6张表,其实最主要的是做数据的统计。直接看SQL吧。

1.这个是最初的:速度是16秒。

SELECT
*
FROM
(
SELECT
A . ID,
warehousecode,
sku,
OWNER,
enname,
customername,
createtime,
(startnum + changenum) sumnum,
(startnum + changenum - locknum) availablenum,
locknum
FROM
(
SELECT
t1. ID,
t2.warehousecode,
t1.sku,
C . NAME customername,
t1.createtime,
t1. OWNER,
P .cnname enname,
(
NUMBER + COALESCE (locknumber, 0)
) startnum,
(
SELECT
COALESCE (
SUM (
(
CASE
WHEN TYPE = 'inbound' THEN
qty
ELSE
(- 1 * qty)
END
)
),
0
) AS qty
FROM
t_inventory_change tc
WHERE
tc.warehousecode = t2.warehousecode
AND tc. OWNER = t1. OWNER
AND tc.sku = t1.sku
AND tc.createtime > t1.createtime
) changeNum,
(
SELECT
COALESCE (SUM(qty), 0)
FROM
t_inventory_lock tl
WHERE
VALID = 't'
AND tl.warehousecode = t2.warehousecode
AND tl. OWNER = t1. OWNER
AND tl.sku = t1.sku
AND tl.createtime > t1.createtime
) lockNum
FROM
t_inventory_detail t1
LEFT JOIN t_inventory t2 ON t1.inventoryid = t2. ID
LEFT JOIN t_product P ON P . OWNER = t1. OWNER
AND P .status = 1
AND P .sku = t1.sku
LEFT JOIN t_customer C ON C .code = t1. OWNER
WHERE
t1.createtime = (
SELECT
MAX (t3.createtime)
FROM
t_inventory_detail t3,
t_inventory t4
WHERE
t3.inventoryid = t4. ID
AND t2.warehousecode = t4.warehousecode
AND t1.sku = t3.sku
)

) AS A
) AS T
WHERE
1 = 1
order by createtime desc


2.这个是 160 秒的

select DISTINCT t.*
,(NUMBER + COALESCE (locknumber, 0) + changenum) sumnum
,(NUMBER + COALESCE (locknumber, 0) + changenum - locknum) availablenum 
from(
select td.sku,td.warehousecode,td.owner,td.cnname,td.number,td.locknumber,td.createtime,
c.name customername,
p.cnname enname,
COALESCE(SUM(CASE WHEN tc.TYPE = 'inbound' THEN tc.qty ELSE (- 1 * tc.qty) END ) OVER(partition by tc.warehousecode,tc.OWNER,tc.sku),0) changenum,
COALESCE(SUM(tl.qty) OVER(partition by tl.warehousecode,tl.OWNER,tl.sku),0) lockNum
from(
select sku,warehousecode,owner,cnname,number,locknumber,createtime from(
select t1.sku,t2.warehousecode,t1.owner,t1.cnname,t1.number,t1.locknumber,t1.createtime,
row_number() over(partition by t1.sku,t1.owner,t2.warehousecode order by t1.createtime desc) rn 
from t_inventory_detail t1 left join t_inventory t2 on t1.inventoryid=t2.id) t where rn=1) td
left join t_product p on p.owner = td.owner and p.status = 1 and p .sku = td.sku
left join t_customer c on c.code = td.owner
left join t_inventory_lock tl on tl.warehousecode = td.warehousecode AND tl. OWNER = td. OWNER AND tl.sku = td.sku AND tl.createtime > td.createtime and VALID = 't' 
left join t_inventory_change tc on tc.warehousecode = td.warehousecode AND tc. OWNER = td. OWNER AND tc.sku = td.sku AND tc.createtime > td.createtime
) t;


3.这个是0.3秒的

SELECT
*
FROM
(
SELECT
A . ID,
warehousecode,
sku,
OWNER,
enname,
customername,
createtime,
(startnum + changenum) sumnum,
(startnum + changenum - locknum) availablenum,
locknum
FROM
(
SELECT
td. ID,
td.warehousecode,
td.sku,
C . NAME customername,
td.createtime,
td. OWNER,
P .cnname enname,
(
NUMBER + COALESCE (locknumber, 0)
) startnum,
(
SELECT
COALESCE (
SUM (
(
CASE
WHEN TYPE = 'inbound' THEN
qty
ELSE
(- 1 * qty)
END
)
),
0
) AS qty
FROM
t_inventory_change tc
WHERE
tc.warehousecode = td.warehousecode
AND tc. OWNER = td. OWNER
AND tc.sku = td.sku
AND tc.createtime > td.createtime
) changeNum,
(
SELECT
COALESCE (SUM(qty), 0)
FROM
t_inventory_lock tl
WHERE
VALID = 't'
AND tl.warehousecode = td.warehousecode
AND tl. OWNER = td. OWNER
AND tl.sku = td.sku
AND tl.createtime > td.createtime
) lockNum
FROM
(
SELECT
T . ID,
sku,
warehousecode,
OWNER,
cnname,
NUMBER,
locknumber,
createtime
FROM
(
SELECT
t1. ID,
t1.sku,
t2.warehousecode,
t1. OWNER,
t1.cnname,
t1. NUMBER,
t1.locknumber,
t1.createtime,
ROW_NUMBER () OVER (
PARTITION BY t1.sku,
t1. OWNER,
t2.warehousecode
ORDER BY
t1.createtime DESC
) rn
FROM
t_inventory_detail t1
LEFT JOIN t_inventory t2 ON t1.inventoryid = t2. ID
) T
WHERE
rn = 1
) td

LEFT JOIN t_product P ON P . OWNER = td. OWNER
AND P .status = 1
AND P .sku = td.sku
LEFT JOIN t_customer C ON C .code = td. OWNER
) AS A
) AS T
WHERE
1 = 1
 order by createtime desc


其实最主要的问题,还是出在红色标记的区别。就是有多个数据的时候,取最近的数据。最开始以为这里没有问题,一直以为是子查询的问题,后面发现并不是子查询的问题。记在这里,给自己一个教训。

这篇关于一个困扰了我三天的SQL优化问题。(多条数据取最近的数据)的文章就介绍到这儿,希望我们推荐的文章对编程师们有所帮助!



http://www.chinasem.cn/article/1136885

相关文章

Vue3 的 shallowRef 和 shallowReactive:优化性能

大家对 Vue3 的 ref 和 reactive 都很熟悉,那么对 shallowRef 和 shallowReactive 是否了解呢? 在编程和数据结构中,“shallow”(浅层)通常指对数据结构的最外层进行操作,而不递归地处理其内部或嵌套的数据。这种处理方式关注的是数据结构的第一层属性或元素,而忽略更深层次的嵌套内容。 1. 浅层与深层的对比 1.1 浅层(Shallow) 定义

大模型研发全揭秘:客服工单数据标注的完整攻略

在人工智能(AI)领域,数据标注是模型训练过程中至关重要的一步。无论你是新手还是有经验的从业者,掌握数据标注的技术细节和常见问题的解决方案都能为你的AI项目增添不少价值。在电信运营商的客服系统中,工单数据是客户问题和解决方案的重要记录。通过对这些工单数据进行有效标注,不仅能够帮助提升客服自动化系统的智能化水平,还能优化客户服务流程,提高客户满意度。本文将详细介绍如何在电信运营商客服工单的背景下进行

SQL中的外键约束

外键约束用于表示两张表中的指标连接关系。外键约束的作用主要有以下三点: 1.确保子表中的某个字段(外键)只能引用父表中的有效记录2.主表中的列被删除时,子表中的关联列也会被删除3.主表中的列更新时,子表中的关联元素也会被更新 子表中的元素指向主表 以下是一个外键约束的实例展示

基于MySQL Binlog的Elasticsearch数据同步实践

一、为什么要做 随着马蜂窝的逐渐发展,我们的业务数据越来越多,单纯使用 MySQL 已经不能满足我们的数据查询需求,例如对于商品、订单等数据的多维度检索。 使用 Elasticsearch 存储业务数据可以很好的解决我们业务中的搜索需求。而数据进行异构存储后,随之而来的就是数据同步的问题。 二、现有方法及问题 对于数据同步,我们目前的解决方案是建立数据中间表。把需要检索的业务数据,统一放到一张M

关于数据埋点,你需要了解这些基本知识

产品汪每天都在和数据打交道,你知道数据来自哪里吗? 移动app端内的用户行为数据大多来自埋点,了解一些埋点知识,能和数据分析师、技术侃大山,参与到前期的数据采集,更重要是让最终的埋点数据能为我所用,否则可怜巴巴等上几个月是常有的事。   埋点类型 根据埋点方式,可以区分为: 手动埋点半自动埋点全自动埋点 秉承“任何事物都有两面性”的道理:自动程度高的,能解决通用统计,便于统一化管理,但个性化定

如何去写一手好SQL

MySQL性能 最大数据量 抛开数据量和并发数,谈性能都是耍流氓。MySQL没有限制单表最大记录数,它取决于操作系统对文件大小的限制。 《阿里巴巴Java开发手册》提出单表行数超过500万行或者单表容量超过2GB,才推荐分库分表。性能由综合因素决定,抛开业务复杂度,影响程度依次是硬件配置、MySQL配置、数据表设计、索引优化。500万这个值仅供参考,并非铁律。 博主曾经操作过超过4亿行数据

使用SecondaryNameNode恢复NameNode的数据

1)需求: NameNode进程挂了并且存储的数据也丢失了,如何恢复NameNode 此种方式恢复的数据可能存在小部分数据的丢失。 2)故障模拟 (1)kill -9 NameNode进程 [lytfly@hadoop102 current]$ kill -9 19886 (2)删除NameNode存储的数据(/opt/module/hadoop-3.1.4/data/tmp/dfs/na

异构存储(冷热数据分离)

异构存储主要解决不同的数据,存储在不同类型的硬盘中,达到最佳性能的问题。 异构存储Shell操作 (1)查看当前有哪些存储策略可以用 [lytfly@hadoop102 hadoop-3.1.4]$ hdfs storagepolicies -listPolicies (2)为指定路径(数据存储目录)设置指定的存储策略 hdfs storagepolicies -setStoragePo

HDFS—存储优化(纠删码)

纠删码原理 HDFS 默认情况下,一个文件有3个副本,这样提高了数据的可靠性,但也带来了2倍的冗余开销。 Hadoop3.x 引入了纠删码,采用计算的方式,可以节省约50%左右的存储空间。 此种方式节约了空间,但是会增加 cpu 的计算。 纠删码策略是给具体一个路径设置。所有往此路径下存储的文件,都会执行此策略。 默认只开启对 RS-6-3-1024k

Hadoop集群数据均衡之磁盘间数据均衡

生产环境,由于硬盘空间不足,往往需要增加一块硬盘。刚加载的硬盘没有数据时,可以执行磁盘数据均衡命令。(Hadoop3.x新特性) plan后面带的节点的名字必须是已经存在的,并且是需要均衡的节点。 如果节点不存在,会报如下错误: 如果节点只有一个硬盘的话,不会创建均衡计划: (1)生成均衡计划 hdfs diskbalancer -plan hadoop102 (2)执行均衡计划 hd