SQL 大資料查詢如何進行優化？整理

原則,多數資料庫都是從 左到右的順序處理條件,把能過濾更多資料的條件放在前面,過濾少的條件放後面

SQL1: select * from employee

            where salary >1000     --條件1,過濾的資料較少

                 and   dept_id='01'    --條件2,過濾的資料比條件1多

上面的SQL就不符合我們的原則了,應該把過濾資料更多的條件放在前面,因此改為下面這樣更好

             select * from employee

              where   dept_id='01'     --過濾更多資料的條件放在前面

                  and   salary > 1000

在關係資料庫中，除在資料庫的物理設計、關係規範化等方面進行優化外，一個簡單直接有效的方法是對SQL語句進行調整，減少計算量和記憶體需求，提高響應速度。 
　　a.對同一表格進行多個選擇運算 
　　選擇條件的排列順序對效能有較大影響，因為不僅影響索引的選取，而且關係到臨時表的大小。現以下面的查詢語句為例進行說明： 
　　select * from customer 
　　where city=’beijing’ and fname=’li’ 
　　若表中存在100萬條記錄，其中city=’beijing’的10萬，fname=’li’的為2萬，其中city=’beijing’的 為2千，在SQL Server中，查詢條件的選取是從左到右使用的，因而，執行第一個條件結果返回一個10萬行的臨時表，然後再從中進行選擇，從而得到 最終結果。如果把選擇條件改為where fname=’li’ and city=’beijing’，則先得到一個2萬行的臨時表，再得到同樣的結 果。由此可見，選擇條件的選取極大的影響著查詢語句的計算量，所以，要提高查詢的響應速度，可以將較嚴格的條件寫在前面，較弱的條件放在後面。

集合30條

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

[email protected]
可以改為強制查詢使用索引：
select id from t with(index(索引名)) where [email protected]
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.儘量避免向客戶端返回大資料量，若資料量過大，應該考慮相應需求是否合理。

oracle良性SQL建議

