nosql分页查询,sql查询结果分页

如何用sql语句 实现分页查询？

方法1：

适用于 SQL Server 2000/2005

SELECT TOP 页大小 *

FROM table1

WHERE id NOT IN

(

SELECT TOP 页大小*(页数-1) id FROM table1 ORDER BY id

)

ORDER BY id

方法2：

适用于 SQL Server 2000/2005

SELECT TOP 页大小 *

FROM table1

WHERE id

(

SELECT ISNULL(MAX(id),0)

FROM

(

SELECT TOP 页大小*(页数-1) id FROM table1 ORDER BY id

) A

)

ORDER BY id

方法3：

适用于 SQL Server 2005

SELECT TOP 页大小 *

FROM

(

SELECT ROW_NUMBER() OVER (ORDER BY id) AS RowNumber,* FROM table1

) A

WHERE RowNumber 页大小*(页数-1)

相关问答

Q1: SQL Server 分页 查询语句

四种方式实现SQLServer 分页查询

SQLServer 的数据分页:

假设现在有这样的一张表：

CREATE TABLE test

(

id int primary key not null identity,

names varchar(20)

)

然后向里面插入大约1000条数据，进行分页测试

假设页数是10，现在要拿出第5页的内容，查询语句如下：

--10代表分页的大小

select top 10 *

from test

where id not in

(

--40是这么计算出来的：10*(5-1)

select top 40 id from test order by id

)

order by id

原理：需要拿出数据库的第5页，就是40-50条记录。首先拿出数据库中的前40条记录的id值，然后再拿出剩余部分的前10条元素

第二种方法：

还是以上面的结果为例，采用另外的一种方法

--数据的意思和上面提及的一样

select top 10 *

from test

where id

(

select isnull(max(id),0)

from

(

select top 40 id from test order by id

) A

)

order by id

原理：先查询前40条记录，然后获得其最id值，如果id值为null的，那么就返回0

然后查询id值大于前40条记录的最大id值的记录。

这个查询有一个条件，就是id必须是int类型的。

第三种方法：

select top 10 *

from

(

select row_number() over(order by id) as rownumber,* from test

) A

where rownumber 40

原理：先把表中的所有数据都按照一个rowNumber进行排序，然后查询rownuber大于40的前十条记录

这种方法和oracle中的一种分页方式类似，不过只支持2005版本以上的

第四种：

存储过程查询

创建存储过程

alter procedure pageDemo

@pageSize int,

@page int

AS

declare @temp int

set @temp=@pageSize*(@page - 1)

begin

select top (select @pageSize) * from test where id not in (select top (select @temp) id from test) order by id

end

执行存储过程

exec 10,5

Q2: SQL语句分页查询，一页面多少数据合适

2万条。

在SQLServer中通过SQL语句实现分页查询，在SQLServer中通过SQL语句实现分页后插入数据2万条，用更多的数据测试会明显一些。微软的SQLSERVER提供了两种索引：聚集索引，也称聚类索引、簇集索引和非聚集索引，也称非聚类索引、非簇集索引。

建立一个web应用，分页浏览功能必不可少。这个问题是数据库处理中十分常见的问题。经典的数据分页方法是：ADO纪录集分页法，也就是利用ADO自带的分页功能（利用游标）来实现分页。但这种分页方法仅适用于较小数据量的情形，因为游标本身有缺点：游标是存放在内存中，很费内存。游标一建立，就将相关的记录锁住，直到取消游标。游标提供了对特定集合中逐行扫描的手段，一般使用游标来逐行遍历数据，根据取出数据条件的不同进行不同的操作。而对于多表和大表中定义的游标（大的数据集合）循环很容易使程序进入一个漫长的等待甚至死机。更重要的是，对于非常大的数据模型而言，分页检索时，如果按照传统的每次都加载整个数据源的方法是非常浪费资源的。现在流行的分页方法一般是检索页面大小的块区的数据，而非检索所有的数据，然后单步执行当前行。最早较好地实现这种根据页面大小和页码来提取数据的方法大概就是“俄罗斯存储过程”。这个存储过程用了游标，由于游标的局限性，所以这个方法并没有得到大家的普遍认可，后来，网上有人改造了此存储过程，实现了分页储存。

Q3: NoSQL应用

而传统的关系数据库在应付web2.0网站，特别是超大规模和高并发的SNS类型的web2.0纯动态网站已经显得力不从心，暴露了很多难以克服的问题，例如：

1、High performance - 对数据库高并发读写的需求

web2.0网站要根据用户个性化信息来实时生成动态页面和提供动态信息，所以基本上无法使用动态页面静态化技术，因此数据库并发负载非常高，往往要达到每秒上万次读写请求。关系数据库应付上万次SQL查询还勉强顶得住，但是应付上万次SQL写数据请求，硬盘IO就已经无法承受了。其实对于普通的BBS网站，往往也存在对高并发写请求的需求。

2、Huge Storage - 对海量数据的高效率存储和访问的需求

对于大型的SNS网站，每天用户产生海量的用户动态，以国外的Friendfeed为例，一个月就达到了2.5亿条用户动态，对于关系数据库来说，在一张2.5亿条记录的表里面进行SQL查询，效率是极其低下乃至不可忍受的。再例如大型web网站的用户登录系统，例如腾讯，盛大，动辄数以亿计的帐号，关系数据库也很难应付。

3、High Scalability High Availability- 对数据库的高可扩展性和高可用性的需求

在基于web的架构当中，数据库是最难进行横向扩展的，当一个应用系统的用户量和访问量与日俱增的时候，你的数据库却没有办法像web server和app server那样简单的通过添加更多的硬件和服务节点来扩展性能和负载能力。对于很多需要提供24小时不间断服务的网站来说，对数据库系统进行升级和扩展是非常痛苦的事情，往往需要停机维护和数据迁移，为什么数据库不能通过不断的添加服务器节点来实现扩展呢？

在上面提到的“三高”需求面前，关系数据库遇到了难以克服的障碍，而对于web2.0网站来说，关系数据库的很多主要特性却往往无用武之地，例如：

1、数据库事务一致性需求

很多web实时系统并不要求严格的数据库事务，对读一致性的要求很低，有些场合对写一致性要求也不高。因此数据库事务管理成了数据库高负载下一个沉重的负担。

2、数据库的写实时性和读实时性需求

对关系数据库来说，插入一条数据之后立刻查询，是肯定可以读出来这条数据的，但是对于很多web应用来说，并不要求这么高的实时性。

3、对复杂的SQL查询，特别是多表关联查询的需求

任何大数据量的web系统，都非常忌讳多个大表的关联查询，以及复杂的数据分析类型的复杂SQL报表查询，特别是SNS类型的网站，从需求以及产品设计角度，就避免了这种情况的产生。往往更多的只是单表的主键查询，以及单表的简单条件分页查询，SQL的功能被极大的弱化了。

因此，关系数据库在这些越来越多的应用场景下显得不那么合适了，为了解决这类问题的非关系数据库应运而生。

NoSQL 是非关系型数据存储的广义定义。它打破了长久以来关系型数据库与ACID理论大一统的局面。NoSQL 数据存储不需要固定的表结构，通常也不存在连接操作。在大数据存取上具备关系型数据库无法比拟的性能优势。该术语在 2009 年初得到了广泛认同。

当今的应用体系结构需要数据存储在横向伸缩性上能够满足需求。而 NoSQL 存储就是为了实现这个需求。Google 的BigTable与Amazon的Dynamo是非常成功的商业 NoSQL 实现。一些开源的 NoSQL 体系，如Facebook 的Cassandra， Apache 的HBase，也得到了广泛认同。