1、使用索引來更快地遍歷表。
缺省情況下建立的索引是非羣集索引，但有時它並不是最佳的。在非羣集索引下，數據在物理上隨機存放在數據頁上。合理的索引設計要建立在對各種查詢的分析和預測上。一般來說：
a.有大量重複值、且經常有範圍查詢（ > ,< ，> =,< =）和order by、group by發生的列，可考慮建立羣集索引；
b.經常同時存取多列，且每列都含有重複值可考慮建立組合索引；
c.組合索引要儘量使關鍵查詢形成索引覆蓋，其前導列一定是使用最頻繁的列。索引雖有助於提高性能但不是索引越多越好，恰好相反過多的索引會導致系統低效。用戶在表中每加進一個索引，維護索引集合就要做相應的更新工作。
2、在海量查詢時儘量少用格式轉換。
3、ORDER BY和GROPU BY使用ORDER BY和GROUP BY短語，任何一種索引都有助於SELECT的性能提高。
4、任何對列的操作都將導致表掃描，它包括數據庫函數、計算表達式等等，查詢時要儘可能將操作移至等號右邊。
5、IN、OR子句常會使用工作表，使索引失效。如果不產生大量重複值，可以考慮把子句拆開。拆開的子句中應該包含索引。
Sql的優化原則：
1、只要能滿足你的需求，應儘可能使用更小的數據類型：例如使用MEDIUMINT代替INT
2、儘量把所有的列設置爲NOT NULL，如果你要保存NULL，手動去設置它，而不是把它設爲默認值。
3、儘量少用VARCHAR、TEXT、BLOB類型
4、如果你的數據只有你所知的少量的幾個。最好使用ENUM類型
5、正如graymice所講的那樣，建立索引。
以下是我做的一個實驗，可以發現索引能極大地提高查詢的效率：
我有一個會員信息表users，裏邊有37365條用戶記錄：
在不加索引的時候進行查詢：
sql語句A:
在Mysql-Front中的8次查詢時長爲：1.40,0.54,0.54,0.54,0.53,0.55,0.54 共找到960條記錄
sql語句B:
在Mysql-Front中的8次查詢時長爲：0.53,0.53,0.53,0.54,0.53,0.53,0.54,0.54 共找到836條記錄
sql語句C:
在Mysql-Front中的8次查詢時長爲：0.51,0.51,0.52,0.52,0.51,0.51,0.52,0.51 共找到7條記錄
爲username列添加索引:
再次查詢：
sql語句A:
在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.1 IN、OR子句常會使用工作表，使索引失效。如果不產生大量重複值，可以考慮把子句拆開。拆開的子句中應該包含索引。這句話怎麼理解決，請舉個例子
例子如下:
如果在fields1和fields2上同時建立了索引，fields1爲主索引
以下sql會用到索引
以下sql不會用到索引
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,deptno from emp where trunc(hiredate)='01-MAY-81';
把上面的語句改成下面的語句，這樣就可以通過索引進行查找。
select empno,ename,deptno from emp where hiredate<(to_date('01-MAY-81')+0.9999);
7.4 比較不匹配的數據類型
比較不匹配的數據類型也是比較難於發現的性能問題之一。注意下面查詢的例子，account_number是一個VARCHAR2類型，在account_number字段上有索引。下面的語句將執行全表掃描。
select bank_name,address,city,state,zip from banks where account_number = 990354;
Oracle可以自動把where子句變成to_number(account_number)=990354，這樣就限制了索引的使用,改成下面的查詢就可以使用索引：
select bank_name,address,city,state,zip from banks where account_number ='990354';
特別注意：不匹配的數據類型之間比較會讓Oracle自動限制索引的使用，即便對這個查詢執行Explain Plan也不能讓您明白爲什麼做了一 次“全表掃描”。
補充:
1.索引帶來查詢上的速度的大大提升,但索引也佔用了額外的硬盤空間(當然現在一般硬盤空間不成問題),而且往表中插入新記錄時索引也要隨着更新這也需要一定時間。有些表如果經常insert,而較少select,就不用加索引了.不然每次寫入數據都要重新改寫索引,花費時間; 這個視實際情況而定,通常情況下索引是必需的。
2.我在對查詢效率有懷疑的時候,一般是直接用Mysql的Explain來跟蹤查詢情況。你用Mysql-Front是通過時長來比較,我覺得如果從查詢時掃描字段的次數來比較更精確一些。
