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 CREATE INDEX ASYNC
commande 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écutezCREATE INDEX ASYNC
, Aurora DSQL renvoie immédiatement unjob_id
.
Vous pouvez surveiller l'état de cette tâche asynchrone à l'aide de la vue sys.jobs
système. Pendant que le travail de création d'index est en cours, vous pouvez utiliser les procédures et commandes suivantes :
sys.wait_for_job(job_id)
'your_index_creation_job_id'
-
Bloque la session en cours jusqu'à ce que la tâche spécifiée soit terminée ou échoue. Renvoie une valeur booléenne indiquant le succès ou l'échec.
DROP INDEX
-
Annule une tâche de création d'index en cours.
Lorsque la création de l'index asynchrone est terminée, Aurora DSQL met à jour le catalogue système pour marquer l'index comme actif.
Note
Notez que les transactions simultanées accédant à des objets dans le même espace de noms au cours de cette mise à jour peuvent rencontrer des erreurs de simultanéité.
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 s'afficher.
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
UNIQUE
-
Indique à Aurora DSQL de vérifier la présence de valeurs dupliquées dans la table lors de la création de l'index et à chaque fois que vous ajoutez des données. Si vous spécifiez ce paramètre, les opérations d'insertion et de mise à jour susceptibles d'entraîner des doublons génèrent une erreur.
IF NOT EXISTS
-
Indique qu'Aurora DSQL ne doit pas générer d'exception si un index portant le même nom existe déjà. Dans ce cas, Aurora DSQL ne crée pas le nouvel index. Notez que l'index que vous essayez de créer peut avoir une structure très différente de celle de l'index existant. Si vous spécifiez ce paramètre, le nom de l'index est obligatoire.
name
-
Nom de l'index. Vous ne pouvez pas inclure le nom de votre schéma dans ce paramètre.
Aurora DSQL crée l'index dans le même schéma que sa table parent. Le nom de l'index doit être distinct du nom de tout autre objet, tel qu'une table ou un index, dans le schéma.
Si vous ne spécifiez aucun nom, Aurora DSQL en génère automatiquement un en fonction du nom de la table parent et de la colonne indexée. Par exemple, si vous exécutez
CREATE INDEX ASYNC on table1 (col1, col2)
, Aurora DSQL nomme automatiquement l'indextable1_col1_col2_idx
. NULLS FIRST | LAST
-
Ordre de tri des colonnes nulles et non nulles.
FIRST
indique qu'Aurora DSQL doit trier les colonnes nulles avant les colonnes non nulles.LAST
indique qu'Aurora DSQL doit trier les colonnes nulles après les colonnes non nulles. INCLUDE
-
Liste des colonnes à inclure dans l'index en tant que colonnes non clés. Vous ne pouvez pas utiliser de colonne non clé dans une qualification de recherche par analyse d'index. Aurora DSQL ignore la colonne en termes d'unicité d'un index.
NULLS DISTINCT | NULLS NOT DISTINCT
-
Spécifie si Aurora DSQL doit considérer les valeurs nulles comme distinctes dans un index unique. La valeur par défaut est
DISTINCT
, ce qui signifie qu'un index unique peut contenir plusieurs valeurs nulles dans une colonne.NOT DISTINCT
indique qu'un index ne peut pas contenir plusieurs valeurs nulles dans une colonne.
Notes d’utilisation
Considérez les directives suivantes :
-
La
CREATE INDEX ASYNC
commande n'introduit pas de verrous. Cela n'affecte pas non plus la table de base qu'Aurora DSQL utilise pour créer l'index. -
Lors des opérations de migration de schéma, la
sys.wait_for_job(job_id)
procédure est utile. Cela garantit que les opérations DDL et DML suivantes ciblent l'index nouvellement créé.'your_index_creation_job_id'
-
Chaque fois qu'Aurora DSQL exécute une nouvelle tâche asynchrone, il vérifie la
sys.jobs
vue et supprime les tâches dont le statut est supérieurcompleted
ou égal à 30failed
minutes. Ainsi, affichesys.jobs
principalement les tâches en cours et ne contient aucune information sur les anciennes tâches. -
Si Aurora DSQL ne parvient pas à créer un index asynchrone, l'index est conservé.
INVALID
Pour les index uniques, les opérations DML sont soumises à des contraintes d'unicité jusqu'à ce que vous supprimiez l'index. Nous vous recommandons de supprimer les index non valides et de les recréer.
Création d'un index : exemple
L'exemple suivant montre comment créer un schéma, une table, puis un index.
-
Créez une table nommée
test.departments
.CREATE SCHEMA test; CREATE TABLE test.departments (name varchar(255) primary key NOT null, manager varchar(255), size varchar(4));
-
Insérez une ligne dans le tableau.
INSERT INTO test.departments VALUES ('Human Resources', 'John Doe', '10')
-
Créez un index asynchrone.
CREATE INDEX ASYNC test_index on test.departments(name, manager, size);
La
CREATE INDEX
commande renvoie un identifiant de tâche, comme indiqué ci-dessous.job_id -------------------------- jh2gbtx4mzhgfkbimtgwn5j45y
Cela
job_id
indique qu'Aurora DSQL a soumis une nouvelle tâche pour créer l'index. Vous pouvez utiliser cette procéduresys.wait_for_job(job_id)
pour bloquer d'autres tâches au cours de la session jusqu'à ce qu'elles soient terminées ou expirent.'your_index_creation_job_id'
Interrogation de l'état de création de l'index : exemple
Interrogez la vue sys.jobs
système 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 similaire à la suivante.
job_id | status | details ----------------------------+------------+--------- vs3kcl3rt5ddpk3a6xcq57cmcy | completed | ihbyw2aoirfnrdfoc4ojnlamoq | processing |
La colonne d'état peut prendre l'une des valeurs suivantes.
submitted |
processing |
failed |
completed |
---|---|---|---|
La tâche est envoyée, mais Aurora DSQL n'a pas encore commencé à la traiter. | Aurora DSQL est en train de traiter la tâche. | La tâche a échoué. Consultez la colonne de détails pour plus d'informations. Si Aurora DSQL ne parvient pas à créer l'index, Aurora DSQL ne supprime pas automatiquement la définition de l'index. Vous devez supprimer manuellement l'index à l'aide de la DROP INDEX commande. |
Aurora SQL |
Vous pouvez également demander l'état de l'index via les tables du catalogue pg_index
etpg_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 un statut initial deINVALID
. L'indisvalid
indicateur de l'index renvoie FALSE
ouf
, ce qui indique que l'index n'est pas valide. Si le drapeau revient TRUE
out
, 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 détaillé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é.
Pour résoudre les échecs de création d'index uniques
-
Supprimez toutes les lignes de votre table principale contenant des entrées dupliquées pour les clés spécifiées dans votre index secondaire unique.
-
Supprimez l'index défaillant.
-
Émettez une nouvelle commande de création d'index.
Détecter les 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 d'utilisateurs, le 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)