zoukankan      html  css  js  c++  java
  • 问题消灭机

    .distinct 的详细用法?是否只对第一个字段起作用?

    -->

    distinct用于select 后,需要查询的字段左,用于过滤重复记录,

    影响查询结果的并不只是最靠近它的那个字段,而是select后的所有字段

    例如有这么一个表#temp

    type name

    0      a

    0      a

    1      c

    0      d

    如果查询 select distinct type from #temp  会返回2行结果集

    type

    0

    1

    如果查询 select distinct type,name from #temp  会返回3行结果集

    type name

    0      a

    1      c

    0      d

    总结为:distinct 会筛选掉 column1+column2+……+columnN 中的重复数据

    显然通常情况下查询的列越少,结果集的行数也越少

    .Exist的详细用法?目前只知道它返回的是bool,并且效率上比较快

    -->

    .Left Join ,Right Join,Inner Join,Join 的具体区别?

    -->

    有这两个表

    drop table book
    create table book
    (
         id int identity(1,1) primary key,
         name varchar(100),
         booktype int references booktype(id) 
    )
    drop table booktype
    create table booktype
    (
        id int identity(1,1) primary key,
        typename varchar(100),
    )

    http://dl.iteye.com/upload/picture/pic/104062/678662f1-689d-3af4-9be9-310497e33e88.png

    --left join  会返回左表的所有行,以及匹配条件的右表行,不匹配的显示为null

    select a.id 书id,a.name 书名,b.typename 类型名
    from book a
    left join booktype b on b.id=a.booktype

     http://dl.iteye.com/upload/picture/pic/104054/d6b97276-4360-3978-a648-b43cdfdac33a.png

    --right join 会返回右表的所有行,以及匹配条件的左表行,不匹配的显示为null

    http://dl.iteye.com/upload/picture/pic/104058/9daa1d77-eeab-3fd6-bc2a-d01462cc9dc9.png

    --join 只返回符合匹配条件的所有行

     http://dl.iteye.com/upload/picture/pic/104056/d6372728-4302-3ca1-bfa6-a10d31ed50ef.png

    --inner join 在此例子中,查询结果和join没什么区别

    --full join 返回左表和右表的所有行,不匹配的部分显示null

    http://dl.iteye.com/upload/picture/pic/104060/80198a3e-a9ee-3dfb-b50b-ed5846ac7e12.png

    .多个表连接时,此时"left join"的"left"表是指主表还是左边那个表?

    -->

    初步觉得应该"on" 后的那个表

    有待检验

    .在使用Group by 时,通常不需要汇总的字段都要写在Group by 后面,

    那么,那些字段的先后顺序是否会对查询结果造成影响?

    以下是从网上找来的答案,觉得能解开一部分疑惑:

    写道
    在SQL中使用GROUP BY来对SELECT的结果进行数据分组,在具体使用GROUP BY之前需要知道一些重要的规定。

    •GROUP BY子句可以包含任意数目的列。也就是说可以在组里再分组,为数据分组提供更细致的控制。
    如果在GROUP BY子句中指定多个分组,数据将在最后指定的分组上汇总。
    •GROUP BY子句中列出的每个列都必须是检索列或有效的表达式(但不能是聚集函数)。如果在SELECT中使用了表达式,则必须在GROUP BY子句中指定相同的表达式。不能使用别名。
    •出了聚集计算语句外,SELECT语句中的每一列都必须在GROUP BY子句中给出。
    •如果分组列中有NULL值,则NULL将作为一个分组返回。如果有多行NULL值,它们将分为一组。
    •GROUP BY子句必须在WHERE子句之后,ORDER BY之前。
    过滤分组
    对分组过于采用HAVING子句。HAVING子句支持所有WHERE的操作。
    HAVING与WHERE的区别在于WHERE是过滤行的,而HAVING是用来过滤分组。

    另一种理解WHERE与HAVING的区别的方法是,WHERE在分组之前过滤,而HAVING在分组之后以每组为单位过滤。

    分组与排序
    一般在使用GROUP BY子句时,也应该使用ORDER BY子句。这是保证数据正确排序的唯一方法。

    SQL SELECT语句的执行顺序:

    1.from子句组装来自不同数据源的数据;
    2.where子句基于指定的条件对记录行进行筛选;
    3.group by子句将数据划分为多个分组;
    4.使用聚集函数进行计算;
    5.使用having子句筛选分组;
    6.计算所有的表达式;
    7.使用order by对结果集进行排序;
    8.select 集合输出。
    举个例子吧。 

    select 考生姓名, max(总成绩) as max总成绩
    from tb_Grade
    where 考生姓名 is not null
    group by 考生姓名
    having max(总成绩) > 600
    order by max总成绩

    在上面的示例中 SQL 语句的执行顺序如下:

    1.首先执行 FROM 子句, 从 tb_Grade 表组装数据源的数据
    2.执行 WHERE 子句, 筛选 tb_Grade 表中所有数据不为 NULL 的数据
    3.执行 GROUP BY 子句, 把 tb_Grade 表按 "学生姓名" 列进行分组
    4.计算 max() 聚集函数, 按 "总成绩" 求出总成绩中最大的一些数值
    5.执行 HAVING 子句, 筛选课程的总成绩大于 600 分的.
    6.执行 ORDER BY 子句, 把最后的结果按 "Max 成绩" 进行排序.

     <!-- 本文来源于 简明现代魔法 http://www.nowamagic.net/ ,转载请务必注明出处 -->

    以上只解决了一部分疑问,关于group by后的字段的次序问题还没得到解决

    于是自己动手建了两个表,写了几个sql

    1).两个表的源数据

     

    2).次序1

    3).次序2

    4).次序3

    5).group by 后定义三个分组字段

    6).group by 后定义两个分组字段 

     

    得出结论:
    1).在group by 后的字段及数目完全相同的情况下,
    改变字段的次序,不会影响查询结果,只会影响到排序情况,

    即按照最靠近group by的那个字段来排序
    2).当增、减group by后的字段时,会影响结果集行数

    .什么时候使用子查询?(单个字段)不同的方式的表连接,得到的结果集行数

     

     

    .Not in 怎么用?是否可以用于整个结果集的比较?

     

  • 相关阅读:
    Do You See Me? Ethical Considerations of the Homeless
    ELDER HOMELESSNESS WHY IS THIS AN ISSUE?
    Endoflife support is lacking for homeless people
    html内联框架
    html字体
    html块 div span
    html列表
    html表格
    SQL Server管理员专用连接的使用   作为一名DBA,经常会处理一些比较棘手的服务无响应问题,鉴于事态的严重性,多数DBA可能直接用“重启”大法,以便尽快的恢复生产环境的正常运转,但是多数情况
    如何配置最大工作线程数 (SQL Server Management Studio)
  • 原文地址:https://www.cnblogs.com/xcxcxcxc/p/5541179.html
Copyright © 2011-2022 走看看