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.盡量避免向客戶端返回大數據量，若數據量過大，應該考慮相應需求是否合理。