前往小程序,Get更优阅读体验!
立即前往
首页
学习
活动
专区
工具
TVP
发布
社区首页 >专栏 >SQL优化案例一则

SQL优化案例一则

作者头像
jeanron100
发布2019-05-17 15:16:17
5220
发布2019-05-17 15:16:17
举报

这是学习笔记的第 1978 篇文章

今天优化了几个SQL问题,拿出来两个做下总结和分享。

第一条SQL如下,内容做了删减。

SELECT p.*, m.uid, m.username, m.groupid, ....m.email, m.gender, m.showemail, m.invisible

FROM cdb_posts p

LEFT JOIN cdb_members m ON m.uid=p.authorid

LEFT JOIN cdb_memberfields mf ON mf.uid=m.uid

WHERE p.tid='xxxxx' AND p.invisible='0' ORDER BY first DESC,dateline DESC LIMIT 13250, 50

这条语句的执行效率根据监控,平均时间在9秒,但是在测试的时候,时间执行时间远远大于9秒,我们就暂且按照9秒来估算时间成本吧。

cdb_posts表的数据有3000多万,另外两个表cdb_members,cdb_memberfields的数据量也不小,量级在七百万。 其中索引分布在如下的字段中:

  • 索引字段:cdb_posts.authorid,tid 数据量:3000多万
  • 索引字段:cdb_members.uid 数据量:700多万
  • 索引字段:cdb_memberfields.uid 数据量:3000多万

对于这样一个SQL,按照目前的执行情况,基于LEFT JOIN,肯定是有一个表要“全量”了。

所以整个SQL的关注目标先在于where子句:

p.tid='xxxxx' AND p.invisible='0'

根据测试,这个数据量也相对小一些:

>>SELECT count(*)

-> FROM cdb_posts p

-> LEFT JOIN discuz.cdb_members m ON m.uid=p.authorid

-> WHERE p.tid='6297759' AND p.invisible='0' ;

+----------+

| count(*) |

+----------+

| 29625 |

+----------+

1 row in set (7.27 sec)

所以我们后续的测试会以这个数据作为基础,执行计划如下:

*************************** 1. row ***************************

id: 1

select_type: SIMPLE

table: p

type: ref

possible_keys: displayorder,idx_tid_fir_authorid,idx_invisible

key: displayorder

key_len: 4

ref: const,const

rows: 59148

Extra: Using where; Using filesort

*************************** 2. row ***************************

id: 1

select_type: SIMPLE

table: m

type: eq_ref

possible_keys: PRIMARY

key: PRIMARY

key_len: 4

ref: test.p.authorid

rows: 1

Extra:

*************************** 3. row ***************************

id: 1

select_type: SIMPLE

table: mf

type: eq_ref

possible_keys: PRIMARY

key: PRIMARY

key_len: 4

ref: test.m.uid

rows: 1

Extra:

3 rows in set (0.00 sec)

从执行计划来看,瓶颈点就在于第1部分了,整个SQL的执行路径类似于下面的形式:

对于这个部分的评估,主要是做了索引的评估,发现改进力度很有限,所以我的注意力放在了逻辑部分,其中cdb_posts是最全面的信息,后续的信息都是以它作为基础,而输出结果是只有50行。

所以从优化上来说,既然优化器看不到这个边界,我们可以间接告诉它。

即把cdb_posts缩小为一个派生表:

select * from cdb_posts where tid='xxxx' AND invisible='0' LIMIT 11625, 50

这样的话数据量是绝对可控,而且符合逻辑的。

改造后的语句如下:

SELECT SQL_NO_CACHE p.*, m.uid, m.username, 。。。m.email, m.gender, m.showemail, m.invisible。。。

FROM (

select * from cdb_posts where tid='xxxx' AND invisible='0' LIMIT 11625, 50

)p

LEFT JOIN cdb_members m ON m.uid=p.authorid

LEFT JOIN cdb_memberfields mf ON mf.uid=m.uid

ORDER BY dateline DESC,first asc;

改造后,执行时间为0.14秒,相比之前的方式快了许多。

本文参与 腾讯云自媒体分享计划,分享自微信公众号。
原始发表:2019-05-13,如有侵权请联系 cloudcommunity@tencent.com 删除

本文分享自 杨建荣的学习笔记 微信公众号,前往查看

如有侵权,请联系 cloudcommunity@tencent.com 删除。

本文参与 腾讯云自媒体分享计划  ,欢迎热爱写作的你一起参与!

评论
登录后参与评论
0 条评论
热度
最新
推荐阅读
领券
问题归档专栏文章快讯文章归档关键词归档开发者手册归档开发者手册 Section 归档