Що використовує блокування MySQL FOR UPDATE, що саме блокується?

Це не лише повний / правильний запит MySQL, лише псевдокод:

Select *
 from Notifications as n
 where n.date > (CurrentDate-10 days)
 limit by 1
 FOR UPDATE

http://dev.mysql.com/doc/refman/5.0/en/select.html стверджує: Якщо ви використовуєте FOR UPDATE із механізмом зберігання, який використовує блокування сторінок або рядків, рядки, що перевіряються запитом, блокуються під час запису, доки закінчення поточної транзакції

Тут лише один запис, повернутий заблокований MySQL, або всі записи, які він повинен відсканувати, щоб знайти один запис?

Чому б нам просто не спробувати?

Налаштування бази даних

CREATE DATABASE so1;
USE so1;
CREATE TABLE notification (`id` BIGINT(20), `date` DATE, `text` TEXT) ENGINE=InnoDB;
INSERT INTO notification(id, `date`, `text`) values (1, '2011-05-01', 'Notification 1');
INSERT INTO notification(id, `date`, `text`) values (2, '2011-05-02', 'Notification 2');
INSERT INTO notification(id, `date`, `text`) values (3, '2011-05-03', 'Notification 3');
INSERT INTO notification(id, `date`, `text`) values (4, '2011-05-04', 'Notification 4');
INSERT INTO notification(id, `date`, `text`) values (5, '2011-05-05', 'Notification 5');

Тепер запустіть два підключення до бази даних

З'єднання 1

BEGIN;
SELECT * FROM notification WHERE `date` >= '2011-05-03' FOR UPDATE;

З'єднання 2

BEGIN;

Якщо MySQL заблокує всі рядки, наступний оператор заблокує. Якщо він блокує лише ті рядки, які повертає, він не повинен блокувати.

SELECT * FROM notification WHERE `date` = '2011-05-02' FOR UPDATE;

І справді це блокує.

Цікаво, що ми також не можемо додавати записи, які будуть прочитані, тобто

INSERT INTO notification(id, `date`, `text`) values (6, '2011-05-06', 'Notification 6');

блоки також!

На даний момент я не можу бути впевненим, чи MySQL просто продовжує і блокує всю таблицю, коли певний відсоток рядків заблоковано, чи де це насправді розумно, переконавшись, що результат SELECT ... FOR UPDATEзапиту ніколи не може бути змінений іншою транзакцією ( з INSERT, UPDATEабо DELETE) в той час як замок проходить.

Я знаю, що це запитання досить давнє, але я хотів поділитися результатами деяких відповідних тестів, які я провів, з індексованими стовпцями, що дало досить дивні результати.

Структура таблиці:

CREATE TABLE `t1` (                       
  `id` int(11) NOT NULL AUTO_INCREMENT,                 
  `notid` int(11) DEFAULT NULL,                         
  PRIMARY KEY (`id`)                                    
) ENGINE=InnoDB DEFAULT CHARSET=latin1;

12 рядків, вставлених с INSERT INTO t1 (notid) VALUES (1), (2),..., (12). При підключенні 1 :

BEGIN;    
SELECT * FROM t1 WHERE id=5 FOR UPDATE;

При підключенні 2 блокуються такі оператори:

SELECT * FROM t1 WHERE id!=5 FOR UPDATE;
SELECT * FROM t1 WHERE id<5 FOR UPDATE;
SELECT * FROM t1 WHERE notid!=5 FOR UPDATE;
SELECT * FROM t1 WHERE notid<5 FOR UPDATE;
SELECT * FROM t1 WHERE id<=4 FOR UPDATE;

Дивна частина , яка SELECT * FROM t1 WHERE id>5 FOR UPDATE;є не блокується , ніяка - або з

...
SELECT * FROM t1 WHERE id=3 FOR UPDATE;
SELECT * FROM t1 WHERE id=4 FOR UPDATE;
SELECT * FROM t1 WHERE id=6 FOR UPDATE;
SELECT * FROM t1 WHERE id=7 FOR UPDATE;
...

Я також хотів би зазначити, що, здається, вся таблиця заблокована, коли WHEREумова у запиті з підключення 1 відповідає неіндексованому рядку. Наприклад, коли з'єднання 1 виконати ють SELECT * FROM t1 WHERE notid=5 FOR UPDATEвсі запити з виберіть FOR UPDATEі UPDATEзапити з сполуки 2 блокуються.

