1.為了優化查詢，我們應該盡可能避免掃描整個表。首先，我們應該考慮在where和order by中涉及的列上建立索引。
2.盡量避免判斷where子句中字段的空值，否則引擎會放棄使用索引並掃描整個表，比如:
從t中選擇id，其中num為空
您可以將num的默認值設置為0，以確保表中的num列沒有空值，然後像這樣查詢它:
從t中選擇id，其中num=0
3.盡量避免在where子句中使用！=或者
4.盡量避免在where子句中使用or連接條件，否則會導致引擎放棄使用索引並掃描整個表，例如:
從t中選擇id，其中num=10或num=20
您可以像這樣查詢:
select id from t where num=10
聯合所有
從t中選擇id，其中num=20
5.in和not in也要慎用，否則會導致全表掃描，比如:
select id from t where num in(1，2，3)
對於連續值，可以使用between而不是in:
從t中選擇id，其中num介於1和3之間
6.以下查詢也將導致全表掃描:
從t中選擇id，其中名稱如“%abc%”
為了提高效率，可以考慮全文檢索。
7.如果在where子句中使用參數，也會導致全表掃描。因為SQL只在運行時解析局部變量，所以優化器不能將訪問計劃的選擇推遲到運行時；必須在編譯時選擇它。但是，如果訪問計劃是在編譯時建立的，那麽變量的值仍然是未知的，因此它不能作為索引選擇的輸入項。以下語句將掃描整個表:
select id from t where num=@num
您可以強制查詢使用索引:
Select id from t with(index)其中num=@num。
8.盡量避免對where子句中的字段進行表達式操作，這將導致引擎放棄使用索引並掃描整個表。比如:
select id from t其中num/2=100
應改為:
select id from t where num = 100 * 2
9.應盡可能避免where子句中對字段的函數操作，這將導致引擎放棄使用索引並掃描整個表。比如:
select id from where substring(name，1，3)= ' abc '-以ABC開頭的名稱ID。
Select id from where datediff(日，創建日期，' 2005-11-30 ')= 0-' 2005-11-30 '生成的id。
應改為:
從t中選擇id，其中名稱如“abc%”
select id from t where create date & gt；='2005-11-30 '並創建日期& lt'2005-12-1'
10.不要在where子句中的“=”左側執行函數、算術運算或其他表達式運算，否則系統可能無法正確使用索引。
11.使用索引字段作為條件時，如果索引是復合索引，則必須將索引中的第壹個字段作為條件，以保證系統使用該索引，否則不會使用該索引，並且字段順序應盡可能與索引順序壹致。
12.不要寫壹些無意義的查詢。如果需要生成空表結構:
select col1，col2 into #t from t其中1=0
這種代碼不會返回任何結果集，但是會消耗系統資源。應該改成這樣:
創建表#t(...)
13.在很多時候用exists代替是壹個不錯的選擇:
從a中選擇編號，其中編號在(從b中選擇編號)
替換為以下語句:
select num from a where exists(select 1 from b where num = a . num)
14.並非所有索引都對查詢有效。SQL根據表中的數據優化查詢。當索引列中有大量重復數據時，SQL查詢可能不會使用索引。舉個例子，如果壹個表中有差不多壹半的字段，男性和女性，那麽即使索引建立在性別上，也不會對查詢效率起到作用。
15.索引越多越好。雖然索引可以提高相應選擇的效率，但也會降低插入和更新的效率。因為索引可能會在插入或更新期間重建，所以如何建立索引需要根據具體情況仔細考慮。壹個表中的索引數不應超過6。如果索引太多，就要考慮是否有必要在壹些不常用的列上建立索引。
16.應盡可能避免更新聚集索引數據列，因為聚集索引數據列的順序就是表記錄的物理存儲順序。壹旦列值發生變化，整個表記錄的順序都會進行調整，這將消耗相當大的資源。如果應用程序系統需要頻繁更新聚集索引數據列，則有必要考慮是否應該將索引構建為聚集索引。
17.嘗試使用數值字段。如果字段只包含數值信息，盡量不要設計成字符，這樣會降低查詢和連接的性能，增加存儲開銷。這是因為引擎在處理查詢和連接時會逐個比較字符串中的每個字符，但是對於number類型只比較壹次就夠了。
18.盡可能用varchar/nvarchar代替char/nchar，因為首先變長字段的存儲空間小，可以節省存儲空間，其次對於查詢來說，在相對較小的字段中搜索效率明顯更高。
19.不要在任何地方使用select * from t，用特定的字段列表替換“*”，不要返回任何不需要的字段。
20.盡量使用表變量，而不是臨時表。如果表變量包含大量數據，請註意索引非常有限(只有主鍵索引)。
21.避免頻繁創建和刪除臨時表，以減少系統表資源的消耗。
22.臨時表並非不可用。正確使用它們可以使壹些例程更加有效，例如，當需要重復引用大型表或公共表中的數據集時。但是，對於壹次性事件，最好使用導出表。
23.創建臨時表時，如果壹次插入大量數據，可以用select into代替create table，避免創建大量日誌，提高速度；如果數據量不大，為了減輕系統表的資源，應該先創建表然後再插入。
24.如果使用臨時表，壹定要在存儲過程的末尾顯式刪除所有臨時表，先truncate table table，然後drop table table，以免長時間鎖定系統表。
25.盡量避免使用遊標，因為遊標的效率很差。如果遊標操作的數據超過654.38+0百萬行，那麽就要考慮重寫了。
26.在使用基於遊標的方法或臨時表方法之前，首先要找到壹個基於集合的方法來解決問題，基於集合的方法通常更有效。
27.與臨時表壹樣，遊標也不是不可用的。對小數據集使用FAST_FORWARD遊標通常優於其他逐行處理方法，尤其是在必須引用多個表來獲取所需數據時。在結果集中包含“Total”的例程通常比使用遊標更快。如果開發時間允許，基於光標的方法和基於集合的方法都可以嘗試，看哪種方法效果更好。
28.在所有存儲過程和觸發器的開頭設置SET NOCOUNT ON，在結尾設置set SET NOCOUNT OFF。在執行完存儲過程和觸發器的每壹條語句後，不需要向客戶端發送DONE_IN_PROC消息。
29.盡量避免大事務操作，提高系統並發性。
30.盡量避免向客戶端返回大量數據。如果數據量過大，就要考慮相應的要求是否合理。
1.避免將該字段設置為“允許空”
2、數據表設計要規範。
3.深入分析數據操作對數據庫的操作。
4.盡量不要使用臨時表。
5.使用更多交易
6.盡量不要使用遊標。
7.避免死鎖
8.註意讀寫鎖的使用。
9.不要打開大型數據集。
10.不要使用服務器端光標。
11.編寫程序時使用大型數據庫。
12.不要為性別列創建索引。
13，註意超時問題
14，不要使用Select *
15.在明細表中插入記錄時，不要在主表中執行Select MAX(ID)。
16.盡量不要使用文本數據類型。
17，使用參數查詢
18，不要用Insert導入大量數據。
19，學會分析和查詢
20.使用參照完整性
21，用內連接和左連接替換Where。
提高SQL查詢的效率(要點和技巧)；
提示1:
問題類型:當ACCESS數據庫字段包含日語片假名或其他未知字符時，查詢會提示內存溢出。
解決方法:修改查詢語句。
SQL = " select * from tablename where column like“%”& amp；單詞& amp%'"
代替
sql="select * from tablename "
rs.filter = " column like ' % " & amp單詞& amp%'"
===========================================================
提示2:
問題類型:如何用簡單的方式實現類似百度的多關鍵詞查詢(多個關鍵詞之間用空格或其他符號隔開)。
解決方案:
//用空格分割查詢字符串
ck=split(單詞，" ")
//獲取除以的數量
sck =欠載(ck)
sql="select * tablename where "
字段中的查詢
對於i = 0至sck
SQL = SQL & amptempJoinWord & amp"(" & amp_
“列像”& ampck(壹)& amp%')"
tempJoinWord = " and "
然後
同時在兩個字段中查詢
對於i = 0至sck
SQL = SQL & amptempJoinWord & amp"(" & amp_
“列像”& ampck(壹)& amp“%”或“& amp_
" column 1 like " & amp；ck(壹)& amp%')"
tempJoinWord = " and "
然後
===========================================================
技巧三:大大提高查詢效率的幾個技巧。
1.盡量不要使用or，這樣會造成全表掃描，大大降低查詢效率。
2.實踐證明，charindex()對查詢效率的提升不會超過% like，charindex()會使索引變得無用(參考sqlserver數據庫)。
3.類似“%”的列& amp單詞& amp“%”將使索引無用。
像“”& amp單詞& amp“%”將使索引有效(刪除前面的%符號)。
(指sqlserver數據庫)
4.% " & amp單詞& amp“%”和“&；單詞& amp查詢中% '的差異:
比如妳的領域內容是壹個脆弱的女人。
% " & amp單詞& amp“%”:所有字符串都將是通配符，無論“受傷”還是“壹”都將顯示結果。
“& amp單詞& amp“%”:只有前面的字符串是通配符。比如搜索“受傷”沒有結果，只有搜索“壹個”才會顯示結果。
5.字段提取要遵循“需要多少取多少”的原則，避免“選擇*”，盡量使用“選擇字段1，字段2，字段3 ...”。實踐證明，每少抽取壹個字段，數據抽取的速度就會相應提高。提升的速度取決於妳丟棄的字段的大小。
6.order by是按聚集索引列進行最有效的排序。壹個sqlserver數據表只能建立壹個聚集索引，默認情況下通常為ID，也可以更改為其他字段。
7.為妳的表建立壹個合適的索引，可以讓妳的查詢速度提高幾十倍甚至上百倍。(指sqlserver數據庫)
下面是有索引和沒有索引時查詢效率的分析:
Sqlserver索引和查詢效率分析。
餐桌新聞
領域
Id:自動編號
標題:文章的標題
作者:作者
內容:內容
星號:優先級
添加時間:時間
記錄:654.38+0萬。
測試機器:P4 2.8/1G內存/IDE硬盤。
=======================================================
方案1:
主鍵Id，默認情況下是聚集索引。不會建立其他非聚集索引。
select * from News where Title like“%”& amp；單詞& amp“%”或類似“%”的作者& amp單詞& amp“%”按Id排序desc
從標題和作者字段進行模糊檢索，按Id排序。
查詢時間:50秒
=======================================================
選項2:
主鍵Id，默認為聚集索引。
建立標題、作者和星號的非聚集索引。
select * from News where Title like ' " & amp；單詞& amp% '或作者喜歡' " & amp單詞& amp“%”按Id排序desc
從標題和作者字段進行模糊檢索，按Id排序。
查詢時間:2-2.5秒
=======================================================
選項3:
主鍵Id，默認為聚集索引。
建立標題、作者和星號的非聚集索引。
select * from News where Title like ' " & amp；單詞& amp% '或作者喜歡' " & amp單詞& amp“%”按明星desc排序
標題和作者字段的模糊檢索，按星號排序。
查詢時間:2秒
=======================================================
選項4:
主鍵Id，默認為聚集索引。
建立標題、作者和星號的非聚集索引。
select * from News where Title like ' " & amp；單詞& amp% '或作者喜歡' " & amp單詞& amp%'
從標題和作者字段進行模糊檢索，不排序。
查詢時間:1.8-2秒
=======================================================
選項5:
主鍵Id，默認為聚集索引。
建立標題、作者和星號的非聚集索引。
select * from News where Title like ' " & amp；單詞& amp%'
或者
從作者喜歡的新聞中選擇。單詞& amp%'
從字段標題或作者中檢索，不排序。
查詢時間:1秒
如何提高SQL語言的查詢效率？
問:如何提高SQL語言的查詢效率？
答:這得從頭說起:
因為SQL是面向結果的查詢語言而不是面向過程的查詢語言，所以通常支持SQL的大型關系數據庫使用基於查詢成本的優化器來為實時查詢提供最佳的執行策略。對於優化器，輸入是查詢語句，輸出是執行策略。
壹條SQL查詢語句可以有多種執行策略，優化器會在所有執行方法中估計出花費時間最少的所謂成本最低的方法。所有的優化都是基於用戶使用的查詢語句中的where子句，優化器主要使用where子句中的Serach參數進行優化。
搜索參數的核心思想是數據庫利用表中字段的索引來查詢數據，而不是直接查詢記錄中的數據。
With =，
Emp_id = "10001 "或工資> 3000或a =1且c = 7。
以下不是搜索參數:
Salary = emp_salary或dep_id！= 10或薪金* 12 > = 3000或a=1或c=7。
應該盡量提供壹些冗余的搜索參數，讓優化器有更多的選擇。請看以下三種方法:
第壹種方法:
select employee.emp_name，department . dep _ name from department，employee where(employee . dep _ id = department . dep _ id)and(department . dep _ code = " 01 ")and(employee . dep _ code = " 01 ")；
其搜索分析結果如下:
估計2次I/O操作
使用主鍵掃描部門
對於dep_code等於“01”的行
估計到達這裏1次
按順序掃描員工
估計到達這裏5次
第二種方法:
select employee.emp_name，department . dep _ name from department，employee where(employee . dep _ id = department . dep _ id)and(department . dep _ code = " 01 ")；
其搜索分析結果如下:
估計2次I/O操作
使用主鍵掃描部門
對於dep_code等於“01”的行
估計到達這裏1次
按順序掃描員工
估計到達這裏5次
第壹種方法與第二種方法壹樣有效，但是第壹種方法是最好的，因為它為優化器提供了更多的選擇。
第三種方法:
select employee.emp_name，department . dep _ name from department，employee where(employee . dep _ id = department . dep _ id)and(employee . dep _ code = " 01 ")；
這種方法是最差的，因為它不能使用索引，也就是說，它不能被優化...
使用SQL語句時，請註意以下幾點:
1.避免使用不兼容的數據類型。比如Float和Integer，Char和Varchar，Binary和Long Binary是不兼容的。數據類型的不兼容可能會阻止優化器執行壹些本來可以完成的優化操作。例如:
select emp_name form雇員，其中薪金& gt3000;
在這個語句中，如果salary是Float類型，那麽優化器就很難對其進行優化，因為3000是壹個整數，所以我們應該在編程中使用3000.0，而不是在運行時等待DBMS對其進行轉換。
2.盡量不要使用表達式，因為編譯時無法獲取，所以SQL只能用其平均密度來估計將要命中的記錄數。
3.避免對搜索參數使用其他數學運算符。比如:
select EMP _ name from employee where salary * 12 & gt；3000;
應改為:
select emp_name from員工where salary & gt250;
4、避免使用！=或者
口腔應用
A 16萬數據表-短信上行表TBL _短信_莫
結構:
創建表TBL_SMS_MO
（
SMS_ID號碼，
MO_ID VARCHAR2(50)，
移動VARCHAR2(11)，
SPNUMBER VARCHAR2(20)，
消息VARCHAR2(150)，
TRADE_CODE VARCHAR2(20)，
LINK_ID VARCHAR2(50)，
網關標識號，
網關端口號，
MO_TIME日期默認系統日期
);
在TBL月日創建索引IDX月日
PCTFREE 10
INITRANS 2
MAXTRANS 255
儲存；儲備
（
初始1M
下壹個1M
MINEXTENTS 1
MAXEXTENTS無限制
百分比增加0
);
在TBL移動電話上創建IDX移動電話索引
PCTFREE 10
INITRANS 2
MAXTRANS 255
儲存；儲備
（
初始64K
下壹個1M
MINEXTENTS 1
MAXEXTENTS無限制
百分比增加0
);
問題:從表中查詢手機在壹定時間內發送的短信，如以下SQL語句所示:
選擇手機、消息、交易代碼、時間
從TBL發來的短信
其中MOBILE='130XXXXXXXX '
以及到日期(' 2006-04-01 '，' YYYY-MM-DD HH24:MI:SS ')和到日期(' 2006-04-07 '，' YYYY-MM-DD HH24:MI:SS ')之間的MO_TIME
按DESC時間順序
返回結果大約需要10分鐘，對於web查詢來說是無法承受的。
分析:
在PL/SQL Developer中，點擊“解釋計劃”按鈕(或F5鍵)分析SQL，發現默認索引為IDX _莫_日期。問題可能就在這裏，因為相對於1600萬的數據總量，杜移動的數據量很小，如果用_MO_MOBILE更容易鎖定數據。
優化如下:
SELECT/*+index(TBL _短信_莫IDX _莫_手機)*/手機，消息，交易代碼，莫_時間
從TBL發來的短信
其中MOBILE='130XXXXXXXX '
以及到日期(' 2006-04-01 '，' YYYY-MM-DD HH24:MI:SS ')和到日期(' 2006-04-07 '，' YYYY-MM-DD HH24:MI:SS ')之間的MO_TIME
按DESC時間順序
測試:
按F8運行這個SQL，哇~......2.360s，這就是區別。
blogs . com/ShaYeBlog/archive/2013/07/31/3227244 . html