我们都知道，各种主流的社交应用或者阅读应用，基本都有列表类视图，并且都有滑到底部加载更多这一功能， 对应后端就是分页拉取数据。
好处不言而喻，一般来说，这些数据项都是按时间倒序排列的，用户只关心最新的动态，而不关心几个月甚至几年前消息，所以后端返回给客户端的数据是不会一次性传递全部内容的（不仅耗费流量，而且还给服务器带来巨大压力）。
举个例就说MySQL，它已经给我们提供了相应的语句来支持这一功能，那就是limit关键字。
比如我要拉取一个消息表中用户id为1的前10条最新数据，SQL语句如下：
select uid, content, time
from message
where uid = 1
order by time desc
limit 0, 10
1
2
3
4
5
其中，message是表名，查询3个字段uid，content（消息详情内容），time（消息发送时间），用order by time desc对数据进行时间倒序排序，一般time的数据类型可以用datetime（格式：yyyy-MM-dd HH:mm:ss）。
然后limit 0, 10表示将查询结果限制在从下标为0开始的10行数据。
比如你只查询第8行这一行数据，就是limit 7, 1，形式化描述就是：
limit [index], [count]
顺理成章地，我们会自然想到，当用户加载更多时，我们就将上述SQL语句改为：
select uid, content, time
from message
where uid = 1
order by time desc
limit 10, 10
1
2
3
4
5
09行数据我们已经查询过了，接下来就是查询1019行数据，以此类推。
所以，实际的服务端Web程序中，我们可以在编程时把index这个值作为变量，每次加载更多时，就改变index为列表数据项的大小，描述为：
index = listSize
每加载一次新数据，listSize就会增大，下一次查询从index = listSize这个位置开始即可。
MySQL分页就搞定了，但是在实际应用中，我们不得不面临一个数据重复的问题。
举个例子，我第一页有10条数据，在加载第二页新10条数据时，正好总表里增加了n条新数据，这样第二页的前n条数据就会与第一页的后n条数据重复。
如果正确理解这个意思，那么大家就明白当这个n=10时，第二页数据就会和已经加载的第一页数据完全一样。
然而第一页数据已经在客户端UI填充完毕了，我们不可能回头重查，这不仅影响程序效率，而且用户体验也很不好。
为了避免这个问题，我们利用时间来控制查询结果。第1页到第n页的分页数据，其实都是在某个时间点之前的内容，这个时间点之后新插入的数据我们不管。
所以，SQL语句改为：
select uid, content, time
from message
where uid = 1 and time < time_point
order by time desc
limit listSize, 10
1
2
3
4
5
这个time_point在拉取第一页数据之前就要确定下来，并且和listSize一样，都是服务端程序代码中的变量，此处只是个形式化描述。
当前时间可以通过相应的代码来获取系统时间（比如Java中的Calendar或者Date类），也可以直接通过SQL语句的now函数获取系统时间：
select NOW()
1
查询结果为（这是我此时写文的时间）：
‘2017-01-19 16:07:46’
所以，time_point实际上也就是形如上的一个时间字符串而已，在MySQL中，时间字符串是可以直接比较大小的。
如果你不喜欢字符串比较或者有其它特殊需求，那么你可以将MySQL中的datetime数据类型转换为整数，这样写：
……
where uid = 1 and (time + 0) < time_point_integer
……
1
2
3
datetime通过加0处理后，会转化为形如20170119160746这样的长整型，所以时间点变量也不能是字符串了，而是经过处理后的整数（在Java中对应long数据类型）。
刚才的时间查询语句即改为：
select NOW() + 0
1
转换成整数有什么好处呢？
比如说，有需求不是定量的分页拉取，而是按时间段拉取，若我需要过去2小时内的数据，就可以通过整数之间的运算来实现，这里不作赘述。
最后的处理：
time_point和listSize这两个变量肯定是需要重置的。
那就是在用户回到列表顶部重新刷新整个列表时，时间点就需要刷新，listSize置为零。
在实际应用中，当用户还在慢慢向下浏览过去的数据时，其实已经有大量新数据已经插入数据库了，正如上文提到的，这时肯定不能立即加载，所以人性化的处理就是，在适当的地方给予用户提示，比如“有n条新动态，点击查看”，用户点击后，就会回到顶部，刷新相应的变量，重新加载整个列表。
---------------------
作者：针叶
来源：CSDN
原文：https://blog.csdn.net/ysy950803/article/details/54617223
版权声明：本文为博主原创文章，转载请附上博文链接！
我们都知道，各种主流的社交应用或者阅读应用，基本都有列表类视图，并且都有滑到底部加载更多这一功能， 对应后端就是分页拉取数据。
好处不言而喻，一般来说，这些数据项都是按时间倒序排列的，用户只关心最新的动态，而不关心几个月甚至几年前消息，所以后端返回给客户端的数据是不会一次性传递全部内容的（不仅耗费流量，而且还给服务器带来巨大压力）。
举个例就说MySQL，它已经给我们提供了相应的语句来支持这一功能，那就是limit关键字。
比如我要拉取一个消息表中用户id为1的前10条最新数据，SQL语句如下：
select uid, content, time
from message
where uid = 1
order by time desc
limit 0, 10
1
2
3
4
5
其中，message是表名，查询3个字段uid，content（消息详情内容），time（消息发送时间），用order by time desc对数据进行时间倒序排序，一般time的数据类型可以用datetime（格式：yyyy-MM-dd HH:mm:ss）。
然后limit 0, 10表示将查询结果限制在从下标为0开始的10行数据。
比如你只查询第8行这一行数据，就是limit 7, 1，形式化描述就是：
limit [index], [count]
顺理成章地，我们会自然想到，当用户加载更多时，我们就将上述SQL语句改为：
select uid, content, time
from message
where uid = 1
order by time desc
limit 10, 10
1
2
3
4
5
09行数据我们已经查询过了，接下来就是查询1019行数据，以此类推。
所以，实际的服务端Web程序中，我们可以在编程时把index这个值作为变量，每次加载更多时，就改变index为列表数据项的大小，描述为：
index = listSize
每加载一次新数据，listSize就会增大，下一次查询从index = listSize这个位置开始即可。
MySQL分页就搞定了，但是在实际应用中，我们不得不面临一个数据重复的问题。
举个例子，我第一页有10条数据，在加载第二页新10条数据时，正好总表里增加了n条新数据，这样第二页的前n条数据就会与第一页的后n条数据重复。
如果正确理解这个意思，那么大家就明白当这个n=10时，第二页数据就会和已经加载的第一页数据完全一样。
然而第一页数据已经在客户端UI填充完毕了，我们不可能回头重查，这不仅影响程序效率，而且用户体验也很不好。
为了避免这个问题，我们利用时间来控制查询结果。第1页到第n页的分页数据，其实都是在某个时间点之前的内容，这个时间点之后新插入的数据我们不管。
所以，SQL语句改为：
select uid, content, time
from message
where uid = 1 and time < time_point
order by time desc
limit listSize, 10
1
2
3
4
5
这个time_point在拉取第一页数据之前就要确定下来，并且和listSize一样，都是服务端程序代码中的变量，此处只是个形式化描述。
当前时间可以通过相应的代码来获取系统时间（比如Java中的Calendar或者Date类），也可以直接通过SQL语句的now函数获取系统时间：
select NOW()
1
查询结果为（这是我此时写文的时间）：
‘2017-01-19 16:07:46’
所以，time_point实际上也就是形如上的一个时间字符串而已，在MySQL中，时间字符串是可以直接比较大小的。
如果你不喜欢字符串比较或者有其它特殊需求，那么你可以将MySQL中的datetime数据类型转换为整数，这样写：
……
where uid = 1 and (time + 0) < time_point_integer
……
1
2
3
datetime通过加0处理后，会转化为形如20170119160746这样的长整型，所以时间点变量也不能是字符串了，而是经过处理后的整数（在Java中对应long数据类型）。
刚才的时间查询语句即改为：
select NOW() + 0
1
转换成整数有什么好处呢？
比如说，有需求不是定量的分页拉取，而是按时间段拉取，若我需要过去2小时内的数据，就可以通过整数之间的运算来实现，这里不作赘述。
最后的处理：
time_point和listSize这两个变量肯定是需要重置的。
那就是在用户回到列表顶部重新刷新整个列表时，时间点就需要刷新，listSize置为零。
在实际应用中，当用户还在慢慢向下浏览过去的数据时，其实已经有大量新数据已经插入数据库了，正如上文提到的，这时肯定不能立即加载，所以人性化的处理就是，在适当的地方给予用户提示，比如“有n条新动态，点击查看”，用户点击后，就会回到顶部，刷新相应的变量，重新加载整个列表。
---------------------
作者：针叶
来源：CSDN
原文：https://blog.csdn.net/ysy950803/article/details/54617223
版权声明：本文为博主原创文章，转载请附上博文链接！