Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.

Index asynchrones dans Aurora DSQL

La commande CREATE INDEX ASYNC crée un index sur une ou plusieurs colonnes d’une table spécifiée. Cette commande est une opération DDL asynchrone qui ne bloque pas les autres transactions. Lorsque vous exécutez CREATE INDEX ASYNC, Aurora DSQL renvoie immédiatement un job_id.

Vous pouvez surveiller l’état de cette tâche asynchrone à l’aide de la vue système sys.jobs. Pendant que le travail de création d’index est en cours, vous pouvez utiliser les procédures et commandes suivantes :

Lorsqu’Aurora DSQL termine une tâche d’indexation asynchrone, il met à jour le catalogue système pour indiquer que l’index est actif. Si d’autres transactions font référence aux objets du même espace de noms à ce stade, une erreur de simultanéité peut apparaître.

Syntaxe

CREATE INDEX ASYNC utilise la syntaxe suivante.

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

Paramètres

Notes d’utilisation

Considérez les directives suivantes :

Création d’un index : exemple

L’exemple suivant montre comment créer un schéma, une table, puis un index.

Interrogation de l’état de création de l’index : exemple

Interrogez la vue système sys.jobs pour vérifier l’état de création de votre index, comme illustré dans l’exemple suivant.

SELECT * FROM sys.jobs

Aurora DSQL renvoie une réponse semblable à ce qui suit.

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

La colonne d’état peut avoir l’une des valeurs suivantes.

Vous pouvez également interroger l’état de l’index via les tables du catalogue pg_index et pg_class. Plus précisément, les attributs indisvalid et indisimmediate peuvent vous indiquer dans quel état se trouve votre index. Lors de la création de votre index par Aurora DSQL, celui-ci possède l’état initial INVALID. L’indicateur indisvalid de l’index renvoie FALSE ou f, ce qui indique que l’index n’est pas valide. Si l’indicateur revient à TRUE ou t, l’index est prêt.

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)

Défaillances de création d’index uniques

Si votre tâche de création d’index unique asynchrone indique un état d’échec avec le détail Found duplicate key while validating index for UCVs, cela indique qu’un index unique n’a pas pu être créé en raison de violations des contraintes d’unicité.

Détection des violations d’unicité dans les tables principales

La requête SQL suivante vous aide à identifier les valeurs dupliquées dans une colonne spécifiée de votre table. Cela est particulièrement utile lorsque vous devez appliquer l’unicité à une colonne qui n’est pas actuellement définie comme clé primaire ou qui n’a pas de contrainte unique, telle que les adresses e-mail dans une table utilisateur.

Les exemples ci-dessous montrent comment créer un exemple de table des utilisateurs, la remplir avec des données de test contenant des doublons connus, puis exécuter la requête de détection.

Définir le schéma de table

-- 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
);      

Insérer des exemples de données comprenant des ensembles d’adresses e-mail dupliquées

-- 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');

Exécuter une requête de détection des doublons

-- 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;

Afficher tous les enregistrements contenant des adresses e-mail dupliquées

 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)

Si nous devions essayer l’instruction de création d’index maintenant, elle échouerait :

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)