目錄

• 一、?? 本章學習導讀
• 1.1 學習目標
• 1.2 本章重點
• 二、?? 為什么要深入學習執(zhí)行計劃
• 三、?? 執(zhí)行計劃基礎：開啟與基礎字段解讀
• 3.1 執(zhí)行計劃兩種查看方式
• 3.1.1 EXPLAIN 預估執(zhí)行計劃
• 3.1.2 EXPLAIN ANALYZE 真實執(zhí)行計劃
• 3.2 核心關鍵字段逐行解讀
• 3.3 實戰(zhàn)判斷：一眼識別好壞計劃
• 四、?? 數(shù)據(jù)訪問方式深度解析：掃描類型與調優(yōu)策略
• 4.1 順序掃描（Seq Scan）全表掃描
• 4.1.1 出現(xiàn)場景
• 4.1.2 典型問題與解決方案
• 4.2 索引掃描（Index Scan）
• 4.2.1 出現(xiàn)場景
• 4.3 唯一索引掃描（Index Unique Scan）
• 4.4 位圖掃描（Bitmap Scan）
• 4.5 掃描類型避坑總結
• 五、?? 三大表連接算法：原理、場景與調優(yōu)
• 5.1 嵌套循環(huán)連接（Nested Loop）
• 5.1.1 工作原理
• 5.1.2 適用場景
• 5.1.3 調優(yōu)要點
• 5.2 哈希連接（Hash Join）
• 5.2.1 工作原理
• 5.2.2 適用場景
• 5.2.3 調優(yōu)要點
• 5.3 合并連接（Merge Join）
• 5.3.1 工作原理
• 5.3.2 適用場景
• 5.3.3 調優(yōu)要點
• 5.4 三大算法選型速記
• 六、?? 優(yōu)化器核心特性：讀懂數(shù)據(jù)庫的“小聰明”
• 6.1 分區(qū)裁剪（Partition Pruning）
• 6.1.1 原理
• 6.1.1 正常案例（裁剪生效）
• 6.1.2 失效案例（裁剪失?。?/a>
• 6.2 謂詞下推（Predicate Pushdown）
• 6.2.1 正常場景
• 6.2.2 失效場景
• 6.3 常量折疊
• 七、??? 經(jīng)典疑難SQL專項深度調
• 7.1 子查詢調優(yōu)：EXISTS、IN 與 JOIN 選型
• 7.2 CTE 公共表達式調優(yōu)
• 7.3 深分頁調優(yōu)
• 7.4 分組聚合（GROUP BY）調優(yōu)
• 7.5 模糊查詢調優(yōu)
• 八、?? 真實企業(yè)案例：政務大數(shù)據(jù)報表SQL深度調優(yōu)
• 8.1 業(yè)務背景
• 8.2 問題分析（通過執(zhí)行計劃定位）
• 8.3 分步調優(yōu)操作
• 第一步：補充關聯(lián)字段索引
• 第二步：多層子查詢改寫為多表JOIN，優(yōu)化謂詞下推
• 第三步：分組字段建立復合索引，消除排序節(jié)點
• 第四步：修正分區(qū)查詢條件，啟用分區(qū)裁剪
• 8.4 調優(yōu)結果
• 九、?? 高級調優(yōu)高頻坑點匯總
• 十、? 本章總結與后續(xù)學習預告

前面的內容，我們把基礎SQL寫法、索引使用、分區(qū)表、普通性能優(yōu)化這些內容都過了一遍。到這一章，我們就往更深一層的調優(yōu)方向走了。平時大部分慢查詢，靠基礎手段就能處理。但碰到多表關聯(lián)、超大結果集、高并發(fā)報表、多層嵌套子查詢這類場景，單純加索引、改語句就不夠用了。這個時候，就得學會看懂執(zhí)行計劃，搞懂數(shù)據(jù)庫底層的運行邏輯，再搭配對應的高級優(yōu)化手段來處理。

一、?? 本章學習導讀

1.1 學習目標

