MySQL深度优化（3）：查询语句改写技巧

你敢信吗？⼀个政务系统的分⻚查询从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[话题]# #数据库查询语句教学[话题]# #实战案例[话题]# #认证考试[话题]# #拿证[话题]# #知识分享[话题]#