【发布时间】：2018-03-17 16:20:01
【问题描述】：
编辑：我从示例查询中删除了GROUP BY 子句，但同样的问题显示“当我将表 x 连接到一个空/1 行表 y 时，尽管我使用限制”
原问题： 我试图学习如何优化我的 SQL 查询，但遇到了我无法理解的行为。有这样的架构
CREATE TABLE `country` (
`id` int(11) NOT NULL AUTO_INCREMENT,
`name` varchar(45) DEFAULT NULL,
PRIMARY KEY (`id`)
) ENGINE=InnoDB ;
CREATE TABLE `school` (
`id` int(11) NOT NULL AUTO_INCREMENT,
`name` varchar(45) DEFAULT NULL,
PRIMARY KEY (`id`)
) ENGINE=InnoDB ;
CREATE TABLE `users` (
`id` int(11) NOT NULL AUTO_INCREMENT,
`name` varchar(45) DEFAULT NULL,
`country_id` int(11) DEFAULT NULL,
PRIMARY KEY (`id`),
KEY `fk_country_idx` (`country_id`),
CONSTRAINT `fk_users_country` FOREIGN KEY (`country_id`) REFERENCES `country` (`id`) ON DELETE NO ACTION ON UPDATE NO ACTION
) ENGINE=InnoDB ;
CREATE TABLE `user_school_mm` (
`user_id` int(11) NOT NULL,
`school_id` int(11) NOT NULL,
PRIMARY KEY (`user_id`, `school_id`),
KEY `fk_user_school_mm_user_idx` (`user_id`),
KEY `fk_user_school_mm_school_idx` (`school_id`),
CONSTRAINT `fk_user_school_mm_user` FOREIGN KEY (`user_id`) REFERENCES `users` (`id`) ON DELETE CASCADE ON UPDATE NO ACTION,
CONSTRAINT `fk_user_school_mm_school` FOREIGN KEY (`school_id`) REFERENCES `school` (`id`) ON DELETE CASCADE ON UPDATE NO ACTION
) ENGINE=InnoDB ;
INSERT INTO country (name) VALUES ('fooCountry1');
INSERT INTO school (name) VALUES ('fooSchool1'),('fooSchool2'),('fooSchool3');
INSERT INTO users (name, country_id) VALUES
('fooUser1',1),
('fooUser2',1),
('fooUser3',1),
('fooUser4',1),
('fooUser5',1),
('fooUser6',1),
('fooUser7',1),
('fooUser8',1),
('fooUser9',1),
('fooUser10',1)
;
INSERT INTO user_school_mm (user_id, school_id) VALUES
(1,1),(1,2),(1,3),
(2,1),(2,2),(2,3),
(3,1),(3,2),(3,3),
(4,1),(4,2),(4,3),
(5,1),(5,2),(5,3),
(6,1),(6,2),(6,3),
(7,1),(7,2),(7,3),
(8,1),(8,2),(8,3),
(9,1),(9,2),(9,3),
(10,1),(10,2),(10,3)
;
查询 1（快速）
-- GOOD QUERY (MySQL uses the limit and skip users table scan after 2 rows )
SELECT *
FROM
users LEFT JOIN
user_school_mm on users.id = user_school_mm.user_id
ORDER BY users.id ASC
LIMIT 2
-- takes about 100 milliseconds if users table is 3 million records
解释
+---+-----------+---------------+------+-----------------------------------+----------+---------+---------------+------+-----------+
|id |select_type|table | type | possible_keys | key | key_len | ref | rows | Extra |
+---+-----------+---------------+------+-----------------------------------+----------+---------+---------------+------+-----------+
|1 |SIMPLE |users |index |PRIMARY,fk_country_idx | PRIMARY |4 | |2 | |
|1 |SIMPLE |user_school_mm |ref |PRIMARY,fk_user_school_mm_user_idx | PRIMARY |4 |tests.users.id |1 |Using index|
+---+-----------+---------------+------+-----------------------------------+----------+---------+---------------+------+-----------+
QUERY 2（慢）
-- BAD QUERY (MySQL ignores the limit and scanned the entire users table )
SELECT *
FROM
users LEFT JOIN
country on users.country_id = country.id
ORDER BY users.id ASC
LIMIT 2
-- takes about 9 seconds if users table is 3 million records
解释
+---+-----------+--------+------+------------------------+-----+---------+-----+------+---------------------------------------------------+
|id |select_type|table | type | possible_keys | key | key_len | ref | rows | Extra |
+---+-----------+--------+------+------------------------+-----+---------+-----+------+---------------------------------------------------+
|1 |SIMPLE |users |ALL | PRIMARY,fk_country_idx | | | | 10 | Using temporary; Using filesort |
|1 |SIMPLE |country |ALL | PRIMARY | | | | 1 | Using where; Using join buffer (Block Nested Loop)|
+---+-----------+--------+------+------------------------+-----+---------+-----+------+---------------------------------------------------+
我不明白幕后发生了什么，我想如果我使用 users 表的主键进行排序和分组，MySQL 将取 users 表的前 2 行并继续加入，但它似乎没有这样做，而是在查询 2 中扫描了整个表
为什么 MySQL 在 query2 中扫描整个表，而在 query1 中只扫描前 2 行？
MySQL 版本是 5.6.38
【问题讨论】：
-
我猜它会在找到足够多的行后结束扫描。
-
@shawnt00 但在查询 2 中，它扫描了整个表（本示例中为 10 行），如果用户表为 300 万行，则扫描 300 万行
-
您的“好”查询也很糟糕...
SELECT * .... GROUP BY users.id是错误的 ansi GROUP BY SQL。它可能导致不良的无关数据psce.com/en/blog/2012/05/15/… -
这些是格式错误的查询，使用
select *和group by。也许这解释了为什么 MySQL 不尝试优化它们。这些很容易被更合适的逻辑替换，从而产生正确的执行计划。 -
很高兴你把它整理好了。我其实只是第一次略过，错过了一个重要的细节。
标签： mysql sql performance