如何通過優化sql語句提高資料庫查詢效率？(如何通過優化分配製度和政策實現共同富裕)

下面簡單說幾種提高SQL查詢效率的方法：

1.對查詢進行優化，應盡量避免全表掃描，首先應考慮在 where 及 order by 涉及的列上建立索引。

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

3.應盡量避免在 where 子句中對欄位進行 null 值判斷，否則將導致引擎放棄使用索引而進行全表掃描，如：

select id from t where num is null

可以在num上設置默認值0，確保表中num列沒有null值，然後這樣查詢：

select id from t where num=0

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

select id from t where num=10 or num=20

可以這樣查詢：

select id from t where num=10

union all

select id from t where num=20

5.in 和 not in 也要慎用，否則會導致全表掃描，如：

select id from t where num in(1,2,3)

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

select id from t where num between 1 and 3

6.下面的查詢也將導致全表掃描：

select id from t where name like \'%abc%\'

若要提高效率，可以考慮全文檢索。

7. 如果在 where 子句中使用參數，也會導致全表掃描。因為SQL只有在運行時才會解析局部變數，但優化程序不能將訪問計劃的選擇推遲到運行時；它必須在編譯時進行選擇。然 而，如果在編譯時建立訪問計劃，變數的值還是未知的，因而無法作為索引選擇的輸入項。如下面語句將進行全表掃描：

select id from t where num=@num

可以改為強制查詢使用索引：

select id from t with(index(索引名)) where num=@num

8.應盡量避免在 where 子句中對欄位進行表達式操作，這將導致引擎放棄使用索引而進行全表掃描。如：

select id from t where num/2=100

應改為:

select id from t where num=100*2

9.應盡量避免在where子句中對欄位進行函數操作，這將導致引擎放棄使用索引而進行全表掃描。如：

select id from t where substring(name,1,3)=\'abc\'--name以abc開頭的id