1. 能把KES執(zhí)行計劃里每一個字段都看懂，順著內容快速找到SQL運行卡頓的地方。
2. 能分清順序掃描、索引掃描、位圖掃描這些不同的數(shù)據(jù)讀取方式，判斷每一種方式的好壞。
3. 把嵌套循環(huán)、哈希連接、合并連接這三種表關聯(lián)方式吃透，結合業(yè)務場景選擇合適的算法。
4. 了解分區(qū)裁剪、謂詞下推、表達式計算這些優(yōu)化器自帶的行為，學會順著規(guī)則寫SQL，引導數(shù)據(jù)庫做優(yōu)化。
5. 搞定分頁、分組聚合、子查詢、CTE、模糊查詢這些線上經(jīng)常出現(xiàn)的慢SQL問題。
6. 會結合系統(tǒng)視圖、執(zhí)行計劃、會話狀態(tài)綜合排查問題，形成屬于自己的一套調優(yōu)思路。

1.2 本章重點

• 執(zhí)行計劃完整解讀，包括里面的關鍵字段、不同節(jié)點、成本和耗時怎么看
• 全表掃描、各類索引掃描、位圖掃描的區(qū)別和對應的優(yōu)化辦法
• 三種表連接算法的原理、適用場景和調優(yōu)小技巧
• 分區(qū)裁剪、謂詞下推、常量折疊這些優(yōu)化器常用能力
• 子查詢、CTE、深分頁、模糊查詢、分組聚合這類復雜SQL的調優(yōu)方法
• 政務類大型報表SQL的真實調優(yōu)案例

二、?? 為什么要深入學習執(zhí)行計劃

我發(fā)現(xiàn)很多做開發(fā)和運維的朋友，調SQL的時候全靠經(jīng)驗。感覺哪里慢，就試著加索引、改SQL語句。運氣好了問題能解決，運氣不好就反復試來試事，白白耗費不少時間。

其實數(shù)據(jù)庫執(zhí)行SQL，是有一套完整步驟的。執(zhí)行計劃，就相當于數(shù)據(jù)庫執(zhí)行任務的步驟清單。數(shù)據(jù)庫會嚴格按照這份清單，一步步讀取數(shù)據(jù)、做關聯(lián)、做計算，最后返回結果。

你看不懂這份清單，就沒法知道數(shù)據(jù)庫實際走了哪條執(zhí)行路徑。也不清楚具體卡在哪個環(huán)節(jié)，更不知道明明建了索引，數(shù)據(jù)庫卻不去使用的原因。

KES是基于PostgreSQL內核打造，同時兼容Oracle的優(yōu)化邏輯。它的執(zhí)行計劃展示得很直觀。只要學會解讀的方法，再棘手的慢SQL，也能找到問題所在。

這里提一句很實在的經(jīng)驗。不管調哪條SQL，第一步一定是查看執(zhí)行計劃。不要上來就盲目修改代碼、新增索引。

三、?? 執(zhí)行計劃基礎：開啟與基礎字段解讀

3.1 執(zhí)行計劃兩種查看方式

KES里有兩條最常用的語句，用來查看執(zhí)行計劃。一種只做預估，一種會真實運行SQL，兩者使用場景不一樣。

3.1.1 EXPLAIN 預估執(zhí)行計劃

執(zhí)行這條語句的時候，數(shù)據(jù)庫只會解析SQL邏輯，算出大致的執(zhí)行成本。不會真正去執(zhí)行SQL。
像數(shù)據(jù)量很大的查詢、有可能鎖表的危險語句，都可以用這個命令查看，能避免影響線上服務。

EXPLAIN
SELECT * FROM t_user WHERE username = '張三';

3.1.2 EXPLAIN ANALYZE 真實執(zhí)行計劃

這條命令不光會生成執(zhí)行計劃，還會把SQL完整跑一遍。每一個步驟的實際耗時、掃描行數(shù)都會展示出來。
日常排查慢SQL，基本都用它，也是我們調優(yōu)時的首選命令。

