Mobile versionCode: Select all
CREATE TABLE master.mytest.control_table (
id int IDENTITY(1,1) NOT NULL,
uuid varchar(36) COLLATE SQL_Latin1_General_CP1_CI_AS NOT NULL,
status int NOT NULL,
CONSTRAINT PK__control___3213E83F4F29C19D PRIMARY KEY (id)
);
CREATE NONCLUSTERED INDEX IControlTable_Uuid ON master.mytest.control_table ( uuid ASC )
WITH ( PAD_INDEX = OFF ,FILLFACTOR = 100 ,SORT_IN_TEMPDB = OFF , IGNORE_DUP_KEY = OFF , STATISTICS_NORECOMPUTE = OFF , ONLINE = OFF , ALLOW_ROW_LOCKS = ON , ALLOW_PAGE_LOCKS = ON )
ON [PRIMARY ] ;
< /code>
Die Tabelle enthält 3 Spalten: ID (PK, automatisch generiert), uUid (varchar (36)) und Status (int). Ich habe einen nicht klusterierten Index für UUID erstellt. < /P>
Dann habe ich 4 Millionen Zeilen mit dieser Schleife eingefügt: < /p>
DECLARE @i INT = 1;
WHILE @i
Meine Tabelle enthält 4M -Einträge mit zufälligen UUIDs. Dann habe ich die folgenden Tests durchgeführt, ich habe eine Auswahlabfrage mit Tabelle Hinweis Updlock, Holdlock durchgeführt und die in der Tabelle dm_tran_locks generierten Sperren abgefragt. Die durchsuchte UUID existiert in der Tabelle nicht.SELECT resource_type, request_session_id, resource_associated_entity_id, request_mode, request_type, request_status, COUNT(*) as 'count' FROM sys.dm_tran_locks
GROUP BY resource_type, request_session_id, resource_associated_entity_id, request_mode, request_type, request_status
ORDER BY request_session_id;
< /code>
Der erste Testfall führte die Abfrage mit einer Verzögerung aus, bis das Commit: < /p>
BEGIN TRANSACTION
SELECT * FROM mytest.control_table WITH(UPDLOCK, HOLDLOCK)
WHERE uuid = 'XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX';
WAITFOR DELAY '00:00:10';
COMMIT TRANSACTION;
Sperrtabelle:
Die generierten Sperren sind unterschiedlich, wenn Sie direkt dieselbe Abfrage in SQL Server ausführen. Jetzt habe ich ein IX auf Objekt, viele von u-Schlössern auf Seite und keine Ranges-U-Taste wie zuvor. Meine ersten Tests zeigten ein X -Schloss auf dem Tisch. Ich habe also eine andere Tabelle mit dem Namen status_control2 mit demselben DDL -Skript erstellt und den Index erstellt, es einfach in icontrolTable_UID2 umbenannt und den Test erneut durchgeführt. Die ausgeführte Abfrage ist die gleiche, außer dass sie jetzt Status_Control2 abfragt. Ein Unterschied ist jedoch die Anzahl der Einträge, die durch die while -Schleife eingefügt wurden. In status_control2 habe ich nur 100K -Einträge eingelegt, während status_control 4 Millionen hat. src = "https://i.sstatic.net/zo2avix5.png"/>
Wie wir sehen können, hat die gesamte Tabelle eine exklusive (x) Sperre erhalten. Ich kann nicht verstehen, warum das unterschiedliche Verhalten. Ich meine, das unterschiedliche Verhalten zwischen den Sperren in status_control und status_control2 und insbesondere dem unterschiedlichen Verhalten zwischen der direkten Ausführung der Abfrage in SQL -Server und dem Durchführen der Java -Anwendung mit JDBI. Die Ergebnisse änderten sich überhaupt nicht. Wenn sie sich die Pläne ansehen, machen sie für mich Sinn. Der zweite, der viele Seite von Seite u sperrt, enthält Einträge der "Parallelität" und "Clustered Index Scan". Der letzte, der die gesamte Tabelle mit einer X -Sperre blockiert, enthält nur den Cluster -Index -Scan. Es gibt eine Warnung in den 2- und 3 Abfrageplänen, die besagen: < /p>
Type conversion in expression
(CONVERT_IMPLICIT(nvarchar(36),[master].[mytest].[control_table2].[uuid],0)=[@P0])
may affect "Seek Plan" in query plan choice.
< /code>
Aber ich bin mir nicht sicher, wie ich es interpretieren soll. Zumindest denke ich, dass dies etwas damit zu tun hat, dass JDBI die Variable ": uUid" durch die bereitgestellte Zeichenfolge ersetzt. Linux (Ubuntu 22.04.5 LTS)
