페이지 공통 스토리지 프로세스(검증되지 않음)

이것은 인터넷에서 본 페이지 저장 과정으로 정리한 다음에 틈이 나면 다시 시도해 보자.대형 데이터베이스에 적용된다면서요?

 1 CREATE PROCEDURE pagination3 

 2 @tblName varchar(255),                    --    

 3 @strGetFields varchar(1000) = '*',        --         

 4 

 5 @fldName varchar(255)='',                --        

 6 @PageSize int = 10,                        --    （     ） 

 7 @PageIndex int = 1,                        --    

 8 @doCount bit = 0,                        --       ,  0        

 9 @OrderType bit = 0,                        --       ,  0     

10 @strWhere  varchar(1500) = ''            --      (  :     where) 

11 AS 

12 declare @strSQL   varchar(5000)            --     

13 declare @strTmp   varchar(110)            --      

14 declare @strOrder varchar(400)            --       

15 if @doCount != 0

16     begin 

17         if @strWhere !='' 

18            set @strSQL = 'select count(*) as Total from [' + @tblName + '] where '+@strWhere

19         else 

20            set @strSQL = 'select count(*) as Total from [' + @tblName + ']' 

21     end                            -->           @doCount       0，       。         @doCount 0    

22 else 

23     begin

24     if @OrderType != 0            -->   (desc) 

25     begin 

26         set @strTmp = '<(select min' 

27         set @strOrder = ' order by [' + @fldName +'] desc' --  @OrderType  0，     ，     ！ 

28     end 

29     else                        -->   (asc) 

30     begin 

31         set @strTmp = '>(select max' 

32         set @strOrder = ' order by [' + @fldName +'] asc' 

33     end

34 

35     if @PageIndex = 1            -->    

36         begin 

37         if @strWhere != ''    

38             set @strSQL = 'select top ' +str(@PageSize)+ ' ' +@strGetFields+ ' from [' + @tblName + '] where ' + @strWhere + ' ' + @strOrder

39         else 

40             set @strSQL = 'select top ' +str(@PageSize)+' ' +@strGetFields+ '  from [' +@tblName+ '] ' +@strOrder --             ，          

41         end 

42     else 

43     begin                        --       @strSQL      SQL   

44         set @strSQL = 'select top ' +str(@PageSize)+ ' ' +@strGetFields+ '  from [' +@tblName+ '] where [' +@fldName+ ']' +@strTmp+ '([' +@fldName+ ']) from (select top ' +str((@PageIndex-1)*@PageSize)+ ' [' +@fldName+ '] from [' +@tblName+ ']' +@strOrder+ ') as tblTmp)' +@strOrder  

45         if @strWhere != '' 

46             set @strSQL ='select top ' +str(@PageSize)+ ' ' +@strGetFields+ '  from [' +@tblName+ '] where [' +@fldName+ ']' +@strTmp+ '([' +@fldName+ ']) from (select top ' +str((@PageIndex-1)*@PageSize) + ' [' +@fldName+ '] from [' +@tblName+ '] where ' +@strWhere+ ' ' +@strOrder+ ') as tblTmp) and ' +@strWhere+ ' ' +@strOrder 

47         end  

48     end    

49 exec (@strSQL) 

50 GO

 
위의 이 저장 프로세스는 일반적인 저장 프로세스로 주석이 이미 그 안에 쓰여 있다.  

select top     * from table1  where id > 

      (select max (id) from  

      (select top ((  -1)*   ) id from table1 order by id) as T        )      

order by id  

빅데이터의 경우 특히 마지막 몇 페이지를 조회할 때 조회 시간은 일반적으로 9초를 넘지 않는다.다른 저장 프로세스를 사용하면 실천 과정에서 시간 초과를 초래하기 때문에 이 저장 과정은 대용량 데이터베이스 조회에 매우 적합하다.
 
