SQL优化终于干掉了“distinct”

本文涉及的产品
云数据库 RDS MySQL,集群系列 2核4GB
推荐场景:
搭建个人博客
RDS MySQL Serverless 基础系列,0.5-2RCU 50GB
云数据库 RDS PostgreSQL,集群系列 2核4GB
简介: SQL优化终于干掉了“distinct”

一、优化目的

在我提交了代码的时候,架构师给我指出我这个sql这样写会有问题。因为在分库分表的时候,是不支持子查询的。

所以需要把多表的子查询的sql结构进行优化。

二、优化之前的sql长这样

是不是挺恐怖的;(此处为了脱敏,我把相关的sql关键词都给打码掉了)

这个sql的执行步骤如下:

1、查询出来d表中的某个id字段包含多个id值的所有的数据(因为此表是1-n的关系,所以需要去重,仅需要拿到不重复的id才可以继续下一个步骤);可以看到此步骤我把查询出来的多个值的结果给生成的了一个子表名为sss;

2、下一个步骤就是需要进行排序(以时间进行倒序排序,因为要在前台进行按时间进行展示);

3、第3步就是把这些结果与a表进行合并,查询出来排序后的每个id的信息;然后进行分页处理;

其他的可以不必关心,最终要的是去重关键字(DISTINCT),拿小本本记号,一会要考哦。

三、DISTINCT关键字的用法

实践是验证真理的唯一标准

例如有下表:

可以看到nameproduct_unit列有可能是重复的

mysql> SELECT t1.id,t1.name,t1.product_unit  FROM dd_product_category t1;
+----+----------+--------------+
| id | name     | product_unit |
+----+----------+--------------+
| 55 | 饮料     | 瓶           |
| 56 | 饮料     | 箱           |
| 57 | 零食     | 包           |
| 59 | 膨化食品 | 袋           |
| 60 | 方便食品 | 箱           |
| 61 | 自热火锅 | 碗           |
| 62 | 方便面   | 箱           |
| 63 | 矿泉水   | 箱           |
| 64 | 糖果     |              |
| 65 | 酒类     | 箱           |
| 66 | 烈酒     | 箱           |
| 67 | 啤酒     | 箱           |
| 68 | 预调酒   | 箱           |
+----+----------+--------------+
13 rows in set (0.13 sec)
mysql> 
mysql>

如何我们想只拿到name或者product_unit列的值并且不想要重复的值该怎么办?

1、拿到单个值是好拿的,但是是存在重复的数据的,这些重复的数据我们只保留一个就可以了,那么该怎么做呢?

mysql> SELECT t1.product_unit  FROM dd_product_category t1;
+--------------+
| product_unit |
+--------------+
| 瓶           |
| 箱           |
| 包           |
| 袋           |
| 箱           |
| 碗           |
| 箱           |
| 箱           |
|              |
| 箱           |
| 箱           |
| 箱           |
| 箱           |
+--------------+
13 rows in set (19.31 sec)
mysql>

2、去除重复列

mysql> 
mysql> SELECT DISTINCT t1.product_unit  FROM dd_product_category t1;
+--------------+
| product_unit |
+--------------+
| 瓶           |
| 箱           |
| 包           |
| 袋           |
| 碗           |
|              |
+--------------+
6 rows in set (0.11 sec)
mysql>

是不是很简单,虽然看着简单,但是如果多表子查询的时候,就会出现问题,例如你想要查询表a,b,c三个表的数据,这三个表必然都是有关系的。


a和b是1-n的关系。但是你只有b表中id,你需要先查询出来b表的数据,然后利用b表的数据去查询a表的数据,然后再去查询c表的数据。


想必肯定是很绕的。


整个过程中你肯定是需要去重的


当整个sql写完,基本上跟我写的优化前的sql也就差不多了。(多表嵌套,多sql嵌套sql,啦啦啦一大堆)。

