当前位置:首页 » 服务存储 » 大数据计算替代存储过程
扩展阅读
webinf下怎么引入js 2023-08-31 21:54:13
堡垒机怎么打开web 2023-08-31 21:54:11

大数据计算替代存储过程

发布时间: 2022-09-11 20:20:50

‘壹’ 如果在数据库中有大数据量,而我们用分页存储过程,怎么样才能效率高

--------------------------------
--关于分页储存的效率问题
--5个存储过程都是采用不同的方式
--------------------------------
------------------------------------------
--利用select top 和select not in进行分页--
------------------------------------------
create procere proc_paged_with_notin --利用select top and select not in
(
@pageIndex int, --页索引
@pageSize int --每页记录数
)
as
begin
set nocount on;
declare @timediff datetime --耗时
declare @sql nvarchar(500)
select @timediff=Getdate()
set @sql='select top '+str(@pageSize)+' * from tb_TestTable where(ID not in(select top '+str(@pageSize*@pageIndex)+' id from tb_TestTable order by ID ASC)) order by ID'
execute(@sql) --因select top后不支技直接接参数,所以写成了字符串@sql
select datediff(ms,@timediff,GetDate()) as 耗时
set nocount off;
endexec proc_paged_with_notin 10000,10
--------------------------------------
--利用select top 和 select max(列键)--
--------------------------------------
create procere proc_paged_with_selectMax --利用select top and select max(列)
(
@pageIndex int, --页索引
@pageSize int --页记录数
)
as
begin
set nocount on;
declare @timediff datetime
declare @sql nvarchar(500)
select @timediff=Getdate()
set @sql='select top '+str(@pageSize)+' * From tb_TestTable where(ID>(select max(id) From (select top '+str(@pageSize*@pageIndex)+' id From tb_TestTable order by ID) as TempTable)) order by ID'
execute(@sql)
select datediff(ms,@timediff,GetDate()) as 耗时
set nocount off;
end--------------------------------------------------------
--利用select top和中间变量--此方法因网上有人说效果最佳--
--------------------------------------------------------
create procere proc_paged_with_Midvar --利用ID>最大ID值和中间变量
(
@pageIndex int,
@pageSize int
)
as
declare @count int
declare @ID int
declare @timediff datetime
declare @sql nvarchar(500)
begin
set nocount on;
select @count=0,@ID=0,@timediff=getdate()
select @count=@count+1,@ID=case when @count<=@pageSize*@pageIndex then ID else @ID end from tb_testTable order by id
set @sql='select top '+str(@pageSize)+' * from tb_testTable where ID>'+str(@ID)
execute(@sql)
select datediff(ms,@timediff,getdate()) as 耗时
set nocount off;
end
---------------------------------------------------------------------------------------
--利用Row_number() 此方法为SQL server 2005中新的方法,利用Row_number()给数据行加上索引--
---------------------------------------------------------------------------------------
create procere proc_paged_with_Rownumber --利用SQL 2005中的Row_number()
(
@pageIndex int,
@pageSize int
)
as
declare @timediff datetime
begin
set nocount on;
select @timediff=getdate()
select * from (select *,Row_number() over(order by ID asc) as IDRank from tb_testTable) as IDWithRowNumber where IDRank>@pageSize*@pageIndex and IDRank<@pageSize*(@pageIndex+1)
select datediff(ms,@timediff,getdate()) as 耗时
set nocount off;
end
--------------------------
--利用临时表及Row_number--
--------------------------
create procere proc_CTE --利用临时表及Row_number
(
@pageIndex int, --页索引
@pageSize int --页记录数
)
as
set nocount on;
declare @ctestr nvarchar(400)
declare @strSql nvarchar(400)
declare @datediff datetime
begin
select @datediff=GetDate()
set @ctestr='with Table_CTE as
(select ceiling((Row_number() over(order by ID ASC))/'+str(@pageSize)+') as page_num,* from tb_TestTable)';
set @strSql=@ctestr+' select * From Table_CTE where page_num='+str(@pageIndex)
end
begin
execute sp_executesql @strSql
select datediff(ms,@datediff,GetDate())
set nocount off;
end
我们分别在每页10条数据的情况下在第2页,第1000页,第10000页,第100000页,第199999页进行测试,耗时单位:ms 每页测试5次取其平均值 存过第2页耗时第1000页耗时第10000页耗时第100000页耗时第199999页耗时效率排行1用not in0ms16ms47ms475ms953ms32用select max5ms16ms35ms325ms623ms13中间变量_number0ms0ms34ms365ms710ms24临时表780ms796ms798ms780ms805ms4正好我正在研究这个问题 给大家分享

