Як ми всі знаємо, ЧИТАЙТЕ НЕЗАБАВЛЕНО - це найнижчий рівень ізоляції, коли такі речі, як брудні читання та фантомні читання, можуть накопичуватися. Коли найкращий час використовувати цей рівень ізоляції і з яких причин він може бути використаний?
Насправді я читав відповіді раніше, але не зміг її зрозуміти повністю, бо не було достатньо прикладів.
Відповіді:
Я використовую READ_UNCOMMITTED(або NOLOCK) під час запитів виробничих баз даних з SSMS, але не регулярно з коду програми. Ця практика (разом із підказкою на запит MAXDOP 1) допомагає гарантувати, що випадкові запити для аналізу даних та усунення несправностей не впливають на виробниче навантаження, оскільки розуміння результатів може бути невірним.
На жаль, я бачу READ_UNCOMMITTED/ NOLOCKвикористовую широко у виробничому коді, щоб уникнути блокування за рахунок цілісності даних. Правильним рішенням є рівень ізоляції в рядкових версіях ( SNAPSHOTабо READ_COMMITTEDз READ_COMMITTED_SNAPSHOTопцією бази даних ON) та / або увага до налаштування запитів та індексів.
Нещодавно я переглянув програму, у якій змінилося лише видалення, NOLOCKоскільки вона іноді призводила до неправильних результатів. Вилучення NOLOCKбуло гарною справою, але, знаючи, що пропущені чи дублюються рядки зазвичай трапляються під час сканування замовлення на розподіл великих таблиць, я запропонував також переробити фактори, щоб використовувати UNION ALLтехніку для просування ефективного використання індексу. Зараз запит працює за кілька мілісекунд з правильними результатами, найкращими з усіх світів.
Я думаю, що це добре за деяких обставин, якщо ви приймаєте наслідки і не маєте інших варіантів.
Для інших варіантів я б підштовхнув людей до використання зчитуваної передачі знімків знімків (RCSI) для нових програм або SNAPSHOT ISOLATION (SI) для старих додатків, де ви не можете легко протестувати всю базу коду на гоночні умови з RCSI.
Однак це може бути не дуже підходящим. Можливо, вам доведеться витратити трохи зайвого часу, люблячись і піклуючись про tempdb, і переконуючись, що ніхто не залишає відкритої транзакції, завдяки якій зберігання версій (і tempdb) зростає та заповнює диск.
Якщо у вас немає DBA або когось, завдання якого - контролювати та керувати вашим SQL сервером, ці параметри можуть бути небезпечними. Загалом, не всі мають повний контроль над кодом, що надходить на їх сервер, де вони можуть змінити рядок з'єднання або код, щоб попросити SI для проблемних запитів.
Крім того, більшість людей не мають проблем із блокуванням у всьому своєму застосуванні . У них є проблеми з такими речами, як звітування про дані OLTP. Якщо ви можете прийняти компроміси NOLOCK / RU в обмін на ті звіти, які письменники не блокують, перейдіть на це.
Просто переконайтеся, що ви розумієте, що це означає. Це не означає, що ваш запит не приймає жодних блокувань, це означає, що він не поважає блокування, виведені іншими запитами.
І звичайно, якщо ваша проблема полягає в блокуванні сценариста / письменника, єдиний варіант, який допоможе, - це SI, але для належного втілення цього завдання при роботі з помилками потрібна неймовірна кількість розробників.
IMHO - єдиний вірний випадок використання для ПРОЧИТАННЯ НЕЗАКОНЕНОГО в сучасній системі - це при налагодженні однієї сесії з іншої в розробці, щоб ви могли побачити, що вона робить під час, наприклад, що зберігається додаток все ще працює. Він ніколи не використовувався б у виробничій системі. Можливо, буде невеликий приріст продуктивності, але довгостроково це ніколи не варто.
Ми його постійно використовуємо в охороні здоров'я.
Вражаюча рідкість для окремих рядків даних змінювати середину запиту, а співвідношення читання / запису - як 10000/1 - і більшість із них - це вставки, а не оновлення. Наприклад, коли інтерфейс лабораторії записує результати лабораторії пацієнта в базу даних, ці значення ніколи не змінюються.
Коли дані робить зміни, він змінює по одному рядку за один раз. Ніхто не оновлює цілі стовпці (крім DBA, коли вони псуються дуже погано).
З іншого боку, ми проводимо купу запитів, щоб сканувати такі речі, як пацієнти, які повертаються до ЕР протягом 72 годин або менше, що абсолютно забиває столи.
За 10 років охорони здоров’я SQL я ніколи не бачив Rollback Transaction. Я хочу входити та виходити, не порушуючи досвід кінцевого користувача. Якщо є високий ризик уповільнення роботи бази даних OLTP і низький ризик отримання поганих даних, я буду НОЛОК.
Чи повинні ми його використовувати? Можливо, може й ні. Взагалі кажучи, я б не сказав, що багато баз даних програм, над якими я працював, добре розроблені. Вони, як правило, укупорені повними анти-візерунками.
READ_UNCOMMITTED/NOLOCK- хороший варіант, коли точність даних насправді не є основною метою. Іноді, коли приблизний підрахунок сукупності - це все, що потрібно. Наприклад: Є збережені процедури, які використовуються для INSERT або UPDATE таблиць. Іноді кількість записів, які потрібно оновити або вставити, величезна (тисячі записів). Під час виконання цих збережених процедур ми можемо NOLOCKперіодично запускати простий запит вибору з цільовою таблицею, щоб побачити, чи він прогресує плавно (Для запиту оновлення, якщо у вас стовпець зміни статусу для оновлених записів, ми можемо використовувати цей стовпець для запуску group byзапиту з NOLOCKщоб дізнатися, чи постійно змінюється кількість змін).
Майте на увазі, що ЧИТАТИ НЕЗАКОМНОГО вводяться додаткові проблеми послідовності, а не лише брудні читання. Залежно від способу доступу, ви можете пропускати рядки або навіть читати один і той же рядок не один раз. Якщо вас цікавлять деталі, прочитайте статтю Іціка Бен-Гана