🗄️ SQL и базы данных · 20 вопросов · ~43 мин · ⏱ Таймер 43:00 · Сложный ·

Блокировки и взаимные блокировки

Блокировка в тесте — не абстрактный запрет, а конкретное ожидание между транзакциями. Нужно понять, что удерживает UPDATE, зачем SELECT FOR UPDATE резервирует строки, как NOWAIT и SKIP LOCKED меняют поведение очереди, почему долгие транзакции увеличивают конфликтность и как противоположный порядок захвата двух ресурсов создаёт deadlock, который СУБД разрывает откатом.

Отвечено: 0 из 20

⏱ --:--

💡 Инструкция: Выбери один ответ из четырёх. В тесте 20 вопросов и 43 минут. После завершения откроются общий процент, четыре тематические шкалы, правильные ответы и разбор каждого задания.

Вопрос 1 из 20

Когда UPDATE обычно удерживает блокировку изменённой строки?

BEGIN;
UPDATE accounts SET balance=balance-10 WHERE id=1;
-- блокировка строки id=1 удерживается
COMMIT;

До закрытия соединения, даже если транзакция уже завершена До завершения следующего оператора в той же транзакции Только пока сервер ищет строку по условию WHERE До завершения транзакции COMMIT или ROLLBACK

Вопрос 2 из 20

Что делает SELECT ... FOR UPDATE?

BEGIN;
SELECT * FROM jobs
WHERE id=10
FOR UPDATE;
-- затем UPDATE
COMMIT;

Сортирует подходящие строки в порядке их физического расположения Создаёт постоянный индекс по столбцам, использованным в WHERE Читает строки и блокирует конфликтующие изменения Немедленно фиксирует текущую транзакцию после чтения подходящих строк

Вопрос 3 из 20

Блокирует ли обычный SELECT строку так же, как FOR UPDATE?

-- сравните
SELECT * FROM jobs WHERE id=5;
SELECT * FROM jobs WHERE id=5 FOR UPDATE;

Нет, потому что SELECT вообще не участвует в транзакциях Да, если есть WHERE Да, обычный SELECT берёт ту же блокировку строки, но освобождает её сразу после чтения Нет, обычное MVCC-чтение не берёт такую блокировку

Вопрос 4 из 20

Почему условие FOR UPDATE без индекса может увеличить проблему конкуренции?

COMMIT недоступен, пока таблица не получит индекс по каждому условию WHERE Наличие индекса заменяет FOR UPDATE обычным чтением и снимает конфликт записей Без индекса FOR UPDATE блокирует только первую найденную строку, а остальные пропускает Поиск может читать много данных и дольше идти к нужным строкам; точный план сокращает длительность операции

Вопрос 5 из 20

Когда освобождается блокировка после ROLLBACK TO SAVEPOINT для строк, изменённых после savepoint в PostgreSQL?

Блокировки после savepoint освобождаются только после отдельной команды RELEASE SAVEPOINT Блокировки, полученные после savepoint, могут быть освобождены при откате к нему Откат к savepoint освобождает все блокировки транзакции, включая полученные до этой точки Изменения после savepoint отменяются, но полученные ими блокировки остаются до конца транзакции

Вопрос 6 из 20

Что происходит со вторым UPDATE той же строки, пока первая транзакция не завершена?

-- T1
BEGIN; UPDATE accounts SET balance=90 WHERE id=1;

-- T2
UPDATE accounts SET balance=80 WHERE id=1; -- ожидает

Оба UPDATE отменяются сразу Строка копируется в новую таблицу Второй UPDATE изменяет видимую старую версию, а конфликт разрешается при COMMIT Он обычно ждёт освобождения конфликтующей блокировки

Вопрос 7 из 20

Для чего полезен NOWAIT?

SELECT * FROM seats WHERE id=10 FOR UPDATE NOWAIT;

Чтобы снять чужую блокировку Сразу получить ошибку вместо ожидания блокировки Чтобы ждать бесконечно Чтобы пропустить все строки без проверки

Вопрос 8 из 20

Для чего полезен SKIP LOCKED в очереди задач?

SELECT id FROM jobs
WHERE status='new'
ORDER BY id
FOR UPDATE SKIP LOCKED
LIMIT 1;

Чтобы гарантировать строгий общий порядок завершения Чтобы работник пропустил уже взятые строки и выбрал другие доступные Чтобы удалить заблокированные задачи Чтобы читать незакоммиченные данные

Вопрос 9 из 20

Какой риск у SKIP LOCKED вне очередей?

Запрос может намеренно не увидеть подходящие, но занятые строки, поэтому результат не является полным снимком Занятые строки всё равно будут ждать освобождения, несмотря на SKIP LOCKED Результат остаётся полным, меняется только порядок возвращённых строк Пропущенные строки автоматически помечаются обработанными текущей транзакцией

Вопрос 10 из 20

Что следует проверить при долгом ожидании блокировки?