그러나 이 저장 프로세스를'사무 자동화'시스템에 응용한 실천에서 필자는 이 세 번째 저장 과정이 작은 데이터 양의 상황에서 다음과 같은 현상이 있음을 발견했다. 1. 페이지 속도는 일반적으로 1초와 3초 사이를 유지한다.2. 마지막 페이지를 조회할 때 속도는 보통 5초에서 8초로 전체 페이지가 3페이지나 30만 페이지만 있어도 된다.초대용량 상황에서 이 페이지의 실현 과정은 매우 빠르지만 몇 페이지 전에 이 1-3초의 속도는 첫 번째 최적화되지 않은 페이지의 방법보다 속도가 더 느리다. 사용자를 빌리는 말은'아직 ACCESS 데이터베이스 속도가 빠르지 않다'는 것이다. 이 인식은 사용자가 개발한 시스템을 사용하는 것을 포기하게 하기에 충분하다.필자는 이에 대해 분석했다. 원래 이런 현상이 발생한 문제점은 이렇게 간단하지만 또 이렇게 중요하다. 정렬된 필드는 색인을 모으는 것이 아니다!
색인을 모으는 데는 두 가지 가장 큰 장점이 있다. 첫째, 가장 빠른 속도로 조회 범위를 좁히는 것이다. 
2. 가장 빠른 속도로 필드를 정렬한다.제1조는 조회 최적화에 많이 쓰이고 제2조는 페이지를 나눌 때의 데이터 정렬에 많이 쓰인다. 
집합 인덱스는 표마다 하나만 만들 수 있기 때문에 집합 인덱스가 더욱 중요하다.색인을 모으는 선택은'조회 최적화'와'효율적인 페이지 나누기'를 실현하는 가장 관건적인 요소라고 할 수 있다.그러나 집합 색인열이 조회열의 수요에 부합되고, 정렬의 수요에 부합되도록 하려면, 이것은 통상적으로 모순이다.필자의 앞에서'인덱스'에 대한 토론에서fariqi, 즉 사용자의 발문 날짜를 인덱스 집합의 시작열로 하고 날짜의 정확도는'일'이다.이런 작법의 장점은 앞에서 언급한 바와 같이 시간대를 긋는 빠른 조회를 하는 데 ID 메인 키열로 하는 것보다 큰 장점이 있다.그러나 페이지를 나눌 때 이 집합 색인열에 중복 기록이 존재하기 때문에 max나min을 가장 페이지를 나누는 참조물로 사용할 수 없기 때문에 더욱 효율적인 정렬을 실현할 수 없다.만약에 ID 키 열을 집합 인덱스로 사용한다면 집합 인덱스는 정렬을 제외하고는 아무 소용이 없고 실제로는 집합 인덱스라는 귀중한 자원을 낭비하는 것이다.이 모순을 해결하기 위해 필자는 나중에 날짜열을 추가했는데 기본값은 getdate () 이다.사용자가 기록을 쓸 때, 이 열은 자동으로 당시의 시간을 쓰고, 시간은 밀리초까지 정확하다.그럼에도 불구하고 가능한 일치를 방지하기 위해 이 열에 UNIQUE 구속조건을 작성합니다.이 날짜 열을 집합 색인 열로 사용합니다.이 시간형 색인열이 생기면 사용자는 이 열로 사용자가 데이터를 삽입할 때의 특정한 시간대의 조회를 찾을 수 있을 뿐만 아니라 유일한 열로 max나min을 실현하여 페이지 알고리즘의 참조물이 될 수 있다.이러한 최적화를 통해 필자는 빅데이터 양이든 작은 데이터 양이든 페이지의 속도는 일반적으로 몇 십 밀리초, 심지어 0 밀리초라는 것을 발견했다.날짜로 범위를 좁히는 검색 속도는 원래보다 둔하지 않았다.집합 인덱스는 이렇게 중요하고 소중하기 때문에 필자는 반드시 집합 인덱스를 다음과 같이 세워야 한다. 1. 당신이 가장 자주 사용하는 검색 범위를 좁히는 필드에 사용해야 한다.2. 가장 자주 사용하는 정렬이 필요한 필드에 있습니다.