Cursor best performance is improved technique: when using a cursor to be avoided.
- Excerpt from "Transact-SQL authoritative guide" Ken Henderson [with]
Cursor best performance is improved technique: when using a cursor to be avoided. SQL Server is a relational database that processes the data set is much better than dealing with a single line, single access line does not fit relationship DBMS. If it can not be avoided when using a cursor, you can optimize the performance of the cursor with the following tips.
(1) Unless otherwise do not need to use static / insensitive cursor. Open the static cursor will cause all rows are copied to a temporary table. This is the reason why it is not sensitive to changes - it is actually pointing to a temporary backup of the database table. Naturally, the larger the result set, statement on the static cursor will lead to more resource contention temporary database problem.
(2) Unless otherwise you do not need to use keyset cursors. And static cursors, like, open keyset cursor creates temporary tables. Although this list includes only one key column of the base table (unless there is no unique key), but when dealing with large result sets still quite large.
(3) When processing the read-only unidirectional result set, instead of using fast_forward FORWARD_ONLY. Use fast_forward define a forward_only, the cursor has a certain internal read_only performance optimization.
(4) Using read_only keyword defines a read-only cursors. This prevents accidental modification, and let the server does not modify the line to know when the cursor is moved.
(5) A large number of rows through the cursor carefully modified transaction. According remain locked before the transaction isolation level, these rows or rollback transaction is completed, which may cause resource contention on the server.
. (6) Be careful dynamic cursor changes, especially built on non-unique clustered index key table of the cursor, because they will cause the "Halloween" problem - repeat mistakes of the same row or line changes. Because SQL Server later modified to a value that already exists in a row inside keyword will, and forced an additional index server, you can then move the result set. When the access from the remaining items in the result set, will encounter the line, then the program is repeated, resulting in an infinite loop.
(7) For large result sets to consider using the asynchronous cursor, as much as possible to control to the caller. When returning a large result set to the movable table, asynchronous cursor is particularly useful, because they allow an application to display the line almost immediately.
Halloween:
CREATE Table #T(
k1 int, that to Top identity (1,1),,
c1 int null
);
CREATE CLUSTERED INDEX C1 ON #T(C1);
INSERT INTO #T(C1) VALUES(8)
INSERT INTO #T(C1) VALUES(6)
INSERT INTO #T(C1) VALUES(7)
INSERT INTO #T(C1) VALUES(5)
INSERT INTO #T(C1) VALUES(3)
INSERT INTO #T(C1) VALUES(0)
INSERT INTO #T(C1) VALUES(9)
DECLARE C CURSOR DYNAMIC
FOR SELECT K1,C1 FROM #T;
OPEN C
FETCH C
WHILE(@@FETCH_Status=0)
BEGIN
UPDATE #T SET C1=C1+1
WHERE CURRENT OF C;
FETCH C;
END
CLOSE C;
DEALLOCATE C;
DROP Table #T;
GO
Reproduced in: https: //www.cnblogs.com/happyhippy/archive/2009/03/29/1424441.html