EXPLAIN ANALYZE
SELECT u.username, o.order_time, o.total_price
FROM t_user u
JOIN t_order o ON u.uid = o.user_id
WHERE u.username = '張三'
ORDER BY o.order_time DESC;

3.2 核心關鍵字段逐行解讀

很多人拿到執(zhí)行計劃的返回內容，看著一堆英文參數(shù)就犯難。我挑平時最常接觸的內容，用大白話講清楚。

1. Seq Scan：順序掃描，也就是大家常說的全表掃描。數(shù)據(jù)庫會逐行讀取整張數(shù)據(jù)表。數(shù)據(jù)量一旦變大，速度就會明顯下降。千萬級別的數(shù)據(jù)表如果出現(xiàn)這個節(jié)點，基本就是我們需要優(yōu)化的目標。
2. Index Scan：普通索引掃描。數(shù)據(jù)庫依靠索引定位數(shù)據(jù)，讀取效率比全表掃描高很多，也是我們希望看到的執(zhí)行方式。
3. Index Unique Scan：唯一索引掃描。一般用在主鍵、唯一約束的查詢場景，數(shù)據(jù)定位速度是最快的。
4. Bitmap Scan：位圖掃描。一條SQL用到多個索引做篩選的時候，就會觸發(fā)這種掃描方式。多條件查詢里很常見。
5. Nested Loop：嵌套循環(huán)，多表關聯(lián)的其中一種算法，后面會詳細說明。
6. Hash Join：哈希連接，兩張大表做關聯(lián)時的主流選擇。
7. Merge Join：合并連接，兩張有序數(shù)據(jù)表做關聯(lián)時會用到。
8. rows：預估或者實際掃描的數(shù)據(jù)行數(shù)。如果這個數(shù)值比業(yè)務實際數(shù)據(jù)量大很多，就說明過濾條件沒有生效。
9. cost：數(shù)據(jù)庫估算出來的執(zhí)行開銷。這個數(shù)值只做參考，優(yōu)先級不如實際耗時。
10. time：對應節(jié)點的實際運行時間，單位是毫秒。整個計劃里耗時最長的節(jié)點，就是整條SQL的瓶頸。

補充一個小知識點。執(zhí)行計劃是樹形的結構。閱讀的時候，要從縮進最深、最內層的節(jié)點開始看?？赐曜庸?jié)點，再往上看父節(jié)點。

3.3 實戰(zhàn)判斷：一眼識別好壞計劃

結合實際場景簡單區(qū)分一下。
出現(xiàn) Seq Scan 全表掃描、單次掃描幾十萬行數(shù)據(jù)、單節(jié)點耗時幾百毫秒以上，這類執(zhí)行計劃就屬于需要優(yōu)化的壞計劃。
查詢條件正常走 Index Scan 索引掃描、掃描行數(shù)和實際業(yè)務匹配、整體耗時控制在幾十毫秒內，這類就是比較理想的執(zhí)行計劃。

四、?? 數(shù)據(jù)訪問方式深度解析：掃描類型與調優(yōu)策略

讀取數(shù)據(jù)是SQL執(zhí)行的第一步。選擇哪種讀取方式，直接決定了整條語句的基礎性能。下面把KES里四種主流的掃描方式、適用場景和對應的優(yōu)化方法逐一說明。

4.1 順序掃描（Seq Scan）全表掃描

4.1.1 出現(xiàn)場景

數(shù)據(jù)表沒有創(chuàng)建對應索引，或者查詢條件沒辦法匹配索引。還有一種情況，數(shù)據(jù)庫判斷走全表掃描，比走索引速度更快。

如果是幾百行以內的小表，數(shù)據(jù)庫選擇全表掃描是正常的，不用額外處理。但數(shù)據(jù)表行數(shù)超過10萬，還在走全表掃描，就必須做優(yōu)化。

4.1.2 典型問題與解決方案

舉個例子，一張100萬行的用戶表，根據(jù)手機號查詢數(shù)據(jù)，沒有建索引的情況下，就會觸發(fā)全表掃描。

