千万级数据深分页查询SQL性能优化实践

原创

于 2024-01-17 12:37:17 发布 · 1.4k 阅读

20 ·

CC 4.0 BY-SA版权

文章标签：

#sql #性能优化 #android

本文介绍了在Mysql中处理上亿级粉丝列表查询的问题，探讨了Limit分页的局限性，提出了标签记录法和区间限制法，以及SQL优化策略，包括索引使用和避免回表查询。作者曹志飞来自京东零售，强调了结合业务场景选择最适合的优化方案。

一、系统介绍和问题描述

如何在Mysql中实现上亿数据的遍历查询？先来介绍一下系统主角：关注系统，主要是维护京东用户和业务对象之前的关注关系；并对外提供各种关系查询，比如查询用户的关注商品或店铺列表，查询用户是否关注了某个商品或店铺等。但是最近接到了一个新需求，要求提供查询关注对象的粉丝列表接口功能。该功能的难点就是关注对象的粉丝数量过多，不少店铺的粉丝数量都是千万级别，并且有些大V粉丝数量能够达到上亿级别。而这些粉丝列表数据目前全都存储在Mysql库中，然后通过业务对象ID进行分库分表，所有的粉丝列表数据分布在16个分片的256张表中。同时为了方便查询粉丝列表，同一个业务对象的所有粉丝都会路由到同一张表中，每个表的数据量都能够达到 2 亿+。

二、解决问题的思路和方法

数据库表结构示例如下：

CREATE TABLE follow_fans_[0-255]
  (
    id bigint(11) NOT NULL AUTO_INCREMENT COMMENT '自增id',
    biz_content   VARCHAR(50) DEFAULT NULL COMMENT '业务对象ID',
    source        VARCHAR(50) DEFAULT NULL COMMENT '来源',
    pin           VARCHAR(50) DEFAULT NULL COMMENT '用户pin',
    ext           VARCHAR(5000) DEFAULT NULL COMMENT '扩展信息',
    status        TINYINT(2) DEFAULT 1 COMMENT '状态，0是失效，1是正常',
    created_time  DATETIME DEFAULT NULL COMMENT '创建时间',
    modified_time DATETIME DEFAULT NULL COMMENT '修改时间',
    PRIMARY KEY(id),
    UNI

最低0.47元/天解锁文章