sql優化提速整理

sql優化提速整理

場景描述

在我們實際開發中，隨著業務的不斷增加，資料量也在不斷的攀公升，這樣就離不開乙個問題：資料查詢效率優化

根據自己的以往實際專案工作經驗和學習所知，現在對sql查詢優化做乙個簡單的梳理總結，總結的不好之處，望多多指點交流學習

主要通過以下幾個點來進行總結分析：索引、語句本身、分割槽儲存、分庫分表

索引

在實際工作中，sql優化第一想到的應該就是索引，因為新增索引能夠很直觀的提公升查詢效率，但是在新增索引的時也不是越多多好，下面簡單總結一下索引的實際使用

索引簡介

關於索引的定義，在此不詳細說明，網上的資料很多。索引簡單的理解就是資料的目錄，就好比乙個字典的目錄，其目的是提高查詢效率

索引分類

sql索引根據儲存關係，分為兩類：聚合索引和非聚合索引

--

-- 根據資料表的字段1、欄位2建立乙個組合的聚合索引
use庫名
create
clustered
index 索引名稱 on 表名(欄位1,欄位2)

sql索引根據使用關係，分為四類：主鍵索引、唯一索引、普通索引（組合索引）、全文索引

主鍵索引：

表的主鍵自動為主鍵索引，每條資料的唯一標識，乙個表只有乙個主鍵索引

唯一索引：

唯一索引也是確保資料的唯一性，乙個表可以多有多個唯一索引，這也是和主鍵索引的區別所在

建立唯一索引sql語句：　　

create

unique
index 索引名稱 on 表名(欄位1,欄位2)

普通索引：

普通索引可以對任意字段或者多個字段新增索引

--

--建立普通索引sql語句：
create
index 索引名稱 on 表名(欄位1,欄位2)

索引建立技巧

動作描述

使用聚集索引

使用非聚集索引

外來鍵列應應

主鍵列應

應列經常被分組排序(order by)應應

返回某範圍內的資料應不應

小數目的不同值應不應

大數目的不同值不應應

頻繁更新的列

不應 應

頻繁修改索引列不應應

乙個或極少不同值

不應不應

建立索引的原則

索引碎片化處理（重構索引）

關於索引的定義，在此不詳細說明，網上的資料很多。索引簡單的理解就是資料的目錄，就好比乙個字典的目錄，其目的是提高查詢效率

索引簡介

在實際開發中，有時候會發現新增了索引，但是效率還是沒有明顯提公升，這時候需要考慮是否由於資料的更新編輯產生了索引碎片化，並處理

如果檢查是否有索引碎片：

--

-- 檢查乙個表索引碎片化 
use庫名
dbcc showcontig(待查詢的表)
---- 執行結果例項：

----資料結構分析：處理

logical scan fragmentation-邏輯掃瞄碎片：無序頁的百分比。該百分比應該在0％到10％之間，高了則說明有外部碎片。

解決方式：

解決方式有兩種方式:整理索引碎片、重建索引，在實際操過程中建議採用：重建索引。

重建索引的sql語句：

use 庫名

dbcc dbreindex(待重建索引的表名稱)

查詢語句優化

在處理好索引後，接下來就是分析查詢語句，查詢語句可以借助專業的分析工具來分析，乙個好的語句和不好的語句也會很影響效率，現在簡單總結一下在查詢語句的優化方向：

1、查詢字段禁止出現 selete * 

2、where 及 order by 涉及的列上建立索引。

3、where避免出現非空判斷：比如：select from table where num is null

此時可以給num賦乙個預設值0，語句修改為：select from table where num=0

4、應盡量避免在 where 子句中使用!=或<>操作符，否則將引擎放棄使用索引而進行全表掃瞄

5、應盡量避免在 where 子句中使用 or 來連線條件，否則將導致引擎放棄使用索引而進行全表掃瞄，如：

-----查詢value值為1 或者 4 的資料集合

select id from sys_confige where value=1 or value=4