EXPLAIN ANALYZE SELECT * FROM t_user WHERE phone = '13800138000';

執(zhí)行計劃里會看到 Seq Scan on t_user。

對應的解決辦法有兩個。第一，給查詢字段補充索引。第二，檢查查詢條件里是不是用了函數(shù)、存在隱式類型轉換，這類寫法都會讓索引失效。

4.2 索引掃描（Index Scan）

4.2.1 出現(xiàn)場景

查詢條件可以匹配B樹索引，數(shù)據(jù)庫通過索引找到數(shù)據(jù)位置，再回表讀取完整內容。單表查詢里，這是比較理想的執(zhí)行方式。

-- 給手機號建立索引后，自動走索引掃描
CREATE INDEX idx_user_phone ON t_user(phone);
EXPLAIN ANALYZE SELECT * FROM t_user WHERE phone = '13800138000';

4.3 唯一索引掃描（Index Unique Scan）

這種方式一般用在主鍵、唯一索引的查詢上。數(shù)據(jù)庫可以直接定位到單條數(shù)據(jù)，整體性能是最優(yōu)的。根據(jù)主鍵ID查詢數(shù)據(jù)，基本都會觸發(fā)它。

EXPLAIN ANALYZE SELECT * FROM t_user WHERE uid = 10001;

4.4 位圖掃描（Bitmap Scan）

當一條SQL同時使用多個索引做篩選的時候，數(shù)據(jù)庫就會啟用位圖掃描。比如同時根據(jù)用戶名、賬號狀態(tài)兩個條件查詢。
這種掃描方式本身性能不錯，日常不用特意去調整，了解原理就可以。

4.5 掃描類型避坑總結

1. 行數(shù)少于1000的小表，走全表掃描屬于正常現(xiàn)象，不用額外建索引。
2. 行數(shù)超過10萬的大表，要避免無意義的全表掃描，優(yōu)先補充合適的索引。
3. 不要在索引字段上嵌套函數(shù)、做運算，也盡量避免隱式類型轉換，這些操作都會讓索引失效。

五、?? 三大表連接算法：原理、場景與調優(yōu)

多表關聯(lián)的SQL，也是慢查詢的重災區(qū)。KES提供嵌套循環(huán)、哈希連接、合并連接三種關聯(lián)算法。優(yōu)化器會根據(jù)表的數(shù)據(jù)量、數(shù)據(jù)排序狀態(tài)自動選擇。我們要做的，就是弄懂每種算法的特點，引導數(shù)據(jù)庫選出最合適的方案。

5.1 嵌套循環(huán)連接（Nested Loop）

5.1.1 工作原理

簡單來說，先拿小表也就是驅動表里的每一行數(shù)據(jù)，去大表也就是被驅動表里做匹配。一輪一輪循環(huán)，完成兩張表的關聯(lián)。

5.1.2 適用場景

小表和大表做關聯(lián)的場景最適合它。驅動表的數(shù)據(jù)量越小，被驅動表的關聯(lián)字段建有索引，整體速度就越快。平時普通的兩表關聯(lián)、維度表關聯(lián)業(yè)務大表，基本都用這種算法。

5.1.3 調優(yōu)要點

1. 被驅動表的關聯(lián)字段，一定要建立索引，這是保證性能的關鍵。
2. 盡量把數(shù)據(jù)量最小的表設置成驅動表。
3. 能提前過濾的數(shù)據(jù)，盡量在關聯(lián)之前處理，減少循環(huán)的次數(shù)。

示例：用戶表數(shù)據(jù)量小，關聯(lián)百萬行的訂單表

EXPLAIN ANALYZE
SELECT u.username, o.order_time
FROM t_user u
JOIN t_order o ON u.uid = o.user_id
WHERE u.uid IN (10001,10002);

5.2 哈希連接（Hash Join）

5.2.1 工作原理

數(shù)據(jù)庫先讀取其中一張表，根據(jù)關聯(lián)字段生成哈希結構。之后再遍歷另一張表，通過哈希匹配的方式完成數(shù)據(jù)關聯(lián)。

