本文爲原創，如需轉載，請註明作者和出處，謝謝！
關於 select * from O1,O2......
至於爲何要進行數據庫優化，就不在這裏重述了。
在做項目的時候，如何最大限度的提高sql的查詢效率，應該是大家永遠的話題：
在這裏，將本着謹慎的，簡單的態度，一點一點的講述sql數據查詢語句的優化問題：
一，關於索引：
使用索引的合理性：
條件子句中變量順序應與索引字鍵順序相同。（儘可能在join和order by 的字段上建立索引）將最具有限制性的條件放在前面，大值在前，小值在後。
eg:...where O.a <1000 and O.a>200 效率高於 where O.a>200 and O.a<1000
...where O.a between 200 and 1000 效率高於 where O.a>200 and O.a<1000
二，關於通配符：
避免採用MATCHES和LIKE通配符匹配查詢：
由於採用like等通配符查詢時，sql優化器實際上還是用順序搜索的方法來查詢的，也就是說，在被查詢的字段上建立的索引實際上是不起作用的。
eg:...where O.b <‘12399’ and O.b>‘123000 ’ 效率高於 where O.b matche ‘123*’
三，關於子查詢：
查詢嵌套層次越多，效率越低，因此應當儘量避免子查詢。假如子查詢不可避免，那麼要在子查詢中過濾掉儘可能多的行。
eg:...from O1,O2 where O1.c=O2.c and O2.a=2009 效率高於 from O1 where O1.c in(select O2.c from O2 where O2.a=2009)
四，關於順序存取時的嵌套查詢：
在進行大數據量的索引歸類時，有些形式的where子句會強迫優化器使用順序存取，從而使得原索引字段失效。
eg:...where (O.d = 123 and O.a>200 ) union O.b=1010 效率高於 where (O.d = 123 and O.b>200) or O.b=1010
五，關於臨時表：
使用臨時表加速查詢
把表的一個子集進行排序並創建臨時表，有時能加速查詢。注意：臨時表創建後不會反映主表的修改。在主表中數據頻繁修改的情況下，注重不要丟失數據。
eg:...select unique tO1 into temp tO1 "然後（then）"select count(*)from temp tO1 效率高於select count(distinct)
六，關於聚集函數：
1.對於大數據量的求和應避免使用單一的sum命令處理，可採用group by方式與其結合，有時會大大提高效率。
2.避免會引起磁盤讀寫的 rowid* 等操作。在where子句中或select語句中，用rowid要產生磁盤讀寫，是一個物理過程，會影響sql性能。