效能提公升效果
優化成本
減少資料訪問
1~1000
低返回更少資料
1~100
低減少互動次數
1~20
低減少伺服器cpu開銷
1~5低
利用更多資源
@~10
高
select
idfrom t where
numis
null
null
,盡可能的使用
not null
填充資料庫
.
select
idfrom t where
num = 0
select
idfrom t where
num=10
orname = 'admin'
select
idfrom t where
num = 10
union allselect id
from t where
name = 'admin'
id
from t where
numin(1,2,3)
between
就不要用
in 了:
select
idfrom t where
numbetween
1and
3
代替
in 是乙個好的選擇:
select
numfrom a where
numin(select
numfrom b)
select
numfrom a where
exists(select
1from b where
num=a.num)
select
idfrom t where
name
like 『%abc%』
select
idfrom t where
num = @num
select
idfrom t with(index(索引名)) where
num = @num
where
子句中對字段進行表示式操作,這將導致引擎放棄使用索引而進行全表掃瞄。如:
select
idfrom t where
num/2 = 100
select
idfrom t wherenum = 100*2
where
子句中對字段進行函式操作,這將導致引擎放棄使用索引而進行全表掃瞄。如:
select
idfrom t
where
substring(
name,
1,3) = 』abc』 -–
name以abc開頭的
idselect
idfrom t
where
datediff(
day,createdate,』
2005
-11-30′) =
0 -–『
2005
-11-30』
--生成的id
select
idfrom t
where
name
like
'abc%'
select
idfrom t
where createdate >=
'2005-11-30'
and createdate <
'2005-12-1'
select col1,col2 into #t from t where
1=0
table #t(…)
update
全部字段,否則頻繁呼叫會引起明顯的效能消耗,同時帶來大量日誌。
14.對於多張大資料量(這裡幾百條就算大了)的表join,要先分頁再join,否則邏輯讀會很高,效能很差。
15.select count(*) from table;這樣不帶任何條件的count會引起全表掃瞄,並且沒有任何業務意義,是一定要杜絕的。
16.索引並不是越多越好,索引固然可以提高相應的 select 的效率,但同時也降低了 insert 及 update 的效率,因為 insert 或 update 時有可能會重建索引,所以怎樣建索引需要慎重考慮,視具體情況而定。乙個表的索引數最好不要超過6個,若太多則應考慮一些不常使用到的列上建的索引是否有 必要。
17.應盡可能的避免更新 clustered 索引資料列,因為 clustered 索引資料列的順序就是表記錄的物理儲存順序,一旦該列值改變將導致整個表記錄的順序的調整,會耗費相當大的資源。若應用系統需要頻繁更新 clustered 索引資料列,那麼需要考慮是否應將該索引建為 clustered 索引。
18.盡量使用數字型字段,若只含數值資訊的字段盡量不要設計為字元型,這會降低查詢和連線的效能,並會增加儲存開銷。這是因為引擎在處理查詢和連 接時會逐個比較字串中每乙個字元,而對於數字型而言只需要比較一次就夠了。
19.盡可能的使用
varchar/nvarchar
代替char/nchar ,因為首先變長字段儲存空間小,可以節省儲存空間,其次對於查詢來說,在乙個相對較小的字段內搜尋效率顯然要高些。
20.任何地方都不要使用 select * from table ,用具體的字段列表代替「*」,如:
不要返回用不到的任何字段。
資料庫之查詢優化
1 來自pg文件 postgresql使用的是基於成本的優化器 cost based optimizer 理論上基於成本的優化器會計算使用者輸入的查詢語句的每個合法的查詢計畫的執行成本,然後從中選擇成本最小的計畫作為執行查詢語句的 最終計畫。在實際應用中,查詢語句的合法的 查詢計畫的個數是隨查詢複雜...
資料庫優化方案
對查詢最有效果的優化,自然是建立索引了,id自然是自增 主鍵,這個前人已經做了 從where語句分析,時間字段作為查詢條件很多,時間是8位元組,而且不重複,設定索引比較適合。我把時間設定為索引,有一點效果,但不大,估算一下 8 4000 0000 320 000 000 位元組,4000萬記錄的表僅...
資料庫優化方案
1.sql 優化 2.索引 where 條件加索引 3.連線池 處理連線數問題,druid 4.快取 持久層快取 記憶體資料庫redis 5.分割槽 分成不同的檔案,不解決根本問題 6.儲存過程 業務 難維護 7.讀寫分離 主從複製 8.集群 與主從的區別 集群是通過負載均衡的方式,目的是容錯性和高...