Wenn eine Transaktion eine Zeile liest, legt die Isolationsstufe der Transaktion fest, ob eine Lesesperre gesetzt wird. Sobald für eine Zeile eine Lesesperre vorliegt, kann keine Transaktion eine Schreibsperre dafür setzen. Das Setzen einer Lesesperre gewährleistet, dass eine Zeile nicht von einer anderen Transaktion geändert oder gelöscht wird, während sie gelesen wird. Beliebig viele Transaktionen können gleichzeitig Lesesperren für eine beliebige Zeile setzen, weshalb Lesesperren manchmal auch als gemeinsame Sperren oder nicht exklusive Sperren bezeichnet werden.

Lesesperren können für verschiedene Zeitspannen aufrechterhalten werden. Auf den Isolationsstufen 2 und 3 werden alle von einer Transaktion gesetzten Lesesperren aufrechterhalten, bis die Transaktion durch COMMIT oder ROLLBACK festgeschrieben wird. Diese Lesesperren werden als langfristige Lesesperren bezeichnet.

Für Transaktionen, die auf Isolationsstufe 1 ausgeführt werden, setzt der Datenbankserver eine kurzfristige Lesesperre für die Zeile, in der ein Cursor positioniert ist. Wenn die Anwendung den Cursor durchläuft, wird die kurzfristige Lesesperre für die zuvor aktive Zeile freigegeben und eine neue kurzfristige Lesesperre wird für die nächste Zeile gesetzt. Diese Technik wird als Cursorstabilität bezeichnet. Da die Anwendung eine Lesesperre für die aktuelle Zeile aufrechterhält, können andere Transaktionen die Zeile nicht ändern, bis die Anwendung die Zeile verlässt. Beachten Sie, dass mehr als eine Sperre gesetzt werden kann, wenn sich der Cursor auf einer Abfrage befindet, die mehrere Tabellen umfasst. Kurzfristige Lesesperren werden nur gesetzt, wenn die Position innerhalb eines Cursors über mehrere Aufrufe aufrechterhalten werden muss (normalerweise würde es sich dabei um FETCH-Anweisungen der Anwendung handeln). Kurzfristige Lesesperren werden beispielsweise nicht gesetzt, wenn eine SELECT COUNT(*)-Abfrage verarbeitet wird, da ein Cursor, der für diese Anweisung geöffnet wird, niemals auf eine bestimmte Zeile der Basistabelle gesetzt wird. In einem solchen Fall braucht der Datenbankserver nur die Semantik der festgeschriebenen Lesevorgänge zu garantieren, das heißt, dass die von der Anweisung verarbeiteten Zeilen durch andere Transaktionen festgeschrieben wurden.

Transaktionen auf Isolationsstufe 0 ("read uncommitted") setzen keine langfristigen oder kurzfristigen Lesesperren, wodurch es auch nicht zu Konflikten mit anderen Transaktionen kommt (außer bei exklusiven Schemasperren). Transaktionen auf Isolationsstufe 0 können jedoch nicht festgeschriebene Änderungen verarbeiten, die durch andere parallele Transaktionen durchgeführt wurden. Sie können die Verarbeitung nicht festgeschriebener Änderungen durch die Snapshot-Isolation verhindern. Siehe Snapshot-Isolation.