MSSQL网页设计SQL Server 存储历程的分页计划比拼
导致了一个使用几乎和mSQL一样的API接口的用于他们的数据库的新的SQL接口的产生，这样，这个API被设计成允许为用于mSQL而写的第三方代码更容易移植到MySQL。server|存储历程|分页SQLServer存储历程的分页，这个成绩已会商过几年了，良多伴侣在问我，以是在此宣布一下我的概念
创建表：
CREATETABLE(
IDENTITY(1,1)NOTNULL,
(100)COLLATEChinese_PRC_CI_ASNULL,
(100)COLLATEChinese_PRC_CI_ASNULL,
(50)COLLATEChinese_PRC_CI_ASNULL,
(2000)COLLATEChinese_PRC_CI_ASNULL
)ON
GO
拔出数据：(2万条，用更多的数据测试会分明一些)
SETIDENTITY_INSERTTestTableON
declare@iint
set@i=1
while@i<=20000
begin
insertintoTestTable(,FirstName,LastName,Country,Note)values(@i,FirstName_XXX,LastName_XXX,Country_XXX,Note_XXX)
set@i=@i+1
end
SETIDENTITY_INSERTTestTableOFF
-------------------------------------
分页计划一：(使用NotIn和SELECTTOP分页)
语句情势：
SELECTTOP10*
FROMTestTable
WHERE(IDNOTIN
(SELECTTOP20id
FROMTestTable
ORDERBYid))
ORDERBYID
SELECTTOP页巨细*
FROMTestTable
WHERE(IDNOTIN
(SELECTTOP页巨细*页数id
FROM表
ORDERBYid))
ORDERBYID
-------------------------------------
分页计划二：(使用ID年夜于几和SELECTTOP分页）
语句情势：
SELECTTOP10*
FROMTestTable
WHERE(ID>
(SELECTMAX(id)
FROM(SELECTTOP20id
FROMTestTable
ORDERBYid)AST))
ORDERBYID
SELECTTOP页巨细*
FROMTestTable
WHERE(ID>
(SELECTMAX(id)
FROM(SELECTTOP页巨细*页数id
FROM表
ORDERBYid)AST))
ORDERBYID
-------------------------------------
分页计划三：(使用SQL的游标存储历程分页)
createprocedureXiaoZhengGe
@sqlstrnvarchar(4000),--查询字符串
@currentpageint,--第N页
@pagesizeint--每页行数
as
setnocounton
declare@P1int,--P1是游标的id
@rowcountint
execsp_cursoropen@P1output,@sqlstr,@scrollopt=1,@ccopt=1,@rowcount=@rowcountoutput
selectceiling(1.0*@rowcount/@pagesize)as总页数--,@rowcountas总行数,@currentpageas以后页
set@currentpage=(@currentpage-1)*@pagesize+1
execsp_cursorfetch@P1,16,@currentpage,@pagesize
execsp_cursorclose@P1
setnocountoff
别的的计划：假如没有主键，能够用一时表，也能够用计划三做，可是效力会低。
倡议优化的时分，加上主键和索引，查询效力会进步。
经由过程SQL查询剖析器，显现对照：我的结论是:
分页计划二：(使用ID年夜于几和SELECTTOP分页）效力最高，必要拼接SQL语句
分页计划一：(使用NotIn和SELECTTOP分页)效力次之，必要拼接SQL语句
分页计划三：(使用SQL的游标存储历程分页)效力最差，可是最为通用
在实践情形中，要详细剖析。
更多的会商见：
http://community.csdn.net/Expert/topic/3292/3292678.xml?temp=.1621515
php本地模拟的prepare底层就是mysql_real_escape_string，所以必须得用mysql_set_character_set去设置mysql->charset，否则就存在字符集问题。 索引视k就有。但是2005对其效率作了一些改进但是schema.viewname的作用域真是太限制了它的应用面。还有一大堆的环境参数和种种限制都让人对它有点却步。 代替了原来VB式的错误判断。比Oracle高级不少。 还不是性能有问题！否则面向对象的数据库早就实现了！建议使用CLR的地方一般是和应用的复杂程度或操作系统环境有很高的耦合度的场景。如你想构建复杂的算法，并且用到了大量的指针和高级数据模型。 只能告诉你，学好数据库语言和原理，多见识几种数据库软件，比一棵树上吊死要好。 原理很简单，对要求长时间计算某一时间点的报表生成和防用户操作错误很有帮助。但是比起Oracle10g的闪回技术还是细粒度不够。可惜！ 代替了原来VB式的错误判断。比Oracle高级不少。 大侠们有推荐的书籍和学习方法写下吧。 如果处理少量数据,比如几百条记录的数据,我不知道这两种情况哪个效率更高,如果处理大量数据呢?比如有表中有20万条记录.
页:
[1]