‘贰’ 大数据时代发展历程是什么

大数据技术发展史:大数据的前世今生

今天我们常说的大数据技术,其实起源于Google在2004年前后发表的三篇论文,也就是我们经常听到的“三驾马车”,分别是分布式文件系统GFS、大数据分布式计算框架MapRece和NoSQL数据库系统BigTable。

你知道,搜索引擎主要就做两件事情,一个是网页抓取,一个是索引构建,而在这个过程中,有大量的数据需要存储和计算。这“三驾马车”其实就是用来解决这个问题的,你从介绍中也能看出来,一个文件系统、一个计算框架、一个数据库系统。

现在你听到分布式、大数据之类的词,肯定一点儿也不陌生。但你要知道,在2004年那会儿,整个互联网还处于懵懂时代,Google发布的论文实在是让业界为之一振,大家恍然大悟,原来还可以这么玩。

因为那个时间段,大多数公司的关注点其实还是聚焦在单机上,在思考如何提升单机的性能,寻找更贵更好的服务器。而Google的思路是部署一个大规模的服务器集群,通过分布式的方式将海量数据存储在这个集群上,然后利用集群上的所有机器进行数据计算。 这样,Google其实不需要买很多很贵的服务器,它只要把这些普通的机器组织到一起,就非常厉害了。

当时的天才程序员,也是Lucene开源项目的创始人Doug Cutting正在开发开源搜索引擎Nutch,阅读了Google的论文后,他非常兴奋,紧接着就根据论文原理初步实现了类似GFS和MapRece的功能。

两年后的2006年,Doug Cutting将这些大数据相关的功能从Nutch中分离了出来,然后启动了一个独立的项目专门开发维护大数据技术,这就是后来赫赫有名的Hadoop,主要包括Hadoop分布式文件系统HDFS和大数据计算引擎MapRece。

当我们回顾软件开发的历史,包括我们自己开发的软件,你会发现,有的软件在开发出来以后无人问津或者寥寥数人使用,这样的软件其实在所有开发出来的软件中占大多数。而有的软件则可能会开创一个行业,每年创造数百亿美元的价值,创造百万计的就业岗位,这些软件曾经是Windows、Linux、Java,而现在这个名单要加上Hadoop的名字。

如果有时间,你可以简单浏览下Hadoop的代码,这个纯用Java编写的软件其实并没有什么高深的技术难点,使用的也都是一些最基础的编程技巧,也没有什么出奇之处,但是它却给社会带来巨大的影响,甚至带动一场深刻的科技革命,推动了人工智能的发展与进步。

我觉得,我们在做软件开发的时候,也可以多思考一下,我们所开发软件的价值点在哪里?真正需要使用软件实现价值的地方在哪里?你应该关注业务、理解业务,有价值导向,用自己的技术为公司创造真正的价值,进而实现自己的人生价值。而不是整天埋头在需求说明文档里,做一个没有思考的代码机器人。

Hadoop发布之后,Yahoo很快就用了起来。大概又过了一年到了2007年,网络和阿里巴巴也开始使用Hadoop进行大数据存储与计算。

2008年,Hadoop正式成为Apache的顶级项目,后来Doug Cutting本人也成为了Apache基金会的主席。自此,Hadoop作为软件开发领域的一颗明星冉冉升起。

同年,专门运营Hadoop的商业公司Cloudera成立,Hadoop得到进一步的商业支持。

这个时候,Yahoo的一些人觉得用MapRece进行大数据编程太麻烦了,于是便开发了Pig。Pig是一种脚本语言,使用类SQL的语法,开发者可以用Pig脚本描述要对大数据集上进行的操作,Pig经过编译后会生成MapRece程序,然后在Hadoop上运行。

编写Pig脚本虽然比直接MapRece编程容易,但是依然需要学习新的脚本语法。于是Facebook又发布了Hive。Hive支持使用SQL语法来进行大数据计算,比如说你可以写个Select语句进行数据查询,然后Hive会把SQL语句转化成MapRece的计算程序。

这样,熟悉数据库的数据分析师和工程师便可以无门槛地使用大数据进行数据分析和处理了。Hive出现后极大程度地降低了Hadoop的使用难度,迅速得到开发者和企业的追捧。据说,2011年的时候,Facebook大数据平台上运行的作业90%都来源于Hive。

