1、使用索引來更快地遍歷表。
預設情況下建立的索引是非群集索引，但有時它並不是最佳的。在非群集索引下，資料在物理上隨機存放在資料頁上。合理的索引設計要建立在對各種查詢的分析和**上。一般來說：
a.有大量重複值、且經常有範圍查詢（> ,<，> =,< =）和order by、group by發生的列，可考
慮建立群集索引；
b.經常同時訪問多列，且每列都含有重複值可考慮建立組合索引；
c.組合索引要盡量使關鍵查詢形成索引覆蓋，其前導列一定是使用最頻繁的列。索引雖有助於提高效能但不是索引越多越好，恰好相反過多的索引會導致系統低效。
使用者在表中每加進乙個索引，維護索引集合就要做相應的更新工作。2、在海量查詢時盡量少用格式轉換。
3、order by和gropu by使用order by和group by短語，任何一種索引都有助於select的效能提高。
7、任何對列的操作都將導致表掃瞄，它包括資料庫函式、計算表示式等等，查詢時要盡可能將操作移至等號右邊。
4、in、or子句常會使用工作表，使索引失效。如果不產生大量重複值，可以考慮把子句拆開。拆開的子句中應該包含索引。sql的優化原則2：
1、只要能滿足你的需求，應盡可能使用更小的資料型別：例如使用mediumint代替int
2、盡量把所有的列設定為not null，如果你要儲存null，手動去設定它，而不是把它設為預設值。
3、盡量少用varchar、text、blob型別
4、如果你的資料只有你所知的少量的幾個。最好使用enum型別5、正如graymice所講的那樣，建立索引。
以下是我做的乙個實驗，可以發現索引能極大地提高查詢的效率：我有乙個會員資訊表users，裡邊有37365條使用者記錄：在不加索引的時候進行查詢：sql語句a:
select * from users where username like 』%許%』;
在mysql-front中的8次查詢時長為：1.40,0.54,0.54,0.54,0.53,0.55,0.54共找到960條記錄
sql語句b:
select * from users where username like 』許%』;
在mysql-front中的8次查詢時長為：0.53,0.
53,0.53,0.54,0.
53,0.53,0.54,0.
54共找到836條記錄sql語句c:
select * from users where username like 』%許』;
在mysql-front中的8次查詢時長為：0.51,0.51,0.52,0.52,0.51,0.51,0.52,0.51共找到7條記錄
為username列新增索引:
create index usernameindex on users(username(6));再次查詢：sql語句a:
select * from users where username like 』%許%』;
在mysql-front中的8次查詢時長為：0.35,0.
34,0.34,0.35,0.
34,0.34,0.35,0.
34共找到960條記錄sql語句b:
select * from users where username like 』許%』;
在mysql-front中的8次查詢時長為：0.06,0.
07,0.07,0.07,0.
07,0.07,0.06,0.
06共找到836條記錄sql語句c:
select * from users where username like 』%許』;
在mysql-front中的8次查詢時長為：0.32,0.31,0.31,0.32,0.31,0.32,0.31,0.31共找到7條記錄
在實驗過程中，我沒有另開任何程式，以上的資料說明在單錶查詢中，建立索引的可以極大地提高查詢速度。
另外要說的是如果建立了索引，對於like 』許%』型別的查詢，速度提公升是最明顯的。因此，我們在寫sql語句的時候也盡量採用這種方式查詢。對於多表查詢我們的優化原則是：
盡量將索引建立在：left join on/right join on ...＋條件，的條件語句中所涉及的字段上。多表查詢比單錶查詢更能體現索引的優勢。
6、索引的建立原則：
如果一列的中資料的字首重複值很少，我們最好就只索引這個字首。mysql支援這種索引。我在上面用到的索引方法就是對username最左邊的6個字元進行索引。索引越短，占用的
磁碟空間越少，在檢索過程中花的時間也越少。這方法可以對最多左255個字元進行索引。
在很多場合，我們可以給建立多列資料建立索引。
索引應該建立在查詢條件中進行比較的字段上，而不是建立在我們要找出來並且顯示的字段上
7、限制索引的使用的避歸。
7.1in、or子句常會使用工作表，使索引失效。
如果不產生大量重複值，可以考慮把子句拆開。拆開的子句中應該包含索引。這句話怎麼理解決，請舉個例子例子如下:
如果在fields1和fields2上同時建立了索引，fields1為主索引以下sql會用到索引
select * from tablename1 where fields1=』value1』 and fields2=』value2』以下sql不會用到索引
select * from tablename1 where fields1=』value1』 or fields2=』value2』7.2使用is null或is not null
使用is null或is not null同樣會限制索引的使用。因為null值並沒有被定義。在sql語句中使用null會有很多的麻煩。
因此建議開發人員在建表時，把需要索引的列設成not null。如果被索引的列在某些行中存在null值，就不會使用這個索引（除非索引是乙個位圖索引，關於位圖索引在稍後在詳細討論）。7.
3使用函式
如果不使用基於函式的索引，那麼在sql語句的where子句中對存在索引的列使用函式時，會使優化器忽略掉這些索引。下面的查詢不會使用索引（只要它不是基於函式的索引）
select empno,ename,deptnofromemp
wheretrunc(hiredate)='01-may-81';
把上面的語句改成下面的語句，這樣就可以通過索引進行查詢。select empno,ename,deptno
fromemp
wherehiredate<(to_date('01-may-81')+0.9999);7.4比較不匹配的資料型別
比較不匹配的資料型別也是比較難於發現的效能問題之一。注意下面查詢的例子，account_number是乙個varchar2型別，在account_number欄位上有索引。下面的語句將執行全表掃瞄。
select bank_name,address,city,state,zipfrombanks
whereaccount_number = 990354;
oracle可以自動把where子句變成to_number(account_number)=990354，這樣就限制了索引的使用,改成下面的查詢就可以使用索引：select bank_name,address,city,state,zipfrombanks
whereaccount_number ='990354';
特別注意：不匹配的資料型別之間比較會讓oracle自動限制索引的使用，即便對這個查詢執行explain plan也不能讓您明白為什麼做了一次「全表掃瞄」。補充:
1.索引帶來查詢上的速度的大大提公升,但索引也占用了額外的硬碟空間(當然現在一般硬碟空間不成問題),而且往表中插入新記錄時索引也要隨著更新這也需要一定時間.有些表如果經常insert,而較少select,就不用加索引了.
不然每次寫入資料都要重新改寫索引,花費時間;
這個視實際情況而定,通常情況下索引是必需的.
2.我在對查詢效率有懷疑的時候,一般是直接用mysql的explain來跟蹤查詢情況.你用mysql-front是通過時長來比較,我覺得如果從查詢時掃瞄欄位的次數來比較更精確一些.
SQL語句優化規律總結 ORACLE
1 from oracle的解析器按照從右到左的順序處理from子句中的表名，因此from子句中寫在最後的表 基礎表 driving table 將被最先處理.在from子句中包含多個表的情況下，你必須選擇記錄條數最少的表作為基礎表 放在where的最後 如果有3個以上的表連線查詢,那就需要選擇交叉...
通過分析SQL語句的執行計畫優化SQL 總結
做dba快7年了，中間感悟很多。在dba的日常工作中，調整個別效能較差的sql語句時一項富有挑戰性的工 作。其中的關鍵在於如何得到sql語句的執行計畫和如何從sql語句的執行計畫中發現問題。總是想將日常 經驗的點點滴滴總結一下，但是直到最近才下定決心，總共花了3個週末時間，才將其整理成冊，便於自 己...
SQL效能優化之索引技巧總結
1.將where語句中經常用到的列設定為索引。2.使用窄索引，例如int欄位，避免使用寬度過大的列作為索引。與char 4 相比，雖然長度一致，但仍然是int更適合作為索引列。4.使用高選擇性列作為索引，避免使用類似 性別 這樣不具備選擇性的列，這樣的索引不如不建。5.結合where語句的常用性，可...