（1）選擇最有效率的表名順序(只在基於規則的優化器中有效)： 
Oracle的解析器按照從右到左的順序處理FROM子句中的表名，FROM子句中寫在最後的表(基礎表 driving table)將被最先處理，在FROM子句中包含多個表的情況下,你必須選擇記錄條數最少的表作為基礎表。如果有3個以上的表連線查詢, 那就需要選擇交叉表(intersection table)作為基礎表, 交叉表是指那個被其他表所引用的表。
（2）WHERE子句中的連線順序： 
Oracle採用自下而上的順序解析WHERE子句,根據這個原理,表之間的連線必須寫在其他WHERE條件之前, 那些可以過濾掉最大數量記錄的條件必須寫在WHERE子句的末尾。 中.國.站長站
（3）SELECT子句中避免使用‘*’：
Oracle在解析的過程中, 會將‘*’依次轉換成所有的列名, 這個工作是通過查詢資料字典完成的, 這意味著將耗費更多的時間。
（4）減少訪問資料庫的次數：
Oracle在內部執行了許多工作: 解析SQL語句, 估算索引的利用率, 繫結變數 , 讀資料塊等。
（5）在SQL*Plus , SQL*Forms和Pro*C中重新設定ARRAYSIZE引數, 可以增加每次資料庫訪問的檢索資料量 ,建議值為200。
（6）使用DECODE函式來減少處理時間： 
使用DECODE函式可以避免重複掃描相同記錄或重複連線相同的表。 
（7）整合簡單,無關聯的資料庫訪問：
如果你有幾個簡單的資料庫查詢語句,你可以把它們整合到一個查詢中(即使它們之間沒有關係)。
（8）刪除重複記錄： 
最高效的刪除重複記錄方法 ( 因為使用了ROWID)例子： 
DELETE FROM EMP E WHERE E.ROWID > (SELECT MIN(X.ROWID) FROM EMP X WHERE X.EMP_NO = E.EMP_NO);
（9）用TRUNCATE替代DELETE： 
當刪除表中的記錄時,在通常情況下, 回滾段(rollback segments ) 用來存放可以被恢復的資訊. 如果你沒有COMMIT事務,ORACLE會將資料恢復到刪除之前的狀態(準確地說是恢復到執行刪除命令之前的狀況) 而當運用TRUNCATE時, 回滾段不再存放任何可被恢復的資訊。當命令執行後,資料不能被恢復.因此很少的資源被呼叫,執行時間也會很短。（TRUNCATE只在刪除全表適 用,TRUNCATE是DDL不是DML）。 Chinaz_com
（10）儘量多使用COMMIT：
只要有可能，在程式中儘量多使用COMMIT, 這樣程式的效能得到提高,需求也會因為COMMIT所釋放的資源而減少，COMMIT所釋放的資源:
a. 回滾段上用於恢復資料的資訊。
b. 被程式語句獲得的鎖。
c. redo log buffer 中的空間。 [email protected]
d. Oracle為管理上述3種資源中的內部花費。
（11）用Where子句替換HAVING子句： 
避免使用HAVING子句，HAVING 只會在檢索出所有記錄之後才對結果集進行過濾。這個處理需要排序,總計等操作。如果能通過WHERE子句限制記錄的數目，那就能減少這方面的開銷。(非 oracle中)on、where、having這三個都可以加條件的子句中，on是最先執行，where次之，having最後，因為on是先把不符合 條件的記錄過濾後才進行統計，它就可以減少中間運算要處理的資料，按理說應該速度是最快的，where也應該比having快點的，因為它過濾資料後才進 行sum，在兩個表聯接時才用on的，所以在一個表的時候，就剩下where跟having比較了。在這單表查詢統計的情況下，如果要過濾的條件沒有涉及 到要計算欄位，那它們的結果是一樣的，只是where可以使用rushmore技術，而having就不能，在速度上後者要慢如果要涉及到計算的欄位，就 表示在沒計算之前，這個欄位的值是不確定的，根據上篇寫的工作流程，where的作用時間是在計算之前就完成的，而having就是在計算後才起作用的， 所以在這種情況下，兩者的結果會不同。在多表聯接查詢時，on比where更早起作用。系統首先根據各個表之間的聯接條件，把多個表合成一個臨時表後，再 由where進行過濾，然後再計算，計算完後再由having進行過濾。由此可見，要想過濾條件起到正確的作用，首先要明白這個條件應該在什麼時候起作 用，然後再決定放在那裡。
（12）減少對錶的查詢： 
在含有子查詢的SQL語句中,要特別注意減少對錶的查詢。例子： Chinaz
SELECT TAB_NAME FROM TABLES WHERE (TAB_NAME,DB_VER) = ( SELECTTAB_NAME,DB_VER FROM TAB_COLUMNS WHERE VERSION = 604)
（13）通過內部函式提高SQL效率：
複雜的SQL往往犧牲了執行效率。能夠掌握上面的運用函式解決問題的方法在實際工作中是非常有意義的。 
（14）使用表的別名(Alias)： 
當在SQL語句中連線多個表時, 請使用表的別名並把別名字首於每個Column上。這樣一來,就可以減少解析的時間並減少那些由Column歧義引起的語法錯誤。 Chinaz_com
（15）用EXISTS替代IN、用NOT EXISTS替代NOT IN：
在許多基於基礎表的查詢中，為了滿足一個條件,往往需要對另一個表進行聯接。在這種情況下，使用EXISTS(或NOT EXISTS)通常將提高查詢的效率。在子查詢中，NOT IN子句將執行一個內部的排序和合並。無論在哪種情況下，NOT IN都是最低效的 (因為它對子查詢中的表執行了一個全表遍歷)。為了避免使用NOT IN ，我們可以把它改寫成外連線(Outer Joins)或NOT EXISTS。
例子： 
（高效）SELECT * FROM EMP (基礎表) WHERE EMPNO > 0 AND EXISTS (SELECT ‘X' FROM DEPT WHERE DEPT.DEPTNO = EMP.DEPTNO AND LOC = ‘MELB')(低效)SELECT * FROM EMP (基礎表) WHERE EMPNO > 0 AND DEPTNO IN(SELECT DEPTNO FROM DEPT WHERE LOC = ‘MELB')
（16）識別‘低效執行’的SQL語句：
雖然目前各種關於SQL優化的圖形化工具層出不窮,但是寫出自己的SQL工具來解決問題始終是一個最好的方法： 
SELECT EXECUTIONS , DISK_READS, BUFFER_GETS, ROUND((BUFFER_GETS-DISK_READS)/BUFFER_GETS,2) Hit_radio, ROUND(DISK_READS/EXECUTIONS,2) Reads_per_run, SQL_TEXT FROM V$SQLAREA WHERE EXECUTIONS>0 AND BUFFER_GETS > 0 AND (BUFFER_GETS-DISK_READS)/BUFFER_GETS < 0.8 ORDER BY 4 DESC;
索引是表的一個概念部分，用來提高檢索資料的效率，Oracle使用了一個複雜的自平衡B-tree結構。通常,通過索引查詢資料比全表掃描要快。當 Oracle找出執行查詢和Update語句的最佳路徑時, Oracle優化器將使用索引。同樣在聯結多個表時使用索引也可以提高效率。另一個使用索引的好處是,它提供了主鍵(primary key)的唯一性驗證。那些LONG或LONG RAW資料型別, 你可以索引幾乎所有的列。通常, 在大型表中使用索引特別有效. 當然,你也會發現, 在掃描小表時，使用索引同樣能提高效率。雖然使用索引能得到查詢效率的提高,但是我們也必須注意到它的代價。索引需要空間來儲存,也需要定期維護, 每當有記錄在表中增減或索引列被修改時, 索引本身也會被修改。這意味著每條記錄的INSERT，DELETE ， UPDATE將為此多付出4、 5次的磁碟I/O 。因為索引需要額外的儲存空間和處理，那些不必要的索引反而會使查詢反應時間變慢。定期的重構索引是有必要的：
ALTER INDEX <INDEXNAME> REBUILD <TABLESPACENAME>
（18）用EXISTS替換DISTINCT：
當提交一個包含一對多表資訊(比如部門表和僱員表)的查詢時，避免在SELECT子句中使用DISTINCT。一般可以考慮用EXIST替換， EXISTS 使查詢更為迅速，因為RDBMS核心模組將在子查詢的條件一旦滿足後，立刻返回結果。例子：
(低效): SELECT DISTINCT DEPT_NO,DEPT_NAME FROM DEPT D , EMP E WHERE D.DEPT_NO = E.DEPT_NO (高效): SELECT DEPT_NO,DEPT_NAME FROM DEPT D WHERE EXISTS ( SELECT ‘X' FROM EMP E WHERE E.DEPT_NO = D.DEPT_NO);
（19）SQL語句用大寫的；因為Oracle總是先解析SQL語句，把小寫的字母轉換成大寫的再執行。 
（20）在Java程式碼中儘量少用連線符“＋”連線字串。
（21）避免在索引列上使用NOT通常，我們要避免在索引列上使用NOT, NOT會產生在和在索引列上使用函式相同的影響。當Oracle“遇到”NOT,他就會停止使用索引轉而執行全表掃描。
（22）避免在索引列上使用計算。WHERE子句中，如果索引列是函式的一部分。優化器將不使用索引而使用全表掃描。
低效： SELECT … FROM DEPT WHERE SAL * 12 > 25000; 高效: SELECT … FROM DEPT WHERE SAL > 25000/12;
（23）用>=替代>：
高效：SELECT * FROM EMP WHERE DEPTNO >=4 低效: SELECT * FROM EMP WHERE DEPTNO >3
兩者的區別在於，前者DBMS將直接跳到第一個DEPT等於4的記錄而後者將首先定位到DEPTNO=3的記錄並且向前掃描到第一個DEPT大於3的記 錄。
（24）用UNION替換OR (適用於索引列)：
通常情況下，用UNION替換WHERE子句中的OR將會起到較好的效果。對索引列使用OR將造成全表掃描。注意，以上規則只針對多個索引列有效。如果有 column沒有被索引，查詢效率可能會因為你沒有選擇OR而降低。在下面的例子中，LOC_ID 和REGION上都建有索引。
高效：SELECT LOC_ID 。 LOC_DESC ，REGION FROM LOCATION WHERE LOC_ID = 10 UNION SELECT LOC_ID ，LOC_DESC ，REGION FROM LOCATION WHERE REGION = “MELBOURNE” 
低效: SELECT LOC_ID ，LOC_DESC ，REGION FROM LOCATION WHERE LOC_ID = 10 OR REGION = “MELBOURNE”
（25）用IN來替換OR： 
這是一條簡單易記的規則，但是實際的執行效果還須檢驗，在Oracle8i下，兩者的執行路徑似乎是相同的:　
低效:
SELECT…. FROM LOCATION WHERE LOC_ID = 10 OR LOC_ID = 20 OR LOC_ID = 30
高效：
SELECT… FROM LOCATION WHERE LOC_IN IN (10,20,30);
（26）避免在索引列上使用IS NULL和IS NOT NULL：
避免在索引中使用任何可以為空的列，Oracle將無法使用該索引。對於單列索引，如果列包含空值，索引中將不存在此記錄。對於複合索引，如果每個列都為 空，索引中同樣不存在此記錄。如果至少有一個列不為空，則記錄存在於索引中。舉例：如果唯一性索引建立在表的A列和B列上，並且表中存在一條記錄的A，B 值為(123，null)， Oracle將不接受下一條具有相同A，B值（123,null）的記錄(插入)。 然而如果所有的索引列都為空，Oracle將認為整個鍵值為空而空不等於空。因此你可以插入1000 條具有相同鍵值的記錄,當然它們都是空! 因為空值不存在於索引列中,所以WHERE子句中對索引列進行空值比較將使ORACLE停用該索引。
低效: (索引失效)
SELECT … FROM DEPARTMENT WHERE DEPT_CODE IS NOT NULL; 
高效：(索引有效) 
SELECT … FROM DEPARTMENT WHERE DEPT_CODE >=0; 站長.站
（27）總是使用索引的第一個列： 
如果索引是建立在多個列上，只有在它的第一個列(leading column)被where子句引用時，優化器才會選擇使用該索引。這也是一條簡單而重要的規則，當僅引用索引的第二個列時，優化器使用了全表掃描而忽略 了索引。 
（28）用UNION-ALL 替換UNION ( 如果有可能的話)：
當SQL語句需要UNION兩個查詢結果集合時，這兩個結果集合會以UNION-ALL的方式被合併，然後在輸出最終結果前進行排序。如果用UNION ALL替代UNION，這樣排序就不是必要了。效率就會因此得到提高。需要注意的是，UNION ALL 將重複輸出兩個結果集合中相同記錄。因此各位還是要從業務需求分析使用UNION ALL的可行性。 UNION 將對結果集合排序,這個操作會使用到SORT_AREA_SIZE這塊記憶體。對於這塊記憶體的優化也是相當重要的。下面的SQL可以用來查詢排序的消耗量： Www.Chinaz.com
低效： SELECT ACCT_NUM, BALANCE_AMT FROM DEBIT_TRANSACTIONS WHERE TRAN_DATE = '31-DEC-95' UNION SELECT ACCT_NUM, BALANCE_AMT FROM DEBIT_TRANSACTIONS WHERE TRAN_DATE = '31-DEC-95' 高效: SELECT ACCT_NUM, BALANCE_AMT FROM DEBIT_TRANSACTIONS WHERE TRAN_DATE = '31-DEC-95' UNION ALL SELECT ACCT_NUM, BALANCE_AMT FROM DEBIT_TRANSACTIONS WHERE TRAN_DATE = '31-DEC-95'
（29）用WHERE替代ORDER BY：
ORDER BY 子句只在兩種嚴格的條件下使用索引。
ORDER BY中所有的列必須包含在相同的索引中並保持在索引中的排列順序。 
ORDER BY中所有的列必須定義為非空。 
WHERE子句使用的索引和ORDER BY子句中所使用的索引不能並列。 
例如: 表DEPT包含以下列: 
DEPT_CODE PK NOT NULL 
DEPT_DESC NOT NULL
DEPT_TYPE NULL 
低效: (索引不被使用) 
SELECT DEPT_CODE FROM DEPT ORDER BY DEPT_TYPE
高效: (使用索引) 
SELECT DEPT_CODE FROM DEPT WHERE DEPT_TYPE > 0 
（30）避免改變索引列的型別: 
當比較不同資料型別的資料時， ORACLE自動對列進行簡單的型別轉換。 假設 EMPNO是一個數值型別的索引列：SELECT … FROM EMP WHERE EMPNO = ‘123'。 實際上,經過Oracle型別轉換, 語句轉化為: SELECT … FROM EMP WHERE EMPNO = TO_NUMBER(‘123') 。
幸運的是,型別轉換沒有發生在索引列上,索引的用途沒有被改變。現在,假設EMP_TYPE是一個字元型別的索引列：SELECT … FROM EMP WHERE EMP_TYPE = 123 。
這個語句被Oracle轉換為: SELECT … FROM EMP WHERETO_NUMBER(EMP_TYPE)=123。因為內部發生的型別轉換， 這個索引將不會被用到! 為了避免Oracle對你的SQL進行隱式的型別轉換，最好把型別轉換用顯式表現出來。注意當字元和數值比較時，Oracle會優先轉換數值型別到字元類 型。
（31）需要當心的WHERE子句: 
某些SELECT 語句中的WHERE子句不使用索引。這裡有一些例子：
(1)‘!=' 將不使用索引。記住, 索引只能告訴你什麼存在於表中, 而不能告訴你什麼不存在於表中。
(2)‘||'是字元連線函式。就象其他函式那樣, 停用了索引。 
(3)‘+'是數學函式。就象其他數學函式那樣, 停用了索引。 
(4)相同的索引列不能互相比較,這將會啟用全表掃描。 
（32）a. 如果檢索資料量超過30%的表中記錄數，使用索引將沒有顯著的效率提高。 
b. 在特定情況下，使用索引也許會比全表掃描慢，但這是同一個數量級上的區別。而通常情況下,使用索引比全表掃描要塊幾倍乃至幾千倍！
（33）避免使用耗費資源的操作：
帶有DISTINCT,UNION,MINUS,INTERSECT,ORDER BY的SQL語句會啟動SQL引擎執行耗費資源的排序(SORT)功能。DISTINCT需要一次排序操作，而其他的至少需要執行兩次排序。通常，帶有 UNION, MINUS , INTERSECT的SQL語句都可以用其他方式重寫。如果你的資料庫的SORT_AREA_SIZE調配得好。使用UNION , MINUS, INTERSECT也是可以考慮的, 畢竟它們的可讀性很強。
（34）優化GROUP BY：
提高GROUP BY 語句的效率，可以通過將不需要的記錄在GROUP BY 之前過濾掉。下面兩個查詢返回相同結果但第二個明顯就快了許多。
低效: SELECT JOB , AVG(SAL) FROM EMP GROUP JOB HAVING JOB = ‘PRESIDENT' OR JOB = ‘MANAGER' 高效: SELECT JOB , AVG(SAL) FROM EMP WHERE JOB = ‘PRESIDENT' OR JOB = ‘MANAGER' GROUP JOB