實際工作中，我們每個人難免都會要寫SQL，執行SQL，但是有時時候執行非常慢，甚至獲得不了結果。這時候你會怎么辦？放棄？去苦口婆心的求隔壁房間胡子擦擦的猥瑣DBA大叔？

NO，正確方法是先檢查一下你的SQL語句。本文蟲蟲給你列出來用來排查SQL查詢比較慢的常見方法和對策。文中所有方法和例子均基于PostgreSQL，當然這些都可以快速移植到MySql和其他數據庫，因為SQL語句基本上都是相通的。

了解現狀

首先，需要先清楚當前數據的環境情況。數據庫是不是很繁忙？有多少用戶在線，多少查詢在執行？當時失敗正處在高峰期？

對策：

可以通過詢問數據庫來了解數據庫當前狀態。不需要你去@ DBA或者運維，你只需執行SQL語句就可以獲得這些信息：

我們可以通過以下語句列出當前所有運行的和空閑的查詢：

select * from pg_stat_activity

下面的語句查找導致鎖表的查詢：

select pid,usename,pg_blocking_pids(pid) as blocked_by,query as blocked_query from pg_stat_activity where cardinality(pg_blocking_pids(pid))> 0;

鎖

表當時正在更新嗎？如果你查詢時候恰好遇到ETL進程在更新被鎖定的表，你也就無法對其查詢。

對策：

了解這些ETL更新執行時間，避開這些時間再執行查詢。

有針對性的查詢

知道了當前數據庫的狀態。現在可以具體從你的SQL語句入手了。首先看你的SQL語句：SELECT * from XXX

咦，為啥要 SELECT * ？

對策：

如果知識為了了解表的結構，請從模式樹獲取表字段。

d 表名

為了執行更快，只SELECT具體的字段值，不要用SELECT * ；

如果有一個特別大的表或寬表(表示字段很多)，查詢引擎不可能將所有數據都取過來。使用'LIMIT'來限制查詢，如果你確實需要關注每一行的內容那另說；

如果要COUNT計算，不要運行查詢通過查詢結果底部統計行數來獲取統計，請使用計算行數的子查詢：

select count(*) from(selectidfrom userswhere preferred_language = 'zh_CN'and private_profile = True) as temp;

大小寫

PostgreSQL是區分大小寫的，這對于Windows下用戶習慣SQL Serve的人來說可能有點別扭。

對策：

如果"小寫化"或"大寫化"數據，比較費勁，在將數據加入查詢中之前，先查看字段的形式。

如果在join時候需求，請僅在join一側使用；嘗試使用ILIKE進行不區分大小寫的匹配。

避免使用NOT IN

盡量避免使用"IN"或"NOT IN"。此操作需要全表掃描，查詢引擎需要對比每一行數據以檢查是否滿足條件。

對策：

嘗試使用"EXCEPT"或"NOT EXISTS"，這些對查詢計劃的影響遠小于"NOT IN"。

CTE

CTE(公共表達式)比子查詢更易于閱讀，但在PostgreSQL中該角色優化有限，查詢優化器無法對其變動約束條件實現查詢優化。

對策：

CTE和子查詢雖然都很有用，但是都有其適用范圍。使用CTE時候請考慮表大小，可能返回的行數以及寫入時在CTE中執行的操作。

通配符和模糊查詢

在LIKE的開頭和結尾使用通配符會降低查詢效率。并且可能會獲得比預期更多的結果。

對策：

在必需地方使用通配符，通常簡易，只在LIKE后的開頭或者結尾一端使用:

select name, email,location from users where name like 'CC%';

嘗試寫入一張表

將幾個嵌套查詢用作函數進行操作非常昂貴，這時候嘗試寫入表會更快。

對策：

如果流程有很多步驟，請考慮創建臨時表，以便加入較小的數據子集。

視圖的視圖

視圖是引用查詢運行的查詢結果。如果要調用多個視圖，或者更復雜情況下訪問視圖的視圖，要求查詢引擎運行多個查詢返回結果。

對策：

如果需要每天/每周/每月等定期的查詢快照，不是動態過濾的查詢視圖，請使用定期結果入表，而不要用視圖。

如果要使用嵌套視圖，請考慮是否有更直接的方法通過編寫查詢來獲取所需的結果，不要使用多個查詢的嵌套視圖。

索引

索引通過對數據字段序列化來加速查詢，可以以讓數據庫引擎快速定位數據的位置。索引類型決定了索引的工作方式。

對策：

對數據表中需要經常查詢的，使用頻繁的字段(或者字段組合)加索引。

評估表中現存的索引確保表中沒有太多的索引或者有無用的索引。

總結

本文列出了SQL查詢中常見可能會導致性能問題事項，并提供具體對策用以優化。當然這些只是給出了一般性質的建議，針對具體問題具體分析才是解決問題的關鍵。