不知道有没有人碰到过这样恶心的问题:两张表连接查询并limit,SQL效率很高,但是加上order by以后,语句的执行时间变的巨长,效率巨低。
情况是这么一个情况:现在有两张表,team表和people表,每个people属于一个team,people中有个字段team_id。
下面给出建表语句:
复制代码 代码如下:
create table t_team
(
id int primary key,
tname varchar(100)
);
create table t_people
(
id int primary key,
pname varchar(100),
team_id int,
foreign key (team_id) references t_team(id)
);
下面我要连接两张表查询出前10个people,按tname排序。
于是,一个SQL语句诞生了:select * from t_people p left join t_team t on p.team_id=t.id order by p.pname limit 10; [语句①]
这个是我第一反应写的SQL,通俗易懂,也是大多数人的第一反应。然后来测试一下这个语句的执行时间。首先要准备数据。我用存储过程在t_team表中生成1000条数据,在t_people表中生成100000条数据。(存储过程在本文最后)
执行上面那条SQL语句,执行了好几次,耗时在3秒左右。
再换两个语句对比一下:
1.把order by子句去掉:select * from t_people p left join t_team t on p.team_id=t.id limit10; [语句②]
耗时0.00秒,忽略不计。
2.还是使用order by,但是把连接t_team表去掉:select * from t_people p order by p.pname limit 10; [语句③]
耗时0.15秒左右。
对比发现[语句①]的效率巨低。
为什么效率这么低呢。[语句②]和[语句③]执行都很快,[语句①]不过是二者的结合。如果先执行[语句③]得到排序好的10条people结果后,再连接查询出各个people的team,效率不会这么低。那么只有一个解释:MySQL先执行连接查询,再进行排序。
解决方法:如果想提高效率,就要修改SQL语句,让MySQL先排序取前10条再连接查询。
SQL语句:
select * from (select * from t_people p order by p.pname limit 10) p left join t_team t on p.team_id=t.id limit 10; [语句④]
[语句④]和[语句①]功能一样,虽然有子查询,虽然看起来很别扭,但是效率提高了很多,它的执行时间只要0.16秒左右,比之前的[语句①] (耗时3秒) 提高了20倍。
这两个表的结构很简单,如果遇到复杂的表结构…我在实际开发中就碰到了这样的问题,使用[语句①]的方式耗时80多秒,但使用[语句④]只需1秒以内。
最后给出造数据的存储过程:
复制代码 代码如下:
CREATE PROCEDURE createdata()
BEGIN
DECLARE i INT;
START TRANSACTION;
SET i=0;
WHILE i<1000 DO
INSERT INTO t_team VALUES(i+1,CONCAT('team',i+1));
SET i=i+1;
END WHILE;
SET i=0;
WHILE i<100000 DO
INSERT INTO t_people VALUES(i+1,CONCAT('people',i+1),i%1000+1);
SET i=i+1;
END WHILE;
COMMIT;
END
情况是这么一个情况:现在有两张表,team表和people表,每个people属于一个team,people中有个字段team_id。
下面给出建表语句:
复制代码 代码如下:
create table t_team
(
id int primary key,
tname varchar(100)
);
create table t_people
(
id int primary key,
pname varchar(100),
team_id int,
foreign key (team_id) references t_team(id)
);
下面我要连接两张表查询出前10个people,按tname排序。
于是,一个SQL语句诞生了:select * from t_people p left join t_team t on p.team_id=t.id order by p.pname limit 10; [语句①]
这个是我第一反应写的SQL,通俗易懂,也是大多数人的第一反应。然后来测试一下这个语句的执行时间。首先要准备数据。我用存储过程在t_team表中生成1000条数据,在t_people表中生成100000条数据。(存储过程在本文最后)
执行上面那条SQL语句,执行了好几次,耗时在3秒左右。
再换两个语句对比一下:
1.把order by子句去掉:select * from t_people p left join t_team t on p.team_id=t.id limit10; [语句②]
耗时0.00秒,忽略不计。
2.还是使用order by,但是把连接t_team表去掉:select * from t_people p order by p.pname limit 10; [语句③]
耗时0.15秒左右。
对比发现[语句①]的效率巨低。
为什么效率这么低呢。[语句②]和[语句③]执行都很快,[语句①]不过是二者的结合。如果先执行[语句③]得到排序好的10条people结果后,再连接查询出各个people的team,效率不会这么低。那么只有一个解释:MySQL先执行连接查询,再进行排序。
解决方法:如果想提高效率,就要修改SQL语句,让MySQL先排序取前10条再连接查询。
SQL语句:
select * from (select * from t_people p order by p.pname limit 10) p left join t_team t on p.team_id=t.id limit 10; [语句④]
[语句④]和[语句①]功能一样,虽然有子查询,虽然看起来很别扭,但是效率提高了很多,它的执行时间只要0.16秒左右,比之前的[语句①] (耗时3秒) 提高了20倍。
这两个表的结构很简单,如果遇到复杂的表结构…我在实际开发中就碰到了这样的问题,使用[语句①]的方式耗时80多秒,但使用[语句④]只需1秒以内。
最后给出造数据的存储过程:
复制代码 代码如下:
CREATE PROCEDURE createdata()
BEGIN
DECLARE i INT;
START TRANSACTION;
SET i=0;
WHILE i<1000 DO
INSERT INTO t_team VALUES(i+1,CONCAT('team',i+1));
SET i=i+1;
END WHILE;
SET i=0;
WHILE i<100000 DO
INSERT INTO t_people VALUES(i+1,CONCAT('people',i+1),i%1000+1);
SET i=i+1;
END WHILE;
COMMIT;
END
标签:
连接查询,limit,join
免责声明:本站文章均来自网站采集或用户投稿,网站不提供任何软件下载或自行开发的软件!
如有用户或公司发现本站内容信息存在侵权行为,请邮件告知! 858582#qq.com
暂无“MySQL查询优化:连接查询排序limit(join、order by、limit语句)介绍”评论...
RTX 5090要首发 性能要翻倍!三星展示GDDR7显存
三星在GTC上展示了专为下一代游戏GPU设计的GDDR7内存。
首次推出的GDDR7内存模块密度为16GB,每个模块容量为2GB。其速度预设为32 Gbps(PAM3),但也可以降至28 Gbps,以提高产量和初始阶段的整体性能和成本效益。
据三星表示,GDDR7内存的能效将提高20%,同时工作电压仅为1.1V,低于标准的1.2V。通过采用更新的封装材料和优化的电路设计,使得在高速运行时的发热量降低,GDDR7的热阻比GDDR6降低了70%。
更新动态
2024年12月28日
2024年12月28日
- 小骆驼-《草原狼2(蓝光CD)》[原抓WAV+CUE]
- 群星《欢迎来到我身边 电影原声专辑》[320K/MP3][105.02MB]
- 群星《欢迎来到我身边 电影原声专辑》[FLAC/分轨][480.9MB]
- 雷婷《梦里蓝天HQⅡ》 2023头版限量编号低速原抓[WAV+CUE][463M]
- 群星《2024好听新歌42》AI调整音效【WAV分轨】
- 王思雨-《思念陪着鸿雁飞》WAV
- 王思雨《喜马拉雅HQ》头版限量编号[WAV+CUE]
- 李健《无时无刻》[WAV+CUE][590M]
- 陈奕迅《酝酿》[WAV分轨][502M]
- 卓依婷《化蝶》2CD[WAV+CUE][1.1G]
- 群星《吉他王(黑胶CD)》[WAV+CUE]
- 齐秦《穿乐(穿越)》[WAV+CUE]
- 发烧珍品《数位CD音响测试-动向效果(九)》【WAV+CUE】
- 邝美云《邝美云精装歌集》[DSF][1.6G]
- 吕方《爱一回伤一回》[WAV+CUE][454M]