select id from t where datediff(day,createdate,\'2005-11-30\')=0--『2005-11-30』生成的id

應改為:

select id from t where name like \'abc%\'

select id from t where createdate>=\'2005-11-30\' and createdate<\'2005-12-1\'

10.不要在 where 子句中的「=」左邊進行函數、算術運算或其他表達式運算，否則系統將可能無法正確使用索引。

11.在使用索引欄位作為條件時，如果該索引是複合索引，那麼必須使用到該索引中的第一個欄位作為條件時才能保證系統使用該索引，否則該索引將不會被使用，並且應儘可能的讓欄位順序與索引順序相一致。

12.不要寫一些沒有意義的查詢，如需要生成一個空表結構：

select col1,col2 into #t from t where 1=0

這類代碼不會返回任何結果集，但是會消耗系統資源的，應改成這樣：

create table #t(...)

13.很多時候用 exists 代替 in 是一個好的選擇：

select num from a where num in(select num from b)

用下面的語句替換：

select num from a where exists(select 1 from b where num=a.num)

14.並不是所有索引對查詢都有效，SQL是根據表中數據來進行查詢優化的，當索引列有大量數據重複時，SQL查詢可能不會去利用索引，如一表中有欄位sex，male、female幾乎各一半，那麼即使在sex上建了索引也對查詢效率起不了作用。

15. 索引並不是越多越好，索引固然可以提高相應的 select 的效率，但同時也降低了 insert 及 update 的效率，因為 insert 或 update 時有可能會重建索引，所以怎樣建索引需要慎重考慮，視具體情況而定。一個表的索引數最好不要超過6個，若太多則應考慮一些不常使用到的列上建的索引是否有 必要。

16.應儘可能的避免更新 clustered 索引數據列，因為 clustered 索引數據列的順序就是表記錄的物理存儲順序，一旦該列值改變將導致整個表記錄的順序的調整，會耗費相當大的資源。若應用系統需要頻繁更新 clustered 索引數據列，那麼需要考慮是否應將該索引建為 clustered 索引。

17.盡量使用數字型欄位，若只含數值信息的欄位盡量不要設計為字元型，這會降低查詢和連接的性能，並會增加存儲開銷。這是因為引擎在處理查詢和連接時會逐個比較字元串中每一個字元，而對於數字型而言只需要比較一次就夠了。

18.儘可能的使用 varchar/nvarchar 代替 char/nchar ，因為首先變長欄位存儲空間小，可以節省存儲空間，其次對於查詢來說，在一個相對較小的欄位內搜索效率顯然要高些。

19.任何地方都不要使用 select * from t ，用具體的欄位列表代替「*」，不要返回用不到的任何欄位。

20.盡量使用表變數來代替臨時表。如果表變數包含大量數據，請注意索引非常有限（只有主鍵索引）。

21.避免頻繁創建和刪除臨時表，以減少系統表資源的消耗。

22.臨時表並不是不可使用，適當地使用它們可以使某些常式更有效，例如，當需要重複引用大型表或常用表中的某個數據集時。但是，對於一次性事件，最好使用導出表。

23.在新建臨時表時，如果一次性插入數據量很大，那麼可以使用 select into 代替 create table，避免造成大量 log ，以提高速度；如果數據量不大，為了緩和系統表的資源，應先create table，然後insert。

24.如果使用到了臨時表，在存儲過程的最後務必將所有的臨時表顯式刪除，先 truncate table ，然後 drop table ，這樣可以避免系統表的較長時間鎖定。

25.盡量避免使用游標，因為游標的效率較差，如果游標操作的數據超過1萬行，那麼就應該考慮改寫。

26.使用基於游標的方法或臨時表方法之前，應先尋找基於集的解決方案來解決問題，基於集的方法通常更有效。

27. 與臨時表一樣，游標並不是不可使用。對小型數據集使用 FAST_FORWARD 游標通常要優於其他逐行處理方法，尤其是在必須引用幾個表才能獲得所需的數據時。在結果集中包括「合計」的常式通常要比使用游標執行的速度快。如果開發時 間允許，基於游標的方法和基於集的方法都可以嘗試一下，看哪一種方法的效果更好。

28.在所有的存儲過程和觸發器的開始處設置 SET NOCOUNT ON ，在結束時設置 SET NOCOUNT OFF 。無需在執行存儲過程和觸發器的每個語句後向客戶端發送 DONE_IN_PROC 消息。

29.盡量避免大事務操作，提高系統並發能力。

30.盡量避免向客戶端返回大數據量，若數據量過大，應該考慮相應需求是否合理。

#####

1.正確的創建合適的索引是提成生資料庫查詢的基礎。

2.索引是為了加速對表中數據行的檢索而創建的一種分散存儲的數據數據結構。如圖以mysql(innodb引擎)為例

3.為什麼要用索引？

a.索引能極大的減少存儲引擎需要掃描的數據量。

b.索引可以把隨機IO變成順序IO。

c.索引可以幫助我們在進行分組、排序等操作時，避免使用臨時表。

4.sql前面加上 explain select Column Name1,Column Name2,Column Name3 from table；

排查是否走索引依次從好到差：system，const，eq_ref，ref，fulltext，ref_or_null，unique_subquery，index_subquery，range，index_merge，index，ALL。

5.索引注意要點

a.選擇離散度高的列建索引.

b.索引列的數據長度能少則少。

c.索引一定不是越多越好，越全越好，一定是建合適的。

d.匹配列前綴可用到索引 like 9999%，like %9999%、like %9999用不到索引；

e.Where 條件中 not in 和 <>操作無法使用索引；匹配範圍值，order by 也可用到索引

f.多用指定列查詢，只返回自己想到的數據列，少用select *；

g.聯合索引中如果不是按照索引最左列開始查找，無法使用索引；聯合索引中精確匹配最左前列並範圍匹配另外一列可以用到索引；

h.聯合索引中如果查詢中有某個列的範圍查詢，則其右邊的所有列都無法使用索引。

我是陽光隨馨馨，如果你看完了，點個贊，加個關注，轉發一下哈

#####

我來說說我日常的語句優化,日常大家都是本著完成客戶的需求進行編寫語句,但是如果一個運行中的Job速度比較慢的話,會導致系統卡死,無響應等情況產生,所以就需要有優化！

1.SELECT子句中避免使用\'*\':查詢的時候最好是不要使用*號 比如你這表列特別多的話會導致查詢速度慢,耗費更多的時間

2.EXISTS替代IN 用NOT EXISTS替代NOT IN:EXISTS用於檢查子查詢是否至少會返回一行數據,該子查詢實際上並不返回任何數據,而是返回值True或False.EXISTS 指定一個子查詢,檢測 行 的存在,返回值是一個BOOL值

IN:子查詢先產生結果集,然後主查詢再去結果集里去找符合要求的欄位列表去.符合要求的輸出,反之則不輸出.

3.能走索引的走索引:要看執行計劃,走什麼索引要根據數據量進行分析

4.我感覺分區也是一周優化查詢效率的方法

嘻嘻~暫時只能想到這麼多,菜鳥一枚!!ヾ(✿ﾟ▽ﾟ)ノ

#####

一、查詢條件精確，針對有參數傳入情況 二、SQL邏輯執行順序 FROM–>JOIN–>WHERE–>GROUP–>HAVING–>DISTINCT–>ORDER–>TOP 三、橫向 查詢需要的欄位 當在SQL語句中連接多個表時，請使用表的別名並把別名前綴於每個Column上這樣一來，就可以減少解析的時間並減少那些由Column歧義引起的語法錯誤 四、少做重複工作 控制同一語句的多次執行，特別是一些基礎數據的多次執行是很多程序員很少注意的 減少多次的數據轉換 杜絕不必要的子查詢和連接表，子查詢在執行計劃一般解釋成外連接，多餘的連接錶帶來額外的開銷 五、關於零時表#與表變數@ 如果語句很複雜，連接太多，可以考慮用臨時表和表變數分步完成 如果需要多次用到一個大表的同一部分數據，考慮用臨時表和表變數暫存這部分數據 如果需要綜合多個表的數據，形成一個結果，可以考慮用臨時表和表變數分步匯總這多個表的數據 關於臨時表和表變數的選擇，在數據量較多的情況下，臨時表的速度反而更快 SELECT INTO會比CREATE TABLE + INSERT INTO的方法快，但是SELECT INTO會鎖定TEMPDB的系統表SYSOBJECTS、SYSINDEXES、SYSCOLUMNS，在多用戶並發環境下，容易阻塞其他進程 六、子查詢 子查詢可以用IN、NOT IN、EXISTS、NOT EXISTS引入 NOT IN、NOT EXISTS的相關子查詢可以改用LEFT JOIN代替寫法 如果保證子查詢沒有重複 ，IN、EXISTS的相關子查詢可以用INNER JOIN 代替 IN的相關子查詢用EXISTS代替 七、索引 避免對索引欄位進行計算操作 SELECT ID FROM T WHERE NUM/2=100 應改為: SELECT ID FROM T WHERE NUM=100*2 避免在索引欄位上使用NOT，<>，!= 避免在索引列上使用IS NULL和IS NOT NULL 避免在索引列上出現數據類型轉換 避免在索引欄位上使用函數 避免建立索引的列中使用空值 不要對索引欄位進行多欄位連接 WHERE FAME+』. 『+LNAME=』HAIWEI.YANG』 應改為: WHERE FNAME=』HAIWEI』 AND LNAME=』YANG』 八、多表連接 多表連接的時候，連接條件必須寫全，寧可重複，不要缺漏 連接條件盡量使用聚集索引 九、其他 在可以使用UNION ALL的語句里，使用UNION ALL 避免在WHERE子句中使用IN，NOT IN，OR 避免使用耗費資源的操作，帶有DISTINCT,UNION,MINUS,INTERSECT,ORDER BY的SQL語句會啟動SQL引擎執行，耗費資源的排序(SORT)功能. DISTINCT需要一次排序操作, 而其他的至少需要執行兩次排序 LIKE 『%5400%』 這種查詢不會引用索引，而LIKE 『X5400%』則會引用範圍索引。

#####

不要濫用索引

#####

由於不同的資料庫版本，一些常用的優化技巧可能隨著資料庫版本的更新發生變化，以下主要把一些常用的優化技巧進行總結，使用時可根據實際情況進行調整，對於MySql要善用Explain查看執行計劃，對於Sql Server要善用執行計劃功能。

1.優化第一步建立合適的索引，要盡量避免全表掃描，考慮在where以及order by 設計的列上建立索引。

2.盡量避免在where子句中對欄位進行null值判斷，這樣會導致全表掃描。

3.避免在where子句中用or進行條件鏈接，可以考慮使用 union all 將查詢進行拆分。

4.盡量用union all 替代union,union和union all的差異主要是前者需要將結果集合併後再進行唯一性過濾操作，這就會涉及到排序，增加大量的CPU運算，加大資源消耗及延遲。當然，union all的前提條件是兩個結果集沒有重複數據。

5.在where子句中避免使用 in 或 not in,應考慮使用exists 或 not exists代替。

6.避免使用 like 模糊查詢，可以考慮使用全文索引。

7.盡量避免在where 子句中對欄位進行表達式操作，這樣會導致全表掃描，（如：select id from table where num/10=2)

