MySQL HINT：Straight_JOIN 來自生產環境的朋友、可能都會碰到： 原本運行良好的查詢語句，過了一段時間後，可能會突然變得很糟糕 一個很大可能的原因就是數據分布情況發生了變化 從而導致MySQL優化器對驅動表的選擇發生了變化，進而出現索引失效的情況 所以、閒著蛋疼喝咖啡的時候、應該多收集兩下表的統計信息 這個時候、Straight_JOIN 閃亮登場 MySQL 只支持 Nested Loop Join、關於這個Nested JOIN的詳細用法請參閱偶之前blog：點擊打開鏈接 http://www.BkJia.com/database/201301/186885.html 和Oracle對比下、不然得知、Straight_JOIN相當於Oracle裡面的：USE_NL、所以、原理和適用上大概都是相同的、 不過、對於驅動表的選擇、MySQL 優化器可能沒有Oracle那般智能、MySQL采用簡單粗暴的方法： 哪個表的結果集小，就以哪個表為驅動表 偶趕腳有2 種原因可令你選擇 Straight_JOIN ① MySQL 優化器不給力、錯誤選擇驅動表 ② Nested Loop Join 的適用場景： ==>一般用在連接的表中有索引，並且索引選擇性較好（也就是Selectivity接近1）的時候 ==>也就是驅動表的記錄集比較小（<10000）而且inner表需要有有效的訪問方法（Index） 一般的優化操作： ① show full processlist; <===查找TOP-SQL ② explain + TOP-SQL ; <===查詢SQL 執行計劃 注意：在EXPLAIN結果中，第一行出現的表就是驅動表 一個經典優化例子： 當explian輸出結果中含：「Using filesort」，甚至「Using temporary」 我們就該擦亮雙眼、像打了雞血一樣、保持時刻優化的姿態 此刻的優化就容易多了、盡可能保證排序字段在驅動表中
