我对两个表进行内连接查询
select D.*,F.* FROM dyn D INNER JOIN uf F ON (D.uid=F.fuid AND F.uid=1) ORDER BY D.id DESC
发现数据量比较大的时候,执行效率低,用explain分析,看到Extra一栏的信息有using temporary,using filesort,查了一些资料说是如果extra有using temporary或者using filesort都会有问题,去掉这个查询语句后面的ORDER BY D.id DESC(D表的id是自动增加的主键,希望能用该字段进行排序),执行就快了很多,而且extra也没有using temporary和usingfilesort,这是怎么回事?如果才能解决?非常感谢。 id select_type table type possible_keys key key_len ref rows Extra
1 SIMPLE F ref FUID,UID UserID 4 const 8 Using temporary; Using filesort
1 SIMPLE D ref UID UserID 4 pdclub.F.FUID 9
select D.*,F.* FROM dyn D INNER JOIN uf F ON (D.uid=F.fuid AND F.uid=1) ORDER BY D.id DESC
发现数据量比较大的时候,执行效率低,用explain分析,看到Extra一栏的信息有using temporary,using filesort,查了一些资料说是如果extra有using temporary或者using filesort都会有问题,去掉这个查询语句后面的ORDER BY D.id DESC(D表的id是自动增加的主键,希望能用该字段进行排序),执行就快了很多,而且extra也没有using temporary和usingfilesort,这是怎么回事?如果才能解决?非常感谢。 id select_type table type possible_keys key key_len ref rows Extra
1 SIMPLE F ref FUID,UID UserID 4 const 8 Using temporary; Using filesort
1 SIMPLE D ref UID UserID 4 pdclub.F.FUID 9
ID
UID
Content
HappenTime
uf表
FID
UID
FUID
这个代表你用了ORDER BY 。所以这个EXTRA是很正常的,除非你不用ORDER BY 。
pdclub.F.FUID这个是索引,用到了。
还有一个CONST。这个代表常量。也是非常优化的。ORDER BY 本来就是很消耗资源的。
如果你经常ORDER BY 的话。建议增加你的SORT_BUFFER_SIZE的值。
mysql> show status like 'Sort_merge_passes';
+-------------------+-------+
| Variable_name | Value |
+-------------------+-------+
| Sort_merge_passes | 0 |
+-------------------+-------+
1 row in set (0.00 sec)