實際工作中，我們每個人難免都會要寫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 ( select id from users where 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查詢中常見可能會導致性能問題事項，并提供具體對策用以優化。當然這些只是給出了一般性質的建議，針對具體問題具體分析才是解決問題的關鍵。
