在一些業務場景中，會使用NOT EXISTS語句確保返回數據不存在於特定集合，部分同事會發現NOT EXISTS有些場景性能較差，甚至有些網上謠言說”NOT EXISTS不走索引”，哪對於NOT EXISTS語句，我們如何優化呢？
以今天優化的SQL為例，優化前SQL為：
SELECT count(1)
FROM t_monitor m
WHERE NOT exists (
SELECT 1
FROM t_alarm_realtime AS a
WHERE a.resource_id=m.resource_id
AND a.resource_type=m.resource_type
AND a.monitor_name=m.monitor_name
)
我們使用LEFT JOIN方式進行優化，優化后SQL為：
SELECT count(1)
FROM t_monitor m
LEFT JOIN t_alarm_realtime AS a
ON a.resource_id=m.resource_id
AND a.resource_type=m.resource_type
AND a.monitor_name=m.monitor_name
WHERE a.resource_id is NULL
優化效果：
優化前執行時間29秒以上，優化后1.2秒，優化提升25倍。
NOT EXISTS真的不走索引么？
查看兩種SQL的執行計划！
使用NOT EXIST方式的執行計划：
使用LEFT JOIN方式的執行計划：
從執行計划來看，兩個表都使用了索引，區別在於NOT EXISTS使用“DEPENDENT SUBQUERY”方式，而LEFT JOIN使用普通表關聯的方式。
通過MySQL提供的Profiling方式來查看兩種方式的執行過程。
使用NOT EXIST方式的執行過程：
使用LEFT JOIN方式的執行過程：
從執行過程來看，LEFT JOIN方式的主要消耗在Sending data一項上(1.2s)，而NOT EXISTS方式主要消耗在executeing和Sending data兩項上，受限於Profiling只存放100行記錄緣故。
從Profiling中只能看到47個” executeing和Sending data”的組合項(每個組合項約50us)，通過執行計划看出，外表t_monitor的數據量為578436行，忽略統計信息不准情況下，使用NOT EXISTS方式應該會產生578436個” executeing和Sending data”的組合項，總計消耗時間=50μs*578436=28921800us=28.92s。
從上面執行過程可以推斷出：
使用NOT EXISTS方式的執行性能嚴重依賴於NOT EXISTS子查詢的執行次數即外層查詢結果集的數據量。
-
當外層查詢結果集的數據量N較小時執行性能較好，如有N=10執行時間為50μs*10=500us=0.005s，再加上一些額外消耗，執行結果也能在0.01秒或10毫秒內范圍，這個響應時間應該能被大部分應用程序接受。
-
當外層程勛結果集的數據量N較大甚至上千萬數據量時，NOT EXISTS的查詢性能會變得非常糟糕，甚至會大量消耗服務器IO和CPU資源從而影響其他業務正常運行。
除上述問題外，在優化過程中發現本應該存儲相同數據的resource_id列在兩個表中定義不同，一表為VARCHAR而另外一表為BIGINT，外部結果集的字段類型和NOT EXIST字表中字段類型不同導致NOT EXISTS子查詢中無法使用索引，使得子查詢性能較差，最終影響整個查詢的執行性能。
京東商城也曾出現過大量類似案例，一些表使用VARCHAR來存放訂單號，而另一些表使用BIGINT來存放，在兩表進行管理時性能極差，希望研發同事引以為戒。關注公眾號Java技術棧回復m36獲取一份MySQL研發軍規。
版權聲明：本文為博主原創文章，遵循 CC 4.0 BY-SA 版權協議，轉載請附上原文出處鏈接和本聲明。本文鏈接：https://blog.csdn.net/guanfengliang1988/article/details/92814376
推薦去我的博客閱讀更多：
2.Spring MVC、Spring Boot、Spring Cloud 系列教程
3.Maven、Git、Eclipse、Intellij IDEA 系列工具教程
覺得不錯，別忘了點贊+轉發哦！