1. a transaction is as short as possible;
Default under TIL (Read Commited), after opening the transaction, the session will continue to update possession exclusive lock until the transaction is committed or rolled back; the transactions as short as possible to reduce the time to hold resources, freeing resources as soon as possible used for other sessions;
2. Try to avoid read operations in a transaction;
Will read resources shared locks, shared locks and exclusive locks are not compatible, transaction read operation may be blocked, which led to the current session held at the same time is blocked waiting for resources, events transaction execution will extend and increase deadlock the probability;
may need to use the data to be read out, and then open the transaction;
If you can not avoid, you can try a read operation on the table plus tips with (nolock). (Note: with nolock may lead to dirty read);
3. Do not wait for the transaction during the interaction with the user;
With (1); user may drink tea or smoke went up, answer it may have been held resources, if people want to use the resources to do so, we would not be able to work.
4. Use caution no operation log
Some operations will be some performance cost, such as SELECT ... .INTO would have been completed before locking the system tables;
The possible use of lower TIL
The default is Read Commited; can be modified by the SET TRANSACTION ISOLATION LEVEL.
But we know that different isolation levels may also lead to side effects: (from SQL Server Books Online)
6. try to make the modified data in the transaction happened
The modified data as little as possible to reduce the number of rows locked, thereby reducing competition for resources between the transaction;
establish an appropriate index, reducing lock granularity, reducing competition for resources between the transaction; (indexing of course there are side effects, could not be built good, it will affect the performance of the CRUD);
considering whether a redo operation, if the cause can be redone without dirty data words (or dirty data does not affect the service data, allowing dirty data is present), the operation can be conveyed to do outside of a transaction. To delete a physical quantities such as batch records and corresponding details; the surface, in order to maintain data consistency, you want to put these operational matters inside; but in fact can not explicitly use transactions: first delete details, and then delete the master record; not explicitly maintain a transaction if the delete fails, the next one and then delete the line.
7. Unless really need, do not use the implicit transaction, even if have to be careful monitoring.
(Form SQL Server Books Online): In order to prevent concurrency issues and resource issues, should be carefully managed implicit transaction. With implicit transaction, after the next COMMIT or ROLLBACK Transact-SQL statement starts a new transaction automatically. (Even when user input is required) this may browse data in an application to open a new business. After the completion of the last transaction to modify the data protection required, it should be closed implicit transaction until the transaction again need to protect data modifications. This process enables SQL Server database engine can browse data in the application and obtain user input when using auto-commit mode.
In addition, Enabling snapshot isolation level, despite a new transaction will not control lock, but long-running transactions will prevent remove the old version from tempdb.
8. The flexible use of lower cursor concurrency option, e.g. optimistic concurrency option.
Expenses (form SQL Server Books Online) The possibility of concurrent updates of small systems, process "someone else changed the data when you read the data," the occasional wrong overhead than when reading data is always locked rows of small much more.
Better approach is to avoid using a cursor.
(After another supplement ...)
Reproduced in: https: //www.cnblogs.com/happyhippy/archive/2010/08/07/1794728.html