【java】itoo項目實戰之百萬資料查詢最佳化收集與實踐,itoo資料查詢
1.對查詢進行最佳化,應考慮在where 及 order by 涉及的列上建立索引。
2.應盡量避免在where 子句中對欄位進行 null值判斷,如: select id from t wherenum is null
可以在num上設定預設值0,確保表中num列沒有null值,然後這樣查詢:
select idfrom t where num=0
3.應盡量避免在where 子句中使用!=或<>操作符。
4.應盡量避免在where 子句中使用 or 來串連條件,如:
select idfrom t where num=10 or num=20
可以這樣查詢:
select idfrom t where num=10
unionall
select idfrom t where num=20
5.in 和 not in也要慎用,如:
select idfrom t where num in(1,2,3)
對於連續的數值,能用between 就不要用 in 了:
select idfrom t where num between 1 and3
6.下面的查詢也將導致全表掃描:
select idfrom t where name like '%abc%'
7.應盡量避免在where 子句中對欄位進行運算式操作,如:
select idfrom t where num/2=100
應改為:
select idfrom t where num=100*2
8.應盡量避免在where子句中對欄位進行函數操作,
9.不要在 where子句中的“=”左邊進行函數、算術運算或其他運算式運算,否則系統將可能無法正確使用索引。
10.在使用索引欄位作為條件時,如果該索引是複合索引,那麼必須使用到該索引中的第一個欄位作為條件時才能保證系統使用該索引,
否則該索引將不會被使用,並且應儘可能的讓欄位順序與索引順序相一致。
以上10條可以總結為:避免全表掃描,正確使用索引
11.不要寫一些沒有意義的查詢,如需要產生一個空表結構:
selectcol1,col2 into #t from t where1=0
這類代碼不會返回任何結果集,但是會消耗系統資源的,應改成這樣:
create table#t(...)
12.很多時候用exists 代替 in 是一個好的選擇:
select numfrom a where num in(select num fromb)
用下面的語句替換:
select numfrom a where exists(select 1 from b wherenum=a.num)
13.並不是所有索引對查詢都有效,SQL是根據表中資料來進行查詢最佳化的,當索引列有大量資料重複時,SQL查詢可能不會去利用索引,
如一表中有欄位sex,male、female幾乎各一半,那麼即使在sex上建了索引也對查詢效率起不了作用。
14.索引並不是越多越好,索引固然可以提高相應的select 的效率,但同時也降低了 insert 及 update的效率,
因為 insert 或update時有可能會重建索引,所以怎樣建索引需要謹慎考慮,視具體情況而定。
一個表的索引數最好不要超過6個,若太多則應考慮一些不常使用到的列上建的索引是否有必要。
15.盡量使用數字型欄位,若只含數值資訊的欄位盡量不要設計為字元型,這會降低查詢和串連的效能,並會增加儲存開銷。
這是因為引擎在處理查詢和串連時會逐個比較字串中每一個字元,而對於數字型而言只需要比較一次就夠了。
16.儘可能的使用varchar 代替 char,因為首先變長欄位儲存空間小,可以節省儲存空間,
其次對於查詢來說,在一個相對較小的欄位內搜尋效率顯然要高些。
17.任何地方都不要使用select * from t,用具體的欄位列表代替“*”,不要返回用不到的任何欄位。
18.避免頻繁建立和刪除暫存資料表,以減少系統資料表資源的消耗。
19.在建立暫存資料表時,如果一次性插入資料量很大,那麼可以使用select into 代替 create table,避免造成大量 log,
以提高速度;如果資料量不大,為了緩和系統資料表的資源,應先createtable,然後insert。
20.盡量避免使用遊標,因為遊標的效率較差,如果遊標操作的資料超過1萬行,那麼就應該考慮改寫。
21.使用基於遊標的方法或暫存資料表方法之前,應先尋找基於集的解決方案來解決問題,基於集的方法通常更有效。
22.盡量避免大事務操作,提高系統並發能力。
23.盡量避免向用戶端返回大資料量,若資料量過大,應該考慮相應需求是否合理。
通過做itoo從V1.0 到V3.0,加上以前做的項目,其實在做SQL最佳化的時候,可是從平常的個人習慣開始的,不需要等到資料量多的時候,發現查詢資料很慢很慢了,才去絞盡腦汁想辦法最佳化,在資料量小的時候就開始考慮資料量大的時候會出現什麼問題,這個需要我們從點滴開始做起,需要我們擁有胸懷,有了胸懷,才會考慮長遠問題。
著作權聲明:本文為博主原創文章,未經博主允許不得轉載。