exec('update SupplyplanLack set Completedate = GetDate()
from supplyPlanLack a where '+ @ssTmp +' and
'+@iCompleteQty+' >= (select s.RequestQty * a.RationQty as ReqQty
from Balance a, SupplyPlan s where a.Vehicle = s.Vehicle
and a.Part=s.Part and a.SupplyPlanNo = s.SupplyPlanNo
and '+ @ssTmp +')')

set @exec_num=0

if (@spNOFrom=0 or @spNOTo=0 or @reuseUser=NULL)
begin
set @exec_num=1
goto the_end
end

the_end:
return

set nocount on

if (@property is null) or (@property = '')
begin
raiserror('Must specify a property name.',-1,-1)
return (1)
end

       假如你写过很多程序，你可能偶尔会碰到要确定字符或字符窜串否包含在一段文字中，在这篇文章中，我将讨论使用CHARINDEX和PATINDEX函数来搜索文字列和字符串。我将告诉你这两个函数是如何运转的，解释他们的区别。同时提供一些例子，通过这些例子，你可以可以考虑使用这两个函数来解决很多不同的字符搜索的问题。
        CHARINDEX和PATINDEX函数常常用来在一段字符中搜索字符或者字符串。如果被搜索的字符中包含有要搜索的字符，那么这两个函数返回一个非零的整数，这个整数是要搜索的字符在被搜索的字符中的开始位数。PATINDEX函数支持使用通配符来进行搜索，然而CHARINDEX不支持通佩符。接下来，我们逐个分析这两个函数。

如何使用CHARINDEX函数

       CHARINDEX函数返回字符或者字符串在另一个字符串中的起始位置。CHARINDEX函数调用方法如下：

       CHARINDEX ( expression1 , expression2 [ , start_location ] )

       Expression1是要到expression2中寻找的字符中，start_location是CHARINDEX函数开始在expression2中找expression1的位置。

       CHARINDEX函数返回一个整数，返回的整数是要找的字符串在被找的字符串中的位置。假如CHARINDEX没有找到要找的字符串，那么函数整数“0”。让我们看看下面的函数命令执行的结果：

      CHARINDEX('SQL', 'Microsoft SQL Server')

      这个函数命令将返回在“Microsoft SQL Server”中“SQL”的起始位置，在这个例子中，CHARINDEX函数将返回“S”在“Microsoft SQL Server”中的位置11。
接下来，我们看这个CHARINDEX命令：

      CHARINDEX('7.0', 'Microsoft SQL Server 2000')

      在这个例子中，CHARINDEX返回零，因为字符串“7.0” 不能在“Microsoft SQL Server”中被找到。接下来通过两个例子来看看如何使用CHARINDEX函数来解决实际的T-SQL问题。

     第一个例子，假设你要显示Northwind数据库Customer表前5行联系人列的Last Name。这是前5行数据
           ContactName
           ------------------------------ 
           Maria Anders
           Ana Trujillo
           Antonio Moreno
           Thomas Hardy
           Christina Berglund

      你可以看到，CustomName包含客户的First Name和Last Name，它们之间被一个空格隔开。我用CHARINDX函数确定两个名字中间空格的位置。通过这个方法，我们可以分析ContactName列的空格位置，这样我们可以只显示这个列的last name部分。这是显示Northwind的Customer表前5行last name的记录！

               select top 5 substring(ContactName,charindex(' ',ContactName)+1 ,
                      len(ContactName)) as [Last Name] from Northwind.dbo.customers

下面是这个命令输出的结果。
           Last Name
           ------------------------------ 
           Anders
           Trujillo
           Moreno
           Hardy
           Berglund

      CHARINDEX函数找到First Name和Last Name之间的空格，所以SUBSTRING函数可以分开ContactName列，这样就只有Last Name被选出。我在CHARINDEX函数返回的整数上加1，这样Last Name不是从空格开始。

      在第二个例子中，即如说你要计算记录中，某一个字段包含特定字符的所有记录数。CHARINDEX函数可以方便的解决你的问题。计算Northwind.dbo.Customer表中Addresses字段中包含单词Road或者它的缩写Rd的记录数，选择语句类似这样：

       SELECT count(*) from Northwind.dbo.Customers
       WHERE CHARINDEX('Rd',Address) > 0 or CHARINDEX('Road',Address)> 1

如何使用PATINDEX函数

      PATINDEX函数返回字符或者字符串在另一个字符串或者表达式中的起始位置，PATINDEX函数支持搜索字符串中使用通配符，这使PATINDEX函数对于变化的搜索字符串很有价值。PATINDEX函数的命令如下：

      PATINDEX ( '%pattern%' , expression )

      Pattern是你要搜索的字符串，expression是被搜索的字符串。一般情况下expression是一个表中的一个字段，pattern的前后需要用“%”标记，除非你搜索的字符串在被收缩的字符串的最前面或者最后面。

      和CHARINDEX函数一样，PATINDEX函数返回搜索字符串在被搜索字符串中的起始位置。假如有这样一个PATINDEX函数：

      PATINDEX('%BC%','ABCD')

      这个PATINDEX函数返回的结果是2，这和CHARINDEX函数一样。这里的%标记告诉PATINDEX函数去找字符串“BC”，不管被搜索的字符串中在“BC”的前后有多少字符！
      假如你想知道被搜索字符串是否由特定的字符串开始，你可以省去前面的%标记。PATINDED函数就要这样写：

      PATINDEX('AB%','ABCD')

      这个命令执行的结果返回1，表示搜索的字符串“AB”在被搜索的字符串中“ABCD”被找到。

      使用通配符可以编辑比我以上举得简单例子复杂得多的搜索字符串。假如说你要确定一个字符串是否包含字母A和Z，还有任何数字，这个PARINDEX函数命令可能像这样：

      PATINDEX('%[A,Z,0-9]%[A,Z,0-9]%[A,Z,0-9]%','XYZABC123')

      注意在上面这个例子中的搜索字符部分使用了很多的通陪符。察看SQL Server联机丛书可以获得更多关于通佩符的信息。接下来，我们用两个例子来看PATINDEX和SELECT怎么联合起来使用。
 
      假设你想要找出Northwind.dbo.Categories表中Description字段中是包含单词“Bread”或“bread”的所有记录，那么选择语句就可能是这样：

        SELECT Description from Northwind.dbo.Categories
        WHERE patindex('%[b,B]read%',description) > 0

      这里我用通配符来确定大写和小写的“b”。我在Notthwind数据库中执行这个脚本后，得到下面的结果：
           Description
           --------------------------------------------------------
           Desserts, candies, and sweet breads
           Breads, crackers, pasta, and cereal

      这是再用另外一个额外的通配符来查找一些记录的例子。这个例子是如何选出上面的查询结果中，Description字段的第二子字母不是“e”的纪录。

                   select Description from Northwind.dbo.Categories     
                   where patindex('%[b,B]read%',description) > 0  
                   and patindex('_[^e]%',description) = 1        

      通过在条件语句中增加一个使用^通配符的PATINDEX函数，我们可以过滤掉“Dessert, candies, and sweet breads”这条记录。上面的查询结果只有一条记录。
           Description
           --------------------------------------------------------
           Breads, crackers, pasta, and cereal 

总结

      你现在可以发现CHARINDEX和PATINDEX搜索字符串时的区别了吧。PATINDEX函数支持使用通配符，可以用在很多有变化的查找中。而CHARINDEX不可以。根据你自己不同的情况，这两个函数对你在SQL Server中的字符串的搜索、控制、分析很有帮助。

来源：http://blog.csdn.net/DigJim/

动作描述	使用聚集索引	使用非聚集索引
列经常被分组排序	应	应
返回某范围内的数据	应	不应
一个或极少不同值	不应	不应
小数目的不同值	应	不应
大数目的不同值	不应	应
频繁更新的列	不应	应
外键列	应	应
主键列	应	应
频繁修改索引列	不应	应

页 码	方案1	方案2	方案3
1	60	30	76
10	46	16	63
100	1076	720	130
500	540	12943	83
1000	17110	470	250
1万	24796	4500	140
10万	38326	42283	1553
25万	28140	128720	2330
50万	121686	127846	7168

下面给出游标的一个完整的例子：
USE master
GO
CREATE PROCEDURE sp_BuildIndexes
AS
DECLARE @TableName sysname, @msg varchar(100), @cmd varchar(100)

DECLARE table_cur CURSOR FOR
SELECT name FROM sysobjects WHERE type=’u’

OPEN table_cur
FETCH NEXT FROM table_cur INTO @TableName

WHILE @@fetch_status = 0
BEGIN
IF @@fetch_status = -2
CONTINUE
SELECT @msg = “Building indexes for table”+@TableName+”…”
PRINT @msg
SELECT @cmd = “DBCC DBREINDEX (‘”+@TableName+”')”
EXEC (@cmd)
PRINT “ “
FETCH NEXT FROM table_cur INTO @TableName
END
DEALLOCATE table_cur
GO
下面的脚本将为PUBS数据库执行sp_BuildIndexes
USE pubs
GO
EXEC ap_BuildIndexes
注意：上面也是创建用户定义的系统存储过程的示例。

使用临时表
临时表是在TempDB中创建的表。临时表的名称都以“#”开头。临时表的范围为创建临时表的连接。因为，临时表不能在两个连接之间共享，一旦连接关闭，临时表就会被丢弃。如果临时表被创建于存储过程之中，则临时表的范围在存储过程之中，或者被该存储过程调用的任何存储过程之中。如果需要在连接之间共享临时表，则需要使用全局的临时表。全局的临时表以“##”符号开头，它将一直存在于数据库中，直到SQL Server重新启动。一旦这类临时表创建之后，所有的用户都可以访问到。在临时表上不能明确地指明权限。 临时表提供了存储中间结果的能力。有时候，临时表还能通过将一个复杂的查询分解成两个查询而获得性能的改善。这可以通过首先将第一个查询的结果存在临时表中，然后在第二个查询中使用临时表来实现。当一个大表中的某个子集在一个在座过程中使用多次时，建议使用临时表。在这种情况下，在临时表中保持数据的子集，以在随后的连接中使用，这样能大大改善性能。还可以在临时表中创建索引。

　　要在良好的SQL Server方案中实现最优的性能，最关键的是要有1个很好的数据库设计方案。在实际工作中，许多SQL Server方案往往是由于数据库设计得不好导致性能很差。所以，要实现良好的数据库设计就必须考虑这些问题。

　　1.1　逻辑库规范化问题

　　一般来说，逻辑数据库设计会满足规范化的前3级标准:

　　1.第1规范:没有重复的组或多值的列。

　　2.第2规范:每个非关键字段必须依赖于主关键字，不能依赖于1个组合式主关键字的某些组成部分。

　　3.第3规范:1个非关键字段不能依赖于另1个非关键字段。

　　遵守这些规则的设计会产生较少的列和更多的表，因而也就减少了数据冗余，也减少了用于存储数据的页。但表关系也许需要通过复杂的合并来处理，这样会降低系统的性能。某种程度上的非规范化可以改善系统的性能，非规范化过程可以根据性能方面不同的考虑用多种不同的方法进行，但以下方法经实践验证往往能提高性能。

　　1.如果规范化设计产生了许多4路或更多路合并关系，就可以考虑在数据库实体(表)中加入重复属性(列)。

　　2.常用的计算字段(如总计、最大值等)可以考虑存储到数据库实体中。

　　比如某一个项目的计划管理系统中有计划表，其字段为:项目编号、年初计划、二次计划、调整计划、补列计划…，而计划总数(年初计划+二次计划+调整计划+补列计划)是用户经常需要在查询和报表中用到的，在表的记录量很大时，有必要把计划总数作为1个独立的字段加入到表中。这里可以采用触发器以在客户端保持数据的一致性。

　　3.重新定义实体以减少外部属性数据或行数据的开支。相应的非规范化类型是:

　　(1)把1个实体(表)分割成2个表(把所有的属性分成2组)。这样就把频繁被访问的数据同较少被访问的数据分开了。这种方法要求在每个表中复制首要关键字。这样产生的设计有利于并行处理，并将产生列数较少的表。

　　(2)把1个实体(表)分割成2个表(把所有的行分成2组)。这种方法适用于那些将包含大量数据的实体(表)。在应用中常要保留历史记录，但是历史记录很少用到。因此可以把频繁被访问的数据同较少被访问的历史数据分开。而且如果数据行是作为子集被逻辑工作组(部门、销售分区、地理区域等)访问的，那么这种方法也是很有好处的。

　　1.2　生成物理数据库

　　要想正确选择基本物理实现策略，必须懂得数据库访问格式和硬件资源的操作特点，主要是内存和磁盘子系统I/O。这是一个范围广泛的话题，但以下的准则可能会有所帮助。

　　1.与每个表列相关的数据类型应该反映数据所需的最小存储空间，特别是对于被索引的列更是如此。比如能使用smallint类型就不要用integer类型，这样索引字段可以被更快地读取，而且可以在1个数据页上放置更多的数据行，因而也就减少了I/O操作。

　　2.把1个表放在某个物理设备上，再通过SQL Server段把它的不分簇索引放在1个不同的物理设备上，这样能提高性能。尤其是系统采用了多个智能型磁盘控制器和数据分离技术的情况下，这样做的好处更加明显。

　　3.用SQL Server段把一个频繁使用的大表分割开，并放在2个单独的智能型磁盘控制器的数据库设备上，这样也可以提高性能。因为有多个磁头在查找，所以数据分离也能提高性能。

　　4.用SQL Server段把文本或图像列的数据存放在1个单独的物理设备上可以提高性能。1个专用的智能型的控制器能进一步提高性能。

　　2　与SQL Server相关的硬件系统

　　与SQL Server有关的硬件设计包括系统处理器、内存、磁盘子系统和网络，这4个部分基本上构成了硬件平台，Windows NT和SQL Server运行于其上。

　　2.1　系统处理器(CPU)

　　根据自己的具体需要确定CPU结构的过程就是估计在硬件平台上占用CPU的工作量的过程。从以往的经验看，CPU配置最少应是1个80586/100处理器。如果只有2～3个用户，这就足够了，但如果打算支持更多的用户和关键应用，推荐采用Pentium Pro或PⅡ级CPU。

　　2.2　内存(RAM)

　　为SQL Server方案确定合适的内存设置对于实现良好的性能是至关重要的。SQL Server用内存做过程缓存、数据和索引项缓存、静态服务器开支和设置开支。SQL Server最多能利用2GB虚拟内存，这也是最大的设置值。还有一点必须考虑的是Windows NT和它的所有相关的服务也要占用内存。

　　Windows NT为每个WIN32应用程序提供了4GB的虚拟地址空间。这个虚拟地址空间由Windows NT虚拟内存管理器(VMM)映射到物理内存上，在某些硬件平台上可以达到4GB。SQL Server应用程序只知道虚拟地址，所以不能直接访问物理内存，这个访问是由VMM控制的。Windows NT允许产生超出可用的物理内存的虚拟地址空间，这样当给SQL Server分配的虚拟内存多于可用的物理内存时，会降低SQL Server的性能。

　　这些地址空间是专门为SQL Server系统设置的，所以如果在同一硬件平台上还有其它软件(如文件和打印共享，应用程序服务等)在运行，那么应该考虑到它们也占用一部分内存。一般来说硬件平台至少要配置32MB的内存，其中，Windows NT至少要占用16MB。1个简单的法则是，给每一个并发的用户增加100KB的内存。例如，如果有100个并发的用户，则至少需要32MB+100用户*100KB=42MB内存，实际的使用数量还需要根据运行的实际情况调整。可以说，提高内存是提高系统性能的最经济的途径。

　　2.3　磁盘子系统

　　设计1个好的磁盘I/O系统是实现良好的SQL Server方案的一个很重要的方面。这里讨论的磁盘子系统至少有1个磁盘控制设备和1个或多个硬盘单元，还有对磁盘设置和文件系统的考虑。智能型SCSI-2磁盘控制器或磁盘组控制器是不错的选择，其特点如下:

　　(1)控制器高速缓存。

　　(2)总线主板上有处理器，可以减少对系统CPU的中断。

　　(3)异步读写支持。

　　(4)32位RAID支持。

　　(5)快速SCSI—2驱动。

　　(6)超前读高速缓存(至少1个磁道)。

　　3　检索策略

　　在精心选择了硬件平台，又实现了1个良好的数据库方案，并且具备了用户需求和应用方面的知识后，现在应该设计查询和索引了。有2个方面对于在SQL Server上取得良好的查询和索引性能是十分重要的，第1是根据SQL Server优化器方面的知识生成查询和索引;第2是利用SQL Server的性能特点，加强数据访问操作。

　　3.1　SQL Server优化器

　　Microsoft SQL Server数据库内核用1个基于费用的查询优化器自动优化向SQL提交的数据查询操作。数据操作查询是指支持SQL关键字WHERE或HAVING的查询，如SELECT、DELETE和UPDATE。基于费用的查询优化器根据统计信息产生子句的费用估算。

　　了解优化器数据处理过程的简单方法是检测SHOWPLAN命令的输出结果。如果用基于字符的工具(例如isql)，可以通过键入SHOW SHOWPLAN ON来得到SHOWPLAN命令的输出。如果使用图形化查询，比如SQL Enterprise Manager中的查询工具或isql/w，可以设定配置选项来提供这一信息。

　　SQL Server的优化通过3个阶段完成:查询分析、索引选择、合并选择。

　　1.查询分析

　　在查询分析阶段，SQL Server优化器查看每一个由正规查询树代表的子句，并判断它是否能被优化。SQL Server一般会尽量优化那些限制扫描的子句。例如，搜索和/或合并子句。但是不是所有合法的SQL语法都可以分成可优化的子句，如含有SQL不等关系符“<>”的子句。因为“<>”是1个排斥性的操作符，而不是1个包括性的操作符，所在扫描整个表之前无法确定子句的选择范围会有多大。当1个关系型查询中含有不可优化的子句时，执行计划用表扫描来访问查询的这个部分，对于查询树中可优化的SQL Server子句，则由优化器执行索引选择。

　　2.索引选择

　　对于每个可优化的子句，优化器都查看数据库系统表，以确定是否有相关的索引能用于访问数据。只有当索引中的列的1个前缀与查询子句中的列完全匹配时，这个索引才被认为是有用的。因为索引是根据列的顺序构造的，所以要求匹配是精确的匹配。对于分簇索引，原来的数据也是根据索引列顺序排序的。想用索引的次要列访问数据，就像想在电话本中查找所有姓为某个姓氏的条目一样，排序基本上没有什么用，因为你还是得查看每一行以确定它是否符合条件。如果1个子句有可用的索引，那么优化器就会为它确定选择性。

　　所以在设计过程中，要根据查询设计准则仔细检查所有的查询，以查询的优化特点为基础设计索引。

　　(1)比较窄的索引具有比较高的效率。对于比较窄的索引来说，每页上能存放较多的索引行，而且索引的级别也较少。所以，缓存中能放置更多的索引页，这样也减少了I/O操作。

　　(2)SQL Server优化器能分析大量的索引和合并可能性。所以与较少的宽索引相比，较多的窄索引能向优化器提供更多的选择。但是不要保留不必要的索引，因为它们将增加存储和维护的开支。对于复合索引、组合索引或多列索引，SQL Server优化器只保留最重要的列的分布统计信息，这样，索引的第1列应该有很大的选择性。

　　(3)表上的索引过多会影响UPDATE、INSERT和DELETE的性能，因为所有的索引都必须做相应的调整。另外，所有的分页操作都被记录在日志中，这也会增加I/O操作。

　　(4)对1个经常被更新的列建立索引，会严重影响性能。

　　(5)由于存储开支和I/O操作方面的原因，较小的自组索引比较大的索引性能更好一些。但它的缺点是要维护自组的列。

　　(6)尽量分析出每一个重要查询的使用频度，这样可以找出使用最多的索引，然后可以先对这些索引进行适当的优化。

　　(7)查询中的WHERE子句中的任何列都很可能是个索引列，因为优化器重点处理这个子句。

　　(8)对小于1个范围的小型表进行索引是不划算的，因为对于小表来说表扫描往往更快而且费用低。

　　(9)与“ORDER BY”或“GROUP BY”一起使用的列一般适于做分族索引。如果“ORDER BY”命令中用到的列上有分簇索引，那么就不会再生成1个工作表了，因为行已经排序了。“GROUP BY”命令则一定产生1个工作表。

　　(10)分簇索引不应该构造在经常变化的列上，因为这会引起整行的移动。在实现大型交易处理系统时，尤其要注意这一点，因为这些系统中数据往往是频繁变化的。

　　3.合并选择

　　当索引选择结束，并且所有的子句都有了一个基于它们的访问计划的处理费用时，优化器开始执行合并选择。合并选择被用来找出一个用于合并子句访问计划的有效顺序。为了做到这一点，优化器比较子句的不同排序，然后选出从物理磁盘I/O的角度看处理费用最低的合并计划。因为子句组合的数量会随着查询的复杂度极快地增长，SQL Server查询优化器使用树剪枝技术来尽量减少这些比较所带来的开支。当这个合并选择阶段结束时，SQL Server查询优化器已经生成了1个基于费用的查询执行计划，这个计划充分利用了可用的索引，并以最小的系统开支和良好的执行性能访问原来的数据。

　　3.2　高效的查询选择

　　从以上查询优化的3个阶段不难看出，设计出物理I/O和逻辑I/O最少的方案并掌握好处理器时间和I/O时间的平衡，是高效查询设计的主要目标。也就是说，希望设计出这样的查询:充分利用索引、磁盘读写最少、最高效地利用了内存和CPU资源。

　　以下建议是从SQL Server优化器的优化策略中总结出来的，对于设计高效的查询是很有帮助的。

　　1.如果有独特的索引，那么带有“=”操作符的WHERE子句性能最好，其次是封闭的区间(范围)，再其次是开放的区间。

　　2.从数据库访问的角度看，含有不连续连接词(OR和IN)的WHERE子句一般来说性能不会太好。所以，优化器可能会采用R策略，这种策略会生成1个工作表，其中含有每个可能匹配的执行的标识符，优化器把这些行标志符(页号和行号)看做是指向1个表中匹配的行的“动态索引”。优化器只需扫描工作表，取出每一个行标志符，再从数据表中取得相应的行，所以R策略的代价是生成工作表。

　　3.包含NOT、<>、或!　=的WHERE子句对于优化器的索引选择来说没有什么用处。因为这样的子句是排斥性的，而不是包括性的，所以在扫描整个原来数据表之前无法确定子句的选择性。

　　4.限制数据转换和串操作，优化器一般不会根据WHERE子句中的表达式和数据转换式生成索引选择。例如:

　　paycheck * 12>36000 or substring(lastname,1,1)=“L”

　　如果该表建立了针对paycheck和lastname的索引，就不能利用索引进行优化，可以改写上面的条件表达式为:

　　paycheck<36000/12 or lastname like “L%”

　　5.WHERE子句中的本地变量被认为是不被优化器知道和考虑的，例外的情况是定义为储备过程输入参数的变量。

　　6.如果没有包含合并子句的索引，那么优化器构造1个工作表以存放合并中最小的表中的行。然后再在这个表上构造1个分簇索引以完成一个高效的合并。这种作法的代价是工作表的生成和随后的分族索引的生成，这个过程叫REFORMATTING。　　所以应该注意RAM中或磁盘上的数据库tempdb的大小(除了SELECT INTO语句)。另外，如果这些类型的操作是很常见的，那么把tempdb放在RAM中对于提高性能是很有好处的。

　　4　性能优化的其他考虑

　　上面列出了影响SQL Server的一些主要因素，实际上远不止这些。操作系统的影响也很大，在Windows NT下，文件系统的选择、网络协议、开启的服务、SQL Server的优先级等选项也不同程度上影响了SQL Server的性能。

　　影响性能的因素是如此的多，而应用又各不相同，找出1个通用的优化方案是不现实的，在系统开发和维护的过程中必须针对运行的情况，不断加以调整。事实上，绝大部分的优化和调整工作是在与客户端独立的服务器上进行的，因此也是现实可行的。

create user test1 identified by test1;
grant connect,resource to test1;

用test1登陆：

sqlplus test1/test1

CREATE procedure main_table_pwqzc
(@pagesize int,
@pageindex int,
@docount bit,
@this_id int)
as
if(@docount=1)
begin
select count(id) from luntan where this_id=@this_id
end
else
begin
declare @PageLowerBound int
declare @PageUpperBound int
set @PageLowerBound=(@pageindex-1)*@pagesize
set @PageUpperBound=@PageLowerBound+@pagesize
create table #pageindex(id int identity(1,1) not null,nid int)
set rowcount @PageUpperBound
insert into #pageindex(nid)
select id from luntan where this_id=@this_id order by reply_time desc
select O.*
from luntan O,#pageindex p
where O.id=p.nid and p.id>@PageLowerBound and p.id<=@PageUpperBound order by p.id
end
GO

存储过程会根据传入的参数@docount来确定是不是要返回所有要分页的记录总数
特别是这两行
set rowcount @PageUpperBound
insert into @indextable(nid) select id from luntan where this_id=@this_id order by reply_time desc

真的是妙不可言!!set rowcount @PageUpperBound当记录数达到@PageUpperBound时就会停止处理查询
,select id 只把id列取出放到临时表里,select a.* from luntan a,@indextable t where a.id=t.nid
and t.id>@PageLowerBound and t.id<=@PageUpperBound order by t.id
而这句也只从表中取出所需要的记录,而不是所有的记录,结合起来,极大的提高了效率!!

（2）

CREATE PROCEDURE Paging_RowCount
(
@Tables varchar(1000),
@PK varchar(100),
@Sort varchar(200) = NULL,
@PageNumber int = 1,
@PageSize int = 10,
@Fields varchar(1000) = '*',
@Filter varchar(1000) = NULL,
@Group varchar(1000) = NULL)
AS

/**//*Default Sorting*/
IF @Sort IS NULL OR @Sort = ''
    SET @Sort = @PK

/**//*Find the @PK type*/
DECLARE @SortTable varchar(100)
DECLARE @SortName varchar(100)
DECLARE @strSortColumn varchar(200)
DECLARE @operator char(2)
DECLARE @type varchar(100)
DECLARE @prec int

/**//*Set sorting variables.*/    
IF CHARINDEX('DESC',@Sort)>0
    BEGIN
        SET @strSortColumn = REPLACE(@Sort, 'DESC', '')
        SET @operator = '<='
    END
ELSE
    BEGIN
        IF CHARINDEX('ASC', @Sort) = 0
            SET @strSortColumn = REPLACE(@Sort, 'ASC', '')
        SET @operator = '>='
    END


IF CHARINDEX('.', @strSortColumn) > 0
    BEGIN
        SET @SortTable = SUBSTRING(@strSortColumn, 0, CHARINDEX('.',@strSortColumn))
        SET @SortName = SUBSTRING(@strSortColumn, CHARINDEX('.',@strSortColumn) + 1, LEN(@strSortColumn))
    END
ELSE
    BEGIN
        SET @SortTable = @Tables
        SET @SortName = @strSortColumn
    END

SELECT @type=t.name, @prec=c.prec
FROM sysobjects o 
JOIN syscolumns c on o.id=c.id
JOIN systypes t on c.xusertype=t.xusertype
WHERE o.name = @SortTable AND c.name = @SortName

IF CHARINDEX('char', @type) > 0
   SET @type = @type + '(' + CAST(@prec AS varchar) + ')'

DECLARE @strPageSize varchar(50)
DECLARE @strStartRow varchar(50)
DECLARE @strFilter varchar(1000)
DECLARE @strSimpleFilter varchar(1000)
DECLARE @strGroup varchar(1000)

/**//*Default Page Number*/
IF @PageNumber < 1
    SET @PageNumber = 1

/**//*Set paging variables.*/
SET @strPageSize = CAST(@PageSize AS varchar(50))
SET @strStartRow = CAST(((@PageNumber - 1)*@PageSize + 1) AS varchar(50))

/**//*Set filter & group variables.*/
IF @Filter IS NOT NULL AND @Filter != ''
    BEGIN
        SET @strFilter = ' WHERE ' + @Filter + ' '
        SET @strSimpleFilter = ' AND ' + @Filter + ' '
    END
ELSE
    BEGIN
        SET @strSimpleFilter = ''
        SET @strFilter = ''
    END
IF @Group IS NOT NULL AND @Group != ''
    SET @strGroup = ' GROUP BY ' + @Group + ' '
ELSE
    SET @strGroup = ''
    
/**//*Execute dynamic query*/    
EXEC(
'
DECLARE @SortColumn ' + @type + '
SET ROWCOUNT ' + @strStartRow + '
SELECT @SortColumn=' + @strSortColumn + ' FROM ' + @Tables + @strFilter + ' ' + @strGroup + ' ORDER BY ' + @Sort + '
SET ROWCOUNT ' + @strPageSize + '
SELECT ' + @Fields + ' FROM ' + @Tables + ' WHERE ' + @strSortColumn + @operator + ' @SortColumn ' + @strSimpleFilter + ' ' + @strGroup + ' ORDER BY ' + @Sort + '
'
)
GO