回答。

分页确保在不对服务器和应用程序过度负担的情况下处理大型SELECT结果。主要方法：

• LIMIT/OFFSET — 方便，但在大OFFSET时不够高效。
• Keyset分页（查找方法） — 根据唯一/可排序字段的值（例如，id或时间戳）进行，在“深度”导航时性能更好。

示例（LIMIT/OFFSET）

SELECT * FROM Orders
ORDER BY OrderID
LIMIT 100 OFFSET 1000;

此查询返回1011–1110条记录。但OFFSET仍然要求服务器排序并跳过前1000行——因此在深度分页时它变得缓慢。

示例（Keyset/查找方法）

SELECT * FROM Orders
WHERE OrderID > 1110
ORDER BY OrderID
LIMIT 100;

这样的查询快速查找下一页，不消耗资源计算OFFSET，尤其在OrderID有索引时更有效。

含有陷阱的问题。

陷阱： “为什么在大数据集上使用LIMIT/OFFSET的分页可能表现不佳，以及如何改善？”

回答： 问题在于OFFSET要求服务器扫描和排序所有之前的行——结果是随着页面深入，速度变得更慢。优化是切换到keyset/查找分页：不按偏移量选择，而是按上一页最后一条记录的键。

-- 通过键获取下一页
SELECT * FROM Orders WHERE OrderID > @LastOrderID ORDER BY OrderID LIMIT 100;

由于对主题细节不了解而导致的实际错误示例。

---

故事

项目： 在线市场，5年的订单数据库（5000万行）

错误： 在旧用户的订单分页中使用OFFSET。OFFSET > 100万的查询开始执行30–60秒。这影响了报告和API接口——导致CPU服务器负担过重，等待时间增加。

---

---

故事

项目： 企业CRM，客户报告。

错误： 在分页中未考虑排序顺序，并未使用索引。性能降低，样本完整性控制失败——用户在表格变更时在不同页面上收到相同的记录。

---

---

故事

项目： 金融平台，仪表板。

错误： 复杂的分页通过生成的动态SQL构建而不使用绑定变量，导致SQL注入和数据页面之间的事务支持问题。

---