做分页功能的同学肯定都遇到过这个问题：项目初期数据量小，分页查询秒级响应，产品经理说加上分页功能吧，很简单。结果上线后数据量上来，第 100 页就开始慢了，到第 10000 页直接超时。 我之前就遇到过这样一个案例：一个订单查询系统，用户反馈查第 1000 页以后的数据要 30 秒+，根本没法用。排查后发现，后端用的就是最常见的 LIMIT 10000, 20。 今天我们就来聊聊深分页的性能问题，以及如何用 Search After 和游标机制让第 100 万页也能毫秒响应。 深分页的性能问题根源 1. 传统分页的致命缺陷 很多开发者用的分页方式是这样的： -- MySQL SELECT * FROM orders ORDER BY create_time DESC LIMIT 10000, 20; -- Elasticsearch GET /orders/_search { "from": 10000, "size": 20, "sort": [{ "create_time": "desc" }] } 这种方式在小数据量时没问题，但数据量上来后就是灾难： 问题场景：1000万数据，....