随后,众多Hadoop周边产品开始出现,大数据生态体系逐渐形成,其中包括:专门将关系数据库中的数据导入导出到Hadoop平台的Sqoop;针对大规模日志进行分布式收集、聚合和传输的Flume;MapRece工作流调度引擎Oozie等。

在Hadoop早期,MapRece既是一个执行引擎,又是一个资源调度框架,服务器集群的资源调度管理由MapRece自己完成。但是这样不利于资源复用,也使得MapRece非常臃肿。于是一个新项目启动了,将MapRece执行引擎和资源调度分离开来,这就是Yarn。2012年,Yarn成为一个独立的项目开始运营,随后被各类大数据产品支持,成为大数据平台上最主流的资源调度系统。

同样是在2012年,UC伯克利AMP实验室(Algorithms、Machine和People的缩写)开发的Spark开始崭露头角。当时AMP实验室的马铁博士发现使用MapRece进行机器学习计算的时候性能非常差,因为机器学习算法通常需要进行很多次的迭代计算,而MapRece每执行一次Map和Rece计算都需要重新启动一次作业,带来大量的无谓消耗。还有一点就是MapRece主要使用磁盘作为存储介质,而2012年的时候,内存已经突破容量和成本限制,成为数据运行过程中主要的存储介质。Spark一经推出,立即受到业界的追捧,并逐步替代MapRece在企业应用中的地位。

一般说来,像MapRece、Spark这类计算框架处理的业务场景都被称作批处理计算,因为它们通常针对以“天”为单位产生的数据进行一次计算,然后得到需要的结果,这中间计算需要花费的时间大概是几十分钟甚至更长的时间。因为计算的数据是非在线得到的实时数据,而是历史数据,所以这类计算也被称为大数据离线计算。

而在大数据领域,还有另外一类应用场景,它们需要对实时产生的大量数据进行即时计算,比如对于遍布城市的监控摄像头进行人脸识别和嫌犯追踪。这类计算称为大数据流计算,相应地,有Storm、Flink、Spark Streaming等流计算框架来满足此类大数据应用的场景。 流式计算要处理的数据是实时在线产生的数据,所以这类计算也被称为大数据实时计算。

在典型的大数据的业务场景下,数据业务最通用的做法是,采用批处理的技术处理历史全量数据,采用流式计算处理实时新增数据。而像Flink这样的计算引擎,可以同时支持流式计算和批处理计算。

除了大数据批处理和流处理,NoSQL系统处理的主要也是大规模海量数据的存储与访问,所以也被归为大数据技术。 NoSQL曾经在2011年左右非常火爆,涌现出HBase、Cassandra等许多优秀的产品,其中HBase是从Hadoop中分离出来的、基于HDFS的NoSQL系统。

我们回顾软件发展的历史会发现,差不多类似功能的软件,它们出现的时间都非常接近,比如Linux和Windows都是在90年代初出现,Java开发中的各类MVC框架也基本都是同期出现,Android和iOS也是前脚后脚问世。2011年前后,各种NoSQL数据库也是层出不群,我也是在那个时候参与开发了阿里巴巴自己的NoSQL系统。

事物发展有自己的潮流和规律,当你身处潮流之中的时候,要紧紧抓住潮流的机会,想办法脱颖而出,即使没有成功,也会更加洞悉时代的脉搏,收获珍贵的知识和经验。而如果潮流已经退去,这个时候再去往这个方向上努力,只会收获迷茫与压抑,对时代、对自己都没有什么帮助。

但是时代的浪潮犹如海滩上的浪花,总是一浪接着一浪,只要你站在海边,身处这个行业之中,下一个浪潮很快又会到来。你需要敏感而又深刻地去观察,略去那些浮躁的泡沫,抓住真正潮流的机会,奋力一搏,不管成败,都不会遗憾。

正所谓在历史前进的逻辑中前进,在时代发展的潮流中发展。通俗的说,就是要在风口中飞翔。

上面我讲的这些基本上都可以归类为大数据引擎或者大数据框架。而大数据处理的主要应用场景包括数据分析、数据挖掘与机器学习。数据分析主要使用Hive、Spark SQL等SQL引擎完成;数据挖掘与机器学习则有专门的机器学习框架TensorFlow、Mahout以及MLlib等,内置了主要的机器学习和数据挖掘算法。

