高逼格的SQL寫法：行行比較
共 4923字，需瀏覽 10分鐘
·
2024-06-03 09:19
往期熱門文章：
1、限流算法哪家強(qiáng)？時(shí)間窗口，令牌桶與漏桶算法對(duì)比
環(huán)境準(zhǔn)備
數(shù)據(jù)庫版本：MySQL 5.7.20-log
建表 SQL
DROP TABLE IF EXISTS `t_ware_sale_statistics`;
CREATE TABLE `t_ware_sale_statistics` (
`id` bigint(20) NOT NULL AUTO_INCREMENT COMMENT '主鍵id',
`business_id` bigint(20) NOT NULL COMMENT '業(yè)務(wù)機(jī)構(gòu)編碼',
`ware_inside_code` bigint(20) NOT NULL COMMENT '商品自編碼',
`weight_sale_cnt_day` double(16,4) DEFAULT NULL COMMENT '平均日銷量',
`last_thirty_days_sales` double(16,4) DEFAULT NULL COMMENT '最近30天銷量',
`last_sixty_days_sales` double(16,4) DEFAULT NULL COMMENT '最近60天銷量',
`last_ninety_days_sales` double(16,4) DEFAULT NULL COMMENT '最近90天銷量',
`same_period_sale_qty_thirty` double(16,4) DEFAULT NULL COMMENT '去年同期30天銷量',
`same_period_sale_qty_sixty` double(16,4) DEFAULT NULL COMMENT '去年同期60天銷量',
`same_period_sale_qty_ninety` double(16,4) DEFAULT NULL COMMENT '去年同期90天銷量',
`create_user` bigint(20) DEFAULT NULL COMMENT '創(chuàng)建人',
`create_time` datetime NOT NULL DEFAULT CURRENT_TIMESTAMP COMMENT '創(chuàng)建時(shí)間',
`modify_user` bigint(20) DEFAULT NULL COMMENT '最終修改人',
`modify_time` datetime NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP COMMENT '最終修改時(shí)間',
`is_delete` tinyint(2) DEFAULT '2' COMMENT '是否刪除，1：是，2：否',
PRIMARY KEY (`id`) USING BTREE,
KEY `idx_business_ware` (`business_id`,`ware_inside_code`) USING BTREE
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 ROW_FORMAT=DYNAMIC COMMENT='商品銷售統(tǒng)計(jì)';
初始化數(shù)據(jù)
準(zhǔn)備了 769063 條數(shù)據(jù)
需求背景
業(yè)務(wù)機(jī)下銷售商品，同個(gè)業(yè)務(wù)機(jī)構(gòu)可以銷售不同的商品，同個(gè)商品可以在不同的業(yè)務(wù)機(jī)構(gòu)銷售，也就說：業(yè)務(wù)機(jī)構(gòu)與商品是多對(duì)多的關(guān)系
假設(shè)現(xiàn)在有 n 個(gè)機(jī)構(gòu)，每個(gè)機(jī)構(gòu)下有幾個(gè)商品，如何查詢出這幾個(gè)門店下各自商品的銷售情況？
具體點(diǎn)，類似如下
如何查出 100001 下商品 1000、1001、1003 、 100002 下商品 1003、1004 、 100003 下商品 1006、1008、1009 的銷售情況
相當(dāng)于是雙層列表（業(yè)務(wù)機(jī)構(gòu)列表中套商品列表）的查詢；業(yè)務(wù)機(jī)構(gòu)列表和商品列表都不是固定的，而是動(dòng)態(tài)的
那么問題就是：如何查詢多個(gè)業(yè)務(wù)機(jī)構(gòu)下，某些商品的銷售情況
問題經(jīng)我一描述，可能更模糊了，大家明白意思了就好！
循環(huán)查詢
這個(gè)很容易想到，在代碼層面循環(huán)業(yè)務(wù)機(jī)構(gòu)列表，每個(gè)業(yè)務(wù)機(jī)構(gòu)查一次數(shù)據(jù)庫，偽代碼如下：
具體的 SQL 類似如下
SQL 能走索引
實(shí)現(xiàn)簡單，也好理解，SQL 也能走索引，一切看起來似乎很完美
然而現(xiàn)實(shí)是：部門開發(fā)規(guī)范約束，不能循環(huán)查數(shù)據(jù)庫
哦豁，這種方式只能放棄，另尋其他方式了
OR 拼接
通過 MyBatis 的 動(dòng)態(tài) SQL 功能，進(jìn)行 SQL 拼接，類似如下
具體的 SQL 類似如下
SQL 也能走索引
實(shí)現(xiàn)簡單，也好理解，SQL 也能走索引，而且只查詢一次數(shù)據(jù)庫，貌似可行
唯一可惜的是：有點(diǎn)費(fèi) OR，如果業(yè)務(wù)機(jī)構(gòu)比較多，那 SQL 會(huì)比較長
作為候選人之一吧，我們接著往下看
混查過濾
同樣是利用 Mybatis 的 動(dòng)態(tài) SQL ，將 business_id 列表拼在一起、 ware_inside_code 拼在一起，類似如下
具體的 SQL 類似如下
SQL 也能走索引
實(shí)現(xiàn)簡單，也好理解，SQL 也能走索引，而且只查詢一次數(shù)據(jù)庫，似乎可行
但是：查出來的結(jié)果集大于等于我們想要的結(jié)果集，你品，你細(xì)品！
所以還需要對(duì)查出來的結(jié)果集進(jìn)行一次過濾，過濾出我們想要的結(jié)果集
姑且也作為候選人之一吧，我們繼續(xù)往下看
行行比較
SQL-92 中加入了行與行比較的功能，這樣一來，比較謂詞 = 、< 、> 和 IN 謂詞的參數(shù)就不再只是標(biāo)量值了，還可以是值列表了
當(dāng)然，還是得用到 Mybatis 的 動(dòng)態(tài) SQL ，類似如下
具體的 SQL 類似如下
SQL 同樣能走索引
實(shí)現(xiàn)簡單，SQL 也能走索引，而且只查詢一次數(shù)據(jù)庫，感覺可行
只是：有點(diǎn)不好理解，因?yàn)槲覀兤綍r(shí)這么用的少，所以這種寫法看起來很陌生
另外，行行比較是 SQL 規(guī)范，不是某個(gè)關(guān)系型數(shù)據(jù)庫的規(guī)范，也就說關(guān)系型數(shù)據(jù)庫都應(yīng)該支持這種寫法
總結(jié)
1、最后選擇了 行行比較 這種方式來實(shí)現(xiàn)了需求
別問我為什么，問就是逼格高！
2、某一個(gè)需求的實(shí)現(xiàn)往往有很多種方式，我們需要結(jié)合業(yè)務(wù)以及各種約束綜合考慮，選擇最合適的那個(gè)
3、行行比較是 SQL-92 中引入的，SQL-92 是 1992 年制定的規(guī)范
行行比較不是新特性，而是很早就存在的基礎(chǔ)功能！
文章來源：【公眾號(hào)：Java充電社】
往期熱門文章：
1、SQL中為什么不要使用1=1?
2、同事使用 insert into select 遷移數(shù)據(jù)，開開心心上線，導(dǎo)致公司損失近10w！
3、拒絕寫重復(fù)代碼，試試這套開源的SpringBoot組件，效率翻倍~
4、我原以為是個(gè)笑話，沒想到深挖一下背后還有故事。錯(cuò)怪官方了...
5、Lombok！代碼“亞健康”元兇？
6、上班摸魚神器！標(biāo)星 17k 的安卓手機(jī)投屏工具！
7、Zed，有望打敗 VS Code 嗎？
8、標(biāo)星 43.1 K！最火跨平臺(tái)筆記開源項(xiàng)目
9、融入團(tuán)隊(duì)代碼風(fēng)格，代碼越寫越爛！
10、4 個(gè) GitHub 上令人驚艷的項(xiàng)目！