sql優化
一 索引原理機制
1 索引類型 : B-tree索引,哈希索引。
2 索引的本質: 索引是一種數據結構,類似于查字典一樣。
二、數據表設計:
為了保證數據庫的一致性和完整性,在邏輯設計的時候往往會設計過多的表間關聯,盡可能的降低數據的冗余。(例如用戶表的地區,我們可以把地區另外存放到一個地區表中)如果數據冗余低,數據的完整性容易得到保證,提高了數據吞吐速度,保證了數據的完整性,清楚地表達數據元素之間的關系。而對于多表之間的關聯查詢(尤其是大數據表)時,其性能將會降低,同時也提高了客戶端程序的編程難度,因此,物理設計需折衷考慮,根據業務規則,確定對關聯表的數據量大小、數據項的訪問頻度,對此類數據表頻繁的關聯查詢應適當提高數據冗余設計但增加了表間連接查詢的操作,也使得程序的變得復雜,為了提高系統的響應時間,合理的數據冗余也是必要的。設計人員在設計階段應根據系統操作的類型、頻度加以均衡考慮。
另外,最好不要用自增屬性字段作為主鍵與子表關聯。不便于系統的遷移和數據恢復。對外統計系統映射關系丟失.
三、 表的設計具體注意的問題:
1、數據行的長度不要超過8020字節,如果超過這個長度的話在物理頁中這條數據會占用兩行從而造成存儲碎片,降低查詢效率。
2、能夠用數字類型的字段盡量選擇數字類型而不用字符串類型的(電話號碼),這會降低查詢和連接的性能,并會增加存儲開銷。這是因為引擎在處理查詢和連接回逐個比較字符串中每一個字符,而對于數字型而言只需要比較一次就夠了。
3、對于不可變字符類型char和可變字符類型varchar 都是8000字節,char查詢快,但是耗存儲空間,varchar查詢相對慢一些但是節省存儲空間。在設計字段的時候可以靈活選擇,例如用戶名、密碼等長度變化不大的字段可以選擇CHAR,對于評論等長度變化大的字段可以選擇VARCHAR。
4、字段的長度在最大限度的滿足可能的需要的前提下,應該盡可能的設得短一些,這樣可以提高查詢的效率,而且在建立索引的時候也可以減少資源的消耗。
四、查詢的優化
保證在實現功能的基礎上,盡量減少對數據庫的訪問次數;
通過搜索參數,盡量減少對表的訪問行數,最小化結果集,從而減輕網絡負擔;
能夠分開的操作盡量分開處理,提高每次的響應速度;
在數據窗口使用SQL時,盡量把使用的索引放在選擇的首列;
算法的結構盡量簡單;在查詢時,不要過多地使用通配符如SELECT * FROM T1語句,要用到幾列就選擇幾列。
- 應盡量避免在 where 子句中對字段進行 null 值判斷,否則將導致引擎放棄使用索引而進行全表掃描。
- 應盡量避免在 where 子句中使用!=或<>操作符,否則將引擎放棄使用索引而進行全表掃描。優化器將無法通過索引來確定將要命中的行數,因此需要搜索該表的所有行。
- 應盡量避免在 where 子句中使用 or 來連接條件,用union all代替or.
- 盡量避免在索引過的字符數據中,使用非打頭字母搜索。這也使得引擎無法利用索引。
- 用exist ,not exist 代替in.
- 必要時強制查詢優化器使用某個索引 select id from t with(index(索引名)) where num=@num.
- 應盡量避免在 where 子句中對字段進行表達式操作,算術計算和函數操作。
- 不要在 where 子句中的“=”左邊進行函數、算術運算或其他表達式運算。
- 避免頻繁創建和刪除臨時表,以減少系統表資源的消耗。
- 如果使用到了臨時表,在存儲過程的最后務必將所有的臨時表顯式刪除,先 truncate table ,然后 drop table ,這樣可以避免系統表的較長時間鎖定。
- 盡量避免大事務操作,提高系統并發能力。
- 使用視圖加速查詢 。表的一個子集進行排序并創建視圖,有時能加速查詢。它有助于避免多重排序 操作,而且在其他方面還能簡化優化器的工作。
- 能用UNION ALL就不要用UNION 。
五、算法的優化
盡量避免使用游標,因為游標的效率較差,如果游標操作的數據超過1萬行,那么就應該考慮改寫。
五、建立高效的索引
創建索引一般有以下兩個目的:維護被索引列的唯一性和提供快速訪問表中數據的策略。大型數據庫有兩種索引即簇索引和非簇索引,一個沒有簇索引的表是按堆結構存儲數據,所有的數據均添加在表的尾部,而建立了簇索引的表,其數據在物理上會按照簇索引鍵的順序存儲,一個表只允許有一個簇索引,因此,根據B樹結構,可以理解添加任何一種索引均能提高按索引列查詢的速度,但會降低插入、更新、刪除操作的性能,尤其是當填充因子(Fill Factor)較大時。所以對索引較多的表進行頻繁的插入、更新、刪除操作,建表和索引時因設置較小的填充因子,以便在各數據頁中留下較多的自由空間,減少頁分割及重新組織的工作。
浙公網安備 33010602011771號