神奇的 SQL 之行行比较 → 逼格高，还很润

青石路
898 阅读7分钟

开心一刻

昨晚我和我爸聊天
我：爸，你怎么把烟戒了，也不出去喝酒了，是因为我妈不让，还是自己醒悟，开始爱惜自己啦？
爸：儿子啊，你说的都不对，是彩礼又涨价了
我：你不是有媳妇了吗？
爸：我有，可你没有啊！
我：爸，我长大了不娶媳妇，好好孝敬您！
爸：臭小子，你想的美，我一定要给你娶媳妇，让你的孩子也好好折腾你，让你也体会一下有一个不争气的儿子是什么感受！

开心一刻

基础准备

数据库版本：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 '业务机构编码',
  `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 '创建人',
  `create_time` datetime NOT NULL DEFAULT CURRENT_TIMESTAMP COMMENT '创建时间',
  `modify_user` bigint(20) DEFAULT NULL COMMENT '最终修改人',
  `modify_time` datetime NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP COMMENT '最终修改时间',
  `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='商品销售统计';

初始化了 769063 条数据

数据量

需要注意的是

下文要讲的内容与具体的关系型数据库无关，采用 MySQL 仅仅是为了演示，我总得基于某个数据库给你们演示案例吧，所以你们不要执着于此

需求背景

业务机构下销售商品，同个业务机构可以销售不同的商品，同个商品可以在不同的业务机构销售，也就说：业务机构与商品是多对多的关系；假设现在有 n 个机构，每个机构下有几个商品，如何查询出这几个门店下各自商品的销售情况？具体点，类似如下

需求案例

如何查出 100001 下商品 1000,1001,1003 、100002 下商品 1003,1004 、100003 下商品 1006,1008,1009 的销售情况；相当于是双层列表（业务机构列表中套商品列表）的查询，业务机构列表和商品列表都不是固定的，而是动态的，所以问题就是：

如何查询多个业务机构下，某些商品的销售情况

如果你们没明白需求，也不用担心，不影响继续往下看；针对如上需求，不知道你们有哪些实现方案，我尝试了以下几种

循环查询

这个很容易想到，在代码层面循环业务机构列表，每个业务机构查一次数据库，伪代码如下

循环查询_伪代码实现

具体的 SQL 类似如下

循环查询_具体SQL案例

SQL 能走索引

循环查询_执行计划

实现简单，也好理解，SQL 也能走索引，一切看起来似乎很完美！然而现实是

开发规范约束，不能循环查数据库

循环查询_不能使用

那这种方案只能放弃，另寻其他方案了

OR 拼接

通过 MyBatis 的 动态 SQL 功能，进行 SQL 拼接，类似如下

OR拼接_MyBatis动态SQL

具体的 SQL 类似如下

OR拼接_案例SQL

SQL 也能走索引

OR拼接_执行计划

实现简单，也好理解，SQL 也能走索引，而且只查询一次数据库，貌似可行

作为候选方案，我们接着往下看

混查过滤

同样是利用 Mybatis 的 动态 SQL ，将 business_id 列表拼在一起、ware_inside_code 拼在一起，类似如下

混查过滤_MyBatis动态SQL

具体的 SQL 类似如下

混查过滤_案例SQL

SQL 也能走索引

混查过滤_执行计划

实现简单，也好理解，SQL 也能走索引，而且只查询一次数据库，似乎可行；但是

查出来的结果集大于等于我们想要的结果集

所以还需要对查出来的结果集进行一次过滤，过滤出我们想要的结果集

姑且也作为候选人之一吧，我们继续往下看

行行比较

SQL-92 中加入了行与行比较的功能，这样一来，比较谓词 = 、< 、> 和 IN 谓词的参数就不再只是标量值了，还可以是值列表了。通过 MyBatis 的 动态 SQL 功能，进行 SQL 拼接，类似如下

行行比较_MyBatis动态SQL

具体的 SQL 类似如下

行行比较_案例SQL

SQL 同样能走索引

行行比较_执行计划

实现简单，SQL 也能走索引，而且只查询一次数据库，感觉可行；只是有点不好理解，因为我们平时这么用的少，对这种写法很陌生，但我希望你们再看了这篇文章之后，对 行行比较 不再陌生

抛开需求实现，我们对 行行比较 进行一个总结

比较谓词的左边不再是单一列了，也可以是多列了，例如可以是 WHERE business_id IN，也可以是 WHERE (business_id,ware_inside_code)
比较谓词的右边不再是标量值了，可以是多列值了，例如可以是 IN (100120609,100121327)，也可以是 IN((100120609,5169),(1000121327,14418))
如下 SQL 写法也是行行比较

SELECT * FROM tbl_a 
WHERE (id,name) IN (
    SELECT id,name FROM tbl_b
);

这样写不用担心连接字段时出现的类型转换问题，也不会对字段进行加工，因此可以使用索引

行行比较 是 SQL 规范，不是某个关系型数据库的规范，也就说关系型数据库都应该支持这种写法，是满足不同库之间迁移的

总结

  1. 最后选择了 行行比较 这种方式来实现了需求

    逼格高还很润.gif

    某一个需求的实现往往有很多种方式，我们需要结合业务以及各种约束综合考虑，选择最合适的那个

  2. 行行比较是 SQL-92 中引入的，SQL-92 是 1992 年制定的规范

    行行比较不是新特性，而是很早就存在的基础功能！但俗话说 上有政策，下有对策，还得看具体的数据库是否有落体实现

参考

《SQL基础教程》
《SQL进阶教程》
神奇的 SQL 之 MySQL 执行计划 → EXPLAIN，让我们了解 SQL 的执行过程！
神奇的SQL，如何让我们的 SQL 飞起来
神奇的SQL，明明有索引，为什么SQL查询还是索引失效

avatar
文章
阅读
粉丝