此外,大数据要存入分布式文件系统(HDFS),要有序调度MapRece和Spark作业执行,并能把执行结果写入到各个应用系统的数据库中,还需要有一个大数据平台整合所有这些大数据组件和企业应用系统。

图中的所有这些框架、平台以及相关的算法共同构成了大数据的技术体系,我将会在专栏后面逐个分析,帮你能够对大数据技术原理和应用算法构建起完整的知识体系,进可以专职从事大数据开发,退可以在自己的应用开发中更好地和大数据集成,掌控自己的项目。

希望对您有所帮助!~

‘叁’ 什么是存储过程有什么优点

存储过程是事先经过编译并存储在数据库中的一段SQL语句的集合,调用存储过程可以简化应用开发人员的很多工作,减少数据在数据库和应用服务器之间的传输,对于提高数据处理的效率是有好处的。

优点:

1、重复使用:存储过程可以重复使用,从而可以减少数据库开发人员的工作量。

2、减少网络流量:存储过程位于服务器上,调用的时候只需要传递存储过程的名称以及参数就可以了,因此降低了网络传输的数据量。

3、安全性:参数化的存储过程可以防止SQL注入式攻击,而且可以将Grant、Deny以及Revoke权限应用于存储过程。

(3)大数据计算替代存储过程扩展阅读

存储过程的缺点:

1、更改比较繁琐:如果更改范围大到需要对输入存储过程的参数进行更改,或者要更改由其返回的数据,则仍需要更新程序集中的代码以添加参数、更新 GetValue() 调用,等等,这时候估计比较繁琐。

2、可移植性差:由于存储过程将应用程序绑定到 SQL Server,因此使用存储过程封装业务逻辑将限制应用程序的可移植性。如果应用程序的可移植性在您的环境中非常重要,则需要将业务逻辑封装在不特定于 RDBMS 的中间层中。

‘肆’ oracle中函数和存储过程的区别和联系

  1. 函数有1个返回值,而存储过程可以有多个或者没有。

  2. 函数可以在其他语句中直接调用,而存储过程必须单独调用。

  3. 函数通常用于计算或较为单一的数据功能,存储过程相对完成更复杂的复合性的数据功能。

  4. 最关键普通语句每次执行都要编译,而存储过程只在创建时编译之后直接调用,速度更快,在大数据复杂功能时尤其明显。

  5. 存储过程还可以指定用户权限。

‘伍’ 对于大量数据(几千万条)的查询,筛选不用触发器或者存储过程,有没有可能用程序实现高效的查询

1.对查询进行优化,应尽量避免全表扫描,首先应考虑在 where 及 order by 涉及的列上建立索引。

2.应尽量避免在 where 子句中对字段进行 null 值判断,否则将导致引擎放弃使用索引而进行全表扫描,如:

select id from t where num is null

可以在num上设置默认值0,确保表中num列没有null值,然后这样查询:

select id from t where num=0

3.应尽量避免在 where 子句中使用!=或<>操作符,否则将引擎放弃使用索引而进行全表扫描。

4.应尽量避免在 where 子句中使用 or 来连接条件,否则将导致引擎放弃使用索引而进行全表扫描,如:

select id from t where num=10 or num=20

可以这样查询:

select id from t where num=10

union all

select id from t where num=20

5.in 和 not in 也要慎用,否则会导致全表扫描,如:

select id from t where num in(1,2,3)

对于连续的数值,能用 between 就不要用 in 了:

select id from t where num between 1 and 3

6.下面的查询也将导致全表扫描:

select id from t where name like '%abc%'

若要提高效率,可以考虑全文检索。

7.如果在 where 子句中使用参数,也会导致全表扫描。因为SQL只有在运行时才会解析局部变量,但优化程序不能将访问计划的选择推迟到运行时;它必须在编译时进行选择。然而,如果在编译时建立访问计划,变量的值还是未知的,因而无法作为索引选择的输入项。如下面语句将进行全表扫描:

select id from t where num=@num

可以改为强制查询使用索引:

select id from t with(index(索引名)) where num=@num

8.应尽量避免在 where 子句中对字段进行表达式操作,这将导致引擎放弃使用索引而进行全表扫描。如:

select id from t where num/2=100

应改为:

select id from t where num=100*2

9.应尽量避免在where子句中对字段进行函数操作,这将导致引擎放弃使用索引而进行全表扫描。如:

select id from t where substring(name,1,3)='abc'--name以abc开头的id

select id from t where datediff(day,createdate,'2005-11-30')=0--‘2005-11-30’生成的id

应改为:

