問題

我們有一個 SQL，用于找到沒有主鍵 / 唯一鍵的表，但是在 MySQL 5.7 上運行特別慢，怎么辦?

實驗

我們搭建一個 MySQL 5.7 的環境，此處省略搭建步驟。

寫個簡單的腳本，制造一批帶主鍵和不帶主鍵的表：

執行一下腳本：

現在執行以下 SQL 看看效果：

...

執行了 16.80s，感覺是非常慢了。

現在用一下 DBA 三板斧，看看執行計劃：

感覺有點慘，由于 information_schema.columns 是元數據表，沒有必要的統計信息。

那我們來 show warnings 看看 MySQL 改寫后的 SQL：

我們格式化一下 SQL：

可以看到 MySQL 將

select from A where A.x not in (select x from B) //非關聯子查詢

轉換成了

select from A where not exists (select 1 from B where B.x = a.x) //關聯子查詢

如果我們自己是 MySQL，在執行非關聯子查詢時，可以使用很簡單的策略：

select from A where A.x not in (select x from B where ...) //非關聯子查詢:1. 掃描 B 表中的所有記錄，找到滿足條件的記錄，存放在臨時表 C 中，建好索引2. 掃描 A 表中的記錄，與臨時表 C 中的記錄進行比對，直接在索引里比對，

而關聯子查詢就需要循環迭代：

select from A where not exists (select 1 from B where B.x = a.x and ...) //關聯子查詢掃描 A 表的每一條記錄 rA： 掃描 B 表，找到其中的第一條滿足 rA 條件的記錄。

顯然，關聯子查詢的掃描成本會高于非關聯子查詢。

我們希望 MySQL 能先"緩存"子查詢的結果（緩存這一步叫物化，MATERIALIZATION），但MySQL 認為不緩存更快，我們就需要給予 MySQL 一定指導。

...

可以看到執行時間變成了 0.67s。

整理

我們診斷的關鍵點如下：

\1. 對于 information_schema 中的元數據表，執行計劃不能提供有效信息。

\2. 通過查看 MySQL 改寫后的 SQL，我們猜測了優化器發生了誤判。

\3. 我們增加了 hint，指導 MySQL 正確進行優化判斷。

但目前我們的實驗僅限于猜測，猜中了萬事大吉，猜不中就無法做出好的診斷。