你敢信吗？⼀个政务系统的分⻚查询从5秒优化到0.1秒，只改了3⾏SQL！上周有个学员分享他们的案例：公安⼾籍查询系统，查询第1000⻚数据时，LIMIT 99900, 100耗时5.2秒，⽤⼾投诉不断。后来我们⽤了3个技巧，直接把查询时间压缩到98毫秒。
深分页性能问题
为什么深分⻚这么慢？我们来看这个SQL（图2)
执⾏过程是：
1. 扫描所有满⾜条件的记录（可能⼏⼗万条）
2. 按id排序
3. 跳过前99900条，取后⾯100条
问题在于：即使有索引，LIMIT offset过⼤时，仍需扫描⼤量数据。offset越⼤，性能越差。
三种优化方案
1. 书签法（推荐）
利⽤索引有序性，记住上⼀⻚最后⼀条记录的id(看图3）
优势：命中索引，扫描⾏数固定为100⾏
限制：需要有序字段，且不能跳⻚查询
2. 子查询优化
先通过索引找到id，再关联查询（看图4）
优势：⼦查询仅扫描索引（覆盖索引），速度快
原理：id是主键，⼦查询⾛索引，返回100个id后再回表取数据
3. 预计算中间表
对超⼤数据量，可定时预计算分⻚中间表（看图5）
适⽤场景：数据不实时更新，查询量极⼤的场景
企业案例对比
某政务系统分⻚查询优化前后对⽐（看图6）
实战技巧
1. 永远⽤书签法：如果业务允许连续翻⻚
2. 避免SELECT*：只查需要的字段，利⽤覆盖索引
3. 分⻚按钮限制：最多显⽰100⻚，超过提⽰"输⼊⻚码跳转"
4. 监控慢查询：设置long_query_time=1，记录所有慢SQL
所以offset过大时，一定要用覆盖索引+分段查询 。不过实际工作里，你肯定遇到过更棘手的情况，这些问题光靠“技巧碎片”根本搞不定，得从基础原理开始系统学。
现在戳我领免费试听课+MYSQL课程大纲，把“数据库瓶颈”变成你的职场加分项噢~
记住：优秀的程序员不仅要写出正确的SQL，更要写出⾼效的SQL。
今⽇作业：检查你们系统中所有带LIMIT的SQL，找出offset>1000的语句，⽤今天学的⽅法优化。优化前后的执⾏计划可以发到评论区点评！#数据库[话题]# #mysql[话题]# #数据库查询语句教学[话题]# #实战案例[话题]# #认证考试[话题]# #拿证[话题]# #知识分享[话题]#