select id from t where name like 'abc%'

select id from t where createdate>='2005-11-30' and createdate<'2005-12-1'

10.不要在 where 子句中的“=”左边进行函数、算术运算或其他表达式运算,否则系统将可能无法正确使用索引。

11.在使用索引字段作为条件时,如果该索引是复合索引,那么必须使用到该索引中的第一个字段作为条件时才能保证系统使用该索引,否则该索引将不会被使用,并且应尽可能的让字段顺序与索引顺序相一致。

12.不要写一些没有意义的查询,如需要生成一个空表结构:

select col1,col2 into #t from t where 1=0

这类代码不会返回任何结果集,但是会消耗系统资源的,应改成这样:

create table #t(...)

13.很多时候用 exists 代替 in 是一个好的选择:

select num from a where num in(select num from b)

用下面的语句替换:

select num from a where exists(select 1 from b where num=a.num)

14.并不是所有索引对查询都有效,SQL是根据表中数据来进行查询优化的,当索引列有大量数据重复时,SQL查询可能不会去利用索引,如一表中有字段sex,male、female几乎各一半,那么即使在sex上建了索引也对查询效率起不了作用。

15.索引并不是越多越好,索引固然可以提高相应的 select 的效率,但同时也降低了 insert 及 update 的效率,因为 insert 或 update 时有可能会重建索引,所以怎样建索引需要慎重考虑,视具体情况而定。一个表的索引数最好不要超过6个,若太多则应考虑一些不常使用到的列上建的索引是否有必要。

16.应尽可能的避免更新 clustered 索引数据列,因为 clustered 索引数据列的顺序就是表记录的物理存储顺序,一旦该列值改变将导致整个表记录的顺序的调整,会耗费相当大的资源。若应用系统需要频繁更新 clustered 索引数据列,那么需要考虑是否应将该索引建为 clustered 索引。

17.尽量使用数字型字段,若只含数值信息的字段尽量不要设计为字符型,这会降低查询和连接的性能,并会增加存储开销。这是因为引擎在处理查询和连接时会逐个比较字符串中每一个字符,而对于数字型而言只需要比较一次就够了。

18.尽可能的使用 varchar/nvarchar 代替 char/nchar ,因为首先变长字段存储空间小,可以节省存储空间,其次对于查询来说,在一个相对较小的字段内搜索效率显然要高些。

19.任何地方都不要使用 select * from t ,用具体的字段列表代替“*”,不要返回用不到的任何字段。

20.尽量使用表变量来代替临时表。如果表变量包含大量数据,请注意索引非常有限(只有主键索引)。

21.避免频繁创建和删除临时表,以减少系统表资源的消耗。

22.临时表并不是不可使用,适当地使用它们可以使某些例程更有效,例如,当需要重复引用大型表或常用表中的某个数据集时。但是,对于一次性事件,最好使用导出表。

23.在新建临时表时,如果一次性插入数据量很大,那么可以使用 select into 代替 create table,避免造成大量 log ,以提高速度;如果数据量不大,为了缓和系统表的资源,应先create table,然后insert。

24.如果使用到了临时表,在存储过程的最后务必将所有的临时表显式删除,先 truncate table ,然后 drop table ,这样可以避免系统表的较长时间锁定。

25.尽量避免使用游标,因为游标的效率较差,如果游标操作的数据超过1万行,那么就应该考虑改写。

26.使用基于游标的方法或临时表方法之前,应先寻找基于集的解决方案来解决问题,基于集的方法通常更有效。

27.与临时表一样,游标并不是不可使用。对小型数据集使用 FAST_FORWARD 游标通常要优于其他逐行处理方法,尤其是在必须引用几个表才能获得所需的数据时。在结果集中包括“合计”的例程通常要比使用游标执行的速度快。如果开发时间允许,基于游标的方法和基于集的方法都可以尝试一下,看哪一种方法的效果更好。

28.在所有的存储过程和触发器的开始处设置 SET NOCOUNT ON ,在结束时设置 SET NOCOUNT OFF 。无需在执行存储过程和触发器的每个语句后向客户端发送 DONE_IN_PROC 消息。

29.尽量避免大事务操作,提高系统并发能力。

30.尽量避免向客户端返回大数据量,若数据量过大,应该考虑相应需求是否合理。

