在工作中常用到的SQL

简介: 前言只有光头才能变强。文本已收录至我的GitHub仓库,欢迎Star:https://github.com/ZhongFuCheng3y/3y最近在公司做了几张报表,还记得刚开始要做报表的时候都快把SQL给忘光了(当时在广州休假了1个月多,在实习期间也没咋写过SQL),回到公司的第一个需求就是做报表。

前言

只有光头才能变强。

文本已收录至我的GitHub仓库,欢迎Star:https://github.com/ZhongFuCheng3y/3y

最近在公司做了几张报表,还记得刚开始要做报表的时候都快把SQL给忘光了(当时在广州休假了1个月多,在实习期间也没咋写过SQL),回到公司的第一个需求就是做报表。

于是我很不要脸地跟带我的学长说:“SQL我好像忘光了,group 分组查询好像都忘得差不多了,我得复习一下”。

这篇文章来记录一下我曾经忘掉的group查询、join查询等一些比较实用/常用的SQL

  • 本文主打通俗易懂,不涵盖任何优化(适合新手观看)

一、回顾group 查询

group 查询就是分组查询,为什么要分组查询?因为我们想按某个维度进行统计。下面来看个图:

现在我的数据如下

比如说,我想知道:每天Java3y这个公众号的点击量是多少。按我们人工而言,思路很简单:把相同的天数以及公众号名称为Java3y的数据找出来,再将每个点击量相加,就得出了结果了。

步骤

用上SQL我们可能会这样写:

select name,time,sum(pv) as pv  
from xxx_table 
where name = 'Java3y' group by name,time

1.1 group 查询可能存在的误解

记得有一天,有个群友在群上问了一个问题:

群里边的一个问题

其实他的需求很简单:检索出数据分组后时间最高的记录。但他是这样干的:

  1. 把先按照时间 order by
  2. order by后的记录进行分组

示例图:

群里面的一个图

1.2 造成这个误解的可能原因

有的工具可以支持这种的写法:

select * from xxx_table group by name

这种写法没有被禁止,并可以得出结果,比如得到的结果是:

Java4y    20  7月15号
Java3y    30  7月15号

这种写法其实是不合理的,要知道的是:使用group by 分组统计之后,我们的select 后面只能跟着group by 的字段,或者是聚合函数。

group by规则

因为,我们对数据进行了分组查询,数据的分布情况,我们是不关心的

记住:先分组,后统计(先把数据归类后,再对相同的数据进行统计)

1.3 group查询最常用的SQL

去重是我们经常会遇到的问题,打个比方说,由于各种原因(不管是业务上还是说是脏数据),现在我有两条重复的数据(除了ID,其余的字段都是相同的):

重复的数据

我这边只希望留下某一条记录作为查询结果就好了,我们可以写下以下的SQL:

select * from user where id in(
   select min(id) from user where name = 'Java3y' and pv = 20 and time='7-25' group by name,pv,time;
)

上面这条SQL是非常非常实用的,除了我说的去重以外,其实我们可以再”思考“一下:

  • 上面已经说了,使用group by 分组统计之后,我们的select 后面只能跟着group by 的字段,或者是聚合函数。
  • 很多时候我们group by 了以后,还想要查询结果中包含group by之外的字段(一般情况下,我们都不可能将group by 涵盖所有的字段),我们就可以上面那样,将查询后的结果作为子查询,放在外部查询的where 子句后,这样外部查询是可以select 出其他字段的。

(SQL写得比较少的朋友可能没什么感触啊,但我希望上面那种写法大家能够记住,以后一定会遇到类似的情况的)

二、回顾join查询

join查询不知道大家在刚学的时候是怎么理解的,反正我当初好像就挺迷迷糊糊的。我觉得join查询可以简单理解成这样:我想要的查询结果,一张表搞不掂,那我就join另一张表

比如说,现在我有两张的表:

第一张表

第二张表

现在我想知道在7月25号时:每个公众号的点击量、公众号名称、号主名称、公众号的创建日期

  • 显然,我们会发现一张表搞不掂啊,某些数据要依赖于另一张表才能把数据"完整"展示出来

那join其实就是把两张表合起来的一个操作:

join其实就是一个合并的操作

两张表合并起来以后我们就会发现,这张“大表”就含有这两张表的所有字段啦,那我想要什么都有了!

