在后端开发面试中，数据库分页查询是高频考点，而“查询第100万页数据”更是区分初级与中高级程序员的“分水岭”。多数开发者第一反应是用Limit语句实现，但这恰恰踩中了面试官预设的性能陷阱。本文将从专业角度拆解问题核心，剖析底层原理，提供可落地的实战方案，帮你在面试中精准应答，同时解决实际项目中的海量数据分页难题。
百万页查询的核心难点
要解决这个问题，首先需明确“第100万页怎么查”的本质——它不仅是分页功能的实现，更考察开发者对数据库执行机制、性能优化的理解。常规分页场景中，每页20条数据，第100万页对应的数据偏移量为(1000000-1)*20=19999980，核心难点集中在两点：
1. 常规方案的性能瓶颈：多数开发者习惯用SELECT * FROM table LIMIT 19999980,20实现分页，但数据库执行该语句时，会先扫描前19999999条数据，再丢弃前19999980条，仅返回20条结果。这种方式在数据量达千万级时，会触发全表扫描或低效索引扫描，导致查询耗时暴增，甚至引发数据库连接超时。
2. 业务场景的隐性需求：面试官问此问题，往往隐含对“海量数据场景适配”的考察——实际项目中，百万页查询可能出现在数据导出、历史记录回溯等场景，不仅要求查询高效，还需兼顾数据库负载、并发稳定性，单纯的语句优化无法满足全场景需求。
数据库分页的底层执行逻辑
要找到优化方案，需先理解数据库对分页语句的执行原理，以主流的MySQL为例，核心逻辑分为两种场景：
1. 无索引场景（全表扫描）：当查询语句无有效索引时，MySQL会执行全表扫描，从磁盘读取数据到内存后，逐行计数至偏移量对应的位置，再取指定条数的数据。此过程中，偏移量越大，磁盘I/O操作越多，耗时呈线性增长，亿级表中Limit 19999980,20耗时可长达数十秒。
2. 有索引场景（索引扫描+回表）：若查询条件包含主键或唯一索引，MySQL会先通过索引定位到偏移量附近的数据，但由于SELECT *需获取全字段数据，仍需通过索引主键值回表查询完整记录。当偏移量极大时，回表次数激增，同样会导致性能瓶颈——索引仅优化了“定位偏移量”的过程，未解决“大量回表”的问题。
核心结论：Limit语句的性能瓶颈本质是“偏移量越大，需扫描/回表的数据量越多”，优化的核心思路的是“避免扫描无关数据，直接定位目标数据位置”。
3种优化方案及代码实现
结合原理分析，以下提供3种从易到难的优化方案，适配不同业务场景，附MySQL实战代码及性能对比。假设业务表user_info含千万级数据，主键为id（自增），每页20条数据，查询第100万页（对应ID范围：19999981-20000000）。
方案1：基于主键ID的精准定位（适用于主键自增场景）
核心逻辑：利用主键自增的连续性，直接通过ID范围定位目标数据，避免使用偏移量。由于主键默认自带聚簇索引，查询时无需回表，性能最优。
-- 第100万页数据查询（每页20条）SELECT * FROM user_info WHERE id BETWEEN 19999981 AND 20000000 ORDER BY id ASC;-- 通用分页公式（第n页，每页size条）SELECT * FROM user_info WHERE id BETWEEN (n-1)*size + 1 AND n*size ORDER BY id ASC;性能测试：千万级表中耗时0.03-0.05秒，较常规Limit方案（耗时50+秒）提升1000倍以上。
局限性：仅适用于主键自增、无数据删除的场景；若存在数据删除导致ID不连续，会出现分页数据缺失问题。
方案2：基于索引的游标分页（适用于非自增主键/有删除场景）
核心逻辑：以非主键索引（如时间戳、业务编号）作为“游标”，通过上一页的最后一条数据索引值，定位下一页数据，避免偏移量。需确保索引字段唯一且有序，减少回表次数。
假设表中存在索引idx_create_time（创建时间），且创建时间唯一，查询第100万页数据：
-- 先查询上一页（第999999页）最后一条数据的创建时间SELECT create_time FROM user_info ORDER BY create_time ASC LIMIT 19999979,1; -- 得到结果：2025-12-31 23:59:59-- 以创建时间为游标，查询第100万页数据SELECT * FROM user_info WHERE create_time > '2025-12-31 23:59:59' ORDER BY create_time ASC LIMIT 20;性能测试：千万级表中耗时0.1-0.2秒，性能接近主键定位方案，且适配数据删除场景。
优化技巧：使用“覆盖索引”（索引包含查询所需全部字段），可彻底避免回表，进一步提升性能，示例：
-- 创建覆盖索引（包含id、name、create_time字段）CREATE INDEX idx_cover_create_time ON user_info(create_time, id, name);-- 基于覆盖索引查询，无需回表SELECT id, name, create_time FROM user_info WHERE create_time > '2025-12-31 23:59:59' ORDER BY create_time ASC LIMIT 20;方案3：分库分表+分页（适用于亿级数据场景）
核心逻辑：当数据量达亿级，单表分页优化空间有限，需通过分库分表（如按主键哈希分表、按时间分表）拆分数据，再在各分表中并行分页查询，最后合并结果。
假设将user_info表按主键哈希分为10个分表（user_info_0至user_info_9），查询第100万页数据步骤：
- 计算目标数据在各分表的分布：每页20条，第100万页共需20条数据，按哈希规则分配至对应分表。
- 各分表并行执行分页查询（采用方案1或方案2），获取符合条件的数据。
- 汇总各分表结果，按排序字段（如ID）合并，最终返回20条数据。
实战代码（以Java+MyBatis为例，简化版）：
// 1. 计算各分表需查询的范围long startId = (1000000 - 1) * 20 + 1;long endId = 1000000 * 20;List tableIndexes = getTableIndexes(startId, endId); // 按哈希规则获取分表索引// 2. 并行查询各分表List resultList = new ArrayList<>();CompletableFuture.allOf( tableIndexes.stream().map(index -> CompletableFuture.runAsync(() -> { String tableName = "user_info_" + index; List list = userInfoMapper.selectByPage(tableName, startId, endId); synchronized (resultList) { resultList.addAll(list); } })).toArray(CompletableFuture[]::new)).join();// 3. 合并排序结果resultList.sort(Comparator.comparingLong(UserInfo::getId));List finalResult = resultList.subList(0, 20); 性能测试：亿级数据分10表场景下，耗时0.3-0.5秒，满足高并发场景需求。
面试应答与实战避坑要点
1. 面试应答技巧
面对该问题，切忌直接说“用Limit”，需按“问题分析-原理拆解-方案分级-场景适配”的逻辑应答，体现技术深度：
- 先指出常规Limit的性能瓶颈（全表扫描/回表）；
- 再分场景给出方案（小数据量用主键定位，中数据量用索引游标，大数据量分库分表）；
- 最后补充各方案的优缺点及适配场景，展现全局思维。
2. 实战避坑要点
- 索引设计：优先使用聚簇索引（主键）或覆盖索引，避免非索引字段排序；
- 数据一致性：游标分页需确保索引字段唯一，防止分页重复/缺失；
- 避免过度优化：中小数据量（百万级以内）无需分库分表，主键定位方案足够；
- 监控告警：海量数据分页查询需添加监控，避免因索引失效导致性能雪崩。
总结
“第100万页怎么查”的本质，是考察开发者对“数据量级与技术选型匹配”的理解。分页优化的核心逻辑始终是“减少无关数据的扫描与回表”，从单表的索引优化，到分布式场景的分库分表，都是围绕这一核心展开。
在实际开发中，需结合业务数据量、并发量、数据特性选择方案：小数据量场景追求简洁，中大数据量场景追求高效，亿级场景追求可扩展。面试中，能清晰拆解各方案的逻辑与适配场景，远比记住单一代码片段更重要。
你在项目中遇到过哪些分页优化难题？欢迎在评论区分享你的解决方案，一起探讨技术进阶之路！
