MySQL 分页查询列表；Explain ；深度分页；管理系统，筛选系统

摘要：文章分析了千万级数据查询中的性能问题，重点探讨了InnoDB引擎计数耗时、深度分页问题及索引优化。通过EXPLAIN命令解析查询计划，说明索引选择对性能的影响，并介绍ANALYZE TABLE统计信息的作用。结合实际场景（如B端管理系统），指出低并发高数据量的业务特性，提出分表分库、冷热数据拆分等解决方案。文中还提供了索引类型对比和EXPLAIN结果解读，帮助优化大表查询性能。

DBWYX

579人浏览 · 2025-06-20 12:18:57

DBWYX · 2025-06-20 12:18:57 发布

文章目录

千万级数据计数

（使用的软件： DataGrip 【JetBrains】）
在这里插入图片描述

计数 innodb会一个一个数，数据量大很耗时：
在这里插入图片描述

深度分页

计数会选择最合适的索引，只数索引数目。而我们查询所有字段时，还要去拿索引对应的数据（57列嘿嘿），居然要25秒【深度分页问题】：
在这里插入图片描述

深度分页 - 索引列：

主键和非主键索引，和计数差不多。

在这里插入图片描述

深度分页 - 非索引列：

比索引列要慢一倍多。索引列拿叶子节点的索引就可以拿到数据，但是非索引列还得去解析字段

在这里插入图片描述

EXPLAIN:

EXPLAIN 只是生成计划，不执行

EXPLAIN 的工作主要是由 MySQL 的优化器（Query Optimizer） 来完成的。平时执行SQL语句时，解析查重完，由优化器生成多个计划，选择最优后，才真正执行的。

在这里插入图片描述

列	含义
id `1`	id，表示这是一条独立的查询
select_type `SIMPLE`	查询类型（简单 SELECT）
table `t_users_00`	表名
type `index`	type，表示走的是索引全扫描（比全表扫描快，但也要一条条扫）
key `idx_created_time`	使用的索引
key_len `4`	每个索引记录的长度
rows `27586380`	估算的扫描行数（就是表行数）
filtered `100`	百分比， MySQL优化器预估该表在这一层中，有多少百分比的行满足 WHERE 条件
Extra `Using index`	表示是覆盖索引，即只用到了索引，不回表，性能比访问整行高

分析统计 - ANALYZE TABLE

innodb既然不存总数，那explain咋能这么快获取总数呢？哪里缓存的（其实可以看到数据不准确）

这些统计信息主要来源于 InnoDB 存储引擎的内部统计 + ANALYZE TABLE 命令生成的数据：

ANALYZE

ANALYZE TABLE <your_table>;

这个命令会：扫描部分页（非全表）；收集每个索引的分布、列中不同值的数量（基数）；把信息存到 information_schema.tables、statistics 表中

（这些信息一般是估值，mysql会缓存。mysql一般会在表变动超过10%/ 显示调用/ 手动或自动开启 innodb_stats_auto_recalc 参数时才去统计）

在这里插入图片描述
(我只有读权限，不能执行呢。 ANALYZE 语句需要 INSERT 权限（虽然它本身不是真的去插入数据，但 InnoDB 统计信息采样需要该权限）)

缓存到这里了：
在这里插入图片描述

索引：

可以发现explian使用的是时间索引

现在表里索引有 timestamp 、 bigint unsigned 、 varchar(64)，mysql选择了最轻量的索引去遍历。

timestamp 是 Unix 时间戳，是从 Unix epoch：1970年1月1日 00:00:00 UTC
32位存储范围：1970-01-01 00:01:00 UTC 到 2038-01-19 03:14:07 UTC

PS C:\Users\xiaoe\Desktop> [DateTimeOffset]::Now.ToUnixTimeSeconds()
1750323859

在这里插入图片描述

场景

一般就是后台管理系统，需要展示数据库列表：
B端商家对自己商品/订单/订阅客户等的增删查改（B端 business，对商家；C端 customer，对用户）

在这里插入图片描述

像美团等平台公司来存所有商家的订单，一般也应该去根据地区去分布式。每天的订单很多，日积月累数据量也会非常大。不过访问压力不大。
B端的优势是一般不会高并发，C端用户可能都在中午一起点餐，而商家可能隔很久才回去看一次订单

B端系统的核心业务特性

特性	说明
面向对象	商家 = 核心用户，关注商品、订单、客户等
功能以管理为主	涉及大量 CRUD（商品管理、客户管理、订单处理等）
页面复杂但访问量不高	页面通常是表格/图表/导出等
低并发、高数据量	订单少则几百条，多则千万级，但访问压力不大
数据增长快	日积月累产生超大量数据，必须做分表分库或冷热数据拆分