线上千万级大表排序:优化攻略揭秘,轻松应对海量数据!

简介: 前段时间应急群有客服反馈,会员管理功能无法按到店时间、到店次数、消费金额 进行排序。经过排查发现是Sql执行效率低,并且索引效率低下。遇到这样的情况我们该如何处理呢?今天我们聊一聊Mysql大表查询优化。

前言

  前段时间应急群有客服反馈,会员管理功能无法按到店时间、到店次数、消费金额 进行排序。经过排查发现是Sql执行效率低,并且索引效率低下。遇到这样的情况我们该如何处理呢?今天我们聊一聊Mysql大表查询优化。

应急问题

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

线上数据量

merchant_member_info 7000W条数据。
member_info 3000W。

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

问题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
        WHEN u.nick_name IS NULL THEN
            '会员'
        WHEN u.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
LEFT JOIN member_info u ON mui.member_id = u.id
WHERE
    1 = 1
AND mui.merchant_id = '商户编号'
ORDER BY
    mui.recently_consume_time DESC / ASC
LIMIT 0,
 10

出现的原因

  经过验证可以按照“到店时间”进行降序排序,但是无法按照升序进行排序主要是查询太慢了。主要原因是:虽然该查询使用建立了recently_consume_time索引,但是索引效率低下,需要查询整个索引树,导致查询时间过长。

DESC 查询大概需要4s,ASC 查询太慢耗时未知。

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

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

解决方案

目前生产库的索引

调整索引

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

调整结果(准生产)

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

 测试数据

merchant_member_info 有902606条记录。
member_info 表有775条记录。

SQL执行效率

优化前

优化后

type由index -> ref

ref由 null -> const

TOP 优化前 优化后
到店时间-降序 0.274s 0.003s
到店时间-升序 11.245s 0.003s

调整索引需要执行的SQL

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

# 删除近期消费时间索引
ALTER TABLE merchant_member_info DROP INDEX index_merchant_user_last_time;

# 删除商户编号索引
ALTER TABLE merchant_member_info DROP INDEX index_merchant_user_merchant_ids;

# 建立商户编号和近期消费时间组合索引
ALTER TABLE merchant_member_info ADD INDEX idx_merchant_id_recently_time (`merchant_id`,`recently_consume_time`);

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

最终的分页查询优化

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

分页数据 查询时间 优化后
limit 0,10 0.003s 0.002s
limit 10,10 0.005s 0.002s
limit 100,10 0.009s 0.002s
limit 1000,10 0.044s 0.004s
limit 9000,10 0.247s 0.016s

最终的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
        WHEN u.nick_name IS NULL THEN
            '会员'
        WHEN u.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
INNER JOIN (
    SELECT
        id
    FROM
        merchant_member_info
    WHERE
        merchant_id = '商户ID'
    ORDER BY
        recently_consume_time DESC
    LIMIT 9000,
    10
) AS tmp ON tmp.id = mui.id
LEFT JOIN member_info u ON mui.member_id = u.id

结尾

  如果觉得对你有帮助,可以多多评论,多多点赞哦,也可以到我的主页看看,说不定有你喜欢的文章,也可以随手点个关注哦,谢谢。

  我是不一样的科技宅,每天进步一点点,体验不一样的生活。我们下期见!

相关文章
|
8月前
|
SQL 存储 数据库连接
日活3kw下,如何应对实际业务场景中SQL过慢的优化挑战?
在面试中,SQL调优是一个常见的问题,通过这个问题可以考察应聘者对于提升SQL性能的理解和掌握程度。通常来说,SQL调优需要按照以下步骤展开。
|
缓存 关系型数据库 Java
哈啰一面:如何优化大表的查询速度?
哈啰一面:如何优化大表的查询速度?
225 1
哈啰一面:如何优化大表的查询速度?
|
2月前
|
消息中间件 存储 缓存
十万订单每秒热点数据架构优化实践深度解析
【11月更文挑战第20天】随着互联网技术的飞速发展,电子商务平台在高峰时段需要处理海量订单,这对系统的性能、稳定性和扩展性提出了极高的要求。尤其是在“双十一”、“618”等大型促销活动中,每秒需要处理数万甚至数十万笔订单,这对系统的热点数据处理能力构成了严峻挑战。本文将深入探讨如何优化架构以应对每秒十万订单级别的热点数据处理,从历史背景、功能点、业务场景、底层原理以及使用Java模拟示例等多个维度进行剖析。
59 8
|
存储 测试技术 C++
实践:几十亿条数据分布在几十个节点上的毫秒级实时排序方法
#引子 先简单的问一下, 你如何解决这样的需求: ``` 对一堆数据按某字段排序,获取第100-10条的数据。 ``` 假设你面对的数据是个单节点,简单来说,就是一个mysql数据库, 很自然地用 select a from tb order by a limit 100, 10; ![imag
4245 0
|
2月前
|
NoSQL 关系型数据库 MySQL
百万数据量优化实战
在现代互联网业务中,处理百万级别的数据量是家常便饭。传统的单体数据库架构在面对如此庞大的数据量时,往往显得力不从心。本文将分享一次实际的优化案例,探讨如何利用MySQL和Redis共同实现百万级数据统计的优化。
127 4
|
3月前
|
存储 监控 Java
千万级数据索引优化策略与实践
【10月更文挑战第10天】在处理千万级数据时,索引是数据库性能优化的关键。以下是根据您的要求,对如何使用索引进行快速查找、如何在实际工作中平衡这些问题,以及聚集索引、覆盖索引和索引下推的详细解读,并附上Java代码示例。
46 0
|
5月前
|
存储 监控 Java
近亿级用户体量高并发实战:大促前压测干崩近百个服务引起的深度反思!
几年前,数百个服务,将堆内存从28GB升配到36GB,引发系统全面OOM的事件。
126 12
|
7月前
|
存储 关系型数据库 分布式数据库
突破大表瓶颈|小鹏汽车使用PolarDB实现百亿级表高频更新和实时分析
PolarDB已经成为小鹏汽车应对TB级别大表标注、分析查询的"利器"。
突破大表瓶颈|小鹏汽车使用PolarDB实现百亿级表高频更新和实时分析
|
存储 监控 关系型数据库
传统库分表麻烦查询慢?TDengine 如何解决“搜狐基金”的应用难题
搜狐基金团队使用的 MySQL 数据库在面对海量数据时存在能力瓶颈,在此背景下,其决定基于 TDengine 尝试一下全新的方案。
144 0
|
存储 关系型数据库 MySQL
太强了!三种方案优化 2000w 数据大表!
太强了!三种方案优化 2000w 数据大表!
178 0

热门文章

最新文章