值得注意的是:在join的时候,会产生笛卡尔积(至于什么是笛卡尔积我这里就不说了,反正我们要记住的是join表时一定要写关联条件去除笛卡尔积

另外,left joinright join也是我们经常用到,如果我们单纯写join关键字,那会被当成是inner join 。下面我简单解释一下:

  • 上面说了,在join的时候一定要写关联条件,如果是inner join的话,只有符合关联条件的数据才会存在最大表中
  • 如果是left join的话,即便关联条件不符合,左边表的数据一定会存在大表中
  • 如果是right join的话,即便关联条件不符合,右边表的数据一定会存在大表中

看下面的图:

join

此时我们的两张表关联的条件是“公众号” :如果是inner join,那么最后我们的表只有两条记录。如果是left join ,那么最后我们的表有三条数据。如果是right join,那么我们最后的表只有两条数据

三、回顾case when

SQL中的case when then else end用法其实跟我们程序语言中的if-else很是类似,在写SQL的时候也常常会用到。

我用得比较多的语法如下:

CASE WHEN sex = '1' THEN '男'
         WHEN sex = '2' THEN '女'
ELSE '其他' END   

在when后面可以跟多个表达式,比如说:

CASE WHEN sex = '1' and name ='Java3y' THEN '男'
         WHEN sex = '2' and name ='Java4y' THEN '女'
ELSE '其他' END   

如果要为case when表达式取别名,在end 关键字后边直接加就好了

更多用法详情参考:

四、一些常用的函数

4.1 hive和presto解析json

我这边会有这种情况:将json数据存到MySQL上。我去网上搜了一下以及问了同事,为什么要将json存到MySQL的字段上时,他们的答复都差不多:

  • 在MySQL存json数据,这样方便扩展啊。如果那些字段不需要用到索引,改动比较频繁,你又不想改动表的结构,那可以存json。
  • ps:在MySQL 5.7版本以后支持json类型

参考资料:

我这边做报表一般来hive或presto上搞的,所以解析json的也是在那上面。

hive解析json函数:

get_json_object(param1,'$.param2')

-- 如果是数组
get_json_object(xjson,'$.[0].param2')

presto 对json的处理函数:

 -- 数组  (去除第index个json)
 json_array_get(xjson,index) 
 
 -- 单个jsoin对象
 json_extract(xjson,'$.param2')

参考资料:

4.2 时间函数

昨天/近7天/本月按照这种指标来查询也是非常常见的:

昨天

SELECT * FROM 表名 WHERE TO_DAYS( NOW( ) ) - TO_DAYS( 时间字段名) <= 1

7天

SELECT * FROM 表名 where DATE_SUB(CURDATE(), INTERVAL 7 DAY) <= date(时间字段名)

近30天

SELECT * FROM 表名 where DATE_SUB(CURDATE(), INTERVAL 30 DAY) <= date(时间字段名)

本月

SELECT * FROM 表名 WHERE DATE_FORMAT( 时间字段名, '%Y%m' ) = DATE_FORMAT( CURDATE( ) , '%Y%m' )

上一月

SELECT * FROM 表名 WHERE PERIOD_DIFF( date_format( now( ) , '%Y%m' ) , date_format( 时间字段名, '%Y%m' ) ) =1

在presto中使用时间格式,需要明确写出关键字timestamp,比如:

select supplier,count(id) 
from xxx_table 
where sendtime >= timestamp '2019-06-01' 

参考资料:

4.3 其他常用的函数

这里我简单整理一下我最近用过函数:

length  --计算字符串长度
concat  --连接两个字符串
substring -- 截取字符串
count   -- 统计数量
max   -- 最大
min   -- 最小
sum   -- 合计
floor/ceil  --...数学函数

再来分享一下最近遇到的一个需求,现在有的数据如下:

【Java3y简单】快乐学习
【Java3y简单】快乐学习渣渣
【Java3y通俗易懂】简单学
【Java3y通俗易懂】简单学芭芭拉
【Java3y平易近人】无聊学
【Java3y初学者】枯燥学
【Java3y初学者】枯燥学呱呱
【Java3y大数据】欣慰学
【Java3y学习】巴拉巴拉学
【Java3y学习】巴拉巴拉学哈哈
【Java3y好】雨女无瓜学

现在我统计出【】括号里边出现的频次,比如说:Java3y通俗易懂出现的频次是多少。当时一直都没想到好的思路,都快要搜“SQL 正则表达式 快速入门”了,请教了一下同事,同事很快就写出来了:

select substring_index(left(title , INSTR(title , '】') -1 ) , '【',-1) 
FROM `xxx_table`

哇~,awesome

最后

乐于输出干货的Java技术公众号:Java3y。公众号内有200多篇原创技术文章、海量视频资源、精美脑图,关注即可获取!

觉得我的文章写得不错,点

相关实践学习
每个IT人都想学的“Web应用上云经典架构”实战
本实验从Web应用上云这个最基本的、最普遍的需求出发,帮助IT从业者们通过“阿里云Web应用上云解决方案”,了解一个企业级Web应用上云的常见架构,了解如何构建一个高可用、可扩展的企业级应用架构。
MySQL数据库入门学习
本课程通过最流行的开源数据库MySQL带你了解数据库的世界。 &nbsp; 相关的阿里云产品:云数据库RDS MySQL 版 阿里云关系型数据库RDS(Relational Database Service)是一种稳定可靠、可弹性伸缩的在线数据库服务,提供容灾、备份、恢复、迁移等方面的全套解决方案,彻底解决数据库运维的烦恼。 了解产品详情:&nbsp;https://www.aliyun.com/product/rds/mysql&nbsp;
目录
相关文章
|
Linux C语言 C++
CentOS7安装gcc-5.4.0
CentoOS7 安装gcc
4290 0
CentOS7安装gcc-5.4.0
|
存储 缓存 流计算
Flink / Scala- BroadCast 广播流数据先到再处理 Source 数据
Flink 支持增加 DataStream KeyBy 之后 conncet BroadCastStream 形成 BroadConnectedStream,广播流内数据一般为不间断更新的上下文信息,这里介绍如果等待广播流初始化完毕再处理 Source 数据
1924 0
Flink / Scala- BroadCast 广播流数据先到再处理 Source 数据
|
SQL 存储 数据库连接
自动生成测试数据—数据库篇
自动生成测试数据—数据库篇
371 0
|
9月前
|
自然语言处理 开发者 容器
鸿蒙5开发宝藏案例分享---一多分栏开发实践
本文为HarmonyOS开发者提供多设备分栏布局的实用指南,介绍“一次开发,多端部署”的高效方案。通过Navigation和SidebarContainer组件,实现手机、折叠屏和平板的自动适配(单栏、双栏、三栏)。文章解析了邮箱、日历和智能客服等实战案例,分享代码技巧与避坑经验,并附赠自研响应式工具类。帮助开发者轻松搞定多端适配,提升开发效率!
抖音直播间刷屏打字发言脚本,全自动弹幕插件发广告插件,按键精灵智能防风控版
这是一款用于直播间批量发送弹幕信息的插件源码,可实现自动刷屏、虚拟欢迎与持续点赞功能。通过预设广告文字和随机话术,模拟真实用户行为以规避风控
|
前端开发 中间件 索引
鸿蒙开发:Navigation路由组件使用由繁入简
使用了插件和路由库之后,在每个Module下都会生成一个路由配置文件,以Module名字+RouterConfig为文件命名,此路由配置文件,也会在AbilityStage中,通过routerInitConfig方法进行自动配置。
298 8
|
存储 人工智能 数据处理
阿里云CTO周靖人:全面投入升级AI大基建
9月19日,在2024杭州云栖大会上,阿里云CTO周靖人表示,阿里云正在围绕AI时代,树立一个AI基础设施的新标准,全面升级从服务器到计算、存储、网络、数据处理、模型训练和推理平台的技术架构体系,让数据中心成为一台超级计算机,为每个AI和应用提供高性能、高效的算力服务。
23638 15
|
域名解析 网络协议 安全
【域名解析DNS专栏】云服务中的DNS解析服务比较:阿里云、AWS、Azure大PK
【5月更文挑战第23天】此对比分析探讨了阿里云DNS、AWS Route 53和Azure DNS的服务特点。阿里云DNS以其智能解析和IPv6支持脱颖而出,适合中国地区用户;AWS Route 53凭借其强大的路由策略和与AWS生态的深度集成吸引高级用户;Azure DNS则以简洁管理和DNSSEC安全支持见长,与Azure平台集成良好。选择取决于具体需求,如功能、易用性、性能、安全性和成本。
907 1
【域名解析DNS专栏】云服务中的DNS解析服务比较:阿里云、AWS、Azure大PK
|
存储 关系型数据库 分布式数据库
PolarDB,阿里云的云原生分布式数据库,以其存储计算分离架构为核心,解决传统数据库的扩展性问题
【7月更文挑战第3天】PolarDB,阿里云的云原生分布式数据库,以其存储计算分离架构为核心,解决传统数据库的扩展性问题。此架构让存储层专注数据可靠性,计算层专注处理SQL,提升性能并降低运维复杂度。通过RDMA加速通信,多副本确保高可用性。资源可独立扩展,便于成本控制。动态添加计算节点以应对流量高峰,展示了其灵活性。PolarDB的开源促进了数据库技术的持续创新和发展。
651 2
|
存储 安全 算法
静态路由与动态路由的区别及应用场景
【8月更文挑战第25天】
1582 0