我们都知道，各种主流的社交应用或者阅读应用，基本都有列表类视图，并且都有滑到底部加载更多这一功能， 对应后端就是分页拉取数据。

好处不言而喻，一般来说，这些数据项都是按时间倒序排列的，用户只关心最新的动态，而不关心几个月甚至几年前消息，所以后端返回给客户端的数据是不会一次性传递全部内容的(不仅耗费流量，而且还给服务器带来巨大压力)。

举个例就说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

版权声明：本文为博主原创文章，转载请附上博文链接！