5.2.2 適用場景

兩張都是大數(shù)據(jù)量的表，索引收益不高的情況下，優(yōu)先使用。政務報表、數(shù)據(jù)統(tǒng)計類SQL里經(jīng)常能看到。

5.2.3 調優(yōu)要點

1. 可以適當調大 work_mem 參數(shù)，讓哈希計算在內存里完成。一旦落到磁盤上，性能會大幅下降。
2. 盡量在關聯(lián)之前用WHERE條件過濾數(shù)據(jù)，減少參與關聯(lián)的數(shù)據(jù)總量。

5.3 合并連接（Merge Join）

5.3.1 工作原理

它要求兩張表的關聯(lián)字段本身是有序的。數(shù)據(jù)庫按照順序逐行比對數(shù)據(jù)，完成關聯(lián)。

5.3.2 適用場景

兩張數(shù)據(jù)表數(shù)據(jù)量偏大，且關聯(lián)字段已經(jīng)排序，比如主鍵、索引字段。

5.3.3 調優(yōu)要點

如果數(shù)據(jù)表本身無序，數(shù)據(jù)庫就要額外執(zhí)行排序操作，會增加耗時。這種情況下，合并連接的表現(xiàn)不如哈希連接。

5.4 三大算法選型速記

小表關聯(lián)大表、關聯(lián)字段有索引 → 選擇嵌套循環(huán)
大表關聯(lián)大表、索引收益低 → 選擇哈希連接
兩張表數(shù)據(jù)量大且字段有序 → 選擇合并連接

六、?? 優(yōu)化器核心特性：讀懂數(shù)據(jù)庫的“小聰明”

KES的查詢優(yōu)化器，會自動做很多邏輯改寫來提升執(zhí)行效率。很多SQL變慢，并不是語句寫錯了，而是我們不了解這些特性，導致優(yōu)化能力沒法生效。這里講分區(qū)裁剪、謂詞下推、常量折疊三個常用能力。

6.1 分區(qū)裁剪（Partition Pruning）

這個功能是針對分區(qū)表設計的，也是分區(qū)表能提速的核心。

6.1.1 原理

查詢條件里包含分區(qū)鍵的時候，優(yōu)化器會自動跳過不相關的分區(qū)，只掃描符合條件的分區(qū)，不用遍歷全部分區(qū)。

6.1.1 正常案例（裁剪生效）

t_order_log 是按月份分區(qū)的表，根據(jù)時間篩選數(shù)據(jù)，只會掃描對應分區(qū)。

EXPLAIN ANALYZE SELECT * FROM t_order_log WHERE create_time >= '2025-06-01';

6.1.2 失效案例（裁剪失?。?/h4>

如果在分區(qū)鍵上使用函數(shù)，優(yōu)化器就沒法識別分區(qū)范圍，分區(qū)裁剪會直接失效，會掃描所有分區(qū)。

-- 分區(qū)鍵使用函數(shù)，分區(qū)裁剪失效，掃描全部分區(qū)
EXPLAIN ANALYZE SELECT * FROM t_order_log WHERE TO_CHAR(create_time,'YYYY-MM') = '2025-06';

小提醒：寫分區(qū)表查詢的時候，不要在分區(qū)鍵上做函數(shù)運算、算術運算，保證分區(qū)裁剪正常觸發(fā)。

6.2 謂詞下推（Predicate Pushdown）

謂詞，其實就是我們寫的過濾條件。謂詞下推的意思，就是優(yōu)化器會把外層的WHERE條件，推到子查詢、視圖里面，提前過濾數(shù)據(jù)，減少后續(xù)關聯(lián)和計算的數(shù)據(jù)量。

6.2.1 正常場景

-- 條件下推到子查詢內部，提前過濾
EXPLAIN ANALYZE
SELECT * FROM (SELECT * FROM t_order) t WHERE user_id = 10001;

6.2.2 失效場景

