sql - When is it appropriate to use NOLOCK? -
I have periodical problems and deadlock coming from time to time with questions that last a few minutes.
I am thinking that when using NOLOCK is most appropriate and where?
Do I update it & amp; Inserts? Or reads? Note that you can specify nolock on each table basis.
I usually used nolock in complex selection choices, but only for small viewing tables, which almost never changed, and for display-only data. You know the tables that list the current half year prices, or the look strings of the id etc. Goods that change with major updates, after which the server usually restarts regularly on a regular basis.
This improved performance, at the busiest time, reduced the chance of stagnation, and more importantly it was not really important during moments of many cases, which touched many tables (which is rational , They have to get less locks, and those sidetables are often used everywhere, often 7-8 to 4 tables are lacking which must be locked)
But it is very careful to add it are Do not hurry it, and do not do it regularly, it will not hurt if used properly, but it will hurt if used incorrectly.
Do not use it for the most important stuff, the stuff that counts, etc., because it will become inconsistent, whatever happens quickly or later.
Another such customization is ROWLOCK, which locks only at the row level This is mainly useful when updating tables (or deletion), where the rows are not related to each other, Like in tables where you only put in log records (and in whatever order they are involved there is no such thing). If you have a plan that, at the end of a transaction, a log record is written in some table, it can be much faster.
If your database writes a relatively small percentage, then it is not possible to do this. <2 p>
Comments
Post a Comment