Сравнение: почему блокировка строки обычно повышает конкурентность по сравнению с блокировкой таблицы, но не всегда оказывается лучшим выбором?
Блокировка строки позволяет параллельно работать с разными строками одной таблицы, тогда как блокировка таблицы временно ограничивает доступ к значительно большему набору данных. Однако построчные блокировки требуют больше памяти и операций учёта, поэтому при массовом изменении строк более грубая блокировка может оказаться дешевле и предсказуемее.
Блокировки возникли как способ согласовать конкурентные операции над общими данными без нарушения целостности. По мере развития СУБД появилась необходимость выбирать компромисс между простым управлением крупными объектами и высокой параллельностью мелких операций.
Гранулярность блокировок стала одним из способов управлять этим компромиссом: таблица, страница или отдельная строка могут быть защищены с разной степенью точности. Конкретный набор уровней и правила перехода между ними зависят от СУБД.
Предположим, две транзакции изменяют разные строки одной таблицы. При блокировке строк они потенциально могут выполняться одновременно, а при блокировке всей таблицы одна транзакция будет ждать другую, хотя их данные не пересекаются.
С другой стороны, операция над большим числом строк создаёт множество блокировок. Это увеличивает накладные расходы, потребление памяти и вероятность конфликтов между блокировками, а при нехватке ресурсов может привести к ухудшению производительности или переходу к более грубой гранулярности.
Построчная блокировка защищает только затронутые записи. Поэтому транзакции, работающие с непересекающимися строками, обычно сохраняют возможность параллельного выполнения. Цена этого подхода — хранение большого числа объектов блокировки и проверка совместимости каждой новой блокировки.
Блокировка таблицы проще для менеджера блокировок: достаточно учитывать один крупный объект. Но она снижает конкурентность, потому что конфликтовать начинают операции, которые логически затрагивают разные строки. Это особенно заметно в высоконагруженных системах с короткими независимыми транзакциями.
Гранулярность не следует смешивать с уровнем изоляции. Уровень изоляции определяет, какие эффекты конкурентного выполнения допустимы, а гранулярность определяет, какой объём данных защищается конкретной блокировкой. Даже высокий уровень изоляции не гарантирует, что все блокировки будут построчными.
СУБД может использовать блокировки страниц или таблиц, а некоторые системы способны автоматически укрупнять множество мелких блокировок. Такое укрупнение уменьшает накладные расходы, но может резко сократить параллелизм. Кроме того, фактическое поведение зависит от плана выполнения, индексов, типа операции и реализации конкретной СУБД.
Практический выбор обычно зависит от характера нагрузки: небольшие точечные изменения выигрывают от мелкой гранулярности, а массовая обработка может быть эффективнее при контролируемой крупной блокировке или при разбиении работы на части. Важно проверять не только среднее время запроса, но и ожидания блокировок, потребление памяти и задержки конкурирующих транзакций.
Сервис обрабатывает заказы, и параллельные транзакции обычно обновляют разные строки. Блокировка всей таблицы упрощает контроль, но создаёт очередь: даже независимые заказы ждут друг друга. Построчные блокировки повышают пропускную способность, однако при пакетном обновлении десятков тысяч заказов начинают расти расходы на управление блокировками.
Рассматривались три варианта. Полная блокировка таблицы проста, но плохо использует параллелизм. Построчная блокировка лучше для точечных операций, но требует контроля размера пакетов и возможного роста числа блокировок. Разбиение массовой операции на небольшие транзакции уменьшает длительность удержания блокировок, но усложняет обработку частичного сбоя.
Выбрали построчные изменения небольшими пакетами с повторным запуском неуспешных частей. Это сохранило параллельную обработку независимых заказов и ограничило объём одновременно удерживаемых блокировок. Результат нужно подтверждать измерениями: решение считается удачным только при приемлемых задержках, числе ожиданий и корректности транзакционной обработки.
Нет. Транзакции могут конфликтовать из-за блокировок индексов, страниц, диапазонов или внутренних структур СУБД. Кроме того, одна операция может затрагивать не только явно изменяемые строки, но и связанные записи, индексы или ограничения целостности.
Поэтому утверждение «разные строки всегда изменяются независимо» слишком сильное. Нужно анализировать фактический план, индексы и правила блокировок конкретной СУБД.
Каждая блокировка требует учёта и проверки совместимости. При массовой операции это увеличивает использование памяти и процессорные расходы, а также время фиксации или отката транзакции.
Если СУБД применяет автоматическое укрупнение блокировок, конкурентность может неожиданно снизиться. Если укрупнения нет, транзакция может потреблять слишком много ресурсов. Поэтому для массовых операций важны размер пакета и длительность транзакции, а не только исходная гранулярность.
Индекс меняет способ поиска строк и набор структур, через которые проходит операция. При точечном поиске хороший индекс может позволить быстро найти нужные записи и удерживать узкие блокировки, тогда как отсутствие подходящего индекса может привести к чтению большого объёма данных и более широкому конфликту.
Однако индекс не гарантирует исключительно построчное блокирование: СУБД может блокировать страницы, диапазоны или использовать другую стратегию. Поэтому влияние индекса оценивают вместе с планом выполнения и фактическими ожиданиями блокировок, а не по одному факту его наличия.