Die vorliegende Übersetzung wurde maschinell erstellt. Im Falle eines Konflikts oder eines Widerspruchs zwischen dieser übersetzten Fassung und der englischen Fassung (einschließlich infolge von Verzögerungen bei der Übersetzung) ist die englische Fassung maßgeblich.

Asynchrone Indizes in Aurora DSQL

Der CREATE INDEX ASYNC Befehl erstellt einen Index für eine oder mehrere Spalten einer angegebenen Tabelle. Bei diesem Befehl handelt es sich um eine asynchrone DDL-Operation, die andere Transaktionen nicht blockiert. Wenn Sie es ausführenCREATE INDEX ASYNC, gibt Aurora DSQL sofort a job_id zurück.

Sie können den Status dieses asynchronen Jobs mithilfe der sys.jobs Systemansicht überwachen. Während der Indexerstellung können Sie die folgenden Verfahren und Befehle verwenden:

Wenn Aurora DSQL eine asynchrone Indexaufgabe beendet, aktualisiert es den Systemkatalog, um anzuzeigen, dass der Index aktiv ist. Wenn andere Transaktionen zu diesem Zeitpunkt auf die Objekte im selben Namespace verweisen, wird möglicherweise ein Parallelitätsfehler angezeigt.

Syntax

CREATE INDEX ASYNCverwendet die folgende Syntax.

CREATE [ UNIQUE ] INDEX ASYNC [ IF NOT EXISTS ] name ON table_name 
     ( { column_name } [ NULLS { FIRST | LAST } ] ) 
     [ INCLUDE ( column_name [, ...] ) ] 
     [ NULLS [ NOT ] DISTINCT ]

Parameter

Nutzungshinweise

Berücksichtigen Sie die folgenden Hinweise:

Einen Index erstellen: Beispiel

Das folgende Beispiel zeigt, wie Sie ein Schema, eine Tabelle und dann einen Index erstellen.

Den Status der Indexerstellung abfragen: Beispiel

Fragen Sie die sys.jobs Systemansicht ab, um den Erstellungsstatus Ihres Indexes zu überprüfen, wie im folgenden Beispiel gezeigt.

SELECT * FROM sys.jobs

Aurora DSQL gibt eine Antwort ähnlich der folgenden zurück.

           job_id           |   status   | details 
----------------------------+------------+---------
 vs3kcl3rt5ddpk3a6xcq57cmcy | completed  | 
 ihbyw2aoirfnrdfoc4ojnlamoq | processing | 

Die Statusspalte kann einen der folgenden Werte haben.

Sie können den Status des Indexes auch über die Katalogtabellen pg_index und pg_class abfragen. Insbesondere die Attribute indisvalid und indisimmediate können Ihnen sagen, in welchem Zustand sich Ihr Index befindet. Aurora DSQL erstellt zwar Ihren Index, hat aber den Anfangsstatus. INVALID Das indisvalid Kennzeichen für den Index gibt FALSE oder zurückf, was darauf hinweist, dass der Index nicht gültig ist. Wenn das Flag TRUE oder zurückgibtt, ist der Index bereit.

SELECT relname AS index_name, indisvalid as is_valid, pg_get_indexdef(indexrelid) AS index_definition
from pg_index, pg_class
WHERE pg_class.oid = indexrelid AND indrelid = 'test.departments'::regclass;

    index_name    | is_valid |                                                 index_definition                                                  
------------------+----------+-------------------------------------------------------------------------------------------------------------------
 department_pkey  |     t    | CREATE UNIQUE INDEX department_pkey ON test.departments USING btree_index (title) INCLUDE (name, manager, size)
 test_index1      |     t    | CREATE INDEX test_index1 ON test.departments USING btree_index (name, manager, size)

Fehler bei der Erstellung eines eindeutigen Indexes

Wenn Ihr asynchroner Auftrag zur Erstellung eines eindeutigen Indexes den Status „Fehlgeschlagen“ mit den entsprechenden Details anzeigtFound duplicate key while validating index for UCVs, deutet dies darauf hin, dass ein eindeutiger Index aufgrund von Verstößen gegen Eindeutigkeitsbeschränkungen nicht erstellt werden konnte.

