在MySQL中應用STRAIGHT_JOIN的教程。本站提示廣大學習愛好者：（在MySQL中應用STRAIGHT_JOIN的教程）文章只能為提供參考，不一定能成為您想要的結果。以下是在MySQL中應用STRAIGHT_JOIN的教程正文
成績
經由過程「SHOW FULL PROCESSLIST」語句很輕易就可以查到成績SQL，以下：
SELECT post.* FROM post INNER JOIN post_tag ON post.id = post_tag.post_id WHERE post.status = 1 AND post_tag.tag_id = 123 ORDER BY post.created DESC LIMIT 100
解釋：由於post和tag是多對多的關系，所以存在一個聯系關系表post_tag。
試著用EXPLAIN查詢一下SQL履行籌劃(篇幅所限，成果有刪減)：
+----------+---------+-------+-----------------------------+ | table | key | rows | Extra | +----------+---------+-------+-----------------------------+ | post_tag | tag_id | 71220 | Using where; Using filesort | | post | PRIMARY | 1 | Using where | +----------+---------+-------+-----------------------------+
上面給出優化後的SQL，獨一的變更就是把銜接方法改成了「STRAIGHT_JOIN」：
SELECT post.* FROM post STRAIGHT_JOIN post_tag ON post.id = post_tag.post_id WHERE post.status = 1 AND post_tag.tag_id = 123 ORDER BY post.created DESC LIMIT 100
試著用EXPLAIN查詢一下SQL履行籌劃(篇幅所限，成果有刪減)：
+----------+----------------+--------+-------------+ | table | key | rows | Extra | +----------+----------------+--------+-------------+ | post | status_created | 119340 | Using where | | post_tag | post_id | 1 | Using where | +----------+----------------+--------+-------------+
比較優化前後兩次EXPLAIN的成果來看，優化後的SQL固然「rows」更年夜了，然則沒有了「Using filesort」，綜合來看，機能仍然獲得了晉升。
說明
對第一條SQL而言，為何MySQL優化器選擇了一個耗時的履行計劃？對第二條SQL而言，為何把銜接方法改成STRAIGHT_JOIN以後就晉升了機能？
這一切還得從MySQL對多表銜接的處置方法說起，起首要肯定以誰為驅動表，也就是說以哪一個表為基准，在處置此類成績時，MySQL優化器采取了簡略粗魯的處理辦法：哪一個表的成果集小，就以哪一個表為驅動表，平日這都是最好選擇。
解釋：在EXPLAIN成果中，第一行湧現的表就是驅動表。
持續post銜接post_tag的例子，MySQL優化器有以下兩個選擇，分離是：
不言而喻，post_tag過濾的成果集更小，所以MySQL優化器選擇它作為驅動表，可悲催的是我們還須要以post表中的created字段來排序，也就是說排序字段不在驅動內外，因而乎弗成防止的湧現了「Using filesort」，從而招致慢查詢。
曉得了前因後果，優化起來就輕易了。優等年夜事是務必包管排序字段在驅動表中，所以必需以post是驅動表，因而乎「STRAIGHT_JOIN」就成了謎底，它強迫了銜接次序。
…
不外我總認為「STRAIGHT_JOIN」這類非尺度的語法屬於奇技淫巧的領域，能不消盡可能不消，究竟多半情形下，MySQL優化器都能做出准確的選擇。
