先说结论速度天差地别。LIMIT 100000000, 10会比LIMIT 10慢非常多甚至可能导致数据库响应超时。虽然最终返回给客户端的都是 10 条数据但数据库内部为了找到这 10 条数据付出的工作量完全不同。为什么LIMIT 100000000, 10更慢要理解这一点需要知道LIMIT M, N在 MySQL 中实际执行的过程。当你执行SELECT ... LIMIT 100000000, 10时MySQL 的服务器层并不是聪明地直接跳到第 1 亿条数据的位置开始读。它的操作逻辑是1.读取从满足WHERE条件的第 0 条开始一条一条地读取。2.跳过读取到的前 100000000 条数据虽然不会返回给客户端但 MySQL 必须检查它们是否符合条件如果符合就直接丢弃。3.返回直到跳过前 1 亿条后从第 100000001 条开始取下 10 条数据返回。所以执行LIMIT 100000000, 10实际上读取了 100000010 行数据然后丢弃了前 100000000 行。而LIMIT 10只读取了 10 行数据。这中间的 IO 开销和 CPU 计算开销是完全不同的。更深入一点不同场景下的性能差异性能差异的大小主要取决于查询是否使用了索引。1. 理想情况有合适的索引 (如ORDER BY id)假设你的查询是SELECT * FROM table ORDER BY id LIMIT 10000000, 10并且id是主键或有索引。-过程MySQL 需要遍历id索引从最小的id开始数数 10000000 个叶子节点然后向后取 10 个。-代价虽然比全表扫描快但仍然需要扫描大量的索引页。扫描 1000 万条索引记录的成本远比扫描 10 条高得多。2. 糟糕的情况没有索引或查询不当如果你的查询没有合适的索引例如ORDER BY non_indexed_columnMySQL 会执行全表扫描或文件排序filesort。-过程MySQL 需要将符合条件的行如果没有 WHERE 条件就是全表全部读出来放到一个临时表里进行排序。-代价它会先根据non_indexed_column对所有数据假设表里有几千万行进行排序排序完成后再应用LIMIT 10000000, 10从头遍历排序后的结果集跳过前 1 亿行。这个代价是极其巨大的很容易把 IO 和 CPU 打满。这种慢查询的典型现象-响应时间随着页码即LIMIT的偏移量增大查询速度会越来越慢。-资源消耗在慢查询期间数据库的 CPU 和 IOPS 会突然飙高。-阻塞风险如果表数据量极大这种查询长时间持有资源可能会影响其他正常业务的执行。如何优化这种深度分页既然性能差异的核心在于偏移量越大扫描越多优化的思路就是避免让数据库扫描大量已经不需要的行。方法一记录上次位置 (推荐方案)使用WHERE条件代替LIMIT偏移量。原始 SQL (慢):SELECT*FROMlogsWHEREuser_id123ORDERBYidLIMIT1000000,10;优化后 SQL (快):-- 假设上一页最后一条记录的 id 是 1000000SELECT*FROMlogsWHEREuser_id123ANDid1000000ORDERBYidLIMIT10;-原理id 1000000可以直接利用主键索引定位到起始位置然后向后扫描 10 条即可完美避开了扫描前 100 万行。方法二延迟关联 (Deferred Join)适用于不能使用上一页位置的场景比如非排序字段。其核心是先通过覆盖索引快速定位需要的 ID再用这些 ID 回表查询完整数据。-- 1. 先快速查出需要的 10 个 ID (这一步在索引上完成很快)SELECTidFROMlogsORDERBYcreate_timeLIMIT1000000,10;-- 2. 再用这些 ID 去关联查询所有字段 (回表)SELECTl.*FROMlogs lINNERJOIN(SELECTidFROMlogsORDERBYcreate_timeLIMIT1000000,10)AStmpONl.idtmp.id;总结-LIMIT 10只读取 10 行速度极快。-LIMIT 10000000, 10需要读取 10000010 行并丢弃前 1 亿行速度极慢。-根本原因MySQL 无法直接跳过偏移量必须老老实实数过去。-优化方向尽量避免使用大的偏移量改用“WHERE 条件 上一页最大值”的方式来实现分页。