Erkennung von Eindeutigkeitsverletzungen in Primärtabellen

Die folgende SQL-Abfrage hilft Ihnen dabei, doppelte Werte in einer bestimmten Spalte Ihrer Tabelle zu identifizieren. Dies ist besonders nützlich, wenn Sie die Eindeutigkeit einer Spalte erzwingen müssen, die derzeit nicht als Primärschlüssel festgelegt ist oder keine eindeutige Einschränkung hat, wie z. B. E-Mail-Adressen in einer Benutzertabelle.

Die folgenden Beispiele zeigen, wie Sie eine Beispielbenutzertabelle erstellen, sie mit Testdaten füllen, die bekannte Duplikate enthalten, und dann die Erkennungsabfrage ausführen.

Definieren Sie das Tabellenschema

-- Drop the table if it exists
DROP TABLE IF EXISTS users;

-- Create the users table with a simple integer primary key
CREATE TABLE users (
    user_id INTEGER PRIMARY KEY,
    email VARCHAR(255),
    first_name VARCHAR(100),
    last_name VARCHAR(100),
    created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP
);      

Fügen Sie Beispieldaten ein, die Sätze doppelter E-Mail-Adressen enthalten

-- Insert sample data with explicit IDs
INSERT INTO users (user_id, email, first_name, last_name) VALUES
    (1, 'john.doe@example.com', 'John', 'Doe'),
    (2, 'jane.smith@example.com', 'Jane', 'Smith'),
    (3, 'john.doe@example.com', 'Johnny', 'Doe'),
    (4, 'alice.wong@example.com', 'Alice', 'Wong'),
    (5, 'bob.jones@example.com', 'Bob', 'Jones'),
    (6, 'alice.wong@example.com', 'Alicia', 'Wong'),
    (7, 'bob.jones@example.com', 'Robert', 'Jones');

Führen Sie eine Abfrage zur Erkennung doppelter Objekte

-- Query to find duplicates
WITH duplicates AS (
    SELECT email, COUNT(*) as duplicate_count
    FROM users
    GROUP BY email
    HAVING COUNT(*) > 1
)
SELECT u.*, d.duplicate_count
FROM users u
INNER JOIN duplicates d ON u.email = d.email
ORDER BY u.email, u.user_id;

Alle Datensätze mit doppelten E-Mail-Adressen anzeigen

 user_id |         email          | first_name | last_name |         created_at         | duplicate_count 
---------+------------------------+------------+-----------+----------------------------+-----------------
       4 | akua.mansa@example.com | Akua       | Mansa     | 2025-05-21 20:55:53.714432 |               2
       6 | akua.mansa@example.com | Akua       | Mansa     | 2025-05-21 20:55:53.714432 |               2
       1 | john.doe@example.com   | John       | Doe       | 2025-05-21 20:55:53.714432 |               2
       3 | john.doe@example.com   | Johnny     | Doe       | 2025-05-21 20:55:53.714432 |               2
(4 rows)

Wenn wir die Anweisung zur Indexerstellung jetzt ausprobieren würden, würde sie fehlschlagen:

postgres=> CREATE UNIQUE INDEX ASYNC idx_users_email ON users(email);
      job_id      
----------------------------
 ve32upmjz5dgdknpbleeca5tri
(1 row)

postgres=> select * from sys.jobs;
           job_id           |  status   |                       details                       |  job_type   | class_id | object_id |      object_name       |       start_time       |      update_time       
----------------------------+-----------+-----------------------------------------------------+-------------+----------+-----------+------------------------+------------------------+------------------------
 qpn6aqlkijgmzilyidcpwrpova | completed |                                                     | DROP        |     1259 |     26384 |                        | 2025-05-20 00:47:10+00 | 2025-05-20 00:47:32+00
 ve32upmjz5dgdknpbleeca5tri | failed    | Found duplicate key while validating index for UCVs | INDEX_BUILD |     1259 |     26396 | public.idx_users_email | 2025-05-20 00:49:49+00 | 2025-05-20 00:49:56+00
(2 rows)