优化思路还是有很多的,当时能想到的就是把这个复杂的sql拆分成多个简单的sql执行,然后使用Java后台代码进行处理。(对于不甘于现状的我,想找到一个比这个更友好的解决方案的我,我是不会屈服这个问题的。

四、谈:如何优化distinct的sql

说到这里,先给大家放上一个链接:

推荐大家阅读。

Mysql5.7官方手册中提及到的关于优化distinct的方法,原文如下:

MySQL 5.7 Reference Manual / … / DISTINCT Optimization

8.2.1.16 DISTINCT Optimization

DISTINCT combined with ORDER BY needs a temporary table in many cases.

distinct 与order by 结合的许多情况下需要建一个临时表;

Because DISTINCT may use GROUP BY, learn how MySQL works with columns in ORDER BY or HAVING clauses that are not part of the selected columns. See Section 12.20.3, “MySQL Handling of GROUP BY”.

因为distinct可能使用group by,了解MySQL如何处理按order by 列或者具有不属于所选列的子句。见12.20.3节, “MySQL Handling of GROUP BY”.

In most cases, a DISTINCT clause can be considered as a special case of GROUP BY. For example, the following two queries are equivalent:

在大多数情况下,一个不同的子句可以被认为是group by 的特殊情况。例如下面这两个查询是等价的:

SELECT DISTINCT c1, c2, c3 FROM t1
WHERE c1 > const;
SELECT c1, c2, c3 FROM t1
WHERE c1 > const GROUP BY c1, c2, c3;

Due to this equivalence, the optimizations applicable to GROUP BY queries can be also applied to queries with a DISTINCT clause. Thus, for more details on the optimization possibilities for DISTINCT queries, see Section 8.2.1.15, “GROUP BY Optimization”.

由于这种等价性,适用于group by查询的优化,也可以应用于具有不同子句的查询。因此,关于distinct的查询优化的更多细节可以参考Section 8.2.1.15, “GROUP BY Optimization”.

When combining LIMIT row_count with DISTINCT, MySQL stops as soon as it finds row_count unique rows.

当row_count与distinct一起使用时,MySQL一旦发现row_count是唯一的行,就会停止。

If you do not use columns from all tables named in a query, MySQL stops scanning any unused tables as soon as it finds the first match. In the following case, assuming that t1 is used before t2 (which you can check with EXPLAIN), MySQL stops reading from t2 (for any particular row in t1) when it finds the first row in t2:

如果在查询中不适用来自所有表的列,MySQL一旦找到第一个匹配项就会停止扫描任何未使用的表。


在下面的例子中,假设t1在t2之前使用(你可以使用explanin来检查),MySQL在找到t2的第一行时停止从t2读取(对于t1中的任何特定行)。

SELECT DISTINCT t1.a FROM t1, t2 where t1.a=t2.a;

官方的手册中写到的,真是句句扣心呀!!!

总结有以下比较重要的几点:

  • 1、distinct与group by几乎等价;
  • 2、distinct的相关优化与group by的查询优化方法是等价的;

五、distinct真的和group by等价吗?

我们抱着试试看的态度,去做个试验。

就以下列这个效果为最终目的好了:

mysql> 
mysql> SELECT DISTINCT t1.product_unit  FROM dd_product_category t1;
+--------------+
| product_unit |
+--------------+
| 瓶           |
| 箱           |
| 包           |
| 袋           |
| 碗           |
|              |
+--------------+
6 rows in set (0.11 sec)
mysql>

使用group by去重:

mysql> select  t1.product_unit from dd_product_category t1 group by t1.product_unit;
+--------------+
| product_unit |
+--------------+
|              |
| 包           |
| 瓶           |
| 碗           |
| 箱           |
| 袋           |
+--------------+
6 rows in set (19.46 sec)
mysql>

可以看到,最终拿到的数据是一模一样的。


那么我们试验是成功的,distinct的效果和group by的效果是一样的。


那么我们优化distinct就变向的去优化group by了(我优化前的sql并未使用group by所以谈不上优化group by,只能说是把distinct的复杂sql改造成group by 的sql)。

打开我前面提到的这个优化group by的官方手册:

https://dev.mysql.com/doc/refman/5.7/en/group-by-optimization.html

由于原文比较长,这里就不在过多赘述。

现在需要做的就是把distinct改造成group by的sql语法的写法。

六、优化后的sql长啥样?

怎么样,改造后的sql,是不是还挺清爽的。


1、我们扔掉了多个嵌套sql


2、也不用去生成一个sss的临时表了

七、总结

对于本人而言学到了:

  • 1、distinct与group by几乎等价;
  • 2、distinct的相关优化与group by的查询优化方法是等价的;
  • 3、如果distinct的不能让sql最优化,那么可以尝试着使用group by的方式去改造一下。

这些我都上传到了百度云。




相关实践学习
如何在云端创建MySQL数据库
开始实验后,系统会自动创建一台自建MySQL的 源数据库 ECS 实例和一台 目标数据库 RDS。
全面了解阿里云能为你做什么
阿里云在全球各地部署高效节能的绿色数据中心,利用清洁计算为万物互联的新世界提供源源不断的能源动力,目前开服的区域包括中国(华北、华东、华南、香港)、新加坡、美国(美东、美西)、欧洲、中东、澳大利亚、日本。目前阿里云的产品涵盖弹性计算、数据库、存储与CDN、分析与搜索、云通信、网络、管理与监控、应用服务、互联网中间件、移动服务、视频服务等。通过本课程,来了解阿里云能够为你的业务带来哪些帮助     相关的阿里云产品:云服务器ECS 云服务器 ECS(Elastic Compute Service)是一种弹性可伸缩的计算服务,助您降低 IT 成本,提升运维效率,使您更专注于核心业务创新。产品详情: https://www.aliyun.com/product/ecs
目录
相关文章
|
2月前
|
SQL
慢sql治理问题之 Task 数量分布不均的问题你们是如何优化的
慢sql治理问题之 Task 数量分布不均的问题你们是如何优化的
慢sql治理问题之 Task 数量分布不均的问题你们是如何优化的
|
2月前
|
Java XML Maven
跨越时代的飞跃:Struts 2 升级秘籍——从旧版本无缝迁移到最新版,焕发应用新生!
【8月更文挑战第31天】随着软件技术的发展,Struts 2 框架也在不断更新。本文通过具体案例指导开发者如何从旧版平滑升级到 Struts 2.6.x。首先更新 `pom.xml` 中的依赖版本,并执行 `mvn clean install`。接着检查 `struts.xml` 配置,确保符合新版本要求,调整包扫描器等设置。审查 Action 类及其注解,检查配置文件中的弃用项及插件。更新自定义拦截器实现,并验证日志配置。最后,通过一系列测试确保升级后的系统正常运行。通过这些步骤,可以顺利完成 Struts 2 的版本升级,提升应用的安全性和性能。
94 0
|
2月前
|
SQL 数据采集 数据挖掘
深入理解SQL中的DISTINCT语句及其应用
【8月更文挑战第31天】
45 0
|
2月前
|
SQL 存储 数据库
|
2月前
|
SQL 数据管理 关系型数据库
SQL与云计算:利用云数据库服务实现高效数据管理——探索云端SQL应用、性能优化、安全性与成本效益,为企业数字化转型提供全方位支持
【8月更文挑战第31天】在数字化转型中,企业对高效数据管理的需求日益增长。传统本地数据库存在局限,而云数据库服务凭借自动扩展、高可用性和按需付费等优势,成为现代数据管理的新选择。本文探讨如何利用SQL和云数据库服务(如Amazon RDS、Google Cloud SQL和Azure SQL Database)实现高效的数据管理。通过示例和最佳实践,展示SQL在云端的应用、性能优化、安全性及成本效益,助力企业提升竞争力。
45 0
|
2月前
|
SQL 关系型数据库 MySQL
SQL性能调优的神奇之处:如何用优化技巧让你的数据库查询飞起来,实现秒级响应?
【8月更文挑战第31天】在现代软件开发中,数据库性能至关重要。本文通过一个实战案例,展示了从慢查询到秒级响应的全过程。通过对查询的详细分析与优化,包括创建索引、改进查询语句及数据类型选择等措施,最终显著提升了性能。文章还提供了示例代码及最佳实践建议,帮助读者掌握SQL性能调优的核心技巧。
46 0
|
2月前
|
SQL 关系型数据库 MySQL
SQL索引构建与优化的神奇之处:如何用高效索引让你的数据检索飞起来?
【8月更文挑战第31天】在现代软件开发中,数据库索引对于提升查询性能至关重要。本文详细介绍了SQL索引的概念、构建方法及优化技巧,包括避免不必要的索引、使用复合索引等策略,并提供了实用的示例代码,如 `CREATE INDEX index_name ON table_name (column_name, another_column_name);`。通过遵循这些最佳实践,如了解查询模式和定期维护索引,可以大幅提高数据检索效率,从而增强应用程序的整体性能。
79 0
|
2月前
|
SQL 关系型数据库 MySQL
OceanBase 的 SQL 兼容性与优化
【8月更文第31天】随着分布式计算的发展,越来越多的企业开始采用分布式数据库来满足其大规模数据存储和处理的需求。OceanBase 作为一款高性能的分布式关系数据库,其设计旨在为用户提供与传统单机数据库类似的 SQL 查询体验,同时保持高可用性和水平扩展能力。本文将深入探讨 OceanBase 的 SQL 引擎特性、兼容性问题,并提供一些针对特定查询进行优化的方法和代码示例。
112 0
|
2月前
|
SQL 资源调度 流计算
慢sql治理问题之在 Flink 中, userjar 分发问题如何优化
慢sql治理问题之在 Flink 中, userjar 分发问题如何优化
|
2月前
|
SQL 安全 数据库
如何优化SQL查询
【8月更文挑战第1天】如何优化SQL查询
51 2
下一篇
无影云桌面