性能不理想的系統中除了一部分是因為應用程序的負載確實超過了服務器的實際處理能力外,更多的是因為系統存在大量的SQL語句需要優化。為了獲得穩定的執行性能，SQL語句越簡單越好。對復雜的SQL語句，要設法對之進行簡化提高它的解決效率。
當看到一個SQL語句帶來了性能問題的時候，首先要看看它的執行計劃。看看他是否走了你所期望的索引。物理讀邏輯讀是不是在合理的范圍之內？對于這類的性能問題，可以追溯到表的設計階段，例如，為 了保證數據庫的一致性和完整性，在邏輯設計的時候往往會設計過多的表間關聯，盡可能的降低數據的冗余，然而，為了提高系統的響應時間，合理的數據冗余也是必要的。設計人員在設計階段應根據系統操作的類型、頻度加以均衡考慮。下面我們來談談優化的技巧：
【1】表設計的優化
1、數據行的長度不要超過8020字節，如果超過這個長度的話在物理頁中這條數據會占用兩行從而造成存儲碎片，降低查詢效率。
2、能夠用數字類型的字段盡量選擇數字類型而不用字符串類型的。
3、對于不可變字符類型char和可變字符類型 都是8000字節,char查詢快，但是耗存儲空間，查詢相對慢一些但是節省存儲空間。
4、字段的長度在最大限度的滿足可能的需要的前提下，應該盡可能的設得短一些，這樣可以提高查詢的效率，而且在建立索引的時候也可以減少資源的消耗。
5、字段順序對存儲效率也有不小的影響。在做表結構設計的時候，我們往往不會去考慮字段的擺放順序。但是，實際上字段的擺放順序對數據庫操作的性能是有影響的。
6、針對各種類型的表來存儲各種類型的數據
【2】 語句的查詢優化
1、保證在實現功能的基礎上，盡量減少對數據庫的訪問次數；
2、通過搜索參數，盡量減少對表的訪問行數,最小化結果集，從而減輕網絡負擔；能夠分開的操作盡量分開處理，提高每次的響應速度；
3、在數據窗口使用SQL時，盡量把使用的索引放在選擇的首列；算法的結構盡量簡單；
4、在查詢時sql時間區間查詢效率，不要過多地使用通配符如 * FROM T1語句，要用到幾列就選擇幾列如： COL1,COL2 FROM T1；
5、在可能的情況下盡量限制盡量結果集行數如： TOP 300 COL1,COL2,COL3 FROM T1,因為某些情況下用戶是不需要那么多的數據的。
6、在沒有建索引的情況下，數據庫查找某一條數據，就必須進行全表掃描了，對所有數據進行一次遍歷，查找出符合條件的記錄。
7、在數據量比較小的情況下，也許看不出明顯的差別，但是當數據量大的情況下，這種情況就是極為糟糕的了。
8、合理的使用臨時表。例如表A 的 ID 字段有索引，并且這個表的數據有很多。這時候要查詢這個ID 的最大值與最小值，如果能合理使用臨時表，速度將大幅度提高！
9、多層的子查詢需要進行簡單化。
【3】建立高效的索引
創建索引一般有以下兩個目的：維護被索引列的唯一性和提供快速訪問表中數據的策略。大型數據庫有兩種索引即簇索引和非簇索引，一個沒有簇索引的表是按堆結構存儲數據，所有的數據均添加在表的尾部，而建立了簇索引的表，其數據在物理上會按照簇索引鍵的順序存儲sql時間區間查詢效率，一個表只允許有一個簇索引，因此，根據B樹結構，可以理解添加任何一種索引均能提高按索引列查詢的速度，但會降低插入、更新、刪除操作的性能，尤其是當填充因子（Fill ）較大時。所以對索引較多的表進行頻繁的插入、更新、刪除操作，建表和索引時因設置較小的填充因子，以便在各數據頁中留下較多的自由空間，減少頁分割及重新組織的工作。據說大部分的數據庫性能問題都可以采用索引技術得到解決。
【4】 強制查詢轉換
有時候 的優化器未必能走正確的查詢路線，這個時候就需要添加一些hint 之類的來規定他的執行路線。當然了，這個未必是最好的處理方案。因為雖然現在走這個路線是對的，以為因為數據的變化到這這個HINT 變得不可取！
【經驗之談】
在日常我們開發的系統中有很多的SQL 語句被寫成N層嵌套，我們應該在了解了業務之后，將復雜的SQL 改成多個簡單的語句逐步處理，再或者用with as 語法，這個可以解決不少的性能的問題。再者，很多朋友不會使用分析函數，認為它會帶來一定的性能問題，其實這是錯的。使用分析函數的查詢，不但語法簡潔，查詢效率來看比自己拼得多層查詢的效率要好很多。
以上為個人觀點，供大家參考，因為每個公司的業務邏輯不同，所采用的方法也不盡相同，我們只能做的讓它變的更好，在大數據領域沒有最好。