小红书面经：LIMIT 100000000, 10 和 LIMIT 10 哪个更快？如何优化深度分页？LIMIT 100

LIMIT 100000000, 10 和 LIMIT 10 哪个更快？如何优化深度分页？🤔

你有没有过这种疑惑？

面试的时候，考官问：“「LIMIT 100000000, 10 和 LIMIT 10，哪个更快？」” 你是不是一脸懵？😅 这两个看起来差不多的SQL语句，究竟有什么不同呢？如果你也曾在复杂查询中遇到过分页问题，肯定明白这个问题背后隐藏的优化关键。

今天我们就一起来揭开这个谜团，看看为什么**「LIMIT 100000000, 10」** 有可能比 「LIMIT 10」 更慢？如何在分页时避免性能下降，尤其是做深度分页的优化呢？

先来投票：你觉得哪个更快？

✅ LIMIT 10
❌ LIMIT 100000000,10
（心里默选一下，我们稍后揭晓答案！）

一、LIMIT 100000000, 10 和 LIMIT 10 的本质差异🧐

1. 先看这两个SQL语句

SELECT * FROM products LIMIT 100000000, 10;  -- 从第100000000条开始，取10条

SELECT * FROM products LIMIT 10;  -- 只取前10条

这两个语句乍一看，应该没什么大差异，对吧？「LIMIT 100000000, 10」 表示从第100000000条开始，取10条数据，而**「LIMIT 10」**则是从头开始，直接取前10条数据。

2. 性能对比：看似相似，背后却有大差异

看起来是简单的分页查询，然而**「LIMIT 100000000, 10」** 和 「LIMIT 10」 的性能差异，背后有很大的不同。因为**「LIMIT 100000000, 10」**不仅仅是从100000000条数据中取10条，它的本质上需要扫描并“跳过”前面大量的数据。😓

「LIMIT 100000000, 10」需要「跳过大量记录」

数据库引擎首先要扫描前100000000条记录，直到找到第100000001条。
然后，才开始返回接下来的10条数据。
这就导致了**「大量的扫描开销」**，尤其是在数据量非常大的情况下。

「LIMIT 10」直接取前10条数据

这显然要比前者高效得多，数据库引擎只需要取前10条数据。

3. 为什么这么慢？🔻

根本原因在于，SQL引擎在执行LIMIT 100000000, 10时，会做大量的无效扫描——即便你只需要10条数据，它依然得先扫描掉前100000000条记录。这个过程会让查询变得非常慢，尤其是在数据量极大的时候。⚠️

二、优化深度分页：如何避免性能瓶颈？⚡

1. 深度分页的痛点：性能逐渐下降

假设你在做分页查询时，每次都使用LIMIT 100000000, 10的方式，随着页数的增加，「性能会逐渐下降」。这种方式的问题就在于数据库需要处理**「大量的跳过操作」**，查询时间随着OFFSET值的增加而变得越来越长。

2. 优化方案：游标分页（Cursor Pagination）

游标分页是最常见的优化方案。它通过基于上一页数据的最后一条记录ID来进行分页查询，避免了每次都跳过大量数据。也就是说，通过游标的机制，我们不再依赖OFFSET，而是基于数据的唯一标识（如ID）进行分页查询。

SELECT * FROM products WHERE id > ? ORDER BY id LIMIT 10;

这种方式可以显著提高查询效率，尤其是在大数据量的情况下。

3. 其他深度分页优化方案

除了游标分页，还有一些主流的优化方案，可以根据具体的场景来选择：

三、其他深度分页优化方案🔍

1. 「使用“键集分页”（Keyset Pagination）」

**「键集分页」是一种非常有效的深度分页优化策略，特别适用于那些有唯一标识符（如ID或时间戳）**的场景。与游标分页类似，它避免了OFFSET的性能瓶颈。

在**「键集分页」中，你依赖特定的字段（如ID或时间戳）**来查询下一页的数据，而不是使用OFFSET跳过前面的记录。例如：

SELECT * FROM products WHERE id > ? ORDER BY id LIMIT 10;

这种方式避免了大量无用数据的扫描，并且查询性能几乎不会随着分页的深度增加而下降。🔝

