A. sql 以id为维度,选不重复的
Sql 以id为维度,选不重复信息如下列出SQL语句：
方案一：distinct
select distinct name from table
方案二：group by
select min(fid),name,sex from table group by name
方案三：
select * from table where name in(select name from table group by name having count(name)=2）
以上三个语句，能将sql数据库里不重复的信息筛选出来。
B. sql语句如何实现组合查询数据库中的数据如图：
1 建议不要把所有的逻辑都放到数据库端，包含词汇和不包含词汇都可以先进行信息处理，
如转换成 ‘词汇1’,‘词汇2’,'词汇3','词汇4' 这样的格式
然后用 sql 的 in 和 not in 子句
select * from t where keyword in ('a','b','c','d') and keyword not in ('e','r','f','g');
2 不处理的话也可以实现，参照以下sql 语句：
1 select * from t
2 where
3 (&k1 is null or (keyword =&k1))
4 and (&k2 is null or (keyword =&k2))
说明：
第2行：如果输入变量 k1 为空，则条件 keyword =&k1 就不起作用；反之 k1不为空 keyword =&k1 条件就有效
建议采用第一种方式处理
C. sql中，不同维度的相同度量行转列，我试了不用join得不到结果，有高手不用join，一个sql，可以解决吗
既然JOIN能通过，那么必然有不用JOIN的方法。
下面不用JOIN，一句SQL语句解决。
select t1.file1 as 公司,t1.file2 as 项目,t1.file3 as 工程师类别,
t1.Q1 as 工程师类别维度工程师数,
t2.Q2 as 项目维度工程师数 from
(select file1,file2,file3,count(*) as Q1 from 表名 group by file1,file2,file3)t1,
(select file1,file2 ,count(*) as Q2 from 表名 group by file1,file2)t2
where t1.file1=t2.file1 and t1.file2=t2.file2
order by t1.file1,t1.file2,t1.file3
如果我没有正确理解你的意图，请告诉我，我重新编写代码。
D. sql 查询 表1 和表2组合查询
select 表1.名称 & 表2.名称 as 组合名称 from 表1,表2 where 表1.类型=1 and 表2.类型=表1.类型
E. SQL server 中多条件组合查询
因为你没说a,b,c的数据类型，我就替你假设一下
a：数字类型 默认值为null
b：字符类型 默认值为字符串空''
c：日期类型 默认值为null
那么语句如下：
select
*
from
table1
where
col1=isnull(a,col1)
andcol2like'%b%'
andcol3>=isnull(c,col3)
F. 数据分析课程笔记 - 19 - HiveSQL 常用优化技巧
大家好呀，这节课学习 HiveSQL 的常用优化技巧。由于 Hive 主要用来处理非常大的数据，运行过程由于通常要经过 MapRece 的过程，因此不像 MySQL 一样很快出结果。而使用不同方法写出来的 HiveSQL 语句执行效率也是不一样的，因此为了减少等待的时间，提高服务器的运行效率，我们需要在 HiveSQL 的语句上进行一些优化。
本节课的主要内容 ：
引言
1、技巧一：列裁剪和分区裁剪
（1）列裁剪
（2）分区裁剪
2、技巧二：排序技巧——sort by代替order by
3、技巧三：去重技巧——用group by来替换distinct
4、技巧四：聚合技巧——grouping sets、cube、rollup
（1）grouping sets
（2）cube
（3）rollup
5、技巧五：换个思路解题
6、技巧六：union all时可以开启并发执行
7、技巧七：表连接优化
8、技巧八：遵循严格模式
Hive 作为大数据领域常用的数据仓库组件，在平时设计和查询时要特别注意效率。影响Hive效率的几乎从不是数据量过大，而是数据倾斜、数据冗余、job 或 I/O 过多、MapRece 分配不合理等等。对 Hive 的调优既包含对HiveSQL 语句本身的优化，也包含 Hive 配置项和 MR 方面的调整。
列裁剪就是在查询时只读取需要的列。当列很多或者数据量很大时，如果select 所有的列或者不指定分区，导致的全表扫描和全分区扫描效率都很低。Hive中与列裁剪优化相关的配置项是 hive.optimize.cp ，默认是 true 。
分区裁剪就是在查询时只读需要的分区。Hive中与分区裁剪优化相关的则是 hive.optimize.pruner ，默认是 true 。
HiveSQL中的 order by 与其他 SQL 语言中的功能一样，就是将结果按某个字段全局排序，这会导致所有map端数据都进入一个 rece 中，在数据量大时可能会长时间计算不完。
如果使用 sort by ，那么就会视情况启动多个 recer 进行排序，并且保证每个 recer 内局部有序。为了控制 map 端数据分配到 rece 的 key，往往还要配合 distribute by 一同使用。如果不加 distribute by 的话，map 端数据就会随机分配给 recer。
这里需要解释一下， distribute by 和 sort by 结合使用是如何相较于 order by 提升运行效率的。
假如我们要对一张很大的用户信息表按照年龄进行分组，优化前的写法是直接 order by age 。使用 distribute by 和 sort by 结合进行优化的时候， sort by 后面还是 age 这个排序字段， distribute by 后面选择一个没有重复值的均匀字段，比如 user_id 。
这样做的原因是，通常用户的年龄分布是不均匀的，比如20岁以下和50岁以上的人非常少，中间几个年龄段的人又非常多，在 Map 阶段就会造成有些任务很大，有些任务很小。那通过 distribute by 一个均匀字段，就可以让系统均匀地进行“分桶”，对每个桶进行排序，最后再组合，这样就能从整体上提升 MapRece 的效率。
取出 user_trade 表中全部支付用户：
原有写法的执行时长：
优化写法的执行时长：
考虑对之前的案例进行优化：
注意： 在极大的数据量（且很多重复值）时，可以先 group by 去重，再 count() 计数，效率高于直接 count(distinct **) 。
如果我们想知道用户的性别分布、城市分布、等级分布，你会怎么写？
通常写法：
缺点 ：要分别写三次SQL，需要执行三次，重复工作，且费时。
那该怎么优化呢？
注意 ：这个聚合结果相当于纵向地堆在一起了（Union all），分类字段用不同列来进行区分，也就是每一行数据都包含 4 列，前三列是分类字段，最后一列是聚合计算的结果。
GROUPING SETS() ：在 group by 查询中，根据不同的维度组合进行聚合，等价于将不同维度的 group by 结果集进行 union all。聚合规则在括号中进行指定。
如果我们想知道用户的性别分布以及每个性别的城市分布，你会怎么写？
那该怎么优化呢？
注意： 第二列为NULL的，就是性别的用户分布，其余有城市的均为每个性别的城市分布。
cube：根据 group by 维度的所有组合进行聚合
注意 ：跑完数据后，整理很关键！！！
rollup：以最左侧的维度为主，进行层级聚合，是cube的子集。
如果我想同时计算出，每个月的支付金额，以及每年的总支付金额，该怎么办？
那应该如何优化呢？
条条大路通罗马，写SQL亦是如此，能达到同样效果的SQL有很多种，要学会思路转换，灵活应用。
来看一个我们之前做过的案例：
有没有别的写法呢？
Hive 中互相没有依赖关系的 job 间是可以并行执行的，最典型的就是
多个子查询union all。在集群资源相对充足的情况下，可以开启并
行执行。参数设置： set hive.exec.parallel=true;
时间对比：
所谓严格模式，就是强制不允许用户执行3种有风险的 HiveSQL 语句，一旦执行会直接报错。
要开启严格模式，需要将参数 hive.mapred.mode 设为 strict 。
好啦，这节课的内容就是这些。以上优化技巧需要大家在平时的练习和使用中有意识地去注意自己的语句，不断改进，就能掌握最优的写法。
G. 请教高手指点一下SQL多表组合查询的语句
一个班只能有一个班主任啊！
如果查询的学生在多个班时，应该对应有多个班主任！
可以通过命令distinct完成。条件如下：
select (distinct) T3.*,T2.班级名称
from 学生表 T1, 班级表 T2, 教师表 T3
where T1.班级ID =T2.ID
AND T2.班主任教师ID = T3.ID
AND T1.姓名="口口口"(或者 AND T1.姓名 like "王XX")
H. sql多表关联查询
用SELECT对多表关联进行查询。
I. sql 一张表 组合查询急急急！！！！！！！
是按合计工资排名次吧？我能想到的方法就是用子查询了
select Emp_id, 基本工资,工龄工资, 基本工资+工龄工资 as合计,(select count(*)+1 from Wages where 基本工资+工龄工资>a.基本工资+a.工龄工资)
from Wages a
如果有合计工资相同的，这些相同的名次是一样的，比如合计工资最多的有两个，那么这两个名次都是1，比这两个少的就从3开始排名了。
J. 数据量大,维度多怎么sql做查询，
1.对查询进行优化，应尽量避免全表扫描，首先应考虑在 where 及 order by 涉及的列上建立索引。
2.应尽量避免在 where 子句中对字段进行 null 值判断，否则将导致引擎放弃使用索引而进行全表扫描，如：
select id from t where num is null
可以在num上设置默认值0，确保表中num列没有null值，然后这样查询：
select id from t where num=0
3.应尽量避免在 where 子句中使用!=或<>操作符，否则将引擎放弃使用索引而进行全表扫描。
4.应尽量避免在 where 子句中使用 or 来连接条件，否则将导致引擎放弃使用索引而进行全表扫描，如：
select id from t where num=10 or num=20
可以这样查询：
select id from t where num=10
union all
select id from t where num=20
5.in 和 not in 也要慎用，否则会导致全表扫描，如：
select id from t where num in(1,2,3)
对于连续的数值，能用 between 就不要用 in 了：
select id from t where num between 1 and 3
6.下面的查询也将导致全表扫描：
select id from t where name like '%abc%'
若要提高效率，可以考虑全文检索。
7.如果在 where 子句中使用参数，也会导致全表扫描。因为SQL只有在运行时才会解析局部变量，但优化程序不能将访问计划的选择推迟到运行时；它必须在编译时进行选择。然而，如果在编译时建立访问计划，变量的值还是未知的，因而无法作为索引选择的输入项。如下面语句将进行全表扫描：
select id from t where num=@num
可以改为强制查询使用索引：
select id from t with(index(索引名)) where num=@num
8.应尽量避免在 where 子句中对字段进行表达式操作，这将导致引擎放弃使用索引而进行全表扫描。如：
select id from t where num/2=100
应改为:
select id from t where num=100*2
9.应尽量避免在where子句中对字段进行函数操作，这将导致引擎放弃使用索引而进行全表扫描。如：
select id from t where substring(name,1,3)='abc'--name以abc开头的id
select id from t where datediff(day,createdate,'2005-11-30')=0--‘2005-11-30’生成的id
应改为:
select id from t where name like 'abc%'
select id from t where createdate>='2005-11-30' and createdate<'2005-12-1'
10.不要在 where 子句中的“=”左边进行函数、算术运算或其他表达式运算，否则系统将可能无法正确使用索引。
11.在使用索引字段作为条件时，如果该索引是复合索引，那么必须使用到该索引中的第一个字段作为条件时才能保证系统使用该索引，否则该索引将不会被使用，并且应尽可能的让字段顺序与索引顺序相一致。
12.不要写一些没有意义的查询，如需要生成一个空表结构：
select col1,col2 into #t from t where 1=0
这类代码不会返回任何结果集，但是会消耗系统资源的，应改成这样：
create table #t(...)
13.很多时候用 exists 代替 in 是一个好的选择：
select num from a where num in(select num from b)
用下面的语句替换：
select num from a where exists(select 1 from b where num=a.num)
14.并不是所有索引对查询都有效，SQL是根据表中数据来进行查询优化的，当索引列有大量数据重复时，SQL查询可能不会去利用索引，如一表中有字段sex，male、female几乎各一半，那么即使在sex上建了索引也对查询效率起不了作用。
15.索引并不是越多越好，索引固然可以提高相应的 select 的效率，但同时也降低了 insert 及 update 的效率，因为 insert 或 update 时有可能会重建索引，所以怎样建索引需要慎重考虑，视具体情况而定。一个表的索引数最好不要超过6个，若太多则应考虑一些不常使用到的列上建的索引是否有必要。
16.应尽可能的避免更新 clustered 索引数据列，因为 clustered 索引数据列的顺序就是表记录的物理存储顺序，一旦该列值改变将导致整个表记录的顺序的调整，会耗费相当大的资源。若应用系统需要频繁更新 clustered 索引数据列，那么需要考虑是否应将该索引建为 clustered 索引。
17.尽量使用数字型字段，若只含数值信息的字段尽量不要设计为字符型，这会降低查询和连接的性能，并会增加存储开销。这是因为引擎在处理查询和连接时会逐个比较字符串中每一个字符，而对于数字型而言只需要比较一次就够了。
18.尽可能的使用 varchar/nvarchar 代替 char/nchar ，因为首先变长字段存储空间小，可以节省存储空间，其次对于查询来说，在一个相对较小的字段内搜索效率显然要高些。
19.任何地方都不要使用 select * from t ，用具体的字段列表代替“*”，不要返回用不到的任何字段。
20.尽量使用表变量来代替临时表。如果表变量包含大量数据，请注意索引非常有限（只有主键索引）。
21.避免频繁创建和删除临时表，以减少系统表资源的消耗。
22.临时表并不是不可使用，适当地使用它们可以使某些例程更有效，例如，当需要重复引用大型表或常用表中的某个数据集时。但是，对于一次性事件，最好使用导出表。
23.在新建临时表时，如果一次性插入数据量很大，那么可以使用 select into 代替 create table，避免造成大量 log ，以提高速度；如果数据量不大，为了缓和系统表的资源，应先create table，然后insert。
24.如果使用到了临时表，在存储过程的最后务必将所有的临时表显式删除，先 truncate table ，然后 drop table ，这样可以避免系统表的较长时间锁定。
25.尽量避免使用游标，因为游标的效率较差，如果游标操作的数据超过1万行，那么就应该考虑改写。
26.使用基于游标的方法或临时表方法之前，应先寻找基于集的解决方案来解决问题，基于集的方法通常更有效。
27.与临时表一样，游标并不是不可使用。对小型数据集使用 FAST_FORWARD 游标通常要优于其他逐行处理方法，尤其是在必须引用几个表才能获得所需的数据时。在结果集中包括“合计”的例程通常要比使用游标执行的速度快。如果开发时间允许，基于游标的方法和基于集的方法都可以尝试一下，看哪一种方法的效果更好。
28.在所有的存储过程和触发器的开始处设置 SET NOCOUNT ON ，在结束时设置 SET NOCOUNT OFF 。无需在执行存储过程和触发器的每个语句后向客户端发送 DONE_IN_PROC 消息。
29.尽量避免大事务操作，提高系统并发能力。
30.尽量避免向客户端返回大数据量，若数据量过大，应该考虑相应需求是否合理。