8.盡量避免在 where 字句中對欄位進行函數操作。

9.在使用索引欄位作為條件時，如果該索引是複合索引，那麼必須使用到該索引中的第一個欄位作為條件時才能保證系統使用該索引，否則該索引將不會被使用，並且應儘可能的讓欄位順序與索引順序相一致。

10.不使用無意義的查詢條件，（如：select id from table where 1=1)。

11.不使用count(*)的計數查詢，要指定具體欄位。

12.索引並不是越多越好，索引固然可以提高相應的 select 的效率，但同時也降低了 insert 及 update 的效率，因為 insert 或 update 時有可能會重建索引，所以怎樣建索引需要慎重考慮，視具體情況而定。一個表的索引數最好不要超過6個，若太多則應考慮一些不常使用到的列上建的索引是否有 必要。

14.儘可能的使用 varchar/nvarchar 代替 char/nchar ，因為首先變長欄位存儲空間小，可以節省存儲空間，其次對於查詢來說，在一個相對較小的欄位內搜索效率顯然要高些。

15.查詢語句不可使用 select * from table, 用具體欄位代替*。

16.避免在where子句中出現欄位的類型轉換。

17.注意範圍查詢語句，如between，> ,< 等條件時，後面的索引欄位會失效。

以上只是一些常用的優化技巧，希望能夠有一定的幫助，資料庫優化不是一蹴而就的事情，需要不斷的學習。

#####

只要不懂，還是片面欠缺的，語句優化，能全面的就不要片面，要片面也不要頂全面，就看語句了，提高CPU處理效率也是至關重要的，也就是說計算機效能！除此之外資料庫也重要！

#####

sql優化很多方法，每種情況不一樣。

比如，建立索引，關鍵字大寫，盡量避免使用游標，減少使用星號查詢，盡量避免clustered索引，exists代替in…

#####

子查詢 多表查詢 索引 預編譯函數 緩存 資料庫設計