你有没有遇到过分页查询卡得一批？分页接口慢到让人怀疑人生？
今天就来聊聊，怎么把一个从2秒的分页查询接口，硬是优化到0.01秒。
几步下来，页面刷得飞快，老板一看，满意得差点给我涨薪。来，咱们逐条拆解分析，用几个小妙招教你怎么搞定分页优化。
1. 增加默认条件——精准打击
首先，最直观的一点，给查询增加默认条件，目的就是 缩小数据范围。
数据一少，查询自然快。举个栗子，假设我们的用户数据表 users 中有几百万条记录。如果分页查询没有条件，那么每次查就要从几百万条数据中筛选，效率肯定惨不忍睹。这种时候可以用一些合理的条件缩小范围，比如设定时间范围、数据状态等。
SELECT *
FROM users
WHERE created_at >= '2023-01-01'
AND status = 'active'
LIMIT 10;
注释：这里假设我们只关心2023年以后的活跃用户。这样大大减少了查询数据量。
这个“精确打击”比什么都靠谱。少查点数据出来，你的数据库也会感谢你。😂
2. 减少每页大小：合理设置 pageSize
来来来，合理分页这里可不能偷懒！设置一个合理的 pageSize 是必须的。通常，pageSize 设得越小，查询越快。
一般推荐 pageSize 在 10-50 条之间；一旦超过 100 条，查询速度可能会明显下降。关键是，咱们真没必要一下子给用户展示几百条数据，一般十来条够他们看好半天了。
SELECT *
FROM orders
WHERE user_id = 12345
ORDER BY order_date DESC
LIMIT 20;
注释：这里假设我们查某用户的订单，每页只查20条，用户体验流畅的同时，后台数据库也轻松不少。
3. 减少 JOIN 表数量：能少联就少联
联表查询是分页查询的“绊脚石”。JOIN 操作复杂，联的表越多，查询就越慢。所以，如果不是必须的，尽量减少 JOIN 表的数量。比如，一些冗余数据可以通过预计算、存储到表里，避免实时计算。
举个例子，如果要查一个订单表和商品表，可以把必要的信息直接写入订单表，避免联表查询。
-- 优化前
SELECT o.order_id, p.product_name
FROM orders o
JOIN products p ON o.product_id = p.product_id
WHERE o.user_id = 12345
ORDER BY o.order_date DESC
LIMIT 20;
-- 优化后，直接在订单表中冗余产品名称
SELECT order_id, product_name
FROM orders
WHERE user_id = 12345
ORDER BY order_date DESC
LIMIT 20;
注释：这里直接在订单表存
product_name，减少了产品表的 JOIN，让查询更轻松。可别觉得冗余麻烦，性能就是靠这些细节抠出来的。
4. 优化索引：索引在手，查询无忧
索引是查询优化的“大哥”。没有索引的表就像无头苍蝇一样找数据，非常慢。要优化查询速度，索引的设置至关重要。而且要特别注意的是，索引并不是越多越好！合理地设置组合索引往往比单字段索引效果更好。
-- 为常用的查询条件组合创建复合索引
CREATE INDEX idx_user_status_date ON users (user_id, status, created_at);
注释：这里我们为
user_id、status和created_at创建复合索引，确保这几个字段组合查询时能更快命中数据。索引优化就像是武功中的“九阴真经”，用好了威力无穷，用不好反倒拖累性能。
5. 使用 STRAIGHT_JOIN：明确指令，减少错配
STRAIGHT_JOIN 指的是指定查询的 JOIN 顺序，这样数据库会按指定顺序查表，而不是自己优化顺序。有时候，我们很清楚哪张表应该先查，用 STRAIGHT_JOIN 可以减少数据库的“摸索”时间。
SELECT STRAIGHT_JOIN o.order_id, u.username
FROM orders o
JOIN users u ON o.user_id = u.user_id
WHERE o.order_date >= '2023-01-01';
注释：这里通过
STRAIGHT_JOIN明确指定orders表先查询，避免数据库调皮地调整顺序，增加查询时间。
6. 数据归档：历史数据甩一边
数据量大了，查询性能肯定会受影响。一个经典的优化手法就是 数据归档。把历史数据分表存储或归档，主表只存活跃数据，其他的数据扔到归档表中。这样一来，主表数据量小了，查询速度也快了。
-- 把2022年以前的数据移动到归档表
INSERT INTO orders_archive
SELECT * FROM orders WHERE order_date < '2023-01-01';
DELETE FROM orders WHERE order_date < '2023-01-01';
注释：这种分表策略简单粗暴，但极其有效。用归档表存历史数据，主表“轻装上阵”。
7. 使用 COUNT(*)：提升总记录数统计效率
分页查询经常要查总记录数，用 COUNT(*) 是最佳选择，尤其在有索引的情况下。COUNT(column) 不一定快，甚至可能拖慢查询。很多人误以为 COUNT(1) 会更快，但其实 COUNT(*) 在大多数数据库引擎上是最优化的。
SELECT COUNT(*) FROM orders WHERE user_id = 12345;
注释：这个
COUNT(*)会直接命中索引，效率非常高。别小看这条命令，用对了能帮你省很多时间。
8. 从 ClickHouse 查询：专治大数据
如果数据量巨大，比如需要分析千万级数据，建议将查询转移到 ClickHouse 这种大数据处理引擎。ClickHouse 针对分析型查询进行了优化，处理海量数据时非常有优势。
-- 在ClickHouse上查询大数据集
SELECT order_id, total_amount
FROM orders
WHERE user_id = 12345
AND order_date >= '2023-01-01'
ORDER BY order_date DESC
LIMIT 50;
注释：ClickHouse 对于这种分页大数据查询是小菜一碟，查询速度快得飞起。不过用它得记得数据同步，保持一致性。
9. 数据库读写分离：合理分担压力
最后一点，数据库读写分离。如果项目压力很大，把读写操作分开。主库负责写操作，读操作走从库，这样一来并发性能会提升不少。对于分页查询，几乎都是读操作，这样分担下来，主库压力小了，性能更好。
一般实现读写分离时，可以通过负载均衡工具，比如 MySQL 的读写分离插件。
-- 主库写操作
INSERT INTO orders (user_id, total_amount) VALUES (12345, 200);
-- 从库读操作
SELECT * FROM orders WHERE user_id = 12345 ORDER BY order_date DESC LIMIT 20;
注释：写入数据主库搞定，查询从库走一波，读写分离后你会发现接口轻松多了，性能也是蹭蹭地往上窜。
优化分页查询是个系统工程，以上几条是“看家本领”。优化过程中要具体问题具体分析，不然一招鲜吃遍天的可能性不大。
这一通操作下来，分页接口秒变0.01s，老板笑开了花，自己写代码心情也舒坦。
扫码领红包
微信赞赏
支付宝扫码领红包