---- 可以這樣查詢：

select * from sys_confige where value=1

union all

select * from sys_confige where value=4

6、in 和 not in 也要慎用，否則會導致全表掃瞄，如：

select id from sys_configet where value in(1,2,3)

對於連續的數值，能用 between 就不要用 in 了：

select id from sys_configet where num value 1 and 3

7、查詢時避免使用like '%待查詢關鍵字%' 查詢

8、在使用索引字段作為條件時，如果該索引是復合索引，那麼必須使用到該索引中的第乙個字段作為條件時才能保證系統使用該索引，

否則該索引將不會被使用，並且應盡可能的讓字段順序與索引順序相一致

9、能夠用關聯查詢的不要用exists

10、避免頻繁建立和刪除臨時表，以減少系統表資源的消耗。

11、盡量避免向客戶端返回大資料量，若資料量過大，應該考慮相應需求是否合理

分割槽儲存

當單錶的數量達到一定量時，為了提高查詢效率，資料表分割槽儲存也是乙個不錯的優化方案。

分割槽呢就是把一張表的資料分成n多個區塊，這些區塊可以在同乙個磁碟上，也可以在不同的磁碟上，通過提高減少檔案大小，提高io處理效率，間接的提高查詢效率

分割槽儲存，只是在資料儲存上採用分割槽，但是在表現上還是一張表。

表分割槽有以下優點：

1、改善查詢效能：對分割槽物件的查詢可以僅搜尋自己關心的分割槽，提高檢索速度。

2、增強可用性：如果表的某個分割槽出現故障，表在其他分割槽的資料仍然可用；

3、維護方便：如果表的某個分割槽出現故障，需要修復資料，只修復該分割槽即可；

4、均衡i/o：可以把不同的分割槽對映到磁碟以平衡i/o，改善整個系統效能。

缺點：

分割槽表相關：已經存在的表沒有方法可以直接轉化為分割槽表

分庫分表

分庫分表其實原理也是將乙個大表拆分不同的小表，在拆分上有兩種拆分方式：

橫向拆分：主要針對乙個表的字段比較多，可以根據欄位的查詢頻率、更新頻率進行分割儲存，可以理解為表擴充套件

縱向拆分：縱向拆分主要是根據資料量，將資料儲存在不同的表，常用的拆分方式有：按照時間、按照雜湊等等

分庫分表和分割槽儲存兩者看上去是有點矛盾，實際上兩者的出發點不一樣。分割槽：是降低大單錶資料分割槽儲存，分庫分表：直接將單錶拆分為多表

同時分庫分表不僅僅會增加資料維護難度，同時也會需要投入大量的開發工作，所以分庫分表一般是要系統有一定的規模，公司有一定的資源支援

分庫分表兩種可以配合使用，比如在分表後，還可以對錶進行分割槽儲存。

總結

在資料優化過程中，索引是第一出發點，語句優化必不可少，分割槽、分庫、分表也得考慮。

sql 優化整理

1.避免無計畫的全表掃瞄 如下情況進行全表掃瞄 該錶無索引 對返回的行無任何限制條件 無where子句 對索引主列 索引的第一列 無限制條件 對索引主列的條件含在表示式中 對索引主列的限制條件是is not null或 對索引主列的限制條件是like操作 且 值是乙個bind variable或 打...

sql優化技術整理

1.禁止使用select 需要哪些字段查哪些字段 2.使用select in 的時候，如果存在子查詢，使用exist 代替in select from class a where id in select id from class b 應使用 select from class a a where...

Discuz提速優化技巧

discuz是國內最受站長們歡迎的建站原始碼之一，除了開源以外還有著很強大的後台，即便是沒有建站基礎和不懂 的站長也能很快的架設出乙個論壇，甚至是門戶。乙個 的載入速度除了影響你在搜尋引擎裡的排名以外還影響著你的使用者體驗。最新研究表明，大多數使用者期望的 載入時間是3秒，如果時間超過3秒，就開始流...