sql大数据分页

A. sql语句分页查询，一页面多少数据合适

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

B. sql2000最有效率的分页sql 语句（解决大数据量）

/*
Function:
SuperPaging
*
Description:
*
超强通用分页存储过程
*
Example:
*
SuperPaging
@TableName='表名',@Orderfld='排序列名'
*/
CREATE
PROCEDURE
SupesoftPage
(
@TableName
nvarchar(50),
--
表名
@ReturnFields
nvarchar(2000)
=
'*',
--
需要返回的列
@PageSize
int
=
10,
--
每页记录数
@PageIndex
int
=
1,
--
当前页码
@Where
nvarchar(2000)
=
'',
--
查询条件
@Orderfld
nvarchar(2000),
--
排序字段名
最好为唯一主键
@OrderType
int
=
1
--
排序类型
1:降序
其它为升序
)
AS
DECLARE
@TotalRecord
int
DECLARE
@TotalPage
int
DECLARE
@CurrentPageSize
int
DECLARE
@TotalRecordForPageIndex
int
DECLARE
@OrderBy
nvarchar(255)
DECLARE
@CutOrderBy
nvarchar(255)
if
@OrderType
=
1
BEGIN
set
@OrderBy
=
'
Order
by
'
+
REPLACE(@Orderfld,',','
desc,')
+
'
desc
'
set
@CutOrderBy
=
'
Order
by
'+
REPLACE(@Orderfld,',','
asc,')
+
'
asc
'
END
else
BEGIN
set
@OrderBy
=
'
Order
by
'
+
REPLACE(@Orderfld,',','
asc,')
+
'
asc
'
set
@CutOrderBy
=
'
Order
by
'+
REPLACE(@Orderfld,',','
desc,')
+
'
desc
'
END
--
记录总数
declare
@countSql
nvarchar(4000)
set
@countSql='SELECT
@TotalRecord=Count(*)
From
'+@TableName+'
'+@Where
execute
sp_executesql
@countSql,N'@TotalRecord
int
out',@TotalRecord
out
SET
@TotalPage=(@TotalRecord-1)/@PageSize+1
SET
@CurrentPageSize=@PageSize
IF(@TotalPage=@PageIndex)
BEGIN
SET
@CurrentPageSize=@TotalRecord%@PageSize
IF(@CurrentPageSize=0)
SET
@CurrentPageSize=@PageSize
END
--
返回记录
set
@TotalRecordForPageIndex=@PageIndex*@PageSize
exec('SELECT
*
FROM
(SELECT
TOP
'+@CurrentPageSize+'
*
FROM
(SELECT
TOP
'+@TotalRecordForPageIndex+'
'+@ReturnFields+'
FROM
'+@TableName+'
'+@Where+'
'+@OrderBy+')
TB2
'+@CutOrderBy+')
TB3
'+@OrderBy)
--
返回总页数和总记录数
SELECT
@TotalPage
as
PageCount,@TotalRecord
as
RecordCount
GO

C. sql数据库分页

楼主，刚刚有个问友和你问的差不多，我刚回答了他的。就直接把刚回答的复制给你看看啦。希望对你有帮助、。
要想分页，首先得做好准备工作。你要先声明每页显示多少条数据，还得获取当前选择的是多少页的页码。有了这两个分页就好办了。
sql如下：select top 10 from tableName
where (id not in(select top 20 from tableName order by Id desc)) order by Id desc
分页需要使用到的一些动态数据如下：
每页显示的数量：自己定义。
总页数：数据总条数/每页显示的条数
当前页码的计算方法：(页码-1)*每页显示的数量。比如我要浏览第3页的数据，3从客户端传送过来后，在后台对页码进行处理：(3-1)*每页显示的数量（假如是10）.算出来后的结果就是20.你在把20以参数注入的方式动态添加到上面那个20那里就ok了。

sql中的10表示你每页显示的数据，这里跟10，就代表每页显示10条。(你可以定义一个常量作为每页显示的条数)
where中的20表示不包括前面的20条数据，也就是查询出从第21条到30之间的数据。
不知道我这样说你是否理解，其实只要理解了sql语句，分页就很好做了。

D. sql多表关联，数据量比较大的分页查询，怎么做，有没有较好的方法，

可以做一个存储过程，传入参数的方式，参数可以有显示第几页，分页大小，可以返回总行数和查询结果

E. （问题解决再追加100分）sql server存储过程实现查询数据条数过大，分页查询怎么实现

按说5-8w这样数量级的数据没有问题，写入Excel是布比较耗性能，主要还是要通过优化写入Excel的代码效率上去考虑。你可以考虑利用分批查询写入的方式来避免一次写太多的数据到Excel：将你的查询结果分段，比方你的语句中能不能用时间来认为分段，每次返回部分结果。
回到你的问题，对大数据量查询的解决方案有以下两种：
（1）、将全部数据先查询到内存中，然后在内存中进行分页，这种方式对内存占用较大，必须限制一次查询的数据量。
（2）、采用存储过程在数据库中进行分页，这种方式对数据库的依赖较大，不同的数据库实现机制不通，并且查询效率不够理想。以上两种方式对用户来说都不够友好。

2．解决思路
通过在待查询的数据库表上增加一个用于查询的自增长字段，然后采用该字段进行分页查询，可以很好地解决这个问题。下面举例说明这种分页查询方案。

（1）、在待查询的表格上增加一个long型的自增长列，取名为“queryId”,mssql、sybase直接支持自增长字段，oracle可以用sequence和trigger来实现。然后在该列上加上一个索引。
添加queryId列的语句如下：
Mssql: [QUERYID] [bigint] IDENTITY (1, 1)

Sybase: QUERYID numeric(19) identity

Oracle:
CREATE SEQUENCE queryId_S
INCREMENT BY 1
START WITH 1
MAXVALUE 999999999999999 MINVALUE 1
CYCLE
CACHE 20
ORDER;
CREATE OR REPLACE TRIGGER queryId_T BEFORE INSERT
ON "test_table"
FOR EACH ROW
BEGIN
select queryId_S.nextval into :new.queryId from al;
END;

（2）、在查询第一页时，先按照大小顺序的倒序查出所有的queryId，
语句如下：select queryId from test_table where + 查询条件 +order by queryId desc 。
因为只是查询queryId字段，即使表格中的数据量很大，该查询也会很快得到结果。然后将得到的queryId保存在应用服务器的一个数组中。

（3）、用户在客户端进行翻页操作时，客户端将待查询的页号作为参数传递给应用服务器，服务器通过页号和queyId数组算出待查询的queyId最大和最小值，然后进行查询。

算出queyId最大和最小值的算法如下,其中page为待查询的页号，pageSize为每页的大小，queryIds为第二步生成的queryId数组：
int startRow = (page - 1) * pageSize
int endRow = page * pageSize - 1;
if (endRow >=queryIds.length)
{
endRow = this.queryIds.length - 1;
}
long startId =queryIds[startRow];
long endId =queryIds[endRow];

查询语句如下：
String sql = "select * from test_table" + 查询条件 + "(queryId <= " + startId + " and queryId >= " + endId + ")";

3．效果评价
该分页查询方法对所有数据库都适用，对应用服务器、数据库服务器、查询客户端的cpu和内存占用都较低，查询速度较快，是一个较为理想的分页查询实现方案。经过测试，查询4百万条数据，可以在3分钟内显示出首页数据，以后每一次翻页操作基本在2秒以内。内存和cpu占用无明显增长。

以上也仅仅是分页查询结果查看的问题，你需要写入到Excel的话还需要考虑Excel写入代码的执行效率，这部分是很值得研究的。

F. sqlserver2000 如何提高分页查询大数据量的效率

sqlserver2005及以上的版本有row_number()函数可以高效分页，sqlserver2000的话只能看算法了

G. 对于多表关联的，大数据分页，怎么整sql

SELECT*
FROM(SELECT查询字段,
ROW_NUMBER()OVER(ORDERBY排序字段)ASNum
FROM表1a
INNERJOIN表2bONa.关联字段=b.关联字段
)t
WHEREt.NumBETWEEN10AND20

H. 大数据量实时统计排序分页查询(并发数较小时)的几点建议

大数据量实时统计排序分页查询的瓶颈不是函数（count，sum等）执行，

不是having, 也不是order by，甚至不是表join, 导致慢的原因就在于“数据量太大本身”

就是将表划分为M份相互独立的部分,可以是分表，也可以是不分表但冗余一个取模结果字段

实际结果是不分表比分表更加灵活，只需稍加配置，就可以动态切分大表，随意更改M的大小。

将1条慢sql（大于30秒）拆分成为N条查询速度巨快的sql(单条sql执行时间控制在20毫秒以内)

然后再web应用中以适当的线程数去并发查询这些执行时间快的N条小sql再汇总结果

第一步查询中去并发执行这N条小sql, 只取排序字段和标识字段，其他字段一律丢弃

汇总结果后定位出当前页面要显示的pageNum条数据，再进行第二步查询，取出页面上需要展示的所有字段

PS：这一点是至关重要的，其他几点都可以不看，这点是最关键的。慢慢解释一下：

有三种方式统计所有的记录，

a) 第一种方式是把数据库中所有记录（只取排序字段和标识字段并且不做任何sum，count having order by等操作）

全部拉到web应用中，在web应用中完成所有的计算

b) 第二种方式是把数据库中所有记录做sum count having等操作之后的所有行数拉到web应用中，在web应用中完成剩余计算

c) 第三种方式是把数据库中所有记录做sum count having order by等操作之后把limit后的数据拉到web应用中，

在web应用中对limit后的数据再计算

显然，第一种方式 数据库什么活都不做只取数据 是不可行的。以lg_order_count_seller为例，1500万行，

如果只算id, seller_id和order_count 这三个bigint类型，至少需要拉8*3*1500 0000 = 360000000=340M,

拉到内存中之后存储需要8*4*15000000= 460M,这还不算List是的2的n次方这个特点和计算排序等的内存开销，

不仅数据库与web应用机器IO扛不住，就是应用自身恐怕也要OOM了。

第二种方式，所有记录做sum count having等操作之后,由于是group by seller_id的，总得数据量变为100万（就是卖家总数），

这样子一来，共需要拉8*3*100 0000 = 23M,拉到内存之后，需要8*4*100 0000 = 30M, 再算上List是的2的n次方这个特点和

计算排序等的内存开销也不会超过100M, IO的时间和内存开销勉强可以考虑接受。

第三种方式，所有记录做sum count having order by等操作之后把limit后的数据拉到web应用中，因为做了limit，所以，

数据量很小了，无论是IO还是内存开销都已经很小了。可以忽略。

综合以上三种，第三种方式适用于页面的前n页和后n页，因为这个limit的数据量随着页数的增大而增大，

当大到每个切分后的小表的数据量时就转为第二种方式了。

第二种方式适用于页面的第[n+1, totaoPageNum-n]页。

① 问题描述：

优化之前，还是是一条大慢sql查询时，由于数据库排序是稳定排序，

所以当两条记录排序字段值相同时他们在页面上的页码位置是固定的。

优化之后，当并行执行这N条小sql时，由于无法控制这些小sql的先后执行顺序，

导致在web应用中当两条记录的排序字段值相同时在页面上的页码位置是随机的。

② 解决办法：

除了拉标识字段(seller_id)和排序字段(order_count_sum)之外，再取一个unique（id）的字段，当两条记录的排序字段值相同时，

再用这个unique的字段（在卖家监控中这个字段是id）进行第二次排序.这样就解决了排序不稳定的问题。

③ 也许，看到这里会有疑问，为什么不用seller_id？seller_id也是唯一， 这样子不是少取id这个字段，减少IO了？

seller_id虽然也是唯一，可以辅助排序，但是不要忘记数据库的排序规则是：

如果两列的值相等，那么序号在前的排在前面，这里的序号就是主键(自动生成，autoincrement),

如果用seller_id的话还是不能保证排序的稳定性，只能用主键id.

把数据库的连接，扫表，计算等资源优先让给用户关注的主要元素，次要元素可等主要元素加载完成之后再加载。

反应在卖家监控页面中，查数据和查页页码的sql语句基本相同，是在竞争同一资源，

所以，需要做一个策略，优先把资源让给查数，数据查完之后再去查页码。

由于多线程取数据并没有从本质上提高数据库性能，所以必须针对大数据量实时统计排序分页查询做限流

我这里打个比方：食堂有6个窗口，物流团队吃饭要买6个菜，平均每买1个菜需要1分钟的时间，

如果派我一个人去一个窗口买的话需要6分钟的时间

假如派6个人分别去6个窗口买这6个菜，只需要1分钟的时间

但是，如果除了物流团队，再来其他5个团队呢，也就是说6个团队每个团队买6个菜共买36个菜，

这样子有的团队先买完，有的团队后买完，但平均时间还是6分钟。本质上没有变化。

所以，对于特定的查询条件，必须进行限流。让每分钟至多有6个团队买菜，这样子能使得情况变得不至于太糟糕。

这一点从目前来看只能是展望了，比如mysql数据库换更为强大的oracle数据库，

或更换InnoDb引擎为其他，或更换SATA硬盘为SSD 。。。。。。

相同的查询条件，原来一个页面查询时间由于超过60秒超时了，根据1-6点建议优化之后，查询时间变为2秒至3.5秒之间。

I. 对于多表关联的，大数据分页，怎么整sql

可以做一个存储过程,传入参数的方式,参数可以有显示第几页,分页大小,可以返回总行数和查询结果！