‘陆’ 如何解决执行sql存储过程(大数据量复杂

插入是sql会把数据存到inserted(我不确定对不对啊)表里面,是在内存中的,当插入到你要插入的表了之后才会删除干才插入到inserted表里的数据,是需要消耗内存的。
消耗的内存都是一样的,只是一个是预编译的(存储过程),一个是即时的。使用存储过程效率要高一些。

‘柒’ 存储过程中用什么可以替代游标

Mysql存储过程优化——使用临时表代替游标。

Mysql游标在操作小数据量时比较方便,效率可观,但操作大数据量,速度比较慢,甚至直接产生系统错误。

一般说来,当操作的数据超过1万条时,就避免用游标吧。

为了测试游标性能,写了下面一个游标对IDC_Gather_Info表中数据进行遍历

1.数据量15万,执行成功,耗时8.928s

2.数据量5万,执行成功,耗时2.994s

3.数据量1万,执行成功,耗时0.634s

可以看到Mysql的游标在处理大一点的数据量时还是比较乏力的,仅适合用于操作几百上千的小数据量。

‘捌’ 如何解决执行sql存储过程(大数据量复杂的sql计算操作)时,不影响用户使用

对实时性不是非常必须的功能,不要放在主业务集中操作的同时操作。这个需要引导客户。
系统的开销就在那里摆着,没有别的办法,一运行资源就占了,CPU 资源,数据库资源,内存资源。
两个办法:一个是做一个数据库复制,可以半天复制一次,也可以一天复制一次(闲时复制),根据用户对数据的敏感度决定,存储过程运行不限时间,运行时访问复制数据库,不影响主数据库。需要额外资源:数据库服务器,数据库复制时间和网络资源开销;
第二个是定制成任务,闲时执行结果放到指定表中,或者直接以文件形式导出在服务器指定位置。用的人直接读记录或者读文件就OK 了。
请参考。

‘玖’ 一个比较实用的大数据量分页存储过程

一个比较实用的大数据量分页存储过程

create proc sp_PublicTurnPageWebSite( @TBName nvarchar(100)=‘‘, --表名,如 pinyin
@PageSize int=10, --每页的记录数,默认为 10
@CurPage int=1, --表示当前页 1
@KeyField nvarchar(100)=‘ID‘, --关键字段名,默认为 ID,该字段要求是表中的索引 或 无重复和不为空的字段
@KeyAscDesc nvarchar(4)=‘ASC‘, --关键字的升、降序,默认为升序 ASC , 降序为 DESC
@Fields nvarchar(500)=‘*‘, --所选择的列名,默认为全选
@Condition nvarchar(200)=‘‘, --where 条件,默认为空
@Order nvarchar(200)=‘‘ --排序条件,默认为空
) with encryption as
BEGIN
if @TBName = ‘‘
begin
raiserror(‘请指定表名!‘,11,1)
return
end
if @PageSize <=0 or @CurPage <0
begin
raiserror(‘当前页数和每页的记录数都必须大于零!‘,11,1)
return
end
if @KeyAscDesc = ‘DESC‘
set @KeyAscDesc = ‘<‘
else
set @KeyAscDesc = ‘>‘
if @Condition <> ‘‘
set @Condition = ‘ where ‘ + @Condition
一个比较实用的大数据量分页存储过程
declare @SQL nvarchar(2000) set @SQL = ‘‘
if @CurPage = 1
set @SQL = @SQL + ‘SELECT Top ‘ + cast(@PageSize as nvarchar(20)) + ‘ ‘ + @Fields + ‘ FROM ‘ + @TBName + @Condition + ‘ ‘ + @Order
else
begin
declare @iTopNum int
set @iTopNum = @PageSize * (@CurPage - 1)
set @SQL = @SQL + ‘declare @sLastValue nvarchar(100)‘ + char(13)
set @SQL = @SQL + ‘SELECT Top ‘ + cast(@iTopNum as nvarchar(20)) + ‘ @sLastValue=‘ + @KeyField + ‘ FROM ‘ + @TBName + @Condition + ‘ ‘ + @Order + char(13)

declare @Condition2 nvarchar(200)
if @Condition = ‘‘
set @Condition2 = ‘ where ‘ + @KeyField + @KeyAscDesc + ‘@sLastValue ‘
else
set @Condition2 = ‘ and ‘ + @KeyField + @KeyAscDesc + ‘@sLastValue ‘
set @SQL = @SQL + ‘SELECT Top ‘ + cast(@PageSize as nvarchar(20)) + ‘ ‘ + @Fields + ‘ FROM ‘ + @TBName + @Condition + @Condition2 + @Order
end