在mysql实际使用中，随着业务积累，单表数据量可能增长到几百万甚至上千万行。此时执行一条简单的查询语句，前端页面或后端接口就容易出现卡顿、超时。很多开发者第一反应是给sql加上limit限制返回记录数，认为返回行数少了自然就快了，但事实并非总是如此。
limit在mysql中的真实作用
limit语法用于限制查询结果集返回的条数，例如下面的语句只取前十条记录：
SELECT id, name, age FROM user ORDER BY id LIMIT 10;
这条语句虽然只返回10行，但mysql在排序和检索时，依然可能先扫描大量数据再截取。如果user表没有命中索引，即使limit 10，也可能进行全表扫描后再排序取前十条，卡顿依旧存在。
为什么单用limit不能解决卡顿
当数据量过大且查询条件没有索引支撑时，mysql执行过程往往是：
- 从磁盘读取大量行到内存
- 按照order by规则排序
- 丢掉前面不需要的记录，只保留limit数量
也就是说，limit只控制了网络返回和最终结果集大小，并不减少引擎层已经做过的扫描与排序开销。用EXPLAIN查看执行计划，常会看到type为ALL，即全表扫描。
正确使用limit的配套方案
1. 为查询条件建立索引
如果业务是按时间范围查最近数据，可以给时间字段加索引：
ALTER TABLE user ADD INDEX idx_create_time (create_time); SELECT id, name FROM user WHERE create_time >= '2023-01-01' ORDER BY create_time LIMIT 20;
这样mysql能利用索引定位起点，避免全表扫描，limit才真正起到减少处理量的作用。
2. 利用覆盖索引减少回表
只查询索引包含的字段，可避免回表取数据：
ALTER TABLE user ADD INDEX idx_age_name (age, name); SELECT age, name FROM user WHERE age > 18 LIMIT 100;
此时查询在索引树内完成，速度明显提升。
3. 使用游标分页代替大offset
很多人用limit 100000, 20翻页，offset越大越慢。可改为基于上一页最大id查询：
SELECT id, name FROM user WHERE id > 100000 ORDER BY id LIMIT 20;
这种方式依赖主键有序，性能稳定。
总结建议
mysql数据量过大导致查询卡顿，limit限制返回记录数只是结果裁剪手段，不能替代索引优化。正确做法是为高频查询建索引、尽量走覆盖索引、避免深分页offset，再把limit作为合理的结果集控制工具，才能从根本上缓解卡顿。