Sql

最近在写几个存储过程,对写SQL有了新的体会,记录点留个纪念

查询数据##

查询的时候先去查需要的,尽量少的数据,假如有基础信息表关联字段,放在最后关联,结论就是尽量减少废操作,也是SQL优化的一部分吧

ORDER BY##

操作一般是在最后才来排序,排序当然可以根据几个字段来,优先第一个字段,也可以将排序的每个字段给它一个指定顺序比如ORDER BY COLUMN1 ASC ,COLUMN2 DESC

GROUP BY##

GROUP BY 语句用于结合合计函数,根据一个或多个列对结果集进行分组;GROUP BY 是属于实际中可能用到分组的概念,比如按公司,按品牌,按销量等等,往往需要的是几个分组的情况, 涉及GROUP BY 都需要有聚合函数配合,所谓聚合就是SUM COUNT 等。GROUP BY 后面往往会跟HAVING ...的语句,这个其实是对分组后的结果进行过滤;

刚开始写GROUP BY 语句的时候经常会碰到,提示【选择列表中的列 'column 1' 无效,因为该列没有包含在聚合函数或 GROUP BY 子句中】,因为除了GROUP BY 后面字段以外的信息需要用聚合函数获取,假如确实有查别的数据的需要,可以用MAX()函数来筛选就不会报错了

OVER(PARTITION BY)函数介绍#

分析函数用于计算基于组的某种聚合值,它和聚合函数的不同之处是:对于每个组返回多行,而聚合函数对于每个组只返回一行

over(order by salary) 按照salary排序进行累计,order by是个默认的开窗函数

over(partition by deptno)按照部门分区

详情可以参考这里 OVER(PARTITION BY)函数介绍

该功能还是挺有用的,功能比较多,我筛选一个常用的rank()over(partition by class order by score desc)例子,这段sql就是筛选出每个班级中分数前三名的同学


select * from

(

select name,class,s,rank()over(partition by class order by score desc) mm from t2

)

where mm<=3

left join ,right join ,inner join, full join##

这些啥啥连接说起来名字花样很多,其实根本没必要被他瞎忽悠。首先关心第三个inner join 内连接,left join right join full join 就是把除了innerjoin以外左表 ,右表 ,左右表 多出来的数据多出来。总结五个字曝光单身狗。什么其他理论都是扯蛋!

经常有个理论是 先看清楚哪个是主表,left join 是 左表主表 right join 是右表主表,百度上也经常有人提出怎么A left join B 会查出超过单独查A的数据条数呢,感觉主表是A 查出来的应该不会超出数量。 这种也算是被主表这个概念误导了吧。

假如


select * from class a and student b  where a.tid=b.classid 

估计全知道结果,也不会有疑问(这个是查询所有班级和学生信息,没有学生的班级不会显示)


select * from class a inner join student b  on a.tid=b.classid

这个也没疑问 和上个一样


select * from class a left join student b  on a.tid=b.classid


select * from class a right join student b  on a.tid=b.classid


select * from class a full join student b  on a.tid=b.classid

这些可能会有疑问了,其实不管怎么个join法。全部分两步走,第一将它看成inner join 所有相关数据出来,再来看left 是A表没有再B表中找到对象的光棍显示出来。反之,RIGHT则是表B中的光棍显示出来。full呢,两边光棍都显示出来。(这个有点类似曝光单身狗!!!)

测试下你的理解能力,没学生的班级单身狗,没班级的学生单身狗,两者集合 这些单身狗分别曝光就是结果

多表关联标准SQL写法##


SELECT * FROM TABLE A

LEFT JOIN TABLE B ON A.XX=B.XX

LEFT JOIN TABLE C ON A.XX =C.XX

LEFT JOIN TABLE D ON  B.XX=C.XX

WHERE A.XX++++ 

AND B.XX++++ 

AND C.XX++++

GROUP BY XXXX

HAVING  XXXXXXXXX

ORDER BY XXXXXXXXXX

注意,其实where是对前面语句查询结果的进一步过滤。这点很重要!!!
总结:

先确认你要查那些表

关联的表字段用ON在后面修饰

将过滤条件都放在WHERE里面(你会发现其实筛选条件都是针对单表的)

你要分组吗 分组的话写下面(当然分组意味着有聚合函数,将开始的*改成你要的)

