『壹』 Mysql隨機查詢優化問題，怎麼解決
（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)
（10） 盡量多使用COMMIT：
只要有可能,在程序中盡量多使用COMMIT, 這樣程序的性能得到提高,需求也會因為COMMIT所釋放的資源而減少:
COMMIT所釋放的資源:
a. 回滾段上用於恢復數據的信息.
b. 被程序語句獲得的鎖
c. redo log buffer 中的空間
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語句中,要特別注意減少對表的查詢.例子：
SELECT TAB_NAME FROM TABLES WHERE (TAB_NAME,DB_VER) = ( SELECT
TAB_NAME,DB_VER FROM TAB_COLUMNS WHERE VERSION = 604)
（13） 通過內部函數提高SQL效率.：
復雜的SQL往往犧牲了執行效率. 能夠掌握上面的運用函數解決問題的方法在實際工作中是非常有意義的
（14） 使用表的別名(Alias)：
當在SQL語句中連接多個表時, 請使用表的別名並把別名前綴於每個Column上.這樣一來,就可以減少解析的時間並減少那些由Column歧義引起的語法錯誤.
（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;
（17） 用索引提高效率：
索引是表的一個概念部分,用來提高檢索數據的效率，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」
如果你堅持要用OR, 那就需要返回記錄最少的索引列寫在最前面.
（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可以用來查詢排序的消耗量
低效：
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 by JOB
HAVING JOB = 『PRESIDENT'
OR JOB = 『MANAGER'
高效:
SELECT JOB , AVG(SAL)
FROM EMP
WHERE JOB = 『PRESIDENT'
OR JOB = 『MANAGER'
GROUP by JOB
『貳』 MySQL 對於千萬級的大表要怎麼優化
第一優化你的sql和索引；
第二加緩存，memcached,redis；
第三以上都做了後，還是慢，就做主從復制或主主復制，讀寫分離，可以在應用層做，效率高，也可以用三方工具，第三方工具推薦360的atlas,其它的要麼效率不高，要麼沒人維護；
第四如果以上都做了還是慢，不要想著去做切分，mysql自帶分區表，先試試這個，對你的應用是透明的，無需更改代碼,但是sql語句是需要針對分區表做優化的，sql條件中要帶上分區條件的列，從而使查詢定位到少量的分區上，否則就會掃描全部分區，另外分區表還有一些坑，在這里就不多說了；
第五如果以上都做了，那就先做垂直拆分，其實就是根據你模塊的耦合度，將一個大的系統分為多個小的系統，也就是分布式系統；
第六才是水平切分，針對數據量大的表，這一步最麻煩，最能考驗技術水平，要選擇一個合理的sharding key,為了有好的查詢效率，表結構也要改動，做一定的冗餘，應用也要改，sql中盡量帶sharding key，將數據定位到限定的表上去查，而不是掃描全部的表；
mysql資料庫一般都是按照這個步驟去演化的，成本也是由低到高；
有人也許要說第一步優化sql和索引這還用說嗎？的確，大家都知道，但是很多情況下，這一步做的並不到位，甚至有的只做了根據sql去建索引，根本沒對sql優化（中槍了沒？），除了最簡單的增刪改查外，想實現一個查詢，可以寫出很多種查詢語句，不同的語句，根據你選擇的引擎、表中數據的分布情況、索引情況、資料庫優化策略、查詢中的鎖策略等因素，最終查詢的效率相差很大；優化要從整體去考慮，有時你優化一條語句後，其它查詢反而效率被降低了，所以要取一個平衡點；即使精通mysql的話，除了純技術面優化，還要根據業務面去優化sql語句，這樣才能達到最優效果；你敢說你的sql和索引已經是最優了嗎?
再說一下不同引擎的優化，myisam讀的效果好，寫的效率差，這和它數據存儲格式，索引的指針和鎖的策略有關的，它的數據是順序存儲的（innodb數據存儲方式是聚簇索引），他的索引btree上的節點是一個指向數據物理位置的指針，所以查找起來很快，（innodb索引節點存的則是數據的主鍵，所以需要根據主鍵二次查找）；myisam鎖是表鎖，只有讀讀之間是並發的，寫寫之間和讀寫之間（讀和插入之間是可以並發的，去設置concurrent_insert參數，定期執行表優化操作，更新操作就沒有辦法了）是串列的，所以寫起來慢，並且默認的寫優先順序比讀優先順序高，高到寫操作來了後，可以馬上插入到讀操作前面去，如果批量寫，會導致讀請求餓死，所以要設置讀寫優先順序或設置多少寫操作後執行讀操作的策略;myisam不要使用查詢時間太長的sql，如果策略使用不當，也會導致寫餓死，所以盡量去拆分查詢效率低的sql,
innodb一般都是行鎖，這個一般指的是sql用到索引的時候，行鎖是加在索引上的，不是加在數據記錄上的，如果sql沒有用到索引，仍然會鎖定表,mysql的讀寫之間是可以並發的，普通的select是不需要鎖的，當查詢的記錄遇到鎖時，用的是一致性的非鎖定快照讀，也就是根據資料庫隔離級別策略，會去讀被鎖定行的快照，其它更新或加鎖讀語句用的是當前讀，讀取原始行；因為普通讀與寫不沖突，所以innodb不會出現讀寫餓死的情況，又因為在使用索引的時候用的是行鎖，鎖的粒度小，競爭相同鎖的情況就少，就增加了並發處理，所以並發讀寫的效率還是很優秀的，問題在於索引查詢後的根據主鍵的二次查找導致效率低；
ps:很奇怪，為什innodb的索引葉子節點存的是主鍵而不是像mysism一樣存數據的物理地址指針嗎？如果存的是物理地址指針不就不需要二次查找了嗎，這也是我開始的疑惑，根據mysism和innodb數據存儲方式的差異去想，你就會明白了，我就不費口舌了！
所以innodb為了避免二次查找可以使用索引覆蓋技術，無法使用索引覆蓋的，再延伸一下就是基於索引覆蓋實現延遲關聯；不知道什麼是索引覆蓋的，建議你無論如何都要弄清楚它是怎麼回事！
盡你所能去優化你的sql吧！說它成本低，卻又是一項費時費力的活，需要在技術與業務都熟悉的情況下，用心去優化才能做到最優，優化後的效果也是立竿見影的！
『叄』 mysql 優化包括哪些內容
mysql的優化大的有兩方面：
1、配置優化
配置的優化其實包含兩個方面的：操作系統內核的優化和mysql配置文件的優化
1)系統內核的優化對專用的mysql伺服器來說，無非是內存實用、連接數、超時處理、TCP處理等方面的優化，根據自己的硬體配置來進行優化，這里不多講；
2)mysql配置的優化，一般來說包含：IO處理的常用參數、最大連接數設置、緩存使用參數的設置、慢日誌的參數的設置、innodb相關參數的設置等，如果有主從關系在設置主從同步的相關參數即可，網上的相關配置文件很多，大同小異，常用的設置大多修改這些差不多就夠用了。
2、sql語句的優化
1、 盡量稍作計算
Mysql的作用是用來存取數據的，不是做計算的，做計算的話可以用其他方法去實現，mysql做計算是很耗資源的。
2.盡量少 join
MySQL 的優勢在於簡單，但這在某些方面其實也是其劣勢。MySQL 優化器效率高，但是由於其統計信息的量有限，優化器工作過程出現偏差的可能性也就更多。對於復雜的多表 Join，一方面由於其優化器受限，再者在 Join 這方面所下的功夫還不夠，所以性能表現離 Oracle 等關系型資料庫前輩還是有一定距離。但如果是簡單的單表查詢，這一差距就會極小甚至在有些場景下要優於這些資料庫前輩。
3.盡量少排序
排序操作會消耗較多的 CPU 資源，所以減少排序可以在緩存命中率高等 IO 能力足夠的場景下會較大影響 SQL的響應時間。
對於MySQL來說，減少排序有多種辦法，比如：
通過利用索引來排序的方式進行優化
減少參與排序的記錄條數
非必要不對數據進行排序
4.盡量避免 select *
在數據量少並且訪問量不大的情況下，select * 沒有什麼影響，但是量級達到一定級別的時候，在執行效率和IO資源的使用上，還是有很大關系的，用什麼欄位取什麼欄位，減少不必要的資源浪費。
之前遇到過因為一個欄位存儲的數據比較大，並發高的情況下把網路帶寬跑滿的情況，造成網站打不開或是打開速度極慢的情況。
5.盡量用 join 代替子查詢
雖然 Join 性能並不佳，但是和 MySQL 的子查詢比起來還是有非常大的性能優勢。MySQL 的子查詢執行計劃一直存在較大的問題，雖然這個問題已經存在多年，但是到目前已經發布的所有穩定版本中都普遍存在，一直沒有太大改善。雖然官方也在很早就承認這一問題，並且承諾盡快解決，但是至少到目前為止我們還沒有看到哪一個版本較好的解決了這一問題。
6.盡量少 or
當 where 子句中存在多個條件以「或」並存的時候，MySQL 的優化器並沒有很好的解決其執行計劃優化問題，再加上 MySQL 特有的 SQL 與 Storage 分層架構方式，造成了其性能比較低下，很多時候使用 union all 或者是union(必要的時候)的方式來代替「or」會得到更好的效果。
7.盡量用 union all 代替 union
union 和 union all 的差異主要是前者需要將兩個(或者多個)結果集合並後再進行唯一性過濾操作，這就會涉及到排序，增加大量的 CPU 運算，加大資源消耗及延遲。所以當我們可以確認不可能出現重復結果集或者不在乎重復結果集的時候，盡量使用 union all 而不是 union。
8.盡量早過濾
這一優化策略其實最常見於索引的優化設計中(將過濾性更好的欄位放得更靠前)。
在 SQL 編寫中同樣可以使用這一原則來優化一些 Join 的 SQL。比如我們在多個表進行分頁數據查詢的時候，我們最好是能夠在一個表上先過濾好數據分好頁，然後再用分好頁的結果集與另外的表 Join，這樣可以盡可能多的減少不必要的 IO 操作，大大節省 IO 操作所消耗的時間。
9.避免類型轉換
這里所說的「類型轉換」是指 where 子句中出現 column 欄位的類型和傳入的參數類型不一致的時候發生的類型轉換：
A:人為在column_name 上通過轉換函數進行轉換
直接導致 MySQL(實際上其他資料庫也會有同樣的問題)無法使用索引，如果非要轉換，應該在傳入的參數上進行轉換
B:由資料庫自己進行轉換
如果我們傳入的數據類型和欄位類型不一致，同時我們又沒有做任何類型轉換處理，MySQL 可能會自己對我們的數據進行類型轉換操作，也可能不進行處理而交由存儲引擎去處理，這樣一來，就會出現索引無法使用的情況而造成執行計劃問題。
以上兩種情況在開發者因為某種原因經常會有，本來可以用到索引的結果類型不對沒有用到索引，或是因為類型不對又有越界的情況發生造成無法使用索引的情況，結果造成很嚴重的事故。
10.優先優化高並發的 SQL，而不是執行頻率低某些「大」SQL
對於破壞性來說，高並發的 SQL 總是會比低頻率的來得大，因為高並發的 SQL 一旦出現問題，甚至不會給我們任何喘息的機會就會將系統壓跨。而對於一些雖然需要消耗大量 IO 而且響應很慢的 SQL，由於頻率低，即使遇到，最多就是讓整個系統響應慢一點，但至少可能撐一會兒，讓我們有緩沖的機會。
11.從全局出發優化，而不是片面調整
SQL 優化不能是單獨針對某一個進行，而應充分考慮系統中所有的 SQL，尤其是在通過調整索引優化 SQL 的執行計劃的時候，千萬不能顧此失彼，因小失大。
12.盡可能對每一條運行在資料庫中的SQL進行 explain
優化 SQL，需要做到心中有數，知道SQL 的執行計劃才能判斷是否有優化餘地，才能判斷是否存在執行計劃問題。在對資料庫中運行的 SQL 進行了一段時間的優化之後，很明顯的問題 SQL 可能已經很少了，大多都需要去發掘，這時候就需要進行大量的 explain 操作收集執行計劃，並判斷是否需要進行優化。
『肆』 什麼是SQL的查詢優化,舉例說明
1 使用SET NOCOUNT ON 選項：
預設地，每次執行SQL語句時，一個消息會從服務端發給客戶端以顯示SQL語句影響的行數。這些信息對客戶端來說很少有用。通過關閉這個預設值，你能減少在服務端和客戶端的網路流量，幫助全面提升伺服器和應用程序的性能。為了關閉存儲過程級的這個特點，在每個存儲過程的開頭
包含「SET NOCOUNT ON」語句。
2 正確使用UNION和UNION ALL：
許多人沒完全理解UNION和UNION SELECT是怎樣工作的，因此，結果浪費了大量不必要的SQLServer資源。當使用UNION時，它相當於在結果集上執行SELECT DISTINCT。換句話說，UNION將聯合兩個相類似的記錄集，然後搜索重復的記錄並排除。如果這是你的目的，那麼使用UNION是正
確的。但如果你使用UNION聯合的兩個記錄集沒有重復記錄，那麼使用UNION會浪費資源，因為它要尋找重復記錄，即使你確定它們不存在。
所以如果你知道你要聯合的記錄集里沒有重復，那麼你要使用UNION ALL，而不是UNION。UNION ALL聯合記錄集，但不搜索重復記錄，這樣減少SQLServer資源的使用，從而提升性能。
3 盡量不用SELECT * ：
絕大多數情況下，不要用 * 來代替查詢返回的欄位列表，用 * 的好處是代碼量少、就算是表結構或視圖的列發生變化，編寫的查詢SQL語句也不用變，都返回所有的欄位。但資料庫伺服器在解析時，如果碰到 *，則會先分析表的結構，然後把表的所有欄位名再羅列出來。這就增加了
分析的時間。
4 慎用SELECT DISTINCT：
DISTINCT子句僅在特定功能的時候使用，即從記錄集中排除重復記錄的時候。這是因為DISTINCT子句先獲取結果集然後去重，這樣增加SQLServer有用資源的使用。當然，如果你需要去做，那就只有去做了。
當如果你知道SELECT語句將從不返回重復記錄，那麼使用DISTINCT語句對SQLServer資源不必要的浪費。
5 少用游標：
任何一種游標都會降低SQLServer性能。有些情況不能避免，大多數情況可以避免。所以如果你的應用程序目前正在使用TSQL游標，看看這些代碼是否能夠重寫以避免它們。如果你需要一行一行的執行操作，考慮下邊這些選項中的一個或多個來代替游標的使用：
使用臨時表
使用WHILE循環
使用派生表
使用相關子查詢
使用CASE語句
使用多個查詢
上面每一個都能取代游標並且執行更快。 如果你不能避免使用游標，至少試著提高它們的速度，找出加速游標的方法。
6 選擇最有效率的表名順序：
SQLSERVER的解析器按照從右到左的順序處理FROM子句中的表名，因此FROM子句中寫在最後的表（基礎表driving table）將被最先處理，在FROM子句中包含多個表的情況下，必須選擇記錄條數最少的表作為基礎表，當SQLSERVER處理多個表時，會運用排序及合並的方式連接它們。首先
，掃描第一個表（FROM子句中最後的那個表)並對記錄進行排序；然後掃描第二個表（FROM子句中最後第二個表)；最後將所有從第二個表中檢索出的記錄與第一個表中合適記錄進行合並。
例如: 表 TAB1有 16384 條記錄，表 TAB2 有5條記錄，選擇TAB2作為基礎表 (最好的方法)：
select count(*) from TAB1 a, TAB2 b
選擇TAB1作為基礎表 (不佳的方法)：
select count(*) from TAB2 a, TAB1 b
如果有3個以上的表連接查詢，那就需要選擇交叉表（intersection table）作為基礎表，交叉表是指那個被其他表所引用的表。
7 使用表的別名(Alias)：
當在SQL語句中連接多個表時，請使用表的別名並把別名前綴於每個Column上，這樣可以減少解析的時間並減少那些由Column歧義引起的語法錯誤。
8 SARG你的WHERE條件：
ARGE來源於"Search Argument"（搜索參數）的首字母拼成的"SARG"，它是指WHERE子句里，列和常量的比較。如果WHERE子句是sargable（可SARG的），這意味著它能利用索引加速查詢的完成。如果WHERE子句不是可SARG的，這意味著WHERE子句不能利用索引（或至少部分不能利用），
執行的是全表或索引掃描，這會引起查詢的性能下降。
在WHERE子句里不可SARG的搜索條件如"IS NULL", "<>", "!=", "!>", "!<", "NOT", "NOT EXISTS", "NOT IN", "NOT LIKE"和"LIKE '%500'"，通常（但不總是）會阻止查詢優化器使用索引執行搜索。另外在列上使用包括函數的表達式、兩邊都使用相同列的表達式、或和一個列（不是常
量）比較的表達式，都是不可SARG的。
並不是每一個不可SARG的WHERE子句都註定要全表掃描。如果WHERE子句包括兩個可SARG和一個不可SARG的子句，那麼至少可SARG的子句能使用索引（如果存在的話）幫助快速訪問數據。
大多數情況下，如果表上有包括查詢里所有SELECT、JOIN、WHERE子句用到的列的覆蓋索引，那麼覆蓋索引能夠代替全表掃描去返回查詢的數據，即使它有不可SARG的WHERE子句。但記住覆蓋索引尤其自身的缺陷，如此經常產生寬索引會增加讀磁碟I/O。某些情況下，可以把不可SARG的WHER
E子句重寫成可SARG的子句。例如：
WHERE SUBSTRING(firstname,1,1) = 'm'
可以寫成：
WHERE firstname like 'm%'
這兩個WHERE子句有相同的結果，但第一個是不可SARG的（因為使用了函數）將運行得慢些，而第二個是可SARG的，將運行得快些。
如果你不知道特定的WHERE子句是不是可SARG的，在查詢分析器里檢查查詢執行計劃。這樣做，你能很快的知道查詢是使用了索引還是全表掃描來返回的數據。仔細分析，許多不可SARG的查詢能寫成可SARG的查詢。下面分幾點講解WHERE條件的SARG。
8.1 WHERE子句中的連接順序
SQLSERVER採用自下而上的順序解析WHERE子句，根據這個原理，表之間的連接必須寫在其他WHERE條件之前，那些可以過濾掉最大數量記錄的條件必須寫在WHERE子句的末尾。例如：
(低效)
SELECT * FROM EMP E
WHERE SAL > 50000
AND JOB = 『MANAGER』
AND 25 < (SELECT COUNT(*) FROM EMP WHERE MGR=E.EMPNO)
(高效)
SELECT * FROM EMP E
WHERE 25 < (SELECT COUNT(*) FROM EMP WHERE MGR=E.EMPNO)
AND SAL > 50000
AND JOB = 『MANAGER』
8.2 避免困難的正規表達式：
MATCHES和LIKE關鍵字支持通配符匹配，技術上叫正規表達式。但這種匹配特別耗費時間。例如：
SELECT * FROM customer WHERE zipcode LIKE "98_ _ _"
即使在zipcode欄位上建立了索引，在這種情況下也還是採用順序掃描的方式。如果把語句改為SELECT * FROM customer WHERE zipcode >="98000"，在執行查詢時就會利用索引來查詢，顯然會大大提高速度。
另外，還要避免非開始的子串。例如語句：
SELECT * FROM customer WHERE zipcode[2，3] >"80"
在where子句中採用了非開始子串，因而這個語句也不會使用索引。
8.3 避免對大型錶行數據的順序存取：
在嵌套查詢中，對表的順序存取對查詢效率可能產生致命的影響。比如採用順序存取策略，一個嵌套3層的查詢，如果每層都查詢1000行，那麼這個查詢就要查詢10億行數據。避免這種情況的主要方法就是對連接的列進行索引。例如，兩個表：學生表（學號、姓名、年齡……）和選課表（
學號、課程號、成績）。如果兩個表要做連接，就要在「學號」這個連接欄位上建立索引。
還可以使用並集來避免順序存取。盡管在所有的檢查列上都有索引，但某些形式的where子句強迫優化器使用順序存取。下面的查詢將強迫對orders表執行順序操作：
SELECT * FROM orders WHERE (customer_num=104 AND order_num>1001) OR order_num=1008
雖然在customer_num和order_num上建有索引，但是在上面的語句中優化器還是使用順序存取路徑掃描整個表。因為這個語句要檢索的是分離的行的集合，所以應該改為如下語句：
SELECT * FROM orders WHERE customer_num=104 AND order_num>1001
UNION ALL
SELECT * FROM orders WHERE order_num=1008
這樣就能利用索引路徑處理查詢。
8.4 EXISTS和IN的使用：
在許多基於基礎表的查詢中，為了滿足一個條件，往往需要對另一個表進行聯接。 在這種情況下，使用EXISTS(或NOT EXISTS)通常將提高查詢的效率。在子查詢中，NOT IN子句將執行一個內部的排序和合並。無論在哪種情況下，NOT IN都是最低效的，因為它對子查詢中的表執行
了一個全表遍歷。為了避免使用NOT IN，我們可以把它改寫成外連接(Outer Joins)或NOT EXISTS。
8.5 避免在索引列上使用IS NULL和IS NOT NULL：
避免在索引中使用任何可以為空的列，SQLSERVER將無法使用該索引。對於單列索引，如果列包含空值，索引中將不存在此記錄；對於復合索引，如果每個列都為空，索引中同樣不存在此記錄。如果至少有一個列不為空，則記錄存在於索引中。
如果唯一性索引建立在表的A列和B列上，並且表中存在一條記錄的A,B值為(123,null)，SQLSERVER將不接受下一條具有相同A,B值（123,null）的記錄插入。
如果所有的索引列都為空，SQLSERVER將認為整個鍵值為空，而空不可能等於空，因此你可以插入1000條具有相同鍵值的記錄，當然它們都是空！因為空值不存在於索引列中，所以WHERE子句中對索引列進行空值比較將使SQLSERVER停用該索引。下面的代碼將會很低效（索引失效）：
SELECT … FROM DEPARTMENT WHERE DEPT_CODE IS NOT NULL
8.6 避免在索引列上使用計算：
WHERE子句中，如果索引列是函數的一部分，優化器將不使用索引而使用全表掃描。 例如下面的語句低效 ：
SELECT … FROM DEPT WHERE SAL * 12 > 25000
而下面的語句將是高效的：
SELECT … FROM DEPT WHERE SAL > 25000/12
請務必注意，查詢中不要對索引列進行處理，如：TRIM，substring，convert等等操作。
8.7 用WHERE子句替換HAVING子句：
避免使用HAVING子句，HAVING只會在檢索出所有記錄之後才對結果集進行過濾，這個處理需要排序、統計等操作。如果能通過WHERE子句限制記錄的數目，那就能減少這方面的開銷。
9 避免或簡化排序：
應當簡化或避免對大型表進行重復的排序。當能夠利用索引自動以適當的次序產生輸出時，優化器就避免了排序的步驟。以下是一些影響因素：
l 索引中不包括一個或幾個待排序的列；
l group by或order by子句中列的次序與索引的次序不一樣；
l 排序的列來自不同的表。
為了避免不必要的排序，就要正確地增建索引，合理地合並資料庫表（盡管有時可能影響表的規范化，但相對於效率的提高是值得的）。如果排序不可避免，那麼應當試圖簡化它，如縮小排序的列的范圍等。
10 臨時表的使用：
臨時表有很多特殊的用途，象用來替代游標，不過它們仍能引起性能問題，如果這個問題能消除，SQLServer將執行得更快。在永久表和臨時表的數據行相同的條件下，使用臨時表沒有永久錶快。但有時還必須得使用臨時表，如先從存儲大量數據的永久表中提取符全條件的存放到臨時
表，然後在臨時表上執行操作。如果是直接在存儲大量數據的永久表上執行操作（如：統計、循環等），其性能將大打折扣。所以，使不使用臨時表，何時使用臨時表，需要具體情況決定。
11 是否使用視圖：
視圖最大的用途是處理安全相關的問題，而不是一些懶惰的開發人員用來存儲經常使用的查詢的方法。例如，如果你需要允許用戶訪問特定SQLServer的數據，那麼你也許可以考慮為用戶（或組）創建一個視圖，然後給用戶訪問視圖而不是基表的許可權。另一方面，在應用程序里，從視圖選
擇數據沒有好的理由，相反，繞過視圖直接從需要的表裡獲取數據。原因是許多視圖（當然不是全部）返回比SELECT語句所需更多的數據，增加不必要的開銷。
例如，假定有一個視圖從兩個連接表裡返回10列。你想要從視圖里使用SELECT語句返回其中7列。實際上發生的情況是基於視圖的查詢先運行，返回數據，然後你的查詢針對這些數據運行。既然你僅需要7列，而不是視圖返回的10列，更多不必要的數據被返回。浪費SQLServer的資源。
長久以來，大家在爭論是查詢視圖速度快還是直接查詢快，本人也不敢輕易下結論，因此作了多次試驗，其結果是：基於視圖查詢，性能確實不會比直接寫查詢語句快，對於簡單的查詢，最多是在同一水平上。
當然，上面的測試是在沒有為視圖創建索引的情況下，SQLServer2000以上可以為視圖創建索引，視圖索引與表的索引在作用方式上非常相似。與表一樣，視圖可以有一個集簇索引（clustered index）和多個非集簇索引。創建視圖索引後能夠提高視圖的性能。
如果視圖不包含索引，則資料庫中不保存視圖返回的結果集。有的時候，我們可能要創建涉及大量記錄或必須進行復雜計算的視圖，比如要進行聚合分組處理或多重連接操作。如果每次引用這些視圖的時候讓sql server重新生成結果集，資料庫開銷將非常大。
12 讓事務盡可能的短：
保持TSQL事務盡可能的短。這會幫助減少鎖（所有類型的鎖）的數量，有助於全面提升SQLServer的性能。如果有經驗，你也許要將長事務分成更小的事務組。
13 用存儲過程代替直接寫查詢語句：
存儲過程為開發人員提供了很多好處，包括：
n 減少網路流量和響應時間，提升應用程序性能。例如，通過網路發送一個存儲過程調用，而不是發送500行的TSQL將更快，資源使用更少。當每次執行SQL時，都會執行解析SQL語句、估算索引的利用率、綁定變數、讀數據塊等等工作。
n 存儲過程執行計劃能夠重用，駐留在SQLServer內存的緩存里，減少伺服器開銷。
n 客戶端執行請求更有效率。例如，如果應用程序需要插入大量的二進制值到一個image數據列而不使用存儲過程，它必須轉化二進制為字元串（大小會增加一倍），然後發送給SQLServer。當SQLServer接收到後，它必須把字元串值轉回二進制格式。大量的浪費開銷。存儲過程能
消除這個問題通過將應用程序傳給SQLServer的二進制格式作為參數，從而減少開銷提升性能。
n 存儲過程幫助提供代碼重用。雖然這些不直接提升應用程序的性能，通過減少代碼量和減少調試時間來提升開發人員的效率。
n 存儲過程能封裝邏輯。你能夠改變存儲過程代碼而不影響客戶端（假定你保持參數相同也不移除任何結果集的列）。這節約開發人員的時間。
n 存儲過程為你的數據提供更好的安全性。如果你僅使用存儲過程，你可以移除直接對表的SELECT、INSERT、UPDATE和DELETE許可權從而強迫開發人員使用存儲過程訪問數據。這會節約DBA的時間。
n 作為首要的常規，所有的TSQL代碼都應該通過存儲過程調用。
13.1 存儲過程名不要以 sp_ 開頭：
對這一準則，可能很多人會感覺納悶，是的，我開始也納悶過。如果創建的存儲過程不是運行在Master資料庫里，不要使用以sp_為前綴的名稱。這個特別的前綴是為系統存儲過程保留的。盡管使用這個前綴不會禁止用戶定義的存儲過程的運行，但會稍微降低一些執行效率。這是因為
SQLServer在執行以sp_為前綴的任何一個存儲過程時預設地首先試圖在Master資料庫里尋找，盡管那兒沒有，這就浪費了尋找存儲過程的時間。如果SQLServer在Master資料庫里不能找到存儲過程，那麼接下來會將存儲過程的擁有者作為DBO去解析。如果存儲過程在目前的資料庫里，那麼
它會執行。為了避免不必要的延遲，不要用前綴為sp_命名你的任何一個存儲過程。
13.2 存儲過程的擁有者要相同：
為了最好的性能，同一個存儲過程里調用的所有對象的擁有者都應該相同，DBO更適宜。如果不是那樣，即對象名相同而擁有者不同，那麼SQLServer必須執行名稱判斷。當發生這樣的情形時，SQLServer不能使用存儲過程里在內存里的執行計劃，相反，它必須重新編譯存儲過程，從而
影響性能。當從應用程序里調用存儲過程時，使用分隔符名稱來調用也是重要的。如：
EXEC dbo.myProcere
代替：
EXEC myProcere
這樣做有兩個原因，其中一個和性能有關。首先，使用完全有分隔符的名稱有助於消除那些和你要運行的存儲過程有潛在的混淆，有助於禁止BUG和潛在的問題。但更重要的是，這樣做SQLServer能更直接的訪問存儲過程執行計劃，而不是輪流訪問，從而加速了存儲過程的性能。當然性能
提升很小，但如果你的伺服器每小時要運行成千上萬或更多的存儲過程，這些節約的小段時間加起來就很可觀了。
14 完整性使用下的約束和觸發器：
資料庫里不要執行多餘的完整性特點。例如，如果你正使用主鍵和外鍵約束來強迫引用完整性，則不要添加觸發器來實現相同的功能而增加不必要的開銷。同樣既使用約束又使用默認值或既使用約束又使用規則也會執行多餘的工作。
15 在SQL中捕捉異常：
這一條准則應該不能算是優化方面的，只是編寫要求。現在SQLServer2005中，新增了BEGIN TRY…END TRY和 BEGIN CATCH…END CATCH二個成對語句，用於捕捉運行時出現的異常。在Oracle中，可用 BEGIN…EXCEPTION…END 語句捕捉異常。
把SQL代碼塊中加入捕捉異常的語句內，有二個好處：一是可以在SQL語句內部得到異常並作錯誤處理，如在錯誤代碼塊內返回自定義錯誤信息、ROLBACK等。這樣可減少應用程序捕捉異常帶來的資源開銷；另外一個好處就是可以防止死鎖情況的發生，當出現死鎖時，SQLServer2005會拋出
異常，我們就可捕捉到。
下面列出一些索引的概念，有助於設計表結構和編寫SQL語句：
按照存儲規則來分：
l 聚集索引：該索引中鍵值的邏輯順序決定了表中相應行的物理順序。因此一個表只能包含一個聚集索引，但該索引可以包含多個列（組合索引）。檢索效率比普通索引高，但對數據新增/修改/刪除的影響比較大。
l 非聚集索引：與聚集索引相對，不影響表中的數據存儲順序，檢索效率比聚集索引低，對數據新增/修改/刪除的影響很少。
按照維護與管理的角度來分：
l 唯一索引：惟一索引可以確保索引列不包含重復的值，可以用多個列，但是索引可以確保索引列中每個值組合都是唯一的。
l 主鍵索引：在資料庫關系圖中為表定義一個主鍵將自動創建主鍵索引，主鍵索引是唯一索引的特殊類型。主鍵索引要求主鍵中的每個值是唯一的。當在查詢中使用主鍵索引時，它還允許快速訪問數據。
l 普通索引：由關鍵字KEY或INDEX定義的索引，唯一任務是加快對數據的訪問速度。因此，應該只為那些最經常出現在查詢條件或排序條件中的數據列創建索引。只要有可能，就應該選擇一個數據最整齊、最緊湊的數據列(如整數類型的數據列)來創建索引。允許有重復的列存在
。
l 復合索引：如果在兩上以上的列上創建的索引，則稱為復合索引。
『伍』 資料庫的優化
對於資料庫的優化老漁哥可以為你提供以下六點作為參考：
1、調整數據結構的設計。這一部分在開發信息系統之前完成，程序員需要考慮是否使用ORACLE資料庫的分區功能，對於經常訪問的資料庫表是否需要建立索引等。
2、調整應用程序結構設計。這一部分也是在開發信息系統之前完成，程序員在這一步需要考慮應用程序使用什麼樣的體系結構，是使用傳統的Client/Server兩層體系結構，還是使用Browser/Web/Database的三層體系結構。不同的應用程序體系結構要求的資料庫資源是不同的。
3、調整資料庫SQL語句。應用程序的執行最終將歸結為資料庫中的SQL語句執行，因此SQL語句的執行效率最終決定了ORACLE資料庫的性能。ORACLE公司推薦使用ORACLE語句優化器（Oracle Optimizer）和行鎖管理器（row-level manager）來調整優化SQL語句。
4、調整伺服器內存分配。內存分配是在信息系統運行過程中優化配置的，資料庫管理員可以根據資料庫運行狀況調整資料庫系統全局區（SGA區）的數據緩沖區、日誌緩沖區和共享池的大小；還可以調整程序全局區（PGA區）的大小。需要注意的是，SGA區不是越大越好，SGA區過大會佔用操作系統使用的內存而引起虛擬內存的頁面交換，這樣反而會降低系統。
5、調整硬碟I/O，這一步是在信息系統開發之前完成的。資料庫管理員可以將組成同一個表空間的數據文件放在不同的硬碟上，做到硬碟之間I/O負載均衡。
6、調整操作系統參數，例如：運行在UNIX操作系統上的ORACLE資料庫，可以調整UNIX數據緩沖池的大小，每個進程所能使用的內存大小等參數。
『陸』 oracle中如何優化sql語句的，用什麼方法
2. 選擇最有效率的表名順序(只在基於規則的優化器中有效)
ORACLE的解析器按照從右到左的順序處理FROM子句中的表名,因此FROM子句中寫在最後的表(基礎表 driving table)將被最先處理. 在FROM子句中包含多個表的情況下,你必須選擇記錄條數最少的表作為基礎表.當ORACLE處理多個表時, 會運用排序及合並的方式連接它們.首先,掃描第一個表(FROM子句中最後的那個表)並對記錄進行派序,然後掃描第二個表(FROM子句中最後第二個表),最後將所有從第二個表中檢索出的記錄與第一個表中合適記錄進行合並.
例如: 表 TAB1 16,384 條記錄
表 TAB2 1 條記錄
選擇TAB2作為基礎表 (最好的方法)
select count(*) from tab1,tab2 執行時間0.96秒
選擇TAB2作為基礎表 (不佳的方法)
select count(*) from tab2,tab1 執行時間26.09秒
如果有3個以上的表連接查詢, 那就需要選擇交叉表(intersection table)作為基礎表, 交叉表是指那個被其他表所引用的表.
例如: EMP表描述了LOCATION表和CATEGORY表的交集.
SELECT *
FROM LOCATION L ,
CATEGORY C,
EMP E
WHERE E.EMP_NO BETWEEN 1000 AND 2000
AND E.CAT_NO = C.CAT_NO
AND E.LOCN = L.LOCN
將比下列SQL更有效率
SELECT *
FROM EMP E ,
LOCATION L ,
CATEGORY C
WHERE E.CAT_NO = C.CAT_NO
AND E.LOCN = L.LOCN
AND E.EMP_NO BETWEEN 1000 AND 2000
3. WHERE子句中的連接順序．
ORACLE採用自下而上的順序解析WHERE子句,根據這個原理,表之間的連接必須寫在其他WHERE條件之前, 那些可以過濾掉最大數量記錄的條件必須寫在WHERE子句的末尾.
例如:
(低效,執行時間156.3秒)
SELECT …
FROM EMP E
WHERE SAL > 50000
AND JOB = 『MANAGER』
AND 25 < (SELECT COUNT(*) FROM EMP
WHERE MGR=E.EMPNO);
(高效,執行時間10.6秒)
SELECT …
FROM EMP E
WHERE 25 < (SELECT COUNT(*) FROM EMP
WHERE MGR=E.EMPNO)
AND SAL > 50000
AND JOB = 『MANAGER』;
4. SELECT子句中避免使用 『 * 『
當你想在SELECT子句中列出所有的COLUMN時,使用動態SQL列引用 『*』 是一個方便的方法.不幸的是,這是一個非常低效的方法. 實際上,ORACLE在解析的過程中, 會將』*』 依次轉換成所有的列名, 這個工作是通過查詢數據字典完成的, 這意味著將耗費更多的時間.
5. 減少訪問資料庫的次數
當執行每條SQL語句時, ORACLE在內部執行了許多工作: 解析SQL語句, 估算索引的利用率, 綁定變數 , 讀數據塊等等. 由此可見, 減少訪問資料庫的次數 , 就能實際上減少ORACLE的工作量.
例如,
以下有三種方法可以檢索出雇員號等於0342或0291的職員.
方法1 (最低效)
SELECT EMP_NAME , SALARY , GRADE
FROM EMP
WHERE EMP_NO = 342;
SELECT EMP_NAME , SALARY , GRADE
FROM EMP
WHERE EMP_NO = 291;
方法2 (次低效)
DECLARE
CURSOR C1 (E_NO NUMBER) IS
SELECT EMP_NAME,SALARY,GRADE
FROM EMP
WHERE EMP_NO = E_NO;
BEGIN
OPEN C1(342);
FETCH C1 INTO …,..,.. ;
OPEN C1(291);
FETCH C1 INTO …,..,.. ;
CLOSE C1;
END;
方法3 (高效)
SELECT A.EMP_NAME , A.SALARY , A.GRADE,
B.EMP_NAME , B.SALARY , B.GRADE
FROM EMP A,EMP B
WHERE A.EMP_NO = 342
AND B.EMP_NO = 291;
注意:
在SQL*Plus , SQL*Forms和Pro*C中重新設置ARRAYSIZE參數, 可以增加每次資料庫訪問的檢索數據量 ,建議值為200.
6. 使用DECODE函數來減少處理時間
使用DECODE函數可以避免重復掃描相同記錄或重復連接相同的表.
例如:
SELECT COUNT(*)，SUM(SAL)
FROM EMP
WHERE DEPT_NO = 0020
AND ENAME LIKE 『SMITH%』;
SELECT COUNT(*)，SUM(SAL)
FROM EMP
WHERE DEPT_NO = 0030
AND ENAME LIKE 『SMITH%』;
你可以用DECODE函數高效地得到相同結果
SELECT COUNT(DECODE(DEPT_NO,0020,』X』,NULL)) D0020_COUNT,
COUNT(DECODE(DEPT_NO,0030,』X』,NULL)) D0030_COUNT,
SUM(DECODE(DEPT_NO,0020,SAL,NULL)) D0020_SAL,
SUM(DECODE(DEPT_NO,0030,SAL,NULL)) D0030_SAL
FROM EMP WHERE ENAME LIKE 『SMITH%』;
類似的,DECODE函數也可以運用於GROUP BY 和ORDER BY子句中.
7. 用TRUNCATE替代DELETE
當刪除表中的記錄時,在通常情況下, 回滾段(rollback segments ) 用來存放可以被恢復的信息. 如果你沒有COMMIT事務,ORACLE會將數據恢復到刪除之前的狀態(准確地說是恢復到執行刪除命令之前的狀況)
而當運用TRUNCATE時, 回滾段不再存放任何可被恢復的信息.當命令運行後,數據不能被恢復.因此很少的資源被調用,執行時間也會很短.
TRUNCATE只在刪除全表或分區適用,TRUNCATE是DDL不是DML
8. 用Where子句替換HAVING子句
避免使用HAVING子句, HAVING 只會在檢索出所有記錄之後才對結果集進行過濾. 這個處理需要排序,總計等操作. 如果能通過WHERE子句限制記錄的數目,那就能減少這方面的開銷.
例如:
低效:
SELECT REGION，AVG(LOG_SIZE)
FROM LOCATION
GROUP BY REGION
HAVING REGION REGION != 『SYDNEY』
AND REGION != 『PERTH』
高效
SELECT REGION，AVG(LOG_SIZE)
FROM LOCATION
WHERE REGION REGION != 『SYDNEY』
AND REGION != 『PERTH』
GROUP BY REGION
HAVING 中的條件一般用於對一些集合函數的比較,如COUNT() 等等. 除此而外,一般的條件應該寫在WHERE子句中
9. 減少對表的查詢
在含有子查詢的SQL語句中,要特別注意減少對表的查詢.
例如:
低效
SELECT TAB_NAME
FROM TABLES
WHERE TAB_NAME = ( SELECT TAB_NAME
FROM TAB_COLUMNS
WHERE VERSION = 604)
AND DB_VER= ( SELECT DB_VER
FROM TAB_COLUMNS
WHERE VERSION = 604)
高效
SELECT TAB_NAME
FROM TABLES
WHERE (TAB_NAME,DB_VER)
= ( SELECT TAB_NAME,DB_VER)
FROM TAB_COLUMNS
WHERE VERSION = 604)
Update 多個Column 例子:
低效:
UPDATE EMP
SET EMP_CAT = (SELECT MAX(CATEGORY) FROM EMP_CATEGORIES),
SAL_RANGE = (SELECT MAX(SAL_RANGE) FROM EMP_CATEGORIES)
WHERE EMP_DEPT = 0020;
高效:
UPDATE EMP
SET (EMP_CAT, SAL_RANGE)
= (SELECT MAX(CATEGORY) , MAX(SAL_RANGE)
FROM EMP_CATEGORIES)
WHERE EMP_DEPT = 0020;
10. 通過內部函數提高SQL效率.
SELECT H.EMPNO,E.ENAME,H.HIST_TYPE,T.TYPE_DESC,COUNT(*)
FROM HISTORY_TYPE T,EMP E,EMP_HISTORY H
WHERE H.EMPNO = E.EMPNO
AND H.HIST_TYPE = T.HIST_TYPE
GROUP BY H.EMPNO,E.ENAME,H.HIST_TYPE,T.TYPE_DESC;
通過調用下面的函數可以提高效率.
FUNCTION LOOKUP_HIST_TYPE(TYP IN NUMBER) RETURN VARCHAR2
AS
TDESC VARCHAR2(30);
CURSOR C1 IS
SELECT TYPE_DESC
FROM HISTORY_TYPE
WHERE HIST_TYPE = TYP;
BEGIN
OPEN C1;
FETCH C1 INTO TDESC;
CLOSE C1;
RETURN (NVL(TDESC,』?』));
END;
FUNCTION LOOKUP_EMP(EMP IN NUMBER) RETURN VARCHAR2
AS
ENAME VARCHAR2(30);
CURSOR C1 IS
SELECT ENAME
FROM EMP
WHERE EMPNO=EMP;
BEGIN
OPEN C1;
FETCH C1 INTO ENAME;
CLOSE C1;
RETURN (NVL(ENAME,』?』));
END;
SELECT H.EMPNO,LOOKUP_EMP(H.EMPNO),
H.HIST_TYPE,LOOKUP_HIST_TYPE(H.HIST_TYPE),COUNT(*)
FROM EMP_HISTORY H
GROUP BY H.EMPNO , H.HIST_TYPE;
經常在論壇中看到如 』能不能用一個SQL寫出….』 的貼子, 殊不知復雜的SQL往往犧牲了執行效率. 能夠掌握上面的運用函數解決問題的方法在實際工作中是非常有意義的
11. 使用表的別名(Alias)
當在SQL語句中連接多個表時, 請使用表的別名並把別名前綴於每個Column上.這樣一來,就可以減少解析的時間並減少那些由Column歧義引起的語法錯誤.
Column歧義指的是由於SQL中不同的表具有相同的Column名,當SQL語句中出現這個Column時,SQL解析器無法判斷這個Column的歸屬
12. 用EXISTS替代IN
在許多基於基礎表的查詢中,為了滿足一個條件,往往需要對另一個表進行聯接.在這種情況下, 使用EXISTS(或NOT EXISTS)通常將提高查詢的效率.
低效:
SELECT *
FROM EMP (基礎表)
WHERE EMPNO > 0
AND DEPTNO IN (SELECT DEPTNO
FROM DEPT
WHERE LOC = 『MELB』)
高效:
SELECT *
FROM EMP (基礎表)
WHERE EMPNO > 0
AND EXISTS (SELECT 『X』
FROM DEPT
WHERE DEPT.DEPTNO = EMP.DEPTNO
AND LOC = 『MELB』)
相對來說,用NOT EXISTS替換NOT IN 將更顯著地提高效率,下一節中將指出
13. 用NOT EXISTS替代NOT IN
在子查詢中,NOT IN子句將執行一個內部的排序和合並. 無論在哪種情況下,NOT IN都是最低效的 (因為它對子查詢中的表執行了一個全表遍歷). 為了避免使用NOT IN ,我們可以把它改寫成外連接(Outer Joins)或NOT EXISTS.
例如:
SELECT …
FROM EMP
WHERE DEPT_NO NOT IN (SELECT DEPT_NO
FROM DEPT
WHERE DEPT_CAT=』A』);
為了提高效率.改寫為:
(方法一: 高效)
SELECT ….
FROM EMP A,DEPT B
WHERE A.DEPT_NO = B.DEPT(+)
AND B.DEPT_NO IS NULL
AND B.DEPT_CAT(+) = 『A』
(方法二: 最高效)
SELECT ….
FROM EMP E
WHERE NOT EXISTS (SELECT 『X』
FROM DEPT D
WHERE D.DEPT_NO = E.DEPT_NO
AND DEPT_CAT = 『A』);
14. 用表連接替換EXISTS
通常來說 , 採用表連接的方式比EXISTS更有效率
SELECT ENAME
FROM EMP E
WHERE EXISTS (SELECT 『X』
FROM DEPT
WHERE DEPT_NO = E.DEPT_NO
AND DEPT_CAT = 『A』);
(更高效)
SELECT ENAME
FROM DEPT D,EMP E
WHERE E.DEPT_NO = D.DEPT_NO
AND DEPT_CAT = 『A』 ;
在RBO的情況下,前者的執行路徑包括FILTER,後者使用NESTED LOOP
15. 用EXISTS替換DISTINCT
當提交一個包含一對多表信息(比如部門表和雇員表)的查詢時,避免在SELECT子句中使用DISTINCT. 一般可以考慮用EXIST替換
例如:
低效:
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);
EXISTS 使查詢更為迅速,因為RDBMS核心模塊將在子查詢的條件一旦滿足後,立刻返回結果.
16. 基礎表的選擇
基礎表(Driving Table)是指被最先訪問的表(通常以全表掃描的方式被訪問). 根據優化器的不同, SQL語句中基礎表的選擇是不一樣的.
如果你使用的是CBO (COST BASED OPTIMIZER),優化器會檢查SQL語句中的每個表的物理大小,索引的狀態,然後選用花費最低的執行路徑.
如果你用RBO (RULE BASED OPTIMIZER) , 並且所有的連接條件都有索引對應, 在這種情況下, 基礎表就是FROM 子句中列在最後的那個表.
舉例:
SELECT A.NAME , B.MANAGER
FROM WORKER A,
LODGING B
WHERE A.LODGING = B.LODING;
由於LODGING表的LODING列上有一個索引, 而且WORKER表中沒有相比較的索引, WORKER表將被作為查詢中的基礎表.
17. 多個平等的索引
當SQL語句的執行路徑可以使用分布在多個表上的多個索引時, ORACLE會同時使用多個索引並在運行時對它們的記錄進行合並, 檢索出僅對全部索引有效的記錄.
在ORACLE選擇執行路徑時,唯一性索引的等級高於非唯一性索引. 然而這個規則只有
當WHERE子句中索引列和常量比較才有效.如果索引列和其他表的索引類相比較. 這種子句在優化器中的等級是非常低的.
如果不同表中兩個想同等級的索引將被引用, FROM子句中表的順序將決定哪個會被率先使用. FROM子句中最後的表的索引將有最高的優先順序.
如果相同表中兩個想同等級的索引將被引用, WHERE子句中最先被引用的索引將有最高的優先順序.
舉例:
DEPTNO上有一個非唯一性索引,EMP_CAT也有一個非唯一性索引.
SELECT ENAME,
FROM EMP
WHERE DEPT_NO = 20
AND EMP_CAT = 『A』;
這里,DEPTNO索引將被最先檢索,然後同EMP_CAT索引檢索出的記錄進行合並. 執行路徑如下:
TABLE ACCESS BY ROWID ON EMP
AND-EQUAL
INDEX RANGE SCAN ON DEPT_IDX
INDEX RANGE SCAN ON CAT_IDX
18. 等式比較和范圍比較
當WHERE子句中有索引列, ORACLE不能合並它們,ORACLE將用范圍比較.
舉例:
DEPTNO上有一個非唯一性索引,EMP_CAT也有一個非唯一性索引.
SELECT ENAME
FROM EMP
WHERE DEPTNO > 20
AND EMP_CAT = 『A』;
這里只有EMP_CAT索引被用到,然後所有的記錄將逐條與DEPTNO條件進行比較. 執行路徑如下:
TABLE ACCESS BY ROWID ON EMP
INDEX RANGE SCAN ON CAT_IDX
19. 不明確的索引等級
當ORACLE無法判斷索引的等級高低差別,優化器將只使用一個索引,它就是在WHERE子句中被列在最前面的.
舉例:
DEPTNO上有一個非唯一性索引,EMP_CAT也有一個非唯一性索引.
SELECT ENAME
FROM EMP
WHERE DEPTNO > 20
AND EMP_CAT > 『A』;
這里, ORACLE只用到了DEPT_NO索引. 執行路徑如下:
TABLE ACCESS BY ROWID ON EMP
INDEX RANGE SCAN ON DEPT_IDX
我們來試一下以下這種情況:
SQL> select index_name, uniqueness from user_indexes where table_name = 'EMP';
INDEX_NAME UNIQUENES
------------------------------ ---------
EMPNO UNIQUE
EMPTYPE NONUNIQUE
SQL> select * from emp where empno >= 2 and emp_type = 'A' ;
no rows selected
Execution Plan
----------------------------------------------------------
0 SELECT STATEMENT Optimizer=CHOOSE
1 0 TABLE ACCESS (BY INDEX ROWID) OF 'EMP'
2 1 INDEX (RANGE SCAN) OF 'EMPTYPE' (NON-UNIQUE)
雖然EMPNO是唯一性索引,但是由於它所做的是范圍比較, 等級要比非唯一性索引的等式比較低!
20. 強制索引失效
如果兩個或以上索引具有相同的等級,你可以強制命令ORACLE優化器使用其中的一個(通過它,檢索出的記錄數量少) .
舉例:
SELECT ENAME
FROM EMP
WHERE EMPNO = 7935
AND DEPTNO + 0 = 10 /*DEPTNO上的索引將失效*/
AND EMP_TYPE || 『』 = 『A』 /*EMP_TYPE上的索引將失效*/
這是一種相當直接的提高查詢效率的辦法. 但是你必須謹慎考慮這種策略,一般來說,只有在你希望單獨優化幾個SQL時才能採用它.
這里有一個例子關於何時採用這種策略,
假設在EMP表的EMP_TYPE列上有一個非唯一性的索引而EMP_CLASS上沒有索引.
SELECT ENAME
FROM EMP
WHERE EMP_TYPE = 『A』
AND EMP_CLASS = 『X』;
優化器會注意到EMP_TYPE上的索引並使用它. 這是目前唯一的選擇. 如果,一段時間以後, 另一個非唯一性建立在EMP_CLASS上,優化器必須對兩個索引進行選擇,在通常情況下,優化器將使用兩個索引並在他們的結果集合上執行排序及合並. 然而,如果其中一個索引（EMP_TYPE）接近於唯一性而另一個索引（EMP_CLASS）上有幾千個重復的值. 排序及合並就會成為一種不必要的負擔. 在這種情況下,你希望使優化器屏蔽掉EMP_CLASS索引.
用下面的方案就可以解決問題.
SELECT ENAME
FROM EMP
WHERE EMP_TYPE = 『A』
AND EMP_CLASS||』』 = 『X』;
21. 避免在索引列上使用計算．
WHERE子句中，如果索引列是函數的一部分．優化器將不使用索引而使用全表掃描．
舉例:
低效：
SELECT …
FROM DEPT
WHERE SAL * 12 > 25000;
高效:
SELECT …
FROM DEPT
WHERE SAL > 25000/12;
這是一個非常實用的規則，請務必牢記
22. 自動選擇索引
如果表中有兩個以上（包括兩個）索引，其中有一個唯一性索引，而其他是非唯一性．
在這種情況下，ORACLE將使用唯一性索引而完全忽略非唯一性索引．
舉例:
SELECT ENAME
FROM EMP
WHERE EMPNO = 2326
AND DEPTNO = 20 ;
這里，只有EMPNO上的索引是唯一性的，所以EMPNO索引將用來檢索記錄．
TABLE ACCESS BY ROWID ON EMP
INDEX UNIQUE SCAN ON EMP_NO_IDX
23. 避免在索引列上使用NOT
通常， 我們要避免在索引列上使用NOT, NOT會產生在和在索引列上使用函數相同的
影響. 當ORACLE」遇到」NOT ,!=,他就會停止使用索引轉而執行全表掃描.
舉例:
低效: (這里,不使用索引)
SELECT …
FROM DEPT
WHERE DEPT_CODE != 0;
高效: (這里,使用了索引)
SELECT …
FROM DEPT
知道的基本就這么多了，要加分啊~~O(∩_∩)O~
『柒』 sql 查詢優化
4000多隻是實驗用最基本數據表啊。
查詢速度還不能保證的話，嚴格的說資料庫本身性能是不能讓人滿意的
其次，為什麼同樣的語句要執行數百遍，不能夠公用嗎？，本身減少查詢的次數，也是一種優化。
從硬體上說，可以講這兩張表放入資料庫緩存中進行緩存查詢，這樣可以極大地提高效率（資料庫優化機制中，最常用的緩存其實是放在內存中的），四千多的表應該不會多大的，緩存肯定放的進去。
看你的語句，只怕是用web也就是其它語言調用資料庫的，本身介面設計就是一個大問題，這需要資深人士配合。
總體老說，如果你的資料庫連四千數據量的多次查詢都會導致性能緩慢（尤其是不怎麼佔用存儲的count計算都會導致性能下降）的話，首先應該考慮的資料庫本身的優化。更換設備可能是一個不錯的選擇。
『捌』 SQL 優化問題
lz應該放上點分，0不給力呀！
---------------------------------------
方案有N多：
第一：減少表的掃描計數，如下方式基本可以減少三倍掃描計數，千萬記錄能夠優化幾十毫秒。
select A.target_id as id,B.title as title
from a_tg as A
left join a_ta as B on (A.target_id=B.id)
left join a_tb as C on (A.target_id=C.id)
left join a_td as D on (A.target_id=D.id)
where A.data like '%tag%' and (A.ift='a_ta' or A.ift='a_tb' or A.ift='a_tc')
LOOK! 短小精乾的別名也是能提速的！O(∩_∩)O哈哈哈~
---------------------------------------------------------------------------------------------------------------
第二：建立聯合索引 ，如果進行排序聚合，千萬記錄搜索，速度可以調高5倍上下
。target_id 和 ift 建立聯合索引。
--------------------------------------------------------------------------------------------------------------
第三：構建設計，將名值等元組放入主信息表，這個工程估計可以提速百倍以上，因為沒必要關聯表了。
--------------------------------------------------------------------------------------------------------------
第四：像這種內容匹配是否可以用全局索引，或是 like 'XXX%'的方式就要看LZ怎麼對待了
-------------------------------------------------------------------------------------------------------------------
如果LZ還不滿意，就放上300分，SQL高手團一定獻上更優異的策略。