? ? 最近線上發版的時候，發現有個接口執行特別慢，前端App的表現就是沒有任何的反應，然后從pinpoint上追查接口發現是sql執行特別慢，平均都是在9s左右。這里由于使用了分頁查詢的 Mybatis interceptor所以同樣的sql還需要查詢一次count，導致整個耗時在9s左右，單個sql的耗時在5-6秒左右。

? ? 線上有一張訂單表數據大概是65萬條數據，另一張訂單配送任務表數據大概也是65萬條數據，有一條sql的 inner join兩張表，執行的sql大致如下：

?基于我對join優化的本能（join優化分析博客：Mysql - join（索引和非索引）的實現原理和優化手段也可以參考：https://www.processon.com/view/link/5ff1684ee0b34d19e4f89031），首先想到的就是是否使用了 Index Nested Loop Join，但是一看兩個join on的字段都是有索引的。就先看了一下執行計劃，如下：

? ? 該執行計劃顯示一張 65萬的數據走了全表掃描，使用了臨時表、使用了排序（注意這里寫的 filesort可能是內存排序不一定是文件排序）。出于本能我想到了將小表作為驅動表，但是本能也是將兩張表的位置進行了交互，但是發現效果沒有太大區別。

? ? 我們趕快翻我寫的processon上的優化注意點，試著將 inner join換成了 straght_join，就這一個小小的改動整個耗時從 6s變成了 400ms，我一下子就懵了，馬上看了一下執行計劃，如下：

?兩個表的 ALL、ref變成了 eq_ref、ref，并且兩個的key都使用了索引，Extra這里沒有了臨時表，增加了 Usingwherecondition。事后翻盤如果是兩個表的數據相差很大這個效果是接受的，但是兩個表的數據量都相當，這個性能提升和執行計劃還是有點懵的，希望高手幫解惑。

?在列一下從pinpoint上看到的使用 inner join和 straight_join的性能對比：