如果子查詢里有分組、聚合、集合運算，謂詞下推就會被阻止。數(shù)據(jù)庫會先全量計算，再做過濾，性能會變差。
對應的解決辦法，就是改寫SQL，把過濾條件寫到子查詢內部。

6.3 常量折疊

SQL里的常量計算，優(yōu)化器會提前算好。比如 WHERE age > 10 + 5，優(yōu)化器會直接轉換成 WHERE age > 15。不用在SQL運行階段重復計算。這個功能不用我們手動干預，了解即可。

七、??? 經(jīng)典疑難SQL專項深度調

結合線上經(jīng)常碰到的問題，針對子查詢、CTE、深分頁、分組聚合、模糊查詢這幾類慢SQL，結合執(zhí)行計劃分析問題，給出對應的改寫方案。

7.1 子查詢調優(yōu)：EXISTS、IN 與 JOIN 選型

不少人糾結 IN 和 EXISTS 哪個更快，結合執(zhí)行計劃就能分清。

1. 子查詢返回的數(shù)據(jù)量偏小，優(yōu)先用 IN。
2. 子查詢返回的數(shù)據(jù)量很大，優(yōu)先用 EXISTS。
3. 碰到多層嵌套子查詢，建議全部改寫成 JOIN 關聯(lián)，優(yōu)化器處理起來效率更高。

低效寫法示例：

SELECT * FROM t_user WHERE uid IN (SELECT user_id FROM t_order WHERE order_amount > 1000);

改寫后高效寫法：

SELECT DISTINCT u.* FROM t_user u
JOIN t_order o ON u.uid = o.user_id
WHERE o.order_amount > 1000;

7.2 CTE 公共表達式調優(yōu)

WITH 也就是CTE，可以拆分復雜SQL邏輯。不過在部分舊版本內核里，CTE的結果會生成臨時數(shù)據(jù)。多次引用CTE，就會重復掃描數(shù)據(jù)。
日常建議，簡單邏輯盡量不用CTE。復雜報表可以合理拆分，同時避免多層CTE嵌套。

7.3 深分頁調優(yōu)

普通的 LIMIT + OFFSET 分頁寫法，當OFFSET數(shù)值很大的時候，數(shù)據(jù)庫要先讀取前面所有行，再丟棄。分頁越靠后，速度越慢。

低效寫法：

-- 偏移量10000，性能極差
SELECT * FROM t_order ORDER BY oid LIMIT 20 OFFSET 10000;

可以利用主鍵來改寫，直接定位分頁起始位置，不用掃描前置數(shù)據(jù)。

SELECT * FROM t_order WHERE oid > 10000 ORDER BY oid LIMIT 20;

7.4 分組聚合（GROUP BY）調優(yōu)

大表做分組統(tǒng)計，很容易出現(xiàn)Sort排序節(jié)點，耗時會增加。
優(yōu)化方式：

1. 給GROUP BY、ORDER BY對應的字段建立復合索引，利用索引自帶的有序特性，避免現(xiàn)場排序。
2. 在聚合計算之前先過濾數(shù)據(jù)，縮小統(tǒng)計范圍。

7.5 模糊查詢調優(yōu)

1. like '關鍵詞%' 右模糊查詢，可以正常命中索引，性能沒問題。
2. like '%關鍵詞'、like '%關鍵詞%' 左模糊、全模糊，索引會直接失效，一定會走全表掃描。

如果業(yè)務允許，盡量限制模糊查詢的寫法。如果必須使用全模糊，可以搭配全文檢索插件處理。

八、?? 真實企業(yè)案例：政務大數(shù)據(jù)報表SQL深度調優(yōu)

8.1 業(yè)務背景

某市級政務平臺的綜合統(tǒng)計報表，一共關聯(lián)五張大表，單表數(shù)據(jù)量都超過800萬行。原始SQL執(zhí)行耗時達到22秒，業(yè)務高峰期經(jīng)常超時，影響后臺統(tǒng)計工作正常使用。

8.2 問題分析（通過執(zhí)行計劃定位）