Количество выбранных столбцов, независимо от длительности транзакции владельца Какой процесс владеет ресурсом, когда началась его транзакция и что он выполняет Только наличие индекса у ожидающего запроса Длину SQL-текста блокирующего запроса без анализа его транзакции

Вопрос 11 из 20

Как возникает классический deadlock двух переводов?

-- T1: UPDATE account 1; затем UPDATE account 2
-- T2: UPDATE account 2; затем UPDATE account 1

T1 держит A и ждёт B, а T2 читает B обычным SELECT без конфликтующей блокировки T1 держит A и ждёт B, а T2 держит B и ждёт A Обе транзакции берут A, затем B в одинаковом порядке, поэтому одна ждёт другую T1 ждёт B, но T2 уже освободила B и завершила транзакцию

Вопрос 12 из 20

Что делает PostgreSQL после обнаружения deadlock?

-- T1: UPDATE a; затем UPDATE b;
-- T2: UPDATE b; затем UPDATE a;

Ждёт бесконечно Удаляет обе строки Автоматически выполняет COMMIT обеих Отменяет одну транзакцию, чтобы разорвать цикл

Вопрос 13 из 20

Чем обычное ожидание отличается от deadlock?

Разницы нет: любое ожидание блокировки образует цикл зависимостей При ожидании нет цикла и владелец может завершиться, освободив ресурс Ожидание имеет ограниченный срок и завершается без участия владельца блокировки Deadlock возникает без блокировок — только из-за медленного плана выполнения

Вопрос 14 из 20

Почему deadlock может возникнуть не только на строках одной таблицы?

Цикл возможен только на уровне файлов таблиц, а не отдельных объектов базы Цикл может включать разные таблицы, индексы и другие блокируемые ресурсы В цикл могут входить только блокировки внешних ключей, но не обычных строк Любое соединение двух таблиц создаёт взаимную зависимость между транзакциями

Вопрос 15 из 20

Что произойдёт с работой отменённой транзакции-жертвы?

Сохранится первый UPDATE Она частично останется Все её незакоммиченные изменения откатятся Она станет read-only

Вопрос 16 из 20

Какая мера сильнее всего снижает риск deadlock при обновлении набора счетов?

SELECT id FROM accounts
WHERE id IN (8, 3, 5)
ORDER BY id
FOR UPDATE;

Захватывать счета в одном порядке по id Убрать COMMIT Использовать случайный порядок Увеличить текст запроса

Вопрос 17 из 20

Почему транзакцию не стоит держать открытой, пока пользователь заполняет форму?

Форма отправляет SQL только после COMMIT, поэтому открытая транзакция не влияет на ожидание COMMIT нужно выполнить до показа формы, а последующие изменения писать вне транзакции Долгая пауза пользователя не влияет на блокировки: они удерживаются только во время выполнения SQL Ожидание пользователя продлевает блокировки и возраст снимка

Вопрос 18 из 20

Как правильно реагировать на deadlock в приложении?

Вернуть успех, потому что СУБД самостоятельно завершит отменённую транзакцию позже Откатить и ограниченно повторить всю идемпотентную транзакцию, устранив по возможности порядок конфликта Повторить всю транзакцию в том же ошибочном состоянии соединения, не выполняя ROLLBACK Повторить только последний UPDATE: прочитанные ранее данные остаются актуальными

Вопрос 19 из 20

Почему слишком широкий WHERE увеличивает риск конфликтов?

Он создаёт дополнительные служебные таблицы для хранения множества кандидатов Без точного WHERE планировщик отключает индексы, но число изменяемых строк не меняется Длинное условие WHERE увеличивает только время синтаксического разбора Команда может затронуть и заблокировать больше строк, чем нужно

Вопрос 20 из 20

Несколько работников параллельно забирают готовые задачи из одной таблицы. Какой вариант надёжнее для пакетной обработки?

В одной короткой транзакции заблокировать небольшую упорядоченную порцию, пропуская уже занятые строки

SELECT id
FROM jobs
WHERE status = 'ready'
ORDER BY id
FOR UPDATE SKIP LOCKED
LIMIT 100;

Заблокировать сразу все готовые задачи, обработать их и лишь после этого завершить транзакцию

SELECT id FROM jobs
WHERE status = 'ready'
ORDER BY id
FOR UPDATE;

Блокировать по одной задаче, но в каждом работнике обходить кандидатов в случайном порядке

SELECT id FROM jobs
WHERE status = 'ready'
ORDER BY random()
FOR UPDATE
LIMIT 100;

Сначала прочитать порцию без блокировки, затем отдельной командой обновить найденные идентификаторы

SELECT id FROM jobs
WHERE status = 'ready'
ORDER BY id
LIMIT 100;
-- затем UPDATE ... WHERE id = ANY($1)

Ответьте на все 20 вопросов, чтобы получить результат

🔗 Встроить тест на свой сайт (iframe) ▼

Скопируйте код и вставьте в любое место на вашем сайте:

Также доступна прямая ссылка на embed-страницу