Hvorfor prøver vi det ikke bare?
Opsæt databasen
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');
Start nu to databaseforbindelser
Forbindelse 1
BEGIN;
SELECT * FROM notification WHERE `date` >= '2011-05-03' FOR UPDATE;
Forbindelse 2
BEGIN;
Hvis MySQL låser alle rækker, vil følgende sætning blokere. Hvis den kun låser de rækker, den returnerer, bør den ikke blokere.
SELECT * FROM notification WHERE `date` = '2011-05-02' FOR UPDATE;
Og det blokerer faktisk.
Interessant nok kan vi heller ikke tilføje poster, der ville blive læst, dvs.
INSERT INTO notification(id, `date`, `text`) values (6, '2011-05-06', 'Notification 6');
blokerer også!
Jeg kan på nuværende tidspunkt ikke være sikker på, om MySQL bare går videre og låser hele tabellen, når en vis procentdel af rækker er låst, eller hvor det faktisk er virkelig intelligent til at sikre, at resultatet af SELECT ... FOR UPDATE
forespørgsel kan aldrig ændres af en anden transaktion (med en INSERT
, UPDATE
eller DELETE
) mens låsen holdes.