Це не завжди погано.
Звичайно, це дає змогу читати непередавані значення (які можуть бути повернуті назад і, отже, ніколи не існували логічно), а також допускає такі явища, як читання значень кілька разів або взагалі відсутні.
Єдині рівні ізоляції, які гарантують, що ви не зіткнетеся з подібними аномаліями, - це серіалізація / знімок. Під повторюваними значеннями зчитування можна пропустити, якщо рядок переміщено (за рахунок оновлення ключа) до того, як сканування досягне цього рядка, під знаками, здійсненими для читання, можна прочитати двічі, якщо оновлення ключа змушує попередньо прочитану рядок рухатися вперед.
Ці питання, швидше за все, виникають у зв'язку з nolockтим, що, за замовчуванням, на цьому рівні ізоляції він використовуватиме впорядкований розподіл сканування, коли, за оцінками, потрібно прочитати понад 64 сторінки . Як і категорія питань, що виникають при переміщенні рядків між сторінками через оновлення ключових індексів, ці впорядковані сканування розподілу також вразливі до проблем із розщепленнями сторінок (де рядки можна пропустити, якщо новопризначена сторінка знаходиться раніше у файлі, ніж точка вже відскановано або прочитано двічі, якщо вже відскановану сторінку розділити на пізнішу сторінку у файлі).
Принаймні, для простих запитів (за однією таблицею) можна відмовитися від використання цих сканувань і отримати сканований ключ за nolockдопомогою простого додавання ORDER BY index_keyдо запиту, щоб Orderedвластивість IndexScanбула true.
Але якщо у вашій заяві для звітності не потрібні абсолютно точні цифри і можна допустити більшу ймовірність таких невідповідностей, це може бути прийнятним.
Але, безумовно, не варто це робити за всіма запитами, сподіваючись, що це чарівна кнопка "турбо". Окрім більшої ймовірності зустріти аномальні результати на тому рівні ізоляції або взагалі відсутні результати ("Не вдалося продовжити сканування за допомогою NOLOCK через помилку руху даних"), є навіть випадки, коли продуктивність nolock може бути набагато гіршою .