1. 兩張核心大表采用嵌套循環(huán)，但是關聯(lián)字段沒有索引，出現(xiàn)大量全表掃描。
2. 多層嵌套子查詢，過濾條件無法下推，數(shù)據(jù)過濾時機太晚。
3. GROUP BY 字段沒有索引，數(shù)據(jù)庫需要現(xiàn)場排序，耗時增加。
4. 分區(qū)表沒有正確使用分區(qū)條件，分區(qū)裁剪失效，遍歷了所有歷史分區(qū)。

8.3 分步調優(yōu)操作

第一步：補充關聯(lián)字段索引

CREATE INDEX idx_order_userid ON t_order(user_id);
CREATE INDEX idx_apply_code ON t_gov_apply(dept_code);

第二步：多層子查詢改寫為多表JOIN，優(yōu)化謂詞下推

把三層嵌套的IN子查詢，全部改寫成INNER JOIN。把時間、部門這類過濾條件提前設置。

第三步：分組字段建立復合索引，消除排序節(jié)點

CREATE INDEX idx_stat_dept_time ON t_gov_apply(dept_code, submit_time);

第四步：修正分區(qū)查詢條件，啟用分區(qū)裁剪

去掉分區(qū)鍵上的函數(shù)運算，直接使用時間范圍做篩選。

8.4 調優(yōu)結果

? 報表執(zhí)行耗時從 22秒 → 0.8秒
? 執(zhí)行計劃里的全表掃描、大量Sort排序節(jié)點全部消失
? 高峰期持續(xù)運行，不再出現(xiàn)超時問題，可支撐每日上萬次統(tǒng)計查詢
? 應用端代碼不需要大幅修改，改造成本很低

九、?? 高級調優(yōu)高頻坑點匯總

結合線上大量排錯和調優(yōu)的經(jīng)驗，整理解讀執(zhí)行計劃、做SQL深度優(yōu)化時容易踩的問題，大家提前留意。

1. 只看 EXPLAIN 預估計劃，不看 EXPLAIN ANALYZE 真實計劃。預估結果只能參考，真實耗時一定要以后者為準。
2. 盲目新建索引。索引太多會拖累寫入性能，優(yōu)先改寫SQL邏輯，再考慮加索引。
3. 在分區(qū)鍵上使用函數(shù)，直接讓分區(qū)裁剪失效，分區(qū)表失去優(yōu)化效果。
4. 兩張百萬行以上的大表，依舊使用嵌套循環(huán)，執(zhí)行效率遠不如哈希連接。
5. 深分頁場景一直使用OFFSET，偏移量超過5000之后，性能會明顯下滑。
6. 忽略隱式類型轉換，字符串和數(shù)字做比對，會隱性造成索引失效，不容易排查。
7. 一次性修改多條問題SQL。建議改一條、驗證一條，避免引發(fā)連鎖問題。

十、? 本章總結與后續(xù)學習預告

學完這一章，你就掌握了KES SQL深度調優(yōu)的整套能力。從執(zhí)行計劃解讀、三種表連接算法，再到優(yōu)化器特性、各類疑難SQL改寫，還有大型報表的實戰(zhàn)調優(yōu)，這些內容基本可以應對企業(yè)里絕大多數(shù)SQL性能問題。

簡單梳理下本章學到的內容：

1. 會使用 EXPLAIN / EXPLAIN ANALYZE，看懂執(zhí)行計劃，快速定位性能瓶頸。
2. 分清各類數(shù)據(jù)掃描方式，知道全表掃描和索引掃描各自的使用場景與優(yōu)化邊界。
3. 理解三種表連接算法，根據(jù)數(shù)據(jù)表規(guī)模選擇合適的關聯(lián)方式。
4. 了解分區(qū)裁剪、謂詞下推等優(yōu)化器規(guī)則，按照規(guī)則編寫SQL。
5. 掌握子查詢、分頁、模糊查詢、分組等常見慢SQL的改寫方法。
6. 具備復雜大型報表的綜合調優(yōu)能力。