2. 「延迟加载（Lazy Loading）」

对于某些场景，特别是展示的数据量不太大且不需要一次性全部加载的情况，可以采用**「延迟加载」**（Lazy Loading）策略。它通过懒加载的方式按需加载数据，避免了一次性查询大量数据造成的性能问题。

例如，在用户翻页时，只有在用户实际需要新的数据时，才向数据库发起查询请求。这样可以减少不必要的查询负载。

3. 「分区表（Partitioning）」

对于**「数据量极大」的表，「分区表」**（Partitioning）是一种很好的优化方案。通过分区技术，将数据拆分成多个子表，数据库可以根据查询条件只扫描相关的分区，从而提高查询效率。

例如，如果你有一个用户表，可以根据**「时间范围」或「地理区域」**将数据分区，在分页查询时，只扫描相关的分区，减少了扫描的数据量。

4. 「索引优化」

无论是哪种分页方式，**「索引优化」**都是基础。通过在分页查询的关键字段上建立合适的索引，能够大大提高查询速度，尤其是在分页查询中，如果没有索引，数据库就需要做全表扫描，导致查询变慢。

例如，确保分页查询使用的字段（如ID、创建时间等）都已经建立了合适的索引。这样数据库可以直接通过索引来定位数据，而不需要进行全表扫描。

四、Elasticsearch 和 PostgreSQL 中如何处理深度分页？🧐

除了MySQL，**「Elasticsearch」和「PostgreSQL」**也是常见的数据库系统，它们在处理深度分页时也有各自的优化策略。

1. 「Elasticsearch」的优化：搜索深度（Search After）

在Elasticsearch中，传统的from和size分页方式也会遇到性能问题，特别是在做深度分页时。Elasticsearch推荐使用**「search_after」**来进行分页，它基于游标的机制，避免了from的性能瓶颈。

{
  "query": {
    "match_all": {}
  },
  "size": 10,
  "search_after": ["last_id"]
}

2. 「PostgreSQL」的优化：基于ID的分页

PostgreSQL通常使用**「Keyset Pagination」来优化深度分页，避免了OFFSET的性能问题。在PostgreSQL中，可以基于「主键ID」**进行分页查询，类似于游标分页的思想。

SELECT * FROM products WHERE id > ? ORDER BY id LIMIT 10;

五、总结：你会怎么做？🤔

要记住，在处理深度分页时，「LIMIT 100000000, 10」 和 **「LIMIT 10」的性能差异不容忽视。「LIMIT 100000000, 10」的查询效率明显较低，因为它会扫描大量不必要的数据，而「LIMIT 10」**则是高效的查询方式。

为了优化深度分页，推荐使用以下策略：

「游标分页」：适用于大多数场景，避免了OFFSET的性能瓶颈。
「键集分页」：特别适合有唯一标识符的表，查询效率高。
「延迟加载」：按需加载，减少不必要的查询。
「分区表」：适用于大规模数据表，通过分区提升查询效率。
「索引优化」：确保分页查询的字段有适当的索引。

选择合适的优化方案，不仅能提升查询速度，还能改善用户体验。如果你在实际项目中遇到类似的挑战，记得根据场景选择最佳方案！🚀

Java 示例代码：如何优化分页查询

最后，来看一下如何用Java代码实现一个简单的分页查询优化：

// 伪代码：基于ID的游标分页
public List<Product> getProductsAfterId(long lastProductId, int limit) {
    String sql = "SELECT * FROM products WHERE id > ? ORDER BY id LIMIT ?";
    List<Product> products = jdbcTemplate.query(sql, new Object[]{lastProductId, limit}, new ProductRowMapper());
    return products;
}

这种方式通过**传入lastProductId**来避免全表扫描，使得每次查询都能快速定位到正确的分页位置。

希望这篇文章能够帮你搞定分页查询的优化问题！如果你在实际项目中遇到类似的挑战，记得用游标分页+索引优化来提高性能哦！🚀

觉得有用的话，不妨点个赞👍，有任何问题也欢迎在评论区讨论！💬

本文使用 mdnice 排版

小红书面经：LIMIT 100000000, 10 和 LIMIT 10 哪个更快？如何优化深度分页？