sql限制查询数量

SQL里最容易被忽略、限询数却最影响体验的制查语法，就是限询数LIMIT。它简单到一行字，制查但用不好，限询数数据库能把你的制查内存吃光，接口能把用户等疯。限询数

我见过不少新人写查询，制查上来就是限询数SELECT * FROM orders，然后全表几百万行数据哗啦啦全拉出来，制查前端再慢慢翻页。限询数这种写法不是制查不行，是限询数你得先问自己：用户真的需要一次性看到所有订单吗？绝大多数场景下，他只需要最近二十条。制查

这时候LIMIT就派上用场了。限询数SELECT * FROM orders ORDER BY created_at DESC LIMIT 20，一行代码，数据库只扫描索引，找到最新的20条就停手。响应时间从几秒降到几十毫秒，这不是优化技巧，这是基本常识。

但LIMIT有个坑，很多人栽过——分页。你写LIMIT 0, 20取第一页，LIMIT 20, 20取第二页，逻辑没错，可当页码涨到10000的时候，数据库得先数出前20万条记录再丢掉，这比全表扫描还慢。我去年排查过一个线上慢查询，就是这种深分页，LIMIT 999980, 20，跑了整整11秒。

解法也简单，别用偏移量，改用游标。记住上次拿到的最后一条记录的ID，下次查询写成WHERE id > 上次的最大id ORDER BY id LIMIT 20。这样无论翻到多深，数据库都只走索引，稳定在毫秒级。

还有个细节容易忽略：LIMIT在不同数据库里的写法不一样。MySQL用LIMIT offset, count，PostgreSQL用LIMIT count OFFSET offset，SQL Server用TOP或者OFFSET FETCH，Oracle干脆用ROWNUM。你要是换库不换脑子，直接报语法错误。

另外，LIMIT不是万能的。它只限制返回的行数，不限制数据库内部扫描的行数。比如你WHERE条件没走索引，MySQL照样得全表扫一遍，扫完才取前20条。所以LIMIT前先看执行计划，确认type不是ALL，否则你只是让用户等得短一点，数据库该累还是累。

我自己写查询有个习惯：任何线上接口，默认都加LIMIT，哪怕业务上明确说“最多返回100条”，我也会写LIMIT 100而不是不写。为什么？因为代码是给人看的，也是给未来维护的人看的。你写个裸查询，别人接手时不知道数据量有多大，改着改着就出事。加个LIMIT，等于给数据库和同事都上了一道保险。

有时候我还故意把LIMIT写小一点，比如业务要50条，我写60条，留点余量。万一后面有人加了条关联查询，多出来的10条能兜底。这种小心思不算严谨，但确实帮我挡过几次线上故障。

最后说个反直觉的案例。有次优化一个报表接口，数据量不大，就几千行，但查询要跑2秒。我看代码，发现没写LIMIT，全量返回给前端，前端再自己截断。我加了个LIMIT 200，时间降到0.3秒。你看，数据量小不代表不需要限制——网络传输、JSON序列化、前端渲染，哪一步都在为多余的数据买单。

所以别嫌LIMIT太基础。它就像汽车的安全带，平时感觉不到存在，真到撞车的时候，救你命的就是它。