- РЕДАГУВАТИ -

Це досить специфічна ситуація, але це єдина ситуація, яку я зміг виявити:

Підключення 1:

BEGIN;
SELECT *, @x:=@x+id AS counter FROM t1 CROSS JOIN (SELECT @x:=0) b HAVING counter>5 LIMIT 1 FOR UPDATE;
+----+-------+-------+---------+
| id | notid | @x:=0 | counter |
+----+-------+-------+---------+
|  3 |     3 |     0 |       9 |
+----+-------+-------+---------+
1 row in set (0.00 sec)

З підключення 2 :

SELECT * FROM t1 WHERE id=2 FOR UPDATE; заблоковано;

SELECT * FROM t1 WHERE id=4 FOR UPDATE;це НЕ заблокований.

Потік досить старий, щоб поділитися своїми двома копійками щодо тестів вище, проведених @Frans

З'єднання 1

BEGIN;
SELECT * FROM notification WHERE `date` >= '2011-05-03' FOR UPDATE;

З'єднання 2

BEGIN;

SELECT * FROM notification WHERE `date` = '2011-05-02' FOR UPDATE;

Одночасна транзакція 2 буде заблокована напевно, але причина НЕ в тому, що транзакція 1 утримує блокування на всій таблиці. Далі пояснюється, що сталося за лаштунками:

Перш за все, за замовчуванням рівень ізоляції механізму зберігання InnoDB - Repeatable Read. В цьому випадку,

1- Коли стовпець, що використовується там, де умова не індексується (як у випадку вище):

Механізм зобов'язаний виконати повне сканування таблиці, щоб відфільтрувати записи, що не відповідають критеріям. КОЖНИЙ РЯД, який було відскановано, заблоковано в першу чергу. MySQL може звільнити блокування для тих записів, які згодом не відповідають пункту where. Це оптимізація продуктивності, однак така поведінка порушує обмеження 2PL.

Коли транзакція 2 починається, як пояснювалося, їй потрібно отримати замок X для кожного отриманого рядка, хоча існує лише один запис (id = 2), що відповідає реченню where. Врешті-решт транзакція 2 буде чекати блокування X першого рядка (id = 1), доки транзакція 1 не здійснить або не відкатить.

2- Коли стовпець, що використовується в де умова, є первинним індексом

Заблоковано лише запис індексу, що відповідає критеріям. Тому в коментарях хтось говорить, що деякі тести не блокуються.

3 - Коли стовпець, що використовується в де умова, є індексом, але не унікальним

Цей випадок складніший. 1) Запис індексу заблоковано. 2) Один замок X прикріплений до відповідного первинного індексу. 3) До неіснуючих записів безпосередньо перед записом та після нього, що відповідає критеріям пошуку, прикріплені два зазори.

Наступні посилання зі сторінки документації, яку ви розмістили, дають більше інформації про блокування . На цій сторінці

SELECT ... FOR UPDATE читає останні доступні дані, встановлюючи ексклюзивні блокування для кожного зчитуваних рядків. Таким чином, він встановлює ті самі замки, які шуканий SQL UPDATE встановив би в рядках.

Це здається цілком зрозумілим, що всі рядки він повинен сканувати.

З офіційного документа MySQL:

Блокування читання, ОНОВЛЕННЯ або ВИДАЛЕННЯ зазвичай встановлюють блокування записів для кожного запису індексу, який перевіряється під час обробки оператора SQL. Не має значення, чи є в операторі умови WHERE, які виключають рядок.

Для випадку, обговореного у відповіді Франса, всі рядки заблоковані, оскільки під час обробки sql відбувається сканування таблиці:

Якщо у вас немає індексів, придатних для вашого виписки, і MySQL повинен просканувати всю таблицю для обробки виписки, кожен рядок таблиці стає заблокованим, що, в свою чергу, блокує всі вставки іншими користувачами до таблиці. Важливо створити хороші індекси, щоб ваші запити не зайво сканували багато рядків.

Перевірте останні документи тут: https://dev.mysql.com/doc/refman/8.0/en/innodb-locks-set.html

Як вже згадували інші, SELECT ... FOR UPDATE блокує всі рядки, що зустрічаються на рівні ізоляції за замовчуванням. Спробуйте встановити ізоляцію для сеансу, який запускає цей запит, на READ COMMITTED, наприклад, перед запитом:set session transaction isolation level read committed;

Він блокує всі рядки, вибрані за запитом.