我這裡所說的主表是指在連接查詢裡MySQL以哪個表為主進行查詢。比如說在MySQL左連接查詢裡,一般來說左表就是主表,但這只是經驗之談,很多時候經驗主義是靠不住的,為了說明問題,先來個例子,建兩個演示用的表categorIEs和posts:
- CREATE TABLE IF NOT EXISTS `categorIEs` (
- `id` int(10) unsigned NOT NULL AUTO_INCREMENT,
- `name` varchar(15) NOT NULL,
- `created` datetime NOT NULL,
- PRIMARY KEY (`id`),
- KEY `name` (`name`)
- );
- CREATE TABLE IF NOT EXISTS `posts` (
- `id` int(10) unsigned NOT NULL AUTO_INCREMENT,
- `category_id` int(10) unsigned NOT NULL,
- `title` varchar(100) NOT NULL,
- `content` varchar(200) NOT NULL,
- `created` datetime NOT NULL,
- PRIMARY KEY (`id`),
- KEY `category_id` (`category_id`),
- KEY `created` (`created`),
- KEY `category_id_created` (`category_id`, `created`)
- );
先注意一下每個表的索引情況,以後會用到,記得隨便插入一點測試數據,不用太多,但怎麼也得兩行以上,然後執行以下
- SQL:
- EXPLAIN SELECT *
- FROM posts
- LEFT JOIN categorIEs ON posts.category_id = categorIEs.id
- WHERE categorIEs.name LIKE 'foobar%'
- ORDER BY posts.created DESC
結果如下所示:
- table key Extra
- categorIEs name Using where; Using temporary; Using filesort
- posts category_id
在join查詢的explain的結果中,第一行表示的表就是主表。所以說在此查詢裡categorIEs是主表,而在我們的經驗裡,LEFT JOIN查詢裡,左表(posts表)才應該是主表,這產生一個根本的矛盾,MySQL之所以這樣處理,是因為在我們的WHERE部分,查詢條件是按照categories表的字段來進行篩選的,且categories表剛好存在合適的索引,所以在查詢時把categorIEs表作為主表更有利於縮小結果集。
那explain結果中的Using temporary; Using filesort又是為什麼呢,為什麼created或category_id_created索引無效呢?這是因為主表是categorIEs表,從表是posts表,而我們使用從表的字段去ORDER BY,這通常不是一個好選擇,最好改成主表字段。不過很多時候改不了,那就沒招了。
再看一個比較怪異的例子:
- EXPLAIN SELECT *
- FROM posts
- LEFT JOIN categorIEs ON posts.category_id = categorIEs.id
- WHERE categorIEs.id = ‘一個已經存在的ID’
- ORDER BY posts.created DESC
這個例子裡posts表仍然是從表,但是按照從表排序的結果卻沒有出現文件排序和臨時表,這是因為已經確定了categories.id,所以主表相當於一個只有一行數據的常量表了,從表根據category_id_created索引在連接的同時自然就得到排序後的結果。但換個角度看,既然categories.id都是確定的了,那類似這樣的需求,我們一般就不會再使用LEFT JOIN查詢了,而會分成兩個獨立的查詢去檢索categorIEs和posts才對。
主觀上一旦搞錯了主表,可能怎麼調整索引都得不到高效的SQL,所以在寫SQL時,比如說在寫MySQL左連接查詢時,如果希望左表是主表,那麼就要保證在WHERE語句裡的查詢條件盡可能多的使用左表字段,進而,一旦確定了主表,也最好只通過主表字段去ORDER BY。
注意:大多數情況下,使用從表字段去排序都是低效的,我最初的例子誤導了大家,已更正。