as
set nocount on
create table TableSpace
(
TableName varchar(50),
RowsCount char(11),
Reserved varchar(18),
Data varchar(18),
Index_size varchar(18),
Unused varchar(18)
)
declare @sql varchar(500)
declare @TableName varchar(50)
declare Cursor1 Cursor
for
select name from sysobjects where xtype='U'
open Cursor1
fetch next from Cursor1 into @TableName
while @@fetch_status = 0
begin
set @sql = 'insert into TableSpace '
set @sql = @sql + ' exec sp_spaceused '''+ @TableName + ''' '
exec (@sql)
fetch next from Cursor1 into @TableName
end
close Cursor1
deallocate Cursor1
select tableName,rowscount from TableSpace where tableName<>'TableSpace'
order by rowscount desc
drop table TableSpace
go
exec ss
]]>
SELECT DATE, A.G, A.I, A.V, A.O, A.SC, A.LR, A.PR, A.HL FROM ( select date,PNLID, judge FROM dbo.RCI_LOI2MOVEMENT)BPIVOT (COUNT(PNLID) FOR judge IN(G, I, V, O, SC, LR, PR, HL )) AWHERE DATE >= '2007-4-5' AND DATE <= '2007-4-11']]>
SELECT * FROM( SELECT ROW_NUMBER() OVER(ORDER BY DATE) ROWNUM, * FROM BAS_CALENDAR) CALWHERE ROWNUM BETWEEN (50*1)+1 AND 50*2ORDER BY DATE ASC开发圣l上的示例代?br>
CREATE PROC spGetPages2 @iRowCount INT, @iRowPageNo INTASSELECT * FROM (SELECT ROW_NUMBER() OVER(ORDER BY ProductID ASC) RowNum, * FROM Production.Product ) OrderDataWHERE RowNum BETWEEN @iRowCount*(@iPageNo-1)+1 and @iRowCount*@iPageNoORDER BY ProductID ASCGOEXEC spGetPages2 10,20]]>
pagesizeQ?每页昄记录?br />cureentpageQ当前页?/p>
select * from ( select TOP pagesize * FROM ( SELECT TOP pagesize*cureentpage * from user_table ORDER BY id ASC ) as aSysTable ORDER BY id DESC ) as bSysTable ORDER BY id ASC
例子说明Q?/p>
假如数据库表如下Q?/p>
user_table:
id:主键Q自?br />username:字符
password:字符
假设?0条记录，每页昄10条记录，id ??0
现在按照id升序排列取出W三늚数据应该为：所取得记录的id 应该?21?0?/p>
q时该语句应该ؓQ?/p>
select * from ( select TOP 10 * FROM ( SELECT TOP 30 * from user_table ORDER BY id ASC ) as aSysTable ORDER BY id DESC ) as bSysTable ORDER BY id ASC
原理如下Q?/p>
先按照id从小到大升序取出30条记录（3*10Q?也就是：id ?1-30 之间的记?QSELECT TOP 30 * from user_table ORDER BY id ASCQ?/p>
然后按照ID降序排列q?0条记录，得到记录为id 在：?0?1
然后在这?0条记录中取出?0条记录：取得的记录ؓQid ?0-21之间。这是我们需要的数据Q但q时是按照降序排列的Q不W合要求?/p>
最后在重新排序得到最l我们需要的数据。id?1-30之间?/p>
下面的代码示例都以下面的表结构ؓ准：
| Articles ?/td> | SQL Server cd | Oracle cd | |
| PK | Id | int (自增) | number(9) (插入时在当前最大g?) |
| Author | nvarchar(10) | nvarchar2(10) | |
| Title | nvarchar(50) | nvarchar2(50) | |
| PubTime | datetime | date |
SQL Server / Access {微软品中Q我们通常的自定义分页有两U思\Q?/p>
一U是?ASP.NET Forum Z表的、“时表”方法：卛_存储q程中徏立一个时表Q该临时表包含一个序号字D（1Q?Q?Q?...Q以及表的主键（其他能够唯一定一行记录的字段也是可以的）字段。存储过E可能如下：Q编?SS1Q?/font>
(
@PageIndex int,
@PageSize int,
@TotalRecords out int,
@TotalPages out int
)
AS
DECLARE @PageLowerBound int
DECLARE @PageUpperBound int
-- Set the page bounds
SET @PageLowerBound = @PageSize * @PageIndex
SET @PageUpperBound = @PageLowerBound + @PageSize + 1
-- Create a temp table to store the select results
CREATE TABLE #tmp
(
RecNo int IDENTITY (1, 1) NOT NULL,
ArticleID int
)
INSERT INTO #tmp
SELECT [ID]
FROM Articles
ORDER BY PubTime DESC
SELECT A.*
FROM Articles A (nolock), #tmp T
WHERE A.ID = T.ArticleID AND
T.RecNo > @PageLowerBound AND
T.RecNo < @PageUpperBound
ORDER BY T.RecNo
GO
另一U可能更适合E序中“拼凑?SQL 语句Q用两次 TOP 命o取得我们所要的分页数据Q例如：Q编?SS2Q?/font>
(
SELECT TOP(PageSize) * FROM
(
SELECT TOP (PageSize * PageIndex) *
FROM Articles
ORDER BY PubTime DESC
)
ORDER BY PubTime ASC
)
ORDER BY PubTime DESC
q个的想法就是“掐头去䏀，q有不少分页的方法，q里׃一一列出了?/p>
对于 Oracle 数据库，有几处不同严重妨了上面几个Ҏ的实施，比如QOracle 不支?TOP 关键字：不过q个好像q不十分严重Q因为它提供?rownum q个隐式游标Q可以实C TOP cM的功能，如：
要写?/p>
rownum 是记录序P1Q?Q?...Q，但有一个比较麻烦的事情是：如果 SQL 语句中有 ORDER BY ... 排序的时候，rownum 居然是先“标号”后排序Q这Pq个序号如果不加处理是不合乎使用需求的?/p>
至于临时表，Oracle 的时表?SQL Server 的有很大不同Q我q没搞懂q个东西Q就不妄加揣了?/p>
国内|站中介l?Oracle 分页的资料很，我找C一个国外站点（www.faqts.comQ的一?FAQQ根据这文章的介绍Q可以如下分：Q编?Ora1Q?/font>
(
SELECT A.*, rownum r
FROM
(
SELECT *
FROM Articles
ORDER BY PubTime DESC
) A
WHERE rownum <= PageUpperBound
) B
WHERE r > PageLowerBound;
其中蓝色部分可以改ؓL的、需要的 SQL SELECT 语句Q这点倒是挺方便的?/p>
]]>
DataGrid control in the ASP.NET simplifies this to a few lines of code. So, the paging is easy in ASP.NET, but the default behavior of the DataGrid is that all resulting records from your query will be fetched from SQL server to the ASP.NET application. If your query returns a million records this will cause some serious performance issues (if you need convincing, try executing such a query in your web application and see the memory consumption of the aspnet_wp.exe in the task manager). That's why a custom paging solution is required where desired behavior is to fetch only the rows from the current page.
There are numerous articles and posts concerning this problem and several proposed solutions. My goal here is not to present you with an amazing solves-it-all procedure, but to optimize all the existing methods and provide you with a testing application so you can do evaluation on your own. Here is a good starting point article which describes many different approaches and provides some performance test results:
How do I page through a recordset?
I was not satisfied with the most of them. First, half of the methods use old ADO and are clearly written for the "old" ASP. The rest of the methods are SQL server stored procedures. Some of them yield poor response times as you can see from the author’s performance results at the bottom of the page, but several have caught my attention.
Generalization
The three methods I decided to closely look into are the ones the author calls TempTable, DynamicSQL and Rowcount. I'll refer to the second method as the Asc-Desc method in the rest of this text. I don't think DynamicSQL was a good name, because you can apply dynamic SQL logic to the other methods too. The general problem with all these stored procedures is that you have to assess which columns you'll allow sorting for and that won't probably be just the PK column(s). This leads to a new set of problems ?for each query you want to display via paging you must have as many different paging queries as you have different sorting columns. This means that you will either have a different stored procedure (regardless of the paging method applied) for each sorting column or you'll try to generalize this to only one stored procedure with the help of dynamic SQL. This has a slight performance impact, but increases maintainability if you need to display many different queries using this approach. Thus, I’ll try to generalize all of the stored procedures in this text with dynamic SQL, but in some cases it will be possible to achieve only a certain level of generalization, so you’ll still have to write separate stored procedures for some complex queries.
The second problem with allowing other sorting columns beside the PK column(s) is that if those columns are not indexed in some way, none of these methods will help. In all of them a paged source must be sorted first and the cost of using ordering by non-indexed column is immense for large tables. The response times are so high that all the procedures are practically unusable in this case (the response varies from couple of seconds to couple of minutes depending on the size of the tables and the starting record being fetched). The indexing of other columns brings more performance issues and may be undesirable, for example it might significantly slow you down in a situation where you have a lot of daily imports.
TempTable
The first one I would comment on is the TempTable method. This is actually a widely proposed solution and I encountered it several times. Here is another article that describes it along with the explanation and a sample how to use custom paging with the DataGrid:
ASP.NET DataGrid Paging Part 2 - Custom Paging
The methods in both articles could be optimized with just the Primary Key data copied to the temp table and then doing the join with the main query. Therefore, the essence of this method would be the following
CREATE
TABLE #Temp (
ID intIDENTITYPRIMARYKEY,
PK /* here goes PK type */
)
INSERTINTO #Temp SELECT PK FROM Table ORDERBY SortColumn
SELECT ... FROM Table JOIN #Temp temp ON Table.PK = temp.PK ORDERBY temp.ID
WHERE ID > @StartRow AND ID < @EndRow
The method can be optimized further by copying the rows to the temp table until the end paging row is reached (SELECT TOP EndRow...), but the point is that in the worst case ?for a table with 1 million records you end up with 1 million records in a temp table as well. Considering all this and having looked upon the results in the article above, I decided to discard this method from my tests.
Asc-Desc
This method uses default ordering in a subquery and then applies the reverse ordering. The principle goes like this
DECLARE @temp TABLE (
PK /* PK Type */ NOTNULLPRIMARY
)
INSERTINTO @temp
SELECT TOP @PageSize PK FROM (
SELECT TOP (@StartRow + @PageSize)
PK,
SortColumn /*If sorting column is defferent from the PK, SortColumn must
be fetched as well, otherwise just the PK is necessary */
ORDERBY SortColumn /* default order ?typically ASC */)
ORDERBY SortColumn /* reversed default order ?typically DESC */
SELECT ... FROM Table JOIN @Temp temp ON Table.PK = temp.PK
ORDERBY SortColumn /* default order */Full Code ?Paging_Asc_DescRowCount
The base logic of this method relies on the SQL SET ROWCOUNT expression to both skip the unwanted rows and fetch the desired ones:
DECLARE @Sort /* the type of the sorting column */
SET ROWCOUNT @StartRow
SELECT @Sort = SortColumn FROM Table ORDERBY SortColumn
SET ROWCOUNT @PageSize
SELECT ... FROM Table WHERE SortColumn >= @Sort ORDERBY SortColumnFull Code ?Paging_RowCountSubQuery
There are 2 more methods I’ve taken into consideration, and they come from different resources. The first one is well known triple query or the SubQuery method. The most thorough approach is the one I’ve found in the following article
Server-Side Paging with SQL Server
Although you'll need to be subscribed, a .zip file with the SubQuery stored procedure variations is available. The Listing_04.SELECT_WITH_PAGINGStoredProcedure.txt file contains the complete generalized dynamic SQL. I used a similar generalization logic with all other stored procedures in this text. Here is the principle followed by the link to the whole procedure (I shortened the original code a bit, because a recordcount portion was unnecessary for my testing purposes).
SELECT ... FROM Table WHERE PK IN
(SELECT TOP @PageSize PK FROM Table WHERE PK NOT IN
(SELECT TOP @StartRow PK FROM Table ORDERBY SortColumn)
ORDERBY SortColumn)
ORDERBY SortColumnFull Code ?Paging_SubQueryCursor
I’ve found the last method while browsing through the Google groups, you can find the original thread here. This method uses a server-side dynamic cursor. A lot of people tend to avoid cursors, they usually have poor performance because of their non-relational, sequential nature. The thing is that paging IS a sequential task and whatever method you use you have to somehow reach the starting row. In all the previous methods this is done by selecting all rows preceding the starting row plus the desired rows and then discarding all the preceding rows. Dynamic cursor has the FETCH RELATIVE option which does the “magic?jump. The base logic goes like this
DECLARE @PK /* PK Type */
DECLARE @tblPK TABLE (
PK /* PK Type */ NOTNULLPRIMARYKEY
)
DECLARE PagingCursor CURSOR DYNAMIC READ_ONLY FOR
SELECT @PK FROM Table ORDERBY SortColumn
OPEN PagingCursor
FETCH RELATIVE @StartRow FROM PagingCursor INTO @PK
WHILE @PageSize > 0AND @@FETCH_STATUS = 0BEGININSERT @tblPK(PK) VALUES(@PK)
FETCH NEXT FROM PagingCursor INTO @PK
SET @PageSize = @PageSize - 1END
CLOSE PagingCursor
DEALLOCATE PagingCursor
SELECT ... FROM Table JOIN @tblPK temp ON Table.PK = temp.PK
ORDERBY SortColumnFull Code ?Paging_CursorGeneralization of Complex Queries
As pointed out before, all the procedures are generalized with dynamic SQL, thus, in theory, they can work with any kind of complex query. Here is a complex query sample that works with Northwind database.
SELECT Customers.ContactName AS Customer,
Customers.Address + ', ' + Customers.City + ', ' +
Customers.Country AS Address,
SUM([Order Details].UnitPrice*[Order Details].Quantity) AS
[Total money spent]
FROM Customers
INNERJOIN Orders ON Customers.CustomerID = Orders.CustomerID
INNERJOIN [Order Details] ON Orders.OrderID = [Order Details].OrderID
WHERE Customers.Country <> 'USA' AND Customers.Country <> 'Mexico'
GROUPBY Customers.ContactName, Customers.Address, Customers.City,
Customers.Country
HAVING (SUM([Order Details].UnitPrice*[Order Details].Quantity))>1000ORDERBY Customer DESC, Address DESCThe paging stored procedure call that returns the second page looks like this EXEC ProcedureName
/* Tables */
'Customers
INNERJOIN Orders ON Customers.CustomerID = Orders.CustomerID
INNERJOIN [Order Details] ON Orders.OrderID = [Order Details].OrderID',
/* PK */
'Customers.CustomerID',
/* ORDERBY */
'Customers.ContactName DESC, Customers.Address DESC',
/* PageNumber */
2,
/* Page Size */
10,
/* Fields */
'Customers.ContactName AS Customer,
Customers.Address + '', '' + Customers.City + '', '' + Customers.Country
AS Address,
SUM([Order Details].UnitPrice*[Order Details].Quantity) AS [Total money spent]',
/* Filter */
'Customers.Country <> ''USA'' AND Customers.Country <> ''Mexico''',
/*Group By*/
'Customers.CustomerID, Customers.ContactName, Customers.Address,
Customers.City, Customers.Country
HAVING (SUM([Order Details].UnitPrice*[Order Details].Quantity))>1000'Note that in the original query, aliases are used in the ORDER BY clause. You can't do that in paging procedures, because the most time-consuming task in all of them is skipping rows preceding the starting row. This is done in various ways, but the principle is not to fetch all the required fields at first, but only the PK column(s) (in case of RowCount method the sorting column), which speeds up this task. All required fields are fetched only for the rows that belong to the requested page. Therefore, field aliases don't exist until the final query, and sorting columns have to be used earlier (in row skipping queries).
The RowCount procedure has another problem, it is generalized to work with only one column in the ORDER BY clause. The same goes for Asc-Desc and Cursor methods, though they can work with several ordering columns, but require that only one column is included in the PK. I guess this could be solved with more dynamic SQL, but in my opinion it is not worth the fuss. Although these situations are highly possible, they are not that frequent. Even if they are, you can always write a separate paging procedure following the principles above.
Performance Testing
I used these 4 methods in my tests, if you have a better one, I’d be glad to know about it. Nevertheless, I wanted to compare these methods and measure their performance. The first thought was to write an ASP.NET test application with paged DataGrid and then measure page response. Still, this wouldn’t reflect the true response time of the stored procedures, so the console application seemed more appropriate. I also included a web application, not for performance testing, but rather as an example of how DataGrid custom paging works with these stored procedures. They are both incorporated in the PagingTest Solution.
I used the auto generated large table for my tests and inserted around 500 000 records in it. If you don’t have a large table to experiment on, you can download the script for a table design and stored procedure for data generation here. I didn't want an identity column for my PK, I used the uniqueidentifier instead. If you'll use this script, you may consider to add an identity after you generate the table. It will add numbers sorted by PK and you'll have an indication that correct page is fetched when you call a paging procedure with PK sorting.
The idea behind performance testing was to call a specific stored procedure many times through a loop and then measure the average response time. Also, in order to remove caching deviations and to model the real situation more accurately ?multiple calls to a stored proc with the same page fetched each time seemed inappropriate. Thus, a random sequence of the same stored procedure with a set of different page numbers was required. Of course, a set of different page numbers assumes fixed number of pages (10 ?20) where each page would be fetched many times, but in a random sequence.
It’s not hard to notice that response times depend on the distance of the fetched page from the beginning of the resultset. The further the starting record is, more records need to be skipped. This is the reason I didn’t include first 20 pages in my random sequence. Instead I used the set of 2N pages. A loop was set to a (number of different pages)*1000. So, every page was fetched around 1000 times (more or less because of a random distribution).
Results
Here are the results I've got - Paging_Results (MS Excell file)
Conclusion
The methods performed in the following order, starting from the best one - RowCount, Cursor, Asc-Desc and Subquery. The behavior in the lower portion was especially interesting, because in many real situations you'll browse beyond the first five pages rarely, so the Subquery method might satisfy your needs in those cases. It all depends on the size of your resultset and the prediction how frequently will the distant pages be fetched. You might use the combination of methods as well. As for myself, I decided to use the RowCount method wherever possible. It beaves quite nice, even for the first page. The "wherever possible" part stands for some cases where it's hard to generalize this method, then I would use the Cursor (possibly combined with the SubQuery for the first couple of pages).
Update 2004-05-05
The main reason I wrote this article was the feedback from the vast programming community. In a couple of weeks I'll be starting work on a new project. The preliminary analysis showed that there's going to be a couple of very large tables involved. These tables will be used in many complex joined queries and their results will be displayed in the ASP.NET application (with sorting and paging enabled). That's why I invested some time in research and pursue for the best paging method. It wasn't just the performance that interested me, but also the usability and maintainability.
Now the invested time has started to pay off already. You can find a post by C. v. Berkel below (many thanks) in which he found a flaw in the RowCount method. It won't work correctly if the sorting column is not unique. The RowCount method performed the best in my tests, but now I am seriously considering not using it at all. In most cases sorting columns (besides the PK) won't be unique. This leaves me with the Cursor method as the fastest and applicable to most situations. It can be combined with the SubQuery method for the first couple of pages and possibly with the RowCount method for unique sorting columns.
Another thing which may be worth mentioning is that there's a tiny flaw in the Asc-Desc method as well. It always returns the PageSize number of records for the last page and not the actual number (which may be lower than the PageSize). The correct number can be calculated but since I don't intend to use this procedure (because of how it performed), I didn't want to improve it any further.
http://www.codeproject.com/aspnet/PagingLarge.asp
]]>
对于带滚动条的表|数据是一一顺序滚动，即拖动滚动条，也可以一页滚动到所选的位置Q当拖动C个新|的算法ؓ
select top 大?* from 表名 where 主键 > 上一|记录的主?order by 主键
]]>