写分页把一万条数据全查出来循环分，内存直接跑满，改limit后一秒出结果

刚学写后端那会，做文章列表分页，我图省事，直接写个SQL把数据库里所有文章全查出来，存到PHP数组里，然后用array_slice切当前页的20条，一开始测试的时候数据库才几十篇文章，跑得飞快，我还觉得这写法挺简单。结果网站运营了半年，数据库攒了一万多篇文章，一打开文章列表，页面直接白屏，服务器内存占满到100%。 我当时登宝塔看监控，PHP进程直接把1G内存吃满，内存不足系统直接把进程杀了，页面502。我一开始以为是SQL写得慢，优化了半天索引，结果还是卡，后来把SQL语句打出来才发现，我每次打开列表页，都把一万多篇文章的所有字段全查出来，存在内存里，一万条数据，每条带几百字的内容，光这一次查询就占了几十兆内存，多几个用户同时打开，内存直接爆了。 后来改成分页查询，数据库用limit 0,20，每次只查当前页需要的20条数据，再把总条数查出来算总页数，改完之后，打开列表页速度直接从之前的十几秒白屏变成毫秒级，内存占用从几十兆降到几百K，当时我都傻了，就这么一个小改动，解决了整个网站卡的问题。我之前根本不知道数据库分页是这么写的，以为在代码里切数据更简单，结果数据一多直接崩。 我后来带新手写代码，一看到他写分页把全表查出来，就让他赶紧改。很多新手刚学的时候都犯这个错，测试的时候数据少，觉得怎么写都快，等数据攒到几万条，网站直接崩，排查半天都找不到问题在哪。其实分页根本不用把全表拉出来，数据库天生就支持limit，每次只取当前页需要的20条，哪怕数据库里有十万条文章，打开列表也是秒开，根本不会占内存。 从那之后我写任何列表接口，分页都是数据库层面直接处理，绝对不在PHP里把全表数据拉出来再处理。就这么一个基础的写法，我当时踩坑花了整整一天排查，才搞明白问题在哪，现在写代码看到这种全表拉数据的写法直接就改，再也不犯这个低级错误。