使用SQL時必須考慮的關鍵因素
一，獲得結果集所需訪問的數據量，在沒有確定目標容量之前，很難斷定查詢執行的效率；
二，定義結果集所需的查詢條件，也就是如何限定結果集，如何合理的使用sql子句；
三，結果集的大小，取決於表的大小和過濾條件的細節，但不都是這樣，典型的情況是，若干個獨立使用時效率不高的條件，結合起來使用時會產生很高的效率。比如說：“是不否獲得理科學位或文科學位”作爲查詢學生姓名的條件，結果集很大。但同時使用這兩個條件（雙學位），則產生的結果集大小就會大幅縮小。還有一個很意思的地方，用戶最終的感覺也非常重要，用戶的耐心，在很大程度上和預期返回的記錄條數有關：用戶只檢索一條記錄，則他期望非常快，而有時檢索一條記錄也需要訪問整個數據庫，令最終用戶沮喪的事情莫過於等了很久卻看到“無相符數據”的結果，所以好的開發者應該讓返回少量記錄或不返回記錄的查詢儘量快，原則就是，無論何時，只要查詢有可能返回零結果集時，都應該先檢查那個最大可能導致空結果集的條件。
四，獲得結果集所涉及的表的數量，表的數量影響最大的無疑是join操作。其實，現代DBMS都能比較高效地連接很多表，這可能會當前許多初學者的認識相悖。當然連接大量表時會產生一些額外的問題，
1）當需要連接很多表時，按常理你應該懷疑你的設計的正確性；
2）對於優化器來說，隨着表數量的增加，複雜度將呈指數增長。
3）編寫涉及多表的複雜查詢，若可以進行連接的方式有好多種，增加了分析優化器進行優化的難度，最終選擇出的連接路徑很可能是錯誤的。
當有還有一個問題需要注意，有時我們需要在使用複雜查詢時，如果既可以通過已定義的視圖來獲得數據，也可以通過分解視圖，將其組成部分變成sql語句加到查詢主體中，那麼常常應該採用後者，因爲這樣可以減少不必要的聯接視圖的操作，儘管需要sql編程技巧有所要求。（其實，oracle中的物化視圖中查詢重寫中用到了跟這相反的機制，當然這二者的目的是不一樣的。）
五，多少用戶會同時修改這些數據。也就是說寫數據庫操作必須關注併發性，是否存在block的訪問爭用、阻塞，或者閂定（DBMS內部資源阻塞）。還有一種情況，比如說，排序操作可能會沒有足夠內存可用，於是轉而求助於磁盤，引發新的資源爭用。