『壹』 如果在資料庫中有大數據量，而我們用分頁存儲過程，怎麼樣才能效率高
--------------------------------
--關於分頁儲存的效率問題
--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.對查詢進行優化，應盡量避免全表掃描，首先應考慮在 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