有需要的时候用HAVING将聚合结果进行筛选

将结果排序 怎么排 你怎么看着办
图片发自简书App
最后编辑于
©著作权归作者所有,转载或内容合作请联系作者
  • 序言:七十年代末,一起剥皮案震惊了整个滨河市,随后出现的几起案子,更是在滨河造成了极大的恐慌,老刑警刘岩,带你破解...
    沈念sama阅读 222,252评论 6 516
  • 序言:滨河连续发生了三起死亡事件,死亡现场离奇诡异,居然都是意外死亡,警方通过查阅死者的电脑和手机,发现死者居然都...
    沈念sama阅读 94,886评论 3 399
  • 文/潘晓璐 我一进店门,熙熙楼的掌柜王于贵愁眉苦脸地迎上来,“玉大人,你说我怎么就摊上这事。” “怎么了?”我有些...
    开封第一讲书人阅读 168,814评论 0 361
  • 文/不坏的土叔 我叫张陵,是天一观的道长。 经常有香客问我,道长,这世上最难降的妖魔是什么? 我笑而不...
    开封第一讲书人阅读 59,869评论 1 299
  • 正文 为了忘掉前任,我火速办了婚礼,结果婚礼上,老公的妹妹穿的比我还像新娘。我一直安慰自己,他们只是感情好,可当我...
    茶点故事阅读 68,888评论 6 398
  • 文/花漫 我一把揭开白布。 她就那样静静地躺着,像睡着了一般。 火红的嫁衣衬着肌肤如雪。 梳的纹丝不乱的头发上,一...
    开封第一讲书人阅读 52,475评论 1 312
  • 那天,我揣着相机与录音,去河边找鬼。 笑死,一个胖子当着我的面吹牛,可吹牛的内容都是我干的。 我是一名探鬼主播,决...
    沈念sama阅读 41,010评论 3 422
  • 文/苍兰香墨 我猛地睁开眼,长吁一口气:“原来是场噩梦啊……” “哼!你这毒妇竟也来了?” 一声冷哼从身侧响起,我...
    开封第一讲书人阅读 39,924评论 0 277
  • 序言:老挝万荣一对情侣失踪,失踪者是张志新(化名)和其女友刘颖,没想到半个月后,有当地人在树林里发现了一具尸体,经...
    沈念sama阅读 46,469评论 1 319
  • 正文 独居荒郊野岭守林人离奇死亡,尸身上长有42处带血的脓包…… 初始之章·张勋 以下内容为张勋视角 年9月15日...
    茶点故事阅读 38,552评论 3 342
  • 正文 我和宋清朗相恋三年,在试婚纱的时候发现自己被绿了。 大学时的朋友给我发了我未婚夫和他白月光在一起吃饭的照片。...
    茶点故事阅读 40,680评论 1 353
  • 序言:一个原本活蹦乱跳的男人离奇死亡,死状恐怖,灵堂内的尸体忽然破棺而出,到底是诈尸还是另有隐情,我是刑警宁泽,带...
    沈念sama阅读 36,362评论 5 351
  • 正文 年R本政府宣布,位于F岛的核电站,受9级特大地震影响,放射性物质发生泄漏。R本人自食恶果不足惜,却给世界环境...
    茶点故事阅读 42,037评论 3 335
  • 文/蒙蒙 一、第九天 我趴在偏房一处隐蔽的房顶上张望。 院中可真热闹,春花似锦、人声如沸。这庄子的主人今日做“春日...
    开封第一讲书人阅读 32,519评论 0 25
  • 文/苍兰香墨 我抬头看了看天上的太阳。三九已至,却和暖如春,着一层夹袄步出监牢的瞬间,已是汗流浃背。 一阵脚步声响...
    开封第一讲书人阅读 33,621评论 1 274
  • 我被黑心中介骗来泰国打工, 没想到刚下飞机就差点儿被人妖公主榨干…… 1. 我叫王不留,地道东北人。 一个月前我还...
    沈念sama阅读 49,099评论 3 378
  • 正文 我出身青楼,却偏偏与公主长得像,于是被迫代替她去往敌国和亲。 传闻我的和亲对象是个残疾皇子,可洞房花烛夜当晚...
    茶点故事阅读 45,691评论 2 361

推荐阅读更多精彩内容