分页查询优化需避免大offset，利用索引提升效率。1.基础分页使用limit，但大数据量时性能差；2.优化方法是通过where条件结合索引跳过前面数据，如select id, name from users where id > 1000 order by id limit 10；3.分页加搜索时，应为常用查询字段建立联合索引或使用全文索引；4.统计总数可采用缓存、近似值或explain估算以减少数据库压力。
在mysql中实现分页查询其实挺常见，尤其是在做后台管理系统或者数据展示类应用时。但很多人只是简单用
LIMIT offset, size
来实现，却忽略了性能问题。尤其当数据量大、偏移量高的时候，效率会明显下降。
要写好分页查询，不仅要能实现功能，还得考虑性能优化。下面从几个实际场景出发，讲讲怎么写分页语句，以及怎么优化它。
分页的基本写法：别只记LIMIT
最基础的分页方式就是用
LIMIT
，语法是这样的：
SELECT id, name FROM users ORDER BY id DESC LIMIT 10, 20;
这表示从第10条开始取20条记录。虽然简单，但在大数据量下会出现性能问题，尤其是offset特别大的时候，比如几万甚至几十万。
常见的误区是直接使用这种写法来做“深度分页”，结果数据库要扫描大量数据然后丢弃，最终只返回少量结果，效率低下。
高效分页的关键：避免大offset
当你需要翻到很后面的页数（比如第10000页），这时候使用
LIMIT 100000, 10
会导致MySQL扫描100010条记录，再扔掉前100000条，非常浪费资源。
解决办法是：使用索引来跳过前面的数据
比如你想按id升序分页，可以这样改写：
SELECT id, name FROM users WHERE id > 1000 ORDER BY id LIMIT 10;
这里假设上一页最后一条记录的id是1000，那这一页就从1001开始查，利用主键索引直接定位，效率高很多。
这种方式要求排序字段有索引，并且只能往后翻页（不能随意跳转）。适合一些不需要跳转到具体页码的场景，比如“下一页”按钮。
分页+搜索=更复杂的性能挑战
当你的分页查询还要加上过滤条件（比如根据用户名搜索），情况就会变得更复杂。比如：
SELECT * FROM users WHERE name LIKE '%张%' ORDER BY create_time DESC LIMIT 100, 10;
这时候如果name字段没有合适的索引，或者like用了通配符开头（%张%），查询速度会变得很慢。
优化建议如下：
- 给常用查询字段加联合索引（如
(name, create_time)
）
- 如果模糊匹配不可避免，可以考虑使用全文索引或引入搜索引擎（如elasticsearch）
- 对于大数据量表，尽量避免在WHERE里做全表扫描操作
另外，在设计系统的时候也可以考虑缓存部分高频查询的结果，减少对数据库的直接压力。
分页统计要不要一起做？
有时候我们会在分页的同时，也想显示总共有多少条记录。于是有些人会这么写：
SELECT count(*) FROM users WHERE status = 1; SELECT * FROM users WHERE status = 1 ORDER BY id LIMIT 100, 10;
这种做法没问题，但如果你的数据经常变化，而且并发很高，COUNT查询可能会锁表或拖慢整体性能。
替代方案：
- 如果不要求精确总数，可以用近似值，比如定时任务统计后缓存起来
- 在前端显示“超过1000条”而不是具体数字，也是一种折中方式
- 使用EXPLaiN估算行数，虽然不准确但速度快
当然，这些都属于权衡，具体用哪种要看业务需求和数据规模。
总的来说，MySQL的分页并不难，但要做到高效稳定，就得避开那些“看起来没问题”的写法。合理使用索引、避免大offset、结合业务场景设计查询方式，才是关键。基本上就这些了，不复杂但容易忽略。
