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

千万级数据计数

（使用的软件： 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（商品管理、客户管理、订单处理等）
页面复杂但访问量不高	页面通常是表格/图表/导出等
低并发、高数据量	订单少则几百条，多则千万级，但访问压力不大
数据增长快	日积月累产生超大量数据，必须做分表分库或冷热数据拆分