MySQL线上优化_线上MySQL千万级大表,如何优化?

前段时间应急群有客服反馈,会员管理功能无法按到店时间、到店次数、消费金额进行排序。经过排查发现是 SQL 执行效率低,并且索引效率低下。

d408213022a86b309baabb897fc8bd0f.png

图片来自 Pexels

应急问题

商户反馈会员管理功能无法按到店时间、到店次数、消费金额进行排序,一直转圈圈或转完无变化,商户要以此数据来做活动,比较着急,请尽快处理,谢谢。

线上数据量

merchant_member_info:7000W 条数据。

member_info:3000W。

不要问我为什么不分表,改动太大,无能为力。

问题 SQL

问题 SQL 如下:

SELECT

mui.id,

mui.merchant_id,

mui.member_id,

DATE_FORMAT(

mui.recently_consume_time,

'%Y%m%d%H%i%s'

) recently_consume_time,

IFNULL(mui.total_consume_num, 0) total_consume_num,

IFNULL(mui.total_consume_amount, 0) total_consume_amount,

(

CASE

WHENu.nick_nameISNULLTHEN

'会员'

WHENu.nick_name =''THEN

'会员'

ELSE

u.nick_name

END

) AS'nickname',

u.sex,

u.head_image_url,

u.province,

u.city,

u.country

FROM

merchant_member_info mui

LEFTJOINmember_info uONmui.member_id = u.id

WHERE

1 = 1

ANDmui.merchant_id ='商户编号'

ORDERBY

mui.recently_consume_time DESC/ASC

LIMIT 0,

10

出现的原因

经过验证可以按照“到店时间”进行降序排序,但是无法按照升序进行排序主要是查询太慢了。

主要原因是:虽然该查询使用建立了 recently_consume_time 索引,但是索引效率低下,需要查询整个索引树,导致查询时间过长。DESC 查询大概需要 4s,ASC 查询太慢耗时未知。

为什么降序排序快和而升序慢呢?

如下图:

0a381525431b122aae333bcf56d5d1ea.png

因为是对时间建立了索引,最近的时间一定在最后面,升序查询,需要查询更多的数据,才能过滤出相应的结果,所以慢。

解决方案

目前生产库的索引,如下图:

658506aeaa3a4a467c26bd34a29fc148.png

①调整索引

需要删除 index_merchant_user_last_time 索引,同时将 index_merchant_user_merchant_ids 单例索引,变为 merchant_id,recently_consume_time 组合索引。

②调整结果(准生产)

如下图:

2df5f62576d57eb281049741572fd53b.png

③调整前后结果对比(准生产)

测试数据:

merchant_member_info 有 902606 条记录。

member_info 表有 775 条记录。

④SQL 执行效率

优化前,如下图:

d7c35b33688491099e1def34a8988f4c.png

优化后,如下图:

1363c83a78c5223ff82429b8373dc678.png

type 由 index→ref,ref 由 null→const:

b213e6079c1d7c0a5312f76e59876ea8.png

调整索引需要执行的 SQL

执行的注意事项:由于表中的数据量太大,请在晚上进行执行,并且需要分开执行。

# 删除近期消费时间索引

ALTERTABLEmerchant_member_infoDROPINDEXindex_merchant_user_last_time;

# 删除商户编号索引

ALTERTABLEmerchant_member_infoDROPINDEXindex_merchant_user_merchant_ids;

# 建立商户编号和近期消费时间组合索引

ALTERTABLEmerchant_member_infoADDINDEXidx_merchant_id_recently_time (`merchant_id`,`recently_consume_time`);

经询问,重建索引花了 30 分钟。

最终的分页查询优化

上面的 SQL 虽然经过调整索引,虽然能达到较高的执行效率,但是随着分页数据的不断增加,性能会急剧下降。

9a9ae088255a303ced3ebe6f2b1c9762.png

最终的 SQL

优化思路:先走覆盖索引定位到,需要的数据行的主键值,然后 INNER JOIN 回原表,取到其他数据。

SELECT

mui.id,

mui.merchant_id,

mui.member_id,

DATE_FORMAT(

mui.recently_consume_time,

'%Y%m%d%H%i%s'

) recently_consume_time,

IFNULL(mui.total_consume_num, 0) total_consume_num,

IFNULL(mui.total_consume_amount, 0) total_consume_amount,

(

CASE

WHENu.nick_nameISNULLTHEN

'会员'

WHENu.nick_name =''THEN

'会员'

ELSE

u.nick_name

END

) AS'nickname',

u.sex,

u.head_image_url,

u.province,

u.city,

u.country

FROM

merchant_member_info mui

INNERJOIN(

SELECT

id

FROM

merchant_member_info

WHERE

merchant_id = '商户ID'

ORDERBY

recently_consume_time DESC

LIMIT 9000,

10

) AStmpONtmp.id = mui.id

LEFTJOINmember_info uONmui.member_id = u.id

作者:不一样的科技宅

编辑:陶家龙

出处:juejin.cn/post/6844904053239971854

928cadca50a91770a8d38bc65c1bfd0b.gif

【编辑推荐】

【责任编辑:武晓燕 TEL:(010)68476606】

点赞 0

  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值