事情是从运营那边一句话开始的。后台那个订单列表有个运营的同事过来说翻到后面就翻不动了一点就转转半天。我一开始不太信一个列表能有什么问题自己上手点了下。前面几页刷一下就出来手指往下滑滑到后面圈转了半天页面才慢悠悠出来。我不信邪又往下点了好几页。第 10 页、第 100 页都还行。到一千页往后那个圈明显转得久了再往下基本就是点了就等。同样一个接口同样的表怎么就前面快后面慢。我先怀疑是那一页的数据有毛病。数据能有什么毛病不就是订单嘛。又怀疑是网络换了台电脑试一样。还怀疑过是不是那会儿库正忙可别的接口都好好的就它慢。一个个排除过去剩下的就是它自己。后来我把它当成一个数数的事去看。这个接口是分页的一页二十条。翻到第 5000 页后台那条语句大概长这样。– 之前翻到第 5000 页数据库得先数过前面九万多条SELECT * FROM orders ORDER BY id LIMIT 99980, 20;– 改成记住上一页最后一条 id从它往后取SELECT * FROM orders WHERE id 99980 ORDER BY id LIMIT 20;我原来一直以为这种写法就是「跳过前面那些从第 99981 条开始拿 20 条」跟翻书直接翻到某一页一样一翻就到。不是的。数据库拿到这个得先把前面那九万多条一条条排好、数过去数到第 5000 页的第一条才开始拿那 20 条。前面那九万多条它数完就扔了可它得先数。你翻得越靠后它前面要数的就越多所以是这个越往后越慢的样子。打个比方不是电话簿那种。像你去食堂打饭你要的是队伍里第 501 个人的那份。可食堂的规矩是得从第一个开始一个个点过去点到第 501 个才轮到你。你明明排第 501前头那 500 个人它还是得挨个数一遍。所以慢不慢跟你表里有多少数据没关系。是跟你跳过多少条有关系。这就是为什么第 5 页唰一下第 5000 页半天不出来。明白这个之后改法就清楚了别再让数据库去数前面那一长串。记住上一页最后一条是哪条下次从它往后拿就行。这么改完不管翻到多后面它拿的都是那 20 条不用再从第一个开始数。翻到第 5000 页和翻到第 5 页差不多快。这个坑我以前一直不知道。我一直以为分页就是翻页快慢是数据量决定的。直到那天才明白决定快慢的是你身后拖了多长一条尾巴。改完之后那个运营的同事后来又来找我说现在能翻到底了。