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.
# Aurora DSQL et PostgreSQL
Aurora DSQL est une base de données relationnelle distribuée compatible avec PostgreSQL conçue pour les charges de travail transactionnelles. Aurora DSQL utilise les principaux composants de PostgreSQL tels que l’analyseur, le planificateur, l’optimiseur et le système de types.
La conception d’Aurora DSQL garantit que toutes les syntaxes PostgreSQL prises en charge fournissent un comportement compatible et produisent des résultats de requête identiques. Par exemple, Aurora DSQL fournit des conversions de type, des opérations arithmétiques, ainsi qu’une précision et une échelle numériques identiques à celles de PostgreSQL. Tout écart est documenté.
Aurora DSQL introduit également des fonctionnalités avancées telles que le contrôle de simultanéité optimisé et la gestion distribuée des schémas. Grâce à ces fonctionnalités, vous pouvez utiliser les outils habituels de PostgreSQL tout en bénéficiant des performances et de l'évolutivité d'applications distribuées modernes, natives du cloud.
## Points forts de la compatibilité avec PostgreSQL
Aurora DSQL est actuellement basé sur la version 16 de PostgreSQL. Les principaux points saillants sont les suivants :
**Protocole filaire**
Aurora DSQL utilise le protocole filaire PostgreSQL v3 standard. Cela permet l’intégration avec les clients, pilotes et outils PostgreSQL standard. Par exemple, Aurora DSQL est compatible avec `psql`, `pgjdbc` et `psycopg`.
**Syntaxe SQL**
Aurora DSQL prend en charge un large éventail d’expressions et de fonctions PostgreSQL standard couramment utilisées dans les charges de travail transactionnelles. Les expressions SQL prises en charge produisent des résultats identiques à ceux de PostgreSQL, notamment :
+ Gestion des valeurs nulles
+ Comportement de tri
+ Mise à l’échelle et précision pour les opérations numériques
+ Équivalence pour les opérations de chaîne
Pour de plus amples informations, veuillez consulter [Compatibilité des fonctionnalités SQL dans Aurora DSQL](working-with-postgresql-compatibility.md).
**Gestion des transactions**
Aurora DSQL préserve les principales caractéristiques de PostgreSQL, telles que les transactions ACID et un niveau d’isolement équivalent à PostgreSQL Repeatable Read. Pour de plus amples informations, veuillez consulter [Contrôle de simultanéité dans Aurora DSQL](working-with-concurrency-control.md).
## Avantages de l'architecture distribuée
La conception distribuée et sans partage d'Aurora DSQL offre des avantages en termes de performances et d'évolutivité par rapport aux bases de données à nœud unique traditionnelles. Les principales fonctionnalités sont les suivantes :
**Contrôle de simultanéité optimiste (OCC)**
Aurora DSQL utilise un modèle de contrôle de simultanéité optimiste. Cette approche sans verrouillage empêche les transactions de se bloquer les unes les autres, élimine les blocages et permet une exécution parallèle à haut débit. Ces fonctionnalités rendent Aurora DSQL particulièrement utile pour les applications nécessitant des performances constantes à grande échelle. Pour obtenir plus d’exemples, consultez [Contrôle de simultanéité dans Aurora DSQL](working-with-concurrency-control.md).
**Opérations DDL asynchrones**
Aurora DSQL exécute les opérations DDL de manière asynchrone, ce qui permet des lectures et des écritures ininterrompues lors des modifications du schéma. Son architecture distribuée permet à Aurora DSQL d’effectuer les actions suivantes :
+ Exécuter les opérations DDL en tant que tâches de fond, afin de minimiser les perturbations.
+ Coordonner les modifications du catalogue sous forme de transactions distribuées hautement cohérentes. Cela garantit une visibilité atomique sur tous les nœuds, même en cas de défaillance ou d’opérations simultanées.
+ Opérez de manière entièrement distribuée et autonome sur plusieurs zones de disponibilité grâce à des couches de calcul et de stockage découplées.
Pour en savoir plus sur l'utilisation de la commande EXPLAIN dans PostgreSQL, consultez. [Transactions DDL et distribuées dans Aurora DSQL](working-with-ddl.md)
# Compatibilité des fonctionnalités SQL dans Aurora DSQL
Dans les sections suivantes, découvrez la prise en charge par Aurora DSQL des types de données et des commandes SQL de PostgreSQL.
**Topics**
+ [Types de données pris en charge dans Aurora DSQL](working-with-postgresql-compatibility-supported-data-types.md)
+ [SQL pris en charge pour Aurora DSQL](working-with-postgresql-compatibility-supported-sql-features.md)
+ [Sous-ensembles de commandes SQL pris en charge dans Aurora DSQL](working-with-postgresql-compatibility-supported-sql-subsets.md)
+ [Migration de PostgreSQL vers Aurora DSQL](working-with-postgresql-compatibility-migration-guide.md)
# Types de données pris en charge dans Aurora DSQL
Aurora DSQL prend en charge un sous-ensemble des types PostgreSQL courants.
**Topics**
+ [Types de données numériques](#numeric-data-types)
+ [Types de données de caractères](#character-data-types)
+ [Types de données de date et d’heure](#date-time-data-types)
+ [Types de données divers](#miscellaneous-data-types)
+ [Types de données d’exécution des requêtes](#working-with-postgresql-compatibility-query-runtime)
## Types de données numériques
Aurora DSQL supporte les types de données numériques PostgreSQL suivants.
| Nom | les alias ; | Plage et précision | Taille de stockage | Prise en charge de l’index |
| --- | --- | --- | --- | --- |
| smallint | int2 | -32768 à \$132767 | 2 octets | Oui |
| `integer` | `int`, `int4` | -2147483648 à \$12147483647 | 4 octets | Oui |
| `bigint` | `int8` | -9223372036854775808 à \$19223372036854775807 | 8 octets | Oui |
| `real` | `float4` | Précision à 6 chiffres décimaux | 4 octets | Oui |
| `double precision` | `float8` | Précision à 15 chiffres décimaux | 8 octets | Oui |
| `numeric` [ `(`*p*, *s*`)` ] | `decimal` [ `(`*p*, *s*`)` ] `dec`[ `(`*p*,*s*`)`] | Chiffre exact dont la précision peut être choisie. La précision maximale est de 38 et l’échelle maximale est de 371. La valeur par défaut est `numeric (18,6)`. | 8 octets \$1 2 octets par chiffre de précision. La taille maximale est de 27 octets. | Oui |
1 – Si vous ne spécifiez pas explicitement une taille lorsque vous exécutez `CREATE TABLE` ou `ALTER TABLE ADD COLUMN`, Aurora DSQL applique les valeurs par défaut. Aurora DSQL applique des limites lorsque vous exécutez des instructions `INSERT` ou `UPDATE`.
## Types de données de caractères
Aurora DSQL prend en charge les types de données de caractères PostgreSQL suivants.
| Nom | les alias ; | Description | Limites d’Aurora DSQL | Taille de stockage | Prise en charge de l’index |
| --- | --- | --- | --- | --- | --- |
| `character` [ `(`*n*`)` ] | `char` [ `(`*n*`)` ] | Chaîne de caractères de longueur fixe | 4 096 octets1 | Variable jusqu’à 4 100 octets | Oui |
| `character varying` [ `(`*n*`)` ] | `varchar` [ `(`*n*`)` ] | Chaîne de caractères de longueur variable | 65 535 octets1 | Variable jusqu’à 65 539 octets | Oui |
| `bpchar` [ `(`*n*`)` ] | | Si la longueur est fixe, il s’agit d’un alias pour `char`. Si la longueur est variable, il s’agit d’un alias pour `varchar`, où les espaces de fin sont sémantiquement insignifiants. | 4 096 octets1 | Variable jusqu’à 4 100 octets | Oui |
| `text` | | Chaîne de caractères de longueur variable | 1 MiO1 | Variable jusqu’à 1 MiO | Oui |
1 – Si vous ne spécifiez pas explicitement une taille lorsque vous exécutez `CREATE TABLE` ou `ALTER TABLE ADD COLUMN`, Aurora DSQL applique les valeurs par défaut. Aurora DSQL applique des limites lorsque vous exécutez des instructions `INSERT` ou `UPDATE`.
## Types de données de date et d’heure
Aurora DSQL prend en charge les types de données de date et d’heure PostgreSQL suivants.
| Nom | les alias ; | Description | Range | Résolution | Taille de stockage | Prise en charge de l’index |
| --- | --- | --- | --- | --- | --- | --- |
| `date` | | Date calendaire (année, mois, jour) | 4713 BC — 5874897 AD | 1 jour | 4 octets | Oui |
| `time` [ `(`*p*`)` ] [ `without time zone` ] | `timestamp` | Heure du jour, sans fuseau horaire | 0 – 1 | 1 microseconde | 8 octets | Oui |
| `time` [ `(`*p*`)` ] `with time zone` | `timetz` | heure du jour, avec le fuseau horaire | 00:00:00\$11559 – 24:00:00 –1559 | 1 microseconde | 12 octets | Non |
| `timestamp` [ `(`*p*`)` ] [ `without time zone` ] | | Date et heure, sans fuseau horaire | 4713 BC — 294276 AD | 1 microseconde | 8 octets | Oui |
| `timestamp` [ `(`*p*`)` ] `with time zone` | `timestamptz` | Date et heure, avec le fuseau horaire | 4713 BC — 294276 AD | 1 microseconde | 8 octets | Oui |
| `interval` [ `fields` ] [ `(`*p*`)` ] | | Durée | -178000000 ans — 178000000 ans | 1 microseconde | 16 octets | Non |
## Types de données divers
Aurora DSQL prend en charge les types de données PostgreSQL divers suivants.
| Nom | les alias ; | Description | Limites d’Aurora DSQL | Taille de stockage | Prise en charge de l’index |
| --- | --- | --- | --- | --- | --- |
| `boolean` | `bool` | Booléen logique (true/false) | | 1 octet | Oui |
| `bytea` | | Données binaires (« tableau d’octets ») | 1 MiO1 | Variable jusqu’à la limite de 1 MiO | Non |
| `UUID` | | Identifiant unique et universel | | 16 octets | Oui |
1 – Si vous ne spécifiez pas explicitement une taille lorsque vous exécutez `CREATE TABLE` ou `ALTER TABLE ADD COLUMN`, Aurora DSQL applique les valeurs par défaut. Aurora DSQL applique des limites lorsque vous exécutez des instructions `INSERT` ou `UPDATE`.
## Types de données d’exécution des requêtes
Les types de données d’exécution des requêtes sont des types de données internes utilisés au moment de l’exécution des requêtes. Ces types sont distincts des types compatibles avec PostgreSQL tels que `varchar` et `integer` que vous définissez dans votre schéma. Ces types sont plutôt des représentations d’exécution qu’Aurora DSQL utilise lors du traitement d’une requête.
Les types de données suivants sont pris en charge uniquement pendant l’exécution des requêtes :
**Type de tableau**
Aurora DSQL prend en charge les tableaux des types de données pris en charge. Par exemple, vous pouvez avoir un tableau d’entiers. La fonction `string_to_array` divise une chaîne en un tableau de style PostgreSQL avec la virgule de séparation (`,`), comme indiqué dans l’exemple suivant. Vous pouvez utiliser des tableaux dans des expressions, des sorties de fonctions ou des calculs temporaires lors de l’exécution de requêtes.
```
SELECT string_to_array('1,2', ',');
```
La fonction renvoie une réponse similaire à la réponse suivante :
```
string_to_array
-----------------
{1,2}
(1 row)
```
****type d’inet****
Le type de données représente IPv4 les adresses IPv6 d'hôtes et leurs sous-réseaux. Ce type est utile pour analyser des journaux, filtrer sur des sous-réseaux IP ou effectuer des calculs réseau dans le cadre d’une requête. Pour plus d’informations, consultez [inet dans la documentation de PostgreSQL](https://www.PostgreSQL.org/docs/16/datatype-net-types.html#DATATYPE-INET).
**Fonctions d’exécution JSON**
Aurora DSQL prend en charge JSON et JSONB en tant que types de données d'exécution pour le traitement des requêtes. Stockez les données JSON sous forme de `text` colonnes et convertissez-les en JSON lors de l'exécution de la requête afin d'utiliser les fonctions et les opérateurs JSON de PostgreSQL.
Aurora DSQL prend en charge la plupart des fonctions JSON de PostgreSQL de la [section 9.1.6 Fonctions et opérateurs JSON](https://www.postgresql.org/docs/current/functions-json.html) avec un comportement identique.
Les fonctions qui renvoient des types JSON ou JSONB peuvent nécessiter une conversion `text` supplémentaire pour un affichage correct.
```
SELECT json_build_array(1, 2, 'foo', 4, 5)::text;
```
La fonction renvoie une réponse similaire à la réponse suivante :
```
json_build_array
---------------------
[1, 2, "foo", 4, 5]
(1 row)
```
# SQL pris en charge pour Aurora DSQL
Aurora DSQL prend en charge un large éventail de fonctionnalités SQL PostgreSQL de base. Dans les sections suivantes, vous trouverez des informations sur la prise en charge générale des expressions de PostgreSQL. Cette liste n’est pas exhaustive.
## Commande `SELECT`
Aurora DSQL prend en charge les clauses suivantes de la commande `SELECT`.
| Clause principale | Clauses prises en charge |
| --- | --- |
| `FROM` | |
| `GROUP BY` | `ALL`, `DISTINCT` |
| `ORDER BY` | `ASC`, `DESC`, `NULLS` |
| `LIMIT` | |
| `DISTINCT` | |
| `HAVING` | |
| `USING` | |
| `WITH` (expressions de table communes) | |
| `INNER JOIN` | `ON` |
| `OUTER JOIN` | `LEFT`, `RIGHT`, `FULL`, `ON` |
| `CROSS JOIN` | `ON` |
| `UNION` | `ALL` |
| `INTERSECT` | `ALL` |
| `EXCEPT` | `ALL` |
| `OVER` | `RANK ()`, `PARTITION BY` |
| `FOR UPDATE` | |
## Langage de définition de données (DDL)
Aurora DSQL prend en charge les commandes DDL PostgreSQL suivantes.
| Commande | Clause principale | Clauses prises en charge |
| --- | --- | --- |
| `CREATE` | `TABLE` | Pour plus d’informations sur la syntaxe de la commande `CREATE TABLE` prise en charge, consultez [`CREATE TABLE`](create-table-syntax-support.md). |
| `ALTER` | `TABLE` | Pour plus d’informations sur la syntaxe de la commande `ALTER TABLE` prise en charge, consultez [`ALTER TABLE`](alter-table-syntax-support.md). |
| `DROP` | `TABLE` | |
| `CREATE` | `[UNIQUE] INDEX ASYNC` | Vous pouvez utiliser cette commande avec les paramètres suivants : `ON`, `NULLS FIRST`, `NULLS LAST`. Pour plus d’informations sur la syntaxe de la commande `CREATE INDEX ASYNC` prise en charge, consultez [Index asynchrones dans Aurora DSQL](working-with-create-index-async.md). |
| `DROP` | `INDEX` | |
| `CREATE` | `VIEW` | Pour plus d’informations sur la syntaxe de la commande `CREATE VIEW` prise en charge, consultez [`CREATE VIEW`](create-view.md). |
| ALTER | VIEW | Pour plus d’informations sur la syntaxe de la commande `ALTER VIEW` prise en charge, consultez [`ALTER VIEW`](alter-view-syntax-support.md). |
| DROP | VIEW | Pour plus d’informations sur la syntaxe de la commande DROP VIEW prise en charge, consultez [`DROP VIEW`](drop-view-overview.md). |
| `CREATE` | `SEQUENCE` | Pour plus d’informations sur la syntaxe de la commande `CREATE SEQUENCE` prise en charge, consultez [`CREATE SEQUENCE`](create-sequence-syntax-support.md). |
| `ALTER` | `SEQUENCE` | Pour plus d’informations sur la syntaxe de la commande `ALTER SEQUENCE` prise en charge, consultez [`ALTER SEQUENCE`](alter-sequence-syntax-support.md). |
| `DROP` | `SEQUENCE` | Pour plus d’informations sur la syntaxe de la commande `DROP SEQUENCE` prise en charge, consultez [`DROP SEQUENCE`](drop-sequence-syntax-support.md). |
| `CREATE` | `ROLE`, `WITH` | |
| `CREATE` | `FUNCTION` | `LANGUAGE SQL` |
| `CREATE` | `DOMAIN` | |
## Langage de manipulation de données (DML)
Aurora DSQL prend en charge les commandes DML PostgreSQL suivantes.
| Commande | Clause principale | Clauses prises en charge |
| --- | --- | --- |
| `INSERT` | `INTO` | `VALUES`SELECT |
| `UPDATE` | `SET` | `WHERE (SELECT)` `FROM, WITH` |
| DELETE | FROM | USING, WHERE |
## Langage de contrôle des données (DCL)
Aurora DSQL prend en charge les commandes DCL PostgreSQL suivantes.
| Commande | Clauses prises en charge |
| --- | --- |
| `GRANT` | `ON`, `TO` |
| `REVOKE` | `ON`, `FROM`, `CASCADE`, `RESTRICT` |
## Langage de contrôle des transactions (TCL)
Aurora DSQL prend en charge les commandes TCL PostgreSQL suivantes.
| Commande | Clauses prises en charge | Alias |
| --- | --- | --- |
| `COMMIT` | [`WORK` \$1 `TRANSACTION`] [`AND NO CHAIN`] | `END` |
| `BEGIN` | [`WORK` \$1 `TRANSACTION`] [`ISOLATION LEVEL REPEATABLE READ`] [`READ WRITE` \$1 `READ ONLY`] | |
| `START TRANSACTION` | [`ISOLATION LEVEL REPEATABLE READ`] [`READ WRITE` \$1 `READ ONLY`] | |
| `ROLLBACK` | [`WORK` \$1 `TRANSACTION`] [`AND NO CHAIN`] | `ABORT` |
## Commandes d’utilitaire
Aurora DSQL prend en charge les commandes d’utilitaire PostgreSQL suivantes.
+ `EXPLAIN`
+ `ANALYZE` (nom de relation uniquement)
# Sous-ensembles de commandes SQL pris en charge dans Aurora DSQL
Cette section fournit des informations détaillées sur les commandes SQL prises en charge, en se concentrant sur les commandes comportant de nombreux ensembles de paramètres et sous-commandes. Par exemple, CREATE TABLE dans PostgreSQL propose de nombreuses clauses et paramètres, dont un sous-ensemble est pris en charge par Aurora DSQL. Cette section décrit les sous-ensembles de commandes SQL courantes pris en charge à l'aide d'éléments de syntaxe PostgreSQL courants pris en charge par Aurora DSQL.
**Topics**
+ [`CREATE TABLE`](create-table-syntax-support.md)
+ [`ALTER TABLE`](alter-table-syntax-support.md)
+ [`CREATE SEQUENCE`](create-sequence-syntax-support.md)
+ [`ALTER SEQUENCE`](alter-sequence-syntax-support.md)
+ [`DROP SEQUENCE`](drop-sequence-syntax-support.md)
+ [`CREATE VIEW`](create-view.md)
+ [`ALTER VIEW`](alter-view-syntax-support.md)
+ [`DROP VIEW`](drop-view-overview.md)
# `CREATE TABLE`
`CREATE TABLE` définit une nouvelle table.
```
CREATE TABLE [ IF NOT EXISTS ] table_name ( [
{ column_name data_type [ column_constraint [ ... ] ]
| table_constraint
| LIKE source_table [ like_option ... ] }
[, ... ]
] )
where column_constraint is:
[ CONSTRAINT constraint_name ]
{ NOT NULL |
NULL |
CHECK ( expression )|
DEFAULT default_expr |
GENERATED ALWAYS AS ( generation_expr ) STORED |
GENERATED { ALWAYS | BY DEFAULT } AS IDENTITY ( sequence_options ) |
UNIQUE [ NULLS [ NOT ] DISTINCT ] index_parameters |
PRIMARY KEY index_parameters |
and table_constraint is:
[ CONSTRAINT constraint_name ]
{ CHECK ( expression ) |
UNIQUE [ NULLS [ NOT ] DISTINCT ] ( column_name [, ... ] ) index_parameters |
PRIMARY KEY ( column_name [, ... ] ) index_parameters |
and like_option is:
{ INCLUDING | EXCLUDING } { COMMENTS | CONSTRAINTS | DEFAULTS | GENERATED | IDENTITY | INDEXES | STATISTICS | ALL }
index_parameters in UNIQUE, and PRIMARY KEY constraints are:
[ INCLUDE ( column_name [, ... ] ) ]
```
## Colonnes d'identité
**Note**
Lorsque vous utilisez des colonnes d'identité, la valeur du cache doit être soigneusement prise en compte. Pour plus d'informations, consultez la légende Important sur la [`CREATE SEQUENCE`](create-sequence-syntax-support.md) page.
Pour obtenir des conseils sur la meilleure façon d'utiliser les colonnes d'identité en fonction des modèles de charge de travail, voir[Utilisation de séquences et de colonnes d'identité](sequences-identity-columns-working-with.md).
La `GENERATED { ALWAYS | BY DEFAULT } AS IDENTITY ( sequence_options )` clause crée la colonne en tant que *colonne d'identité*. Une séquence implicite y sera attachée et dans les lignes nouvellement insérées, la colonne contiendra automatiquement les valeurs de la séquence qui lui est attribuée. Une telle colonne l'est implicitement`NOT NULL`.
Les clauses `ALWAYS` et `BY DEFAULT` déterminent la manière dont les valeurs spécifiées explicitement par l'utilisateur sont traitées dans `UPDATE` les commandes `INSERT` et.
Dans une `INSERT` commande, si elle `ALWAYS` est sélectionnée, une valeur spécifiée par l'utilisateur n'est acceptée que si l'`INSERT`instruction le précise`OVERRIDING SYSTEM VALUE`. Si cette option `BY DEFAULT` est sélectionnée, la valeur spécifiée par l'utilisateur est prioritaire.
Dans une `UPDATE` commande, si elle `ALWAYS` est sélectionnée, toute mise à jour de la colonne vers une valeur autre que `DEFAULT` sera rejetée. Si cette option `BY DEFAULT` est sélectionnée, la colonne peut être mise à jour normalement. (Il n'y a aucune `OVERRIDING` clause pour la `UPDATE` commande.)
La *sequence\$1options* clause peut être utilisée pour remplacer les paramètres de la séquence. Les options disponibles incluent celles indiquées pour[`CREATE SEQUENCE`](create-sequence-syntax-support.md), plus`SEQUENCE NAME name`. Sans`SEQUENCE NAME`, le système choisit un nom inutilisé pour la séquence.
# `ALTER TABLE`
`ALTER TABLE` modifie la définition d’une table.
```
ALTER TABLE [ IF EXISTS ] [ ONLY ] name [ * ]
action [, ... ]
ALTER TABLE [ IF EXISTS ] [ ONLY ] name [ * ]
RENAME [ COLUMN ] column_name TO new_column_name
ALTER TABLE [ IF EXISTS ] [ ONLY ] name [ * ]
RENAME CONSTRAINT constraint_name TO new_constraint_name
ALTER TABLE [ IF EXISTS ] name
RENAME TO new_name
ALTER TABLE [ IF EXISTS ] name
SET SCHEMA new_schema
where action is one of:
ADD [ COLUMN ] [ IF NOT EXISTS ] column_name data_type
ALTER [ COLUMN ] column_name { SET GENERATED { ALWAYS | BY DEFAULT } | SET sequence_option | RESTART [ [ WITH ] restart ] } [...]
ALTER [ COLUMN ] column_name DROP IDENTITY [ IF EXISTS ]
OWNER TO { new_owner | CURRENT_ROLE | CURRENT_USER | SESSION_USER }
```
## Actions relatives à la colonne d'identité
**`SET GENERATED { ALWAYS | BY DEFAULT }` / `SET sequence_option` / `RESTART`**
Ces formulaires permettent de déterminer si une colonne est une colonne d'identité ou de modifier l'attribut de génération d'une colonne d'identité existante. Consultez [`CREATE TABLE`](create-table-syntax-support.md) pour plus de détails. Par exemple`SET DEFAULT`, ces formulaires n'affectent que le comportement `INSERT` des `UPDATE` commandes suivantes ; ils ne modifient pas les lignes déjà présentes dans le tableau.
*sequence\$1option*Il s'agit d'une option prise en charge par [`ALTER SEQUENCE`](alter-sequence-syntax-support.md) tel que`INCREMENT BY`. Ces formulaires modifient la séquence qui sous-tend une colonne d'identité existante.
**`DROP IDENTITY [ IF EXISTS ]`**
Ce formulaire supprime la propriété d'identité d'une colonne. Si elle `DROP IDENTITY IF EXISTS` est spécifiée et que la colonne n'est pas une colonne d'identité, aucune erreur n'est renvoyée. Dans ce cas, un avis est émis à la place.
# `CREATE SEQUENCE`
`CREATE SEQUENCE`— définit un nouveau générateur de séquences.
**Important**
Dans PostgreSQL, la `CACHE` spécification est facultative et la valeur par défaut est 1. Dans un système distribué tel qu'Amazon Aurora DSQL, les opérations de séquence impliquent une coordination, et une taille de cache de 1 peut augmenter la charge de coordination en cas de forte simultanéité. Alors que des valeurs de cache plus importantes permettent de servir des numéros de séquence à partir de plages préallouées localement, ce qui améliore le débit, les valeurs réservées non utilisées peuvent être perdues, ce qui rend les écarts et les effets d'ordre plus visibles. Étant donné que la sensibilité des applications à l'ordre d'allocation diffère de celle du débit, Amazon Aurora DSQL doit `CACHE` être spécifiée de manière explicite et prend actuellement en charge `CACHE = 1` ou`CACHE >= 65536`, en établissant une distinction claire entre un comportement d'allocation proche de la génération strictement séquentielle et une allocation optimisée pour des charges de travail hautement simultanées.
Lorsque l'`CACHE >= 65536`unicité des valeurs de séquence reste garantie, mais qu'elles peuvent ne pas être générées dans un ordre strictement croissant d'une session à l'autre, des écarts peuvent survenir, en particulier lorsque les valeurs mises en cache ne sont pas entièrement consommées. Ces caractéristiques sont cohérentes avec la sémantique de PostgreSQL pour les séquences mises en cache utilisées simultanément, où les deux systèmes garantissent des valeurs distinctes mais ne garantissent pas un ordre strictement séquentiel entre les sessions.
Au cours d'une seule session client, les valeurs de séquence peuvent ne pas toujours apparaître strictement croissantes, en particulier en dehors des transactions explicites. Ce comportement est similaire à celui des déploiements PostgreSQL qui utilisent le regroupement de connexions. Un comportement d'allocation plus proche de celui d'un environnement PostgreSQL mono-session peut être obtenu en `CACHE = 1` utilisant ou en obtenant des valeurs de séquence dans le cadre de transactions explicites.
Avec`CACHE = 1`, l'allocation de séquences suit le comportement des séquences non mises en cache de PostgreSQL.
Pour obtenir des conseils sur la meilleure façon d'utiliser les séquences basées sur les modèles de charge de travail, voir[Utilisation de séquences et de colonnes d'identité](sequences-identity-columns-working-with.md).
## Syntaxe prise en charge
```
CREATE SEQUENCE [ IF NOT EXISTS ] name CACHE cache
[ AS data_type ]
[ INCREMENT [ BY ] increment ]
[ MINVALUE minvalue | NO MINVALUE ] [ MAXVALUE maxvalue | NO MAXVALUE ]
[ [ NO ] CYCLE ]
[ START [ WITH ] start ]
[ OWNED BY { table_name.column_name | NONE } ]
where data_type is BIGINT
and cache = 1 or cache >= 65536
```
## Description
`CREATE SEQUENCE`crée un nouveau générateur de numéros de séquence. Cela implique la création et l'initialisation d'une nouvelle table spéciale à une seule ligne portant le nom. *name* Le générateur appartiendra à l'utilisateur qui émet la commande.
Si un nom de schéma est donné, la séquence est créée dans le schéma spécifié. Dans le cas contraire, il est créé dans le schéma actuel. Le nom de séquence doit être distinct du nom de toute autre relation (table, séquence, index, vue, vue matérialisée ou table étrangère) dans le même schéma.
Une fois qu'une séquence est créée, vous utilisez les fonctions `nextval``currval`, et `setval` pour opérer sur la séquence. Ces fonctions sont documentées dans[Fonctions de manipulation de séquence](sequence-functions-syntax-support.md).
Bien que vous ne puissiez pas mettre à jour une séquence directement, vous pouvez utiliser une requête telle que :
```
SELECT * FROM name;
```
pour examiner certains paramètres et l'état actuel d'une séquence. En particulier, le `last_value` champ de la séquence indique la dernière valeur allouée par une session. (Bien entendu, cette valeur peut être obsolète au moment de son impression, si d'autres sessions effectuent activement des `nextval` appels.) D'autres paramètres tels que *increment* et *maxvalue* peuvent être observés dans la `pg_sequences` vue.
## Parameters
**`IF NOT EXISTS`**
Ne renvoie pas d'erreur si une relation portant le même nom existe déjà. Un avis est émis dans ce cas. Notez qu'il n'y a aucune garantie que la relation existante ressemble à la séquence qui aurait été créée ; ce n'est peut-être même pas une séquence.
***name***
Nom (éventuellement qualifié par schéma) de la séquence à créer.
***data\$1type***
La clause facultative `AS data_type` spécifie le type de données de la séquence. Les types valides sont`bigint`. `bigint`est la valeur par défaut. Le type de données détermine les valeurs minimale et maximale par défaut de la séquence.
***increment***
La clause facultative `INCREMENT BY increment` indique quelle valeur est ajoutée à la valeur de séquence actuelle pour créer une nouvelle valeur. Une valeur positive fera une séquence ascendante, une valeur négative une séquence descendante. La valeur par défaut est 1.
***minvalue* / `NO MINVALUE`**
La clause facultative `MINVALUE minvalue` détermine la valeur minimale qu'une séquence peut générer. Si cette clause n'est pas fournie ou `NO MINVALUE` est spécifiée, les valeurs par défaut seront utilisées. La valeur par défaut pour une séquence ascendante est 1. La valeur par défaut pour une séquence descendante est la valeur minimale du type de données.
***maxvalue* / `NO MAXVALUE`**
La clause facultative `MAXVALUE maxvalue` détermine la valeur maximale de la séquence. Si cette clause n'est pas fournie ou `NO MAXVALUE` est spécifiée, les valeurs par défaut seront utilisées. La valeur par défaut pour une séquence ascendante est la valeur maximale du type de données. La valeur par défaut pour une séquence descendante est -1.
**`CYCLE` / `NO CYCLE`**
L'`CYCLE`option permet à la séquence de s'enrouler lorsque le *maxvalue* ou *minvalue* a été atteint par une séquence ascendante ou descendante respectivement. Si la limite est atteinte, le prochain nombre généré sera respectivement *maxvalue* le *minvalue* ou.
Si `NO CYCLE` cette option est spécifiée, tout appel effectué une `nextval` fois que la séquence a atteint sa valeur maximale renverra une erreur. Si aucun des deux `CYCLE` ou `NO CYCLE` n'est spécifié, `NO CYCLE` c'est la valeur par défaut.
***start***
La clause facultative `START WITH start` permet à la séquence de commencer n'importe où. La valeur de départ par défaut est *minvalue* pour les séquences ascendantes et *maxvalue* pour les séquences descendantes.
***cache***
La clause `CACHE cache` indique le nombre de numéros de séquence à préallouer et à stocker en mémoire pour un accès plus rapide. Les valeurs acceptables pour Aurora `CACHE` DSQL sont 1 ou n'importe quel nombre >= 65536. La valeur minimale est 1 (une seule valeur peut être générée à la fois, ce qui signifie qu'il n'y a pas de cache).
**`OWNED BY table_name.column_name` / `OWNED BY NONE`**
`OWNED BY`Cette option permet d'associer la séquence à une colonne de table spécifique, de sorte que si cette colonne (ou le tableau entier) est supprimée, la séquence sera également automatiquement supprimée. La table spécifiée doit avoir le même propriétaire et être dans le même schéma que la séquence. `OWNED BY NONE`, valeur par défaut, indique qu'il n'existe aucune association de ce type.
## Remarques
[`DROP SEQUENCE`](drop-sequence-syntax-support.md)À utiliser pour supprimer une séquence.
Les séquences étant basées sur l'`bigint`arithmétique, la plage ne peut pas dépasser la plage d'un entier de huit octets (-9223372036854775808 à 9223372036854775807).
Comme `nextval` les `setval` appels ne sont jamais annulés, les objets de séquence ne peuvent pas être utilisés si l'attribution « sans interruption » de numéros de séquence est nécessaire.
Chaque session allouera et mettra en cache les valeurs de séquence successives lors d'un accès à l'objet de séquence et augmentera celles de l'objet de séquence `last_value` en conséquence. Ensuite, les *cache* -1 utilisations suivantes de `nextval` cette session renvoient simplement les valeurs préallouées sans toucher à l'objet de séquence. Ainsi, tous les numéros alloués mais non utilisés au cours d'une session seront perdus à la fin de cette session, ce qui entraînera des « trous » dans la séquence.
En outre, bien que plusieurs sessions soient garanties pour allouer des valeurs de séquence distinctes, les valeurs peuvent être générées hors séquence lorsque toutes les sessions sont prises en compte. Par exemple, avec un *cache* paramètre de 10, la session A peut réserver les valeurs 1.. 10 et renvoyer `nextval` =1, puis la session B peut réserver les valeurs 11.. 20 et renvoyer `nextval` =11 avant que la session A n'ait généré `nextval` =2. Ainsi, avec un *cache* paramètre égal à un, on peut supposer sans risque de se tromper que `nextval` les valeurs sont générées de manière séquentielle ; avec un *cache* paramètre supérieur à un, vous devez uniquement supposer que les `nextval` valeurs sont toutes distinctes, et non qu'elles sont générées de manière purement séquentielle. En outre, `last_value` reflétera la dernière valeur réservée par une session, qu'elle ait déjà été renvoyée ou non`nextval`.
Une autre considération est qu'une `setval` exécution sur une telle séquence ne sera pas remarquée par les autres sessions tant qu'elles n'auront pas utilisé les valeurs préallouées qu'elles ont mises en cache.
## Exemples
Créez une séquence ascendante appelée`serial`, à partir de 101 :
```
CREATE SEQUENCE serial CACHE 65536 START 101;
```
Sélectionnez le numéro suivant dans cette séquence :
```
SELECT nextval('serial');
nextval
---------
101
```
Sélectionnez le numéro suivant dans cette séquence :
```
SELECT nextval('serial');
nextval
---------
102
```
Utilisez cette séquence dans une `INSERT` commande :
```
INSERT INTO distributors VALUES (nextval('serial'), 'nothing');
```
Réinitialisez la séquence à une valeur spécifique en utilisant `setval` :
```
SELECT setval('serial', 200);
SELECT nextval('serial');
nextval
---------
201
```
## Compatibilité
`CREATE SEQUENCE`est conforme à la norme SQL, avec les exceptions suivantes :
+ L'obtention de la valeur suivante s'effectue à l'aide de la `nextval()` fonction plutôt que de l'`NEXT VALUE FOR`expression de la norme.
+ La `OWNED BY` clause est une extension PostgreSQL.
# `ALTER SEQUENCE`
`ALTER SEQUENCE`— modifie la définition d'un générateur de séquences.
**Important**
Lorsque vous utilisez des séquences, la valeur du cache doit être soigneusement prise en compte. Pour plus d'informations, consultez la légende Important sur la [`CREATE SEQUENCE`](create-sequence-syntax-support.md) page.
Pour obtenir des conseils sur la meilleure façon d'utiliser les séquences basées sur les modèles de charge de travail, voir[Utilisation de séquences et de colonnes d'identité](sequences-identity-columns-working-with.md).
## Syntaxe prise en charge
```
ALTER SEQUENCE [ IF EXISTS ] name
[ INCREMENT [ BY ] increment ]
[ MINVALUE minvalue | NO MINVALUE ] [ MAXVALUE maxvalue | NO MAXVALUE ]
[ [ NO ] CYCLE ]
[ START [ WITH ] start ]
[ RESTART [ [ WITH ] restart ] ]
[ CACHE cache ]
[ OWNED BY { table_name.column_name | NONE } ]
ALTER SEQUENCE [ IF EXISTS ] name OWNER TO { new_owner | CURRENT_ROLE | CURRENT_USER | SESSION_USER }
ALTER SEQUENCE [ IF EXISTS ] name RENAME TO new_name
ALTER SEQUENCE [ IF EXISTS ] name SET SCHEMA new_schema
where cache is 1 or cache >= 65536
```
## Description
`ALTER SEQUENCE`modifie les paramètres d'un générateur de séquences existant. Tous les paramètres qui ne sont pas spécifiquement définis dans la `ALTER SEQUENCE` commande conservent leurs paramètres antérieurs.
Vous devez être propriétaire de la séquence à utiliser`ALTER SEQUENCE`. Pour modifier le schéma d'une séquence, vous devez également disposer de `CREATE` privilèges sur le nouveau schéma. Pour modifier le propriétaire, vous devez être en mesure d'`SET ROLE`accéder au nouveau rôle propriétaire, et ce rôle doit disposer de `CREATE` privilèges sur le schéma de la séquence. (Ces restrictions font en sorte que le fait de modifier le propriétaire n'a aucun effet que vous ne pourriez pas faire en supprimant et en recréant la séquence. Cependant, un superutilisateur peut de toute façon modifier la propriété de n'importe quelle séquence.)
## Parameters
***name***
Nom (éventuellement qualifié par schéma) d'une séquence à modifier.
**`IF EXISTS`**
Ne renvoie pas d'erreur si la séquence n'existe pas. Un avis est émis dans ce cas.
***increment***
La clause `INCREMENT BY increment` est facultative. Une valeur positive fera une séquence ascendante, une valeur négative une séquence descendante. Si elle n'est pas spécifiée, l'ancienne valeur d'incrément sera conservée.
***minvalue* / `NO MINVALUE`**
La clause facultative `MINVALUE minvalue` détermine la valeur minimale qu'une séquence peut générer. Si elle `NO MINVALUE` est spécifiée, la valeur par défaut de 1 et la valeur minimale du type de données pour les séquences ascendantes et descendantes, respectivement, seront utilisées. Si aucune option n'est spécifiée, la valeur minimale actuelle sera maintenue.
***maxvalue* / `NO MAXVALUE`**
La clause facultative `MAXVALUE maxvalue` détermine la valeur maximale de la séquence. Si `NO MAXVALUE` cette option est spécifiée, les valeurs par défaut de la valeur maximale du type de données et de -1 pour les séquences ascendantes et descendantes, respectivement, seront utilisées. Si aucune option n'est spécifiée, la valeur maximale actuelle sera maintenue.
**`CYCLE`**
Le mot `CYCLE` clé facultatif peut être utilisé pour permettre à la séquence de s'enrouler lorsque le *maxvalue* ou *minvalue* a été atteint par une séquence ascendante ou descendante respectivement. Si la limite est atteinte, le prochain nombre généré sera respectivement *maxvalue* le *minvalue* ou.
**`NO CYCLE`**
Si le mot `NO CYCLE` clé facultatif est spécifié, tout appel effectué `nextval` après que la séquence a atteint sa valeur maximale renverra une erreur. Si aucun `CYCLE` `NO CYCLE` des deux n'est spécifié, le comportement de l'ancien cycle sera conservé.
***start***
La clause facultative `START WITH start` modifie la valeur de départ enregistrée de la séquence. Cela n'a aucun effet sur la valeur de séquence actuelle ; cela définit simplement la valeur que `ALTER SEQUENCE RESTART` les futures commandes utiliseront.
***restart***
La clause facultative `RESTART [ WITH restart ]` modifie la valeur actuelle de la séquence. Cela revient à appeler la `setval` fonction avec `is_called` = `false` : la valeur spécifiée sera renvoyée lors du prochain appel de`nextval`. Écrire `RESTART` sans *restart* valeur équivaut à fournir la valeur de départ enregistrée par `CREATE SEQUENCE` ou définie pour la dernière fois par`ALTER SEQUENCE START WITH`.
Contrairement à un `setval` appel, une `RESTART` opération sur une séquence est transactionnelle et empêche les transactions simultanées d'obtenir des numéros à partir de la même séquence. Si ce n'est pas le mode de fonctionnement souhaité, `setval` il doit être utilisé.
***cache***
La clause `CACHE cache` permet de préallouer les numéros de séquence et de les stocker en mémoire pour un accès plus rapide. La valeur doit être soit 1, soit une valeur >= 65536. Si elle n'est pas spécifiée, l'ancienne valeur du cache sera conservée. Pour plus d'informations sur le comportement du cache, consultez les instructions ci-dessous[`CREATE SEQUENCE`](create-sequence-syntax-support.md).
**`OWNED BY table_name.column_name` / `OWNED BY NONE`**
`OWNED BY`Cette option permet d'associer la séquence à une colonne de table spécifique, de sorte que si cette colonne (ou le tableau entier) est supprimée, la séquence sera également automatiquement supprimée. Si elle est spécifiée, cette association remplace toute association précédemment spécifiée pour la séquence. La table spécifiée doit avoir le même propriétaire et être dans le même schéma que la séquence. La spécification `OWNED BY NONE` supprime toute association existante, rendant la séquence « autonome ».
***new\$1owner***
Le nom d'utilisateur du nouveau propriétaire de la séquence.
***new\$1name***
Le nouveau nom de la séquence.
***new\$1schema***
Le nouveau schéma de la séquence.
## Remarques
`ALTER SEQUENCE`n'affectera pas immédiatement les `nextval` résultats dans les backends, autres que celui en cours, qui ont des valeurs de séquence préallouées (mises en cache). Ils utiliseront toutes les valeurs mises en cache avant de remarquer les paramètres de génération de séquence modifiés. Le backend actuel sera immédiatement affecté.
`ALTER SEQUENCE`n'affecte pas le `currval` statut de la séquence.
`ALTER SEQUENCE`peut entraîner d'autres transactions pour OCC.
Pour des raisons historiques, il `ALTER TABLE` peut également être utilisé avec des `ALTER TABLE` séquences ; mais les seules variantes autorisées avec des séquences sont équivalentes aux formes présentées ci-dessus.
## Exemples
Redémarrer une séquence appelée`serial`, à 105 :
```
ALTER SEQUENCE serial RESTART WITH 105;
```
## Compatibilité
`ALTER SEQUENCE`est conforme à la norme SQL, à l'exception des `SET SCHEMA` clauses`AS`,`START WITH`,`OWNED BY`,`OWNER TO`, et`RENAME TO`, qui sont des extensions PostgreSQL.
# `DROP SEQUENCE`
`DROP SEQUENCE`— supprime une séquence.
## Syntaxe prise en charge
```
DROP SEQUENCE [ IF EXISTS ] name [, ...] [ CASCADE | RESTRICT ]
```
## Description
`DROP SEQUENCE`supprime les générateurs de numéros de séquence. Une séquence ne peut être supprimée que par son propriétaire ou par un superutilisateur.
## Parameters
**`IF EXISTS`**
Ne renvoie pas d'erreur si la séquence n'existe pas. Un avis est émis dans ce cas.
***name***
Le nom (éventuellement qualifié par un schéma) d'une séquence.
**`CASCADE`**
Supprimez automatiquement les objets qui dépendent de la séquence et, à leur tour, tous les objets qui dépendent de ces objets.
**`RESTRICT`**
Refusez de supprimer la séquence si des objets en dépendent. Il s’agit de l’option par défaut.
## Exemples
Pour supprimer la séquence, procédez comme suit `seq` :
```
DROP SEQUENCE seq;
```
## Compatibilité
`DROP SEQUENCE`est conforme à la norme SQL, sauf que la norme ne permet de supprimer qu'une seule séquence par commande, et à l'exception de l'`IF EXISTS`option, qui est une extension PostgreSQL.
# `CREATE VIEW`
`CREATE VIEW` définit une nouvelle vue persistante. Aurora DSQL ne prend pas en charge les vues temporaires ; seules les vues permanentes sont prises en charge.
## Syntaxe prise en charge
```
CREATE [ OR REPLACE ] [ RECURSIVE ] VIEW name [ ( column_name [, ...] ) ]
[ WITH ( view_option_name [= view_option_value] [, ... ] ) ]
AS query
[ WITH [ CASCADED | LOCAL ] CHECK OPTION ]
```
## Description
`CREATE VIEW` définit une vue d’une requête. La vue n’est pas matérialisée physiquement. Au lieu de cela, la requête est exécutée chaque fois que la vue est référencée dans une requête.
`CREATE or REPLACE VIEW` est similaire, mais si une vue du même nom existe déjà, elle est remplacée. La nouvelle requête doit générer les mêmes colonnes que celles générées par la requête de vue existante (c’est-à-dire les mêmes noms de colonnes dans le même ordre et avec les mêmes types de données), mais elle peut ajouter des colonnes supplémentaires à la fin de la liste. Les calculs à l’origine des colonnes de sortie peuvent être différents.
Si un nom de schéma est fourni (tel que `CREATE VIEW myschema.myview ...`), la vue est créée dans le schéma spécifié. Sinon, elle est créée dans le schéma en cours.
Le nom de la vue doit être distinct du nom de toute autre relation (table, index, vue) dans le même schéma.
## Parameters
`CREATE VIEW` prend en charge divers paramètres de contrôle du comportement des vues pouvant être mises à jour automatiquement.
**`RECURSIVE`**
Crée une vue récursive. La syntaxe : `CREATE RECURSIVE VIEW [ schema . ] view_name (column_names) AS SELECT ...;` est équivalente à `CREATE VIEW [ schema . ] view_name AS WITH RECURSIVE view_name (column_names) AS (SELECT ...) SELECT column_names FROM view_name;`.
Une liste de noms de colonnes de vue doit être spécifiée pour une vue récursive.
**`name`**
Le nom de la vue à créer, qui peut éventuellement être qualifié de schéma. Une liste de noms de colonnes doit être spécifiée pour une vue récursive.
**`column_name`**
Liste facultative des noms à utiliser pour les colonnes de la vue. Si elle n’est pas fournie, les noms de colonnes sont déduits de la requête.
**`WITH ( view_option_name [= view_option_value] [, ... ] )`**
Cette clause spécifie des paramètres facultatifs pour une vue ; les paramètres suivants sont pris en charge.
+ `check_option (enum)` : ce paramètre peut être `local` ou `cascaded` et équivaut à la spécification `WITH [ CASCADED | LOCAL ] CHECK OPTION`.
+ `security_barrier (boolean)` : cela doit être utilisé si la vue est destinée à fournir une sécurité au niveau des lignes. Aurora DSQL ne prend actuellement pas en charge la sécurité au niveau des lignes, mais cette option obligera tout de même à évaluer d'`WHERE`abord les conditions de la vue (et toutes les conditions utilisant des opérateurs marqués comme`LEAKPROOF`).
+ `security_invoker (boolean)` : cette option permet de vérifier les relations de base sous-jacentes en fonction des privilèges de l’utilisateur de la vue plutôt que du propriétaire de la vue. Pour plus de détails, consultez les notes ci-dessous.
Toutes les options ci-dessus peuvent être modifiées sur les vues existantes à l’aide de `ALTER VIEW`.
**`query`**
Une `VALUES` commande `SELECT` ou qui fournira les colonnes et les lignes de la vue.
**`WITH [ CASCADED | LOCAL ] CHECK OPTION`**
Cette option contrôle le comportement des vues actualisables automatiquement. Lorsque cette option est spécifiée, les commandes `INSERT` et `UPDATE` de la vue sont vérifiées pour s’assurer que les nouvelles lignes répondent à la condition définissant la vue (c’est-à-dire que les nouvelles lignes sont vérifiées pour s’assurer qu’elles sont visibles dans la vue). Dans le cas contraire, la mise à jour sera rejetée. Si l’option `CHECK OPTION` n’est pas spécifiée, les commandes `INSERT` et `UPDATE` de la vue sont autorisées à créer des lignes qui ne sont pas visibles dans la vue.
`LOCAL` : les nouvelles lignes ne sont vérifiées que par rapport aux conditions définies directement dans la vue elle-même. Les conditions définies sur les vues de base sous-jacentes ne sont pas vérifiées (sauf si elles spécifient également `CHECK OPTION`).
`CASCADED` : les nouvelles lignes sont vérifiées en fonction des conditions de la vue et de toutes les vues de base sous-jacentes. Si l’option `CHECK OPTION` est spécifiée et que ni `LOCAL` ni `CASCADED` n’est spécifié, alors `CASCADED` est supposé.
L’option `CHECK OPTION` ne peut pas être utilisée avec les vues `RECURSIVE`. L’option `CHECK OPTION` est uniquement pris en charge que sur les vues qui peuvent être mises à jour automatiquement.
## Remarques
Utilisez l’instruction `DROP VIEW` pour supprimer des vues.
Les noms et les types de données des colonnes de la vue doivent être soigneusement étudiés. Par exemple, CREATE VIEW vista AS SELECT « Hello World; » n’est pas recommandé, car le nom de colonne par défaut est `?column?;`. De plus, le type de données de colonne par défaut est `text`, ce qui n’est peut-être pas ce que vous vouliez.
Une meilleure approche consiste à spécifier explicitement le nom de la colonne et le type de données, tels que : `CREATE VIEW vista AS SELECT text 'Hello World' AS hello;`.
Par défaut, l’accès aux relations de base sous-jacentes référencées dans la vue est déterminé par les autorisations du propriétaire de la vue. Dans certains cas, cela peut être utilisé pour fournir un accès sécurisé, mais restreint aux tables sous-jacentes. Cependant, toutes les vues ne sont pas protégées contre la falsification.
+ Si la propriété `security_invoker` de la vue est définie sur true, l’accès aux relations de base sous-jacentes est déterminé par les autorisations de l’utilisateur qui exécute la requête plutôt que par celles de la vue. Ainsi, l’utilisateur d’une vue d’invocation de sécurité doit disposer des autorisations appropriées sur la vue et ses relations de base sous-jacentes.
+ Si l’une des relations de base sous-jacentes est une vue d’invocation de sécurité, elle sera traitée comme si elle avait été accessible directement depuis la requête d’origine. Ainsi, une vue d’invocation de sécurité vérifiera toujours ses relations de base sous-jacentes à l’aide des autorisations de l’utilisateur actuel, même si elle est accessible depuis une vue dépourvue de la propriété `security_invoker`.
+ Les fonctions appelées dans la vue sont traitées de la même manière que si elles avaient été appelées directement depuis la requête utilisant la vue. Par conséquent, l’utilisateur d’une vue doit être autorisé à appeler toutes les fonctions utilisées par la vue. Les fonctions de la vue sont exécutées avec les privilèges de l’utilisateur exécutant la requête ou du propriétaire de la fonction, selon que les fonctions sont définies comme `SECURITY INVOKER` ou `SECURITY DEFINER`.
+ L’utilisateur qui crée ou remplace une vue doit disposer de privilèges `USAGE` sur tous les schémas auxquels il est fait référence dans la requête de la vue, afin de pouvoir rechercher les objets référencés dans ces schémas.
+ Lorsque `CREATE OR REPLACE VIEW` est utilisé sur une vue existante, seule la règle `SELECT` de la vue, ainsi que les paramètres `WITH ( ... )` et son option `CHECK OPTION` sont modifiés. Les autres propriétés de la vue, notamment la propriété, les autorisations et les règles autres que SELECT, restent inchangées. Vous devez être propriétaire de la vue pour la remplacer (cela inclut le fait d’être membre du rôle propriétaire).
## Vues qui peuvent être mises à jour
Les vues simples peuvent être mises à jour automatiquement : le système autorisera l’utilisation des instructions `INSERT`, `UPDATE` et `DELETE` sur la vue de la même manière que sur une table normale. Une vue peut être automatiquement mise à jour si elle répond à toutes les conditions suivantes :
+ La vue doit comporter exactement une entrée dans sa liste `FROM`, qui doit être une table ou une autre vue pouvant être mise à jour.
+ La définition de la vue ne doit pas contenir de clauses `WITH`, `DISTINCT`, `GROUP BY`, `HAVING`, `LIMIT` ni `OFFSET` au niveau supérieur.
+ La définition de la vue ne doit pas contenir d’opération définies (`UNION`, `INTERSECT` ni `EXCEPT`) au niveau supérieur.
+ La liste de sélection de la vue ne doit pas contenir d’agrégats, de fonctions de fenêtrage ni de fonctions à renvoi d’ensemble.
Une vue pouvant être automatiquement mise à jour peut contenir un mélange de colonnes pouvant et ne pouvant pas être mises à jour. Une colonne peut être mise à jour s’il s’agit d’une simple référence à une colonne pouvant être mise à jour de la relation de base sous-jacente. Dans le cas contraire, la colonne est en lecture seule et une erreur se produit si une instruction `INSERT` ou `UPDATE` tente de lui attribuer une valeur.
Une vue plus complexe qui ne répond pas à toutes ces conditions est en lecture seule par défaut : le système n’autorise pas l’insertion, la mise à jour ni la suppression de la vue.
**Note**
L’utilisateur qui effectue l’insertion, la mise à jour ou la suppression de la vue doit disposer du privilège d’insertion, de mise à jour ou de suppression de la vue correspondant. Par défaut, le propriétaire de la vue doit avoir les privilèges nécessaires sur les relations de base sous-jacentes, tandis que l’utilisateur qui effectue la mise à jour n’a besoin d’aucune autorisation sur les relations de base sous-jacentes. Toutefois, si security\$1invoker est défini sur true pour la vue, c’est l’utilisateur qui effectue la mise à jour, plutôt que le propriétaire de la vue, qui doit disposer des privilèges appropriés sur les relations de base sous-jacentes.
## Exemples
Création d’une vue comprenant tous les films comiques.
```
CREATE VIEW comedies AS
SELECT *
FROM films
WHERE kind = 'Comedy';
```
Créer une vue avec `LOCAL CHECK OPTION`.
```
CREATE VIEW pg_comedies AS
SELECT *
FROM comedies
WHERE classification = 'PG'
WITH CASCADED CHECK OPTION;
```
Créez une vue récursive.
```
CREATE RECURSIVE VIEW public.nums_1_100 (n) AS
VALUES (1)
UNION ALL
SELECT n+1 FROM nums_1_100 WHERE n < 100;
```
## Compatibilité
`CREATE OR REPLACE VIEW` est une extension du langage PostgreSQL. La clause `WITH ( ... )` est également une extension, tout comme les vues des barrières de sécurité et les vues d’invocation de sécurité. Aurora DSQL prend en charge ces extensions de langage.
# `ALTER VIEW`
L’instruction `ALTER VIEW` permet de modifier diverses propriétés d’une vue existante, et Aurora DSQL prend en charge l’ensemble de la syntaxe PostgreSQL pour cette commande.
## Syntaxe prise en charge
```
ALTER VIEW [ IF EXISTS ] name ALTER [ COLUMN ] column_name SET DEFAULT expression
ALTER VIEW [ IF EXISTS ] name ALTER [ COLUMN ] column_name DROP DEFAULT
ALTER VIEW [ IF EXISTS ] name OWNER TO { new_owner | CURRENT_ROLE | CURRENT_USER | SESSION_USER }
ALTER VIEW [ IF EXISTS ] name RENAME [ COLUMN ] column_name TO new_column_name
ALTER VIEW [ IF EXISTS ] name RENAME TO new_name
ALTER VIEW [ IF EXISTS ] name SET SCHEMA new_schema
ALTER VIEW [ IF EXISTS ] name SET ( view_option_name [= view_option_value] [, ... ] )
ALTER VIEW [ IF EXISTS ] name RESET ( view_option_name [, ... ] )
```
## Description
`ALTER VIEW`modifie diverses propriétés auxiliaires d'une vue. (Si vous souhaitez modifier la requête de définition de la vue, utilisez`CREATE OR REPLACE VIEW`.) Vous devez être propriétaire de la vue pour pouvoir l'utiliser`ALTER VIEW`. Pour modifier le schéma d’une vue, vous devez également disposer du privilège `CREATE` sur le nouveau schéma. Pour modifier le propriétaire, vous devez être en mesure de `SET ROLE` sur le nouveau rôle propriétaire, et ce rôle doit disposer du privilège `CREATE` sur le schéma de la vue.
## Parameters
**`name`**
Nom (éventuellement qualifié selon le schéma) d’une vue existante.
**`column_name`**
Nom d'une colonne existante ou nouveau nom pour une colonne existante.
**`IF EXISTS`**
Ne génère pas d’erreur si la vue n’existe pas. Un avis est émis dans ce cas.
**`SET/DROP DEFAULT`**
Ces formulaires définissent ou suppriment la valeur par défaut d’une colonne. La valeur par défaut d’une colonne de vue est remplacée dans toute commande `INSERT` ou `UPDATE` dont la cible est la vue.
**`new_owner`**
Nom d’utilisateur du nouveau propriétaire de la vue.
**`new_name`**
Nouveau nom de la vue.
**`new_schema`**
Nouveau schéma de la vue.
**`SET ( view_option_name [= view_option_value] [, ... ] )`**
Définit une option d'affichage. Les options suivantes sont prises en charge :
+ `check_option (enum)` : modifie l’option de vérification de la vue. La valeur doit être `local` ou `cascaded`.
+ `security_barrier (boolean)` : modifie la propriété de barrière de sécurité de la vue.
+ `security_invoker (boolean)`- Modifie la propriété security-invoker de la vue.
**`RESET ( view_option_name [, ... ] )`**
Rétablit la valeur par défaut d'une option d'affichage.
## Exemples
Renommer la vue `foo` en `bar` :
```
ALTER VIEW foo RENAME TO bar;
```
Attacher une valeur de colonne par défaut à une vue modifiable :
```
CREATE TABLE base_table (id int, ts timestamptz);
CREATE VIEW a_view AS SELECT * FROM base_table;
ALTER VIEW a_view ALTER COLUMN ts SET DEFAULT now();
INSERT INTO base_table(id) VALUES(1); -- ts will receive a NULL
INSERT INTO a_view(id) VALUES(2); -- ts will receive the current time
```
## Compatibilité
`ALTER VIEW` est une extension PostgreSQL de la norme SQL prise en charge par Aurora DSQL.
# `DROP VIEW`
L’instruction `DROP VIEW` supprime une vue existante. Aurora DSQL prend en charge la syntaxe PostgreSQL complète pour cette commande.
## Syntaxe prise en charge
```
DROP VIEW [ IF EXISTS ] name [, ...] [ CASCADE | RESTRICT ]
```
## Description
`DROP VIEW` supprime une vue existante. Pour exécuter cette commande, vous devez être propriétaire de la vue.
## Parameters
**`IF EXISTS`**
Ne génère pas d’erreur si la vue n’existe pas. Un avis est émis dans ce cas.
**`name`**
Nom (éventuellement qualifié selon le schéma) d’une vue à supprimer.
**`CASCADE`**
Supprime automatiquement les objets qui dépendent de la vue (comme d’autres vues), puis tous les objets qui dépendent de ces objets.
**`RESTRICT`**
Refuser de supprimer la vue si des objets en dépendent. Il s’agit de l’option par défaut.
## Exemples
```
DROP VIEW kinds;
```
## Compatibilité
Cette commande est conforme à la norme SQL, sauf que la norme n’autorise la suppression que d’une seule vue par commande, et à part l’option `IF EXISTS`, qui est une extension PostgreSQL prise en charge par Aurora DSQL.
# Migration de PostgreSQL vers Aurora DSQL
Aurora DSQL est conçu pour être compatible avec [PostgreSQL](working-with-postgresql-compatibility.md) et prend en charge les fonctionnalités relationnelles de base telles que les transactions ACID, les index secondaires, les jointures et les opérations DML standard. La plupart des applications PostgreSQL existantes peuvent migrer vers Aurora DSQL avec un minimum de modifications.
Cette section fournit des conseils pratiques pour la migration de votre application vers Aurora DSQL, notamment la compatibilité du framework, les modèles de migration et les considérations architecturales.
## Compatibilité avec le framework et l'ORM
Aurora DSQL utilise le protocole filaire standard de PostgreSQL, garantissant ainsi la compatibilité avec les pilotes et les frameworks PostgreSQL. Les plus courants ORMs fonctionnent avec Aurora DSQL avec peu ou pas de modifications. Voir [Adaptateurs et dialectes Aurora DSQL](aws-sdks.md#aurora-dsql-adapters) pour les implémentations de référence et les intégrations ORM disponibles.
## Schémas de migration courants
Lors de la migration de PostgreSQL vers Aurora DSQL, certaines fonctionnalités fonctionnent différemment ou ont une syntaxe alternative. Cette section fournit des conseils sur les scénarios de migration courants.
### Alternatives de fonctionnement du DDL
Aurora DSQL propose des alternatives modernes aux opérations DDL PostgreSQL traditionnelles :
**Création d'index**
À utiliser `CREATE INDEX ASYNC` plutôt que `CREATE INDEX` pour la création d'index non bloquants.
**Avantage :** création d'index sans interruption sur de grandes tables.
**Suppression des données**
Utiliser `DELETE FROM table_name` au lieu de`TRUNCATE`.
**Alternative :** Pour une récréation complète de la table, utilisez `DROP TABLE` puis`CREATE TABLE`.
**Configuration du système**
Aurora DSQL étant entièrement géré, la configuration est gérée automatiquement en fonction des modèles de charge de travail. Utilisez la console AWS de gestion ou l'API pour gérer les paramètres du cluster.
**Avantage :** pas besoin de réglage de la base de données ou de gestion des paramètres.
### Modèles de conception de schémas
Adaptez ces modèles PostgreSQL courants pour assurer la compatibilité avec Aurora DSQL :
**Modèles d'intégrité référentiels**
Aurora DSQL prend en charge les relations et les `JOIN` opérations entre les tables. Pour garantir l'intégrité référentielle, implémentez la validation dans votre couche d'application. Cette conception s'aligne sur les modèles de bases de données distribuées modernes dans lesquels la validation de la couche application apporte plus de flexibilité et évite les problèmes de performance liés aux opérations en cascade.
**Modèle :** implémentez des contrôles d'intégrité référentielle dans votre couche d'application en utilisant des conventions de dénomination, une logique de validation et des limites de transaction cohérentes. De nombreuses applications à grande échelle préfèrent cette approche pour un meilleur contrôle de la gestion des erreurs et des performances.
**Traitement temporaire des données**
Utilisez CTEs des sous-requêtes ou des tables ordinaires avec une logique de nettoyage au lieu de tables temporaires.
**Alternative :** créez des tables avec des noms spécifiques à la session et nettoyez-les dans votre application.
## Comprendre les différences architecturales
L'architecture distribuée et sans serveur d'Aurora DSQL se distingue intentionnellement de PostgreSQL traditionnel dans plusieurs domaines. Ces différences permettent d'exploiter les principaux avantages d'Aurora DSQL en termes de simplicité et d'évolutivité.
### Modèle de base de données simplifié
**Base de données unique par cluster**
Aurora DSQL fournit une base de données intégrée nommée `postgres` par cluster.
**Conseil de migration :** si votre application utilise plusieurs bases de données, créez des clusters Aurora DSQL distincts pour une séparation logique ou utilisez des schémas au sein d'un seul cluster.
**Pas de tables temporaires**
Pour le traitement des données temporaires, vous DEVEZ utiliser des expressions de table (CTEs) et des sous-requêtes communes, qui fournissent des alternatives flexibles pour les requêtes complexes.
**Alternative :** à utiliser CTEs avec des `WITH` clauses pour des ensembles de résultats temporaires ou avec des tables ordinaires avec un nom unique pour les données spécifiques à la session.
**Gestion automatique du stockage**
Aurora DSQL élimine les tablespaces et la gestion manuelle du stockage. Le stockage s'adapte et s'optimise automatiquement en fonction de vos modèles de données.
**Avantage :** il n'est pas nécessaire de surveiller l'espace disque, de planifier l'allocation de stockage ou de gérer les configurations des tablespaces.
### Modèles d'application modernes
Aurora DSQL encourage les modèles de développement d'applications modernes qui améliorent la maintenabilité et les performances :
**Logique au niveau de l'application plutôt que des déclencheurs de base de données**
Pour une fonctionnalité similaire à un déclencheur, implémentez une logique pilotée par les événements dans votre couche d'application.
**Stratégie de migration :** déplacez la logique de déclenchement vers le code de l'application, utilisez des architectures axées sur les événements avec des AWS services tels que EventBridge, ou implémentez des pistes d'audit à l'aide de la journalisation des applications.
**Fonctions SQL pour le traitement des données**
Aurora DSQL prend en charge les fonctions basées sur SQL, mais pas les langages procéduraux tels que PL/pgSQL.
**Alternative :** utilisez des fonctions SQL pour les transformations de données ou déplacez une logique complexe vers votre couche d'application ou vos fonctions AWS Lambda.
**Un contrôle de simultanéité optimiste au lieu d'un verrouillage pessimiste**
Aurora DSQL utilise un contrôle de simultanéité optimiste (OCC), une approche sans verrou qui diffère des mécanismes de verrouillage de base de données traditionnels. Au lieu d'acquérir des verrous qui bloquent d'autres transactions, Aurora DSQL permet aux transactions de se poursuivre sans blocage et détecte les conflits au moment de la validation. Cela élimine les blocages et empêche les transactions lentes de bloquer d'autres opérations.
**Principale différence :** en cas de conflit, Aurora DSQL renvoie une erreur de sérialisation plutôt que d'obliger les transactions à attendre le verrouillage. Cela nécessite que les applications mettent en œuvre une logique de nouvelle tentative, similaire à la gestion des délais de verrouillage dans les bases de données traditionnelles, mais les conflits sont résolus immédiatement au lieu de provoquer des blocages d'attente.
**Modèle de conception :** implémentez une logique de transaction idempotente avec des mécanismes de nouvelle tentative. Concevez des schémas pour minimiser les conflits en utilisant des clés primaires aléatoires et en répartissant les mises à jour sur l'ensemble de votre plage de clés. Pour en savoir plus, consultez [Contrôle de simultanéité dans Aurora DSQL](working-with-concurrency-control.md).
**Relations et intégrité référentielle**
Aurora DSQL prend en charge les relations de clé étrangère entre les tables, y compris les ` JOIN ` opérations. Pour garantir l'intégrité référentielle, implémentez la validation dans votre couche d'application. Bien que le renforcement de l'intégrité référentielle puisse être utile, les opérations en cascade (comme les suppressions en cascade) peuvent créer des problèmes de performances inattendus. Par exemple, la suppression d'une commande comportant 1 000 articles devient une transaction de 1 001 lignes. C'est pourquoi de nombreux clients évitent les contraintes liées aux clés étrangères.
**Modèle de conception :** implémentez des contrôles d'intégrité référentiels dans votre couche d'application, utilisez d'éventuels modèles de cohérence ou tirez parti des AWS services pour la validation des données.
### Simplifications opérationnelles
Aurora DSQL élimine de nombreuses tâches de maintenance de base de données traditionnelles, réduisant ainsi les frais d'exploitation :
**Aucune maintenance manuelle requise**
Aurora DSQL gère automatiquement l'optimisation du stockage, la collecte de statistiques et le réglage des performances. Les commandes de maintenance traditionnelles telles que celles-ci `VACUUM` sont gérées par le système.
**Avantage :** élimine le besoin de fenêtres de maintenance des bases de données, de planification du vide et de réglage des paramètres système.
**Partitionnement et mise à l'échelle automatiques**
Aurora DSQL partitionne et distribue automatiquement vos données en fonction des modèles d'accès. Généré par l' UUIDs utilisateur ou généré par l'application IDs pour une distribution optimale.
**Conseil de migration :** supprimez la logique de partitionnement manuel et laissez Aurora DSQL gérer la distribution des données. Généré par l' UUIDs utilisateur ou généré par l'application IDs pour une distribution optimale. Si votre application nécessite des identifiants séquentiels, consultez. [Séquences et colonnes d'identité](sequences-identity-columns.md)
# Migration agentic avec des outils d'IA
Les agents de codage AI peuvent accélérer votre migration vers Aurora DSQL en analysant les schémas, en transformant le code et en exécutant des migrations DDL avec des contrôles de sécurité intégrés.
## Utilisation de Kiro pour la migration
Les agents de codage tels que [Kiro](https://kiro.dev/) peuvent vous aider à analyser et à migrer votre code PostgreSQL vers Aurora DSQL :
+ **Analyse du schéma :** téléchargez vos fichiers de schéma existants et demandez à Kiro d'identifier les problèmes de compatibilité potentiels et de suggérer des alternatives
+ **Transformation du code :** fournissez le code de votre application et demandez à Kiro de vous aider à refactoriser la logique de déclenchement, à remplacer des séquences par des séquences ou à modifier UUIDs les modèles de transaction
+ **Planification de la migration :** demandez à Kiro de créer un plan de step-by-step migration basé sur l'architecture spécifique de votre application
+ **Migrations DDL :** exécutez des modifications de schéma à l'aide du modèle de recréation de table avec contrôles de sécurité intégrés et vérification utilisateur
**Exemples d'instructions :**
```
"Analyze this PostgreSQL schema for DSQL compatibility and suggest alternatives for any unsupported features"
"Help me refactor this trigger function into application-level logic for DSQL migration"
"Create a migration checklist for moving my Django application from PostgreSQL to DSQL"
"Drop the legacy_status column from the orders table"
"Change the price column from VARCHAR to DECIMAL in the products table"
```
## Migration DDL avec recréation de tables
Lorsque vous utilisez des agents d'intelligence artificielle avec le serveur Aurora DSQL MCP, certaines opérations ALTER TABLE utilisent un *modèle de recréation de table* qui migre vos données en toute sécurité. L'agent gère la complexité tout en vous tenant informé à chaque étape.
Les opérations suivantes utilisent le modèle de recréation des tables :
| Opération | Approche |
| --- | --- |
| DROP COLUMN | Exclure la colonne du nouveau tableau |
| ALTER COLUMN TYPE | Type de données Cast pendant la migration |
| ALTER COLUMN SET/DROP NOT NULL | Contrainte de modification dans la nouvelle définition de table |
| ALTER COLUMN SET/DROP DEFAULT | Définir la valeur par défaut dans la nouvelle définition de table |
| ADD/DROP CONSTRAINT | Inclure ou supprimer une contrainte dans le nouveau tableau |
| MODIFY PRIMARY KEY | Définissez un nouveau PK avec validation de l'unicité |
| Diviser/fusionner des colonnes | Utilisez SPLIT\$1PART, SUBSTRING ou CONCAT |
Les opérations ALTER TABLE suivantes sont prises en charge directement sans recréation de table :
+ `ALTER TABLE ... RENAME COLUMN`— Renommer une colonne
+ `ALTER TABLE ... RENAME TO`— Renommer une table
+ `ALTER TABLE ... ADD COLUMN`— Ajoute une nouvelle colonne
**Caractéristiques de sécurité :** lors de l'exécution de migrations DDL, les agents d'intelligence artificielle présentent le plan de migration, vérifient la compatibilité des données, confirment le nombre de lignes et demandent une approbation explicite avant toute opération destructrice telle que DROP TABLE.
**Migrations par lots :** pour les tables de plus de 3 000 lignes, l'agent répartit automatiquement la migration par lots de 500 à 1 000 lignes afin de respecter les limites de transaction.
## Serveur Aurora SQL MCP
Le serveur Aurora DSQL Model Context Protocol (MCP) permet aux assistants IA de se connecter directement à votre cluster Aurora DSQL et de rechercher la documentation Aurora DSQL. Cela permet à l'IA de :
+ Analysez votre schéma existant et suggérez des modifications de migration
+ Exécutez des migrations DDL avec le modèle de recréation de tables
+ Tester les requêtes et vérifier la compatibilité lors de la migration
+ Fournissez des up-to-date conseils précis basés sur la dernière documentation d'Aurora DSQL
Pour utiliser le serveur Aurora DSQL MCP avec des assistants AI, consultez les instructions de configuration du serveur [Aurora DSQL MCP.](SECTION_aurora-dsql-mcp-server.md)
## Considérations relatives à Aurora DSQL pour la compatibilité avec PostgreSQL
La prise en charge des fonctionnalités d'Aurora DSQL présente des différences par rapport à PostgreSQL autogéré, qui permettent son architecture distribuée, son fonctionnement sans serveur et son dimensionnement automatique. La plupart des applications fonctionnent dans les limites de ces différences sans modification.
Pour des considérations générales, consultez [Considérations relatives à l’utilisation d Amazon Aurora DSQL](considerations.md). Pour les quotas et les limites, consultez [Quotas de cluster et limites de base de données dans Amazon Aurora DSQL](CHAP_quotas.md).
+ Aurora DSQL utilise une seule base de données intégrée nommée `postgres` par cluster. Pour une séparation logique, créez des clusters Aurora DSQL distincts ou utilisez des schémas au sein d'un seul cluster.
+ La `postgres` base de données utilise le codage de caractères UTF-8, qui fournit une large prise en charge des caractères internationaux.
+ La base de données utilise uniquement le classement `C`.
+ Aurora DSQL utilise `UTC` comme fuseau horaire du système. Postgres stocke toutes les dates et heures tenant compte du fuseau horaire en interne en UTC. Vous pouvez définir le paramètre de `TimeZone` configuration pour convertir la façon dont il est affiché pour le client et servir de valeur par défaut pour les entrées du client que le serveur utilisera pour convertir en UTC en interne.
+ Le niveau d’isolement des transactions est défini dans PostgreSQL `Repeatable Read`.
+ Les transactions sont soumises aux contraintes suivantes :
+ Les opérations DDL et DML nécessitent des transactions distinctes
+ Une transaction ne peut inclure qu’une seule instruction DDL
+ Une transaction peut modifier jusqu’à 3 000 lignes, quel que soit le nombre d’index secondaires
+ La limite de 3 000 lignes s’applique à toutes les instructions DML (`INSERT`, `UPDATE`, `DELETE`)
+ Les connexions à la base de données expirent au bout d’une heure.
+ Aurora DSQL gère les autorisations par le biais d'autorisations au niveau du schéma. Les utilisateurs administrateurs créent des schémas à l'aide de `CREATE SCHEMA` et accordent l'accès à l'aide `GRANT USAGE ON SCHEMA` de. Les utilisateurs administrateurs gèrent les objets dans le schéma public, tandis que les utilisateurs non administrateurs créent des objets dans des schémas créés par les utilisateurs pour définir clairement les limites de propriété. Pour de plus amples informations, veuillez consulter [Autoriser les rôles de la base de données à utiliser SQL dans votre base de données](using-database-and-iam-roles.md#using-database-and-iam-roles-custom-database-roles-sql).
## Vous avez besoin d'aide pour la migration ?
Si vous rencontrez des fonctionnalités essentielles pour votre migration mais qui ne sont pas actuellement prises en charge dans Aurora DSQL, consultez [Fournir des commentaires sur Amazon Aurora DSQL](providing-feedback.md) pour savoir comment partager des commentaires avec AWS.
# Contrôle de simultanéité dans Aurora DSQL
La simultanéité permet à plusieurs sessions d’accéder aux données et de les modifier simultanément sans compromettre l’intégrité et la cohérence des données. Aurora DSQL assure la [compatibilité avec PostgreSQL](https://docs.aws.amazon.com/aurora-dsql/latest/userguide/working-with-postgresql-compatibility.html) tout en mettant en œuvre un mécanisme de contrôle de simultanéité moderne et sans verrou. Aurora DSQL assure une conformité totale à ACID grâce à l’isolement des instantanés, garantissant ainsi la cohérence et la fiabilité des données.
L’un des principaux avantages d’Aurora DSQL est son architecture sans verrou, qui élimine les problèmes courants liés aux performances des bases de données. Aurora DSQL empêche les transactions lentes de bloquer d’autres opérations et élimine le risque de blocages. Cette approche rend Aurora DSQL particulièrement utile pour les applications à haut débit où les performances et la capacité de mise à l’échelle sont essentielles.
## Conflits de transaction
Aurora DSQL utilise un contrôle de simultanéité optimiste (OCC), qui fonctionne différemment des systèmes traditionnels basés sur des verrous. Au lieu d’utiliser des verrous, l’OCC évalue les conflits au moment de la validation. Lorsque plusieurs transactions entrent en conflit lors de la mise à jour de la même ligne, Aurora DSQL gère les transactions comme suit :
+ La transaction dont l’heure de validation est la plus proche est traitée par Aurora DSQL.
+ Les transactions en conflit reçoivent une erreur de sérialisation PostgreSQL, indiquant la nécessité d’une nouvelle tentative.
Concevez vos applications de manière à mettre en œuvre une logique de nouvelle tentative pour gérer les conflits. Le modèle de conception idéal est idempotent, permettant une nouvelle tentative de transaction comme premier recours dans la mesure du possible. La logique recommandée est similaire à la logique d’abandon et de nouvelle tentative dans une situation de blocage ou de temporisation standard de PostgreSQL. Cependant, l’OCC exige que vos applications appliquent cette logique plus fréquemment.
## Directives pour optimiser les performances des transactions
Pour optimiser les performances, réduisez les risques de conflits sur des clés uniques ou sur de petites plages de clés. Pour atteindre cet objectif, concevez votre schéma de manière à répartir les mises à jour sur l’ensemble de votre plage de clés de cluster en suivant les directives suivantes :
+ Choisissez une clé primaire aléatoire pour vos tables.
+ Évitez les modèles qui accroissent le risque de conflit sur les clés individuelles. Cette approche garantit des performances optimales même lorsque le volume des transactions augmente.
# Transactions DDL et distribuées dans Aurora DSQL
Le langage de définition des données (DDL) se comporte différemment dans Aurora DSQL et dans PostgreSQL. Aurora DSQL propose une couche de base de données distribuée et sans partage Multi-AZ, construite sur des flottes de calcul et de stockage à plusieurs locataires. Comme il n’existe pas de nœud de base de données primaire ni de leader unique, le catalogue de base de données est distribué. Ainsi, Aurora DSQL gère les modifications du schéma DDL sous forme de transactions distribuées.
Plus précisément, DDL se comporte différemment dans Aurora DSQL comme suit :
**Erreurs de contrôle de simultanéité**
Aurora DSQL renvoie une erreur de violation du contrôle de simultanéité si vous exécutez une transaction alors qu’une autre met à jour une ressource. Par exemple, considérez la séquence d’actions suivante :
1. Au cours de la session 1, un utilisateur ajoute une colonne à la table `mytable`.
1. Au cours de la session 2, un utilisateur tente d’insérer une ligne dans `mytable`.
Aurora DSQL renvoie l’erreur `SQL Error [40001]: ERROR: schema has been updated by another transaction, please retry: (OC001).`
**DDL et DML dans la même transaction**
Les transactions dans Aurora DSQL ne peuvent contenir qu’une seule instruction DDL et ne peuvent pas contenir à la fois des instructions DDL et DML. Cette restriction signifie que vous ne pouvez pas créer de table et insérer des données dans la même table au cours de la même transaction. Par exemple, Aurora DSQL prend en charge les transactions séquentielles suivantes.
```
BEGIN;
CREATE TABLE mytable (ID_col integer);
COMMIT;
BEGIN;
INSERT into FOO VALUES (1);
COMMIT;
```
Aurora DSQL ne prend pas en charge la transaction suivante, qui inclut à la fois les instructions `CREATE` et `INSERT`.
```
BEGIN;
CREATE TABLE FOO (ID_col integer);
INSERT into FOO VALUES (1);
COMMIT;
```
**DDL asynchrone**
Dans PostgreSQL standard, les opérations DDL telles que `CREATE INDEX` verrouille la table concernée, la rendant indisponible pour les lectures et les écritures provenant d’autres sessions. Dans Aurora DSQL, ces instructions DDL s’exécutent de manière asynchrone à l’aide d’un gestionnaire d’arrière-plan. L’accès à la table concernée n’est pas bloqué. Ainsi, DDL sur de grandes tables peut fonctionner sans durée d’indisponibilité ni impact sur les performances. Pour plus d’informations sur l’utilisation du gestionnaire de tâches asynchrones dans Aurora DSQL, consultez [Index asynchrones dans Aurora DSQL](working-with-create-index-async.md).
# Clés primaires dans Aurora DSQL
Dans Aurora DSQL, une clé primaire est une fonctionnalité qui organise physiquement les données d’une table. C’est similaire à l’opération `CLUSTER` dans PostgreSQL ou à un index en cluster dans d’autres bases de données. Lorsque vous définissez une clé primaire, Aurora DSQL crée un index qui inclut toutes les colonnes de la table. La structure de clé primaire d’Aurora DSQL garantit un accès et une gestion efficaces des données.
## Structure et stockage des données
Lorsque vous définissez une clé primaire, Aurora DSQL stocke les données des tables dans l’ordre des clés primaires. Cette structure organisée par index permet une recherche par clé primaire pour récupérer directement toutes les valeurs des colonnes, au lieu de suivre un pointeur vers les données comme dans un index d’arbre B traditionnel. Contrairement à l’opération `CLUSTER` de PostgreSQL, qui ne réorganise les données qu’une seule fois, Aurora DSQL maintient cet ordre automatiquement et en continu. Cette approche permet d’améliorer les performances des requêtes qui reposent sur l’accès par clé primaire.
Aurora DSQL utilise également la clé primaire pour générer une clé unique à l’échelle du cluster pour chaque ligne des tables et des index. Cette clé unique est également à la base de la gestion des données distribuées. Elle permet le partitionnement automatique des données sur plusieurs nœuds, prenant en charge un stockage évolutif et une simultanéité élevée. Par conséquent, la structure de clé primaire permet à Aurora DSQL de s’adapter automatiquement et de gérer efficacement les charges de travail simultanées.
## Directives pour choisir une clé primaire
Lorsque vous choisissez et utilisez une clé primaire dans Aurora DSQL, tenez compte des directives suivantes :
+ Définissez une clé primaire lorsque vous créez une table. Vous ne pouvez pas modifier cette clé ni ajouter une nouvelle clé primaire ultérieurement. La clé primaire fait partie de la clé à l’échelle du cluster utilisée pour le partitionnement des données et la mise à l’échelle automatique du débit d’écriture. Si vous ne spécifiez pas de clé primaire, Aurora DSQL attribuera un ID fictif masqué.
+ Pour les tables présentant des volumes d’écriture élevés, évitez d’utiliser des nombres entiers qui augmentent de façon monotone comme clés primaires. Cela peut entraîner des problèmes de performances en dirigeant tous les nouveaux inserts vers une seule partition. Utilisez plutôt des clés primaires à distribution aléatoire pour garantir une répartition uniforme des écritures sur les partitions de stockage.
+ Pour les tables qui changent rarement ou qui sont en lecture seule, vous pouvez utiliser une clé ascendante. Les horodatages ou les numéros de séquence sont des exemples de clés ascendantes. Une clé dense comporte de nombreuses valeurs étroitement espacées ou dupliquées. Vous pouvez utiliser une clé ascendante même si elle est dense, car les performances d’écriture sont moins critiques.
+ Si une analyse complète du tableau ne répond pas à vos exigences de performance, choisissez une méthode d’accès plus efficace. Dans la plupart des cas, cela implique d’utiliser une clé primaire qui correspond à votre clé de jointure et de recherche la plus courante dans les requêtes.
+ La taille maximale combinée des colonnes utilisées dans une clé primaire est de 1 kibioctet. Pour plus d’informations, consultez [Limites de base de données dans Aurora DSQL](https://docs.aws.amazon.com/aurora-dsql/latest/userguide/CHAP_quotas.html#SECTION_database-limits) et [Types de données pris en charge dans Aurora DSQL](https://docs.aws.amazon.com/aurora-dsql/latest/userguide/working-with-postgresql-compatibility-supported-data-types).
+ Vous pouvez inclure jusqu’à 8 colonnes dans une clé primaire ou un index secondaire. Pour plus d’informations, consultez [Limites de base de données dans Aurora DSQL](https://docs.aws.amazon.com/aurora-dsql/latest/userguide/CHAP_quotas.html#SECTION_database-limits) et [Types de données pris en charge dans Aurora DSQL](https://docs.aws.amazon.com/aurora-dsql/latest/userguide/working-with-postgresql-compatibility-supported-data-types).
# Séquences et colonnes d'identité
Les séquences et les colonnes d'identité génèrent des valeurs entières et sont utiles lorsque des identifiants compacts ou lisibles par l'homme sont nécessaires. Ces valeurs impliquent le comportement d'allocation et de mise en cache décrit dans la [`CREATE SEQUENCE`](create-sequence-syntax-support.md) documentation.
**Topics**
+ [Fonctions de manipulation de séquence](sequence-functions-syntax-support.md)
+ [Colonnes d'identité](sequences-identity-columns-overview.md)
+ [Utilisation de séquences et de colonnes d'identité](sequences-identity-columns-working-with.md)
# Fonctions de manipulation de séquence
Cette section décrit les fonctions permettant d'opérer sur des objets de séquence, également appelés générateurs de séquences ou simplement séquences. Les objets de séquence sont des tables spéciales à une seule ligne créées avec[`CREATE SEQUENCE`](create-sequence-syntax-support.md). Les objets de séquence sont couramment utilisés pour générer des identifiants uniques pour les lignes d'une table. Les fonctions de séquence fournissent des méthodes simples et sécurisées pour plusieurs utilisateurs pour obtenir des valeurs de séquence successives à partir d'objets de séquence.
**Important**
Lorsque vous utilisez des séquences, la valeur du cache doit être soigneusement prise en compte. Pour plus d'informations, consultez la légende Important sur la [`CREATE SEQUENCE`](create-sequence-syntax-support.md) page.
Pour obtenir des conseils sur la meilleure façon d'utiliser les séquences basées sur les modèles de charge de travail, voir[Utilisation de séquences et de colonnes d'identité](sequences-identity-columns-working-with.md).
| Fonction | Description |
| --- | --- |
| nextval ( regclass ) → bigint | Avance l'objet de séquence jusqu'à sa valeur suivante et renvoie cette valeur. Cela se fait de manière atomique : même si plusieurs sessions s'exécutent nextval simultanément, chacune recevra en toute sécurité une valeur de séquence distincte. Si l'objet de séquence a été créé avec des paramètres par défaut, les nextval appels successifs renverront des valeurs croissantes commençant par 1. D'autres comportements peuvent être obtenus en utilisant les paramètres appropriés dans la [`CREATE SEQUENCE`](create-sequence-syntax-support.md) commande. Cette fonction requiert USAGE ou UPDATE privilégie la séquence. |
| setval ( regclass, bigint [, boolean ] ) → bigint | Définit la valeur actuelle de l'objet de séquence, et éventuellement son is\$1called indicateur. Le formulaire à deux paramètres définit le last\$1value champ de la séquence à la valeur spécifiée et définit son is\$1called champ à la valeur spécifiéetrue, ce qui signifie que le suivant nextval fera avancer la séquence avant de renvoyer une valeur. La valeur qui sera signalée currval est également définie sur la valeur spécifiée. Dans le formulaire à trois paramètres, il is\$1called peut être défini sur true oufalse. truea le même effet que le formulaire à deux paramètres. S'il est défini surfalse, le suivant nextval renverra exactement la valeur spécifiée, et l'avancement de la séquence commence par ce qui suitnextval. De plus, la valeur indiquée par currval n'est pas modifiée ici. Par exemple : SELECT setval('myseq', 42); -- Next nextval will return 43
SELECT setval('myseq', 42, true); -- Same as above
SELECT setval('myseq', 42, false); -- Next nextval will return 42 Le résultat renvoyé par setval est simplement la valeur de son deuxième argument. Cette fonction nécessite un UPDATE privilège sur la séquence. |
| currval ( regclass ) → bigint | Renvoie la dernière valeur obtenue par nextval pour cette séquence dans la session en cours. (Une erreur est signalée si cette séquence n'nextvala jamais été appelée au cours de cette session.) Comme cela renvoie une valeur locale à la session, cela donne une réponse prévisible, que d'autres sessions aient été exécutées ou non nextval parce que la session en cours l'a fait. Cette fonction requiert USAGE ou SELECT privilégie la séquence. |
| lastval () → bigint | Renvoie la dernière valeur renvoyée par la transaction nextval en cours. Cette fonction est identique àcurrval, sauf qu'au lieu de prendre le nom de la séquence comme argument, elle fait référence à la séquence nextval la plus récente appliquée dans la transaction en cours. L'appel est une erreur lastval s'il nextval n'a pas encore été appelé dans le cadre de la transaction en cours. Cette fonction requiert USAGE ou SELECT privilégie la dernière séquence utilisée. |
**Avertissement**
La valeur obtenue par `nextval` n'est pas récupérée pour être réutilisée si la transaction d'appel est abandonnée ultérieurement. Cela signifie que les annulations de transactions ou les pannes de base de données peuvent entraîner des lacunes dans la séquence des valeurs attribuées. Cela peut également se produire sans interruption de transaction. Par exemple, une `ON CONFLICT` clause `INSERT` with an calculera le to-be-inserted tuple, y compris en effectuant les `nextval` appels requis, avant de détecter tout conflit qui l'obligerait à suivre la `ON CONFLICT` règle à la place. Ainsi, les objets de séquence d'Aurora DSQL *ne peuvent pas être utilisés pour obtenir des séquences « sans interruption ».*
De même, les modifications d'état de séquence effectuées par `setval` sont immédiatement visibles pour les autres transactions et ne sont pas annulées si la transaction appelante est annulée.
La séquence à exécuter par une fonction de séquence est spécifiée par un `regclass` argument, qui est simplement l'OID de la séquence dans le catalogue `pg_class` système. Cependant, il n'est pas nécessaire de rechercher l'OID manuellement, car le convertisseur d'entrée du type de `regclass` données fera le travail à votre place. Consultez la documentation de PostgreSQL [sur les types d'identificateurs d'objets](https://www.postgresql.org/docs/current/datatype-oid.html) pour plus de détails.
# Colonnes d'identité
**Important**
Lorsque vous utilisez des colonnes d'identité, la valeur du cache doit être soigneusement prise en compte. Pour plus d'informations, consultez la légende Important sur la [`CREATE SEQUENCE`](create-sequence-syntax-support.md) page.
Pour obtenir des conseils sur la meilleure façon d'utiliser les colonnes d'identité en fonction des modèles de charge de travail, voir[Utilisation de séquences et de colonnes d'identité](sequences-identity-columns-working-with.md).
Une colonne d'identité est une colonne spéciale générée automatiquement à partir d'une séquence implicite. Il peut être utilisé pour générer des valeurs clés. Pour créer une colonne d'identité, utilisez la `GENERATED ... AS IDENTITY` clause dans[`CREATE TABLE`](create-table-syntax-support.md), par exemple :
```
CREATE TABLE people (
id bigint GENERATED ALWAYS AS IDENTITY (CACHE 70000),
...
);
```
ou bien :
```
CREATE TABLE people (
id bigint GENERATED BY DEFAULT AS IDENTITY (CACHE 70000),
...
);
```
Pour plus d’informations, consultez [`CREATE TABLE`](create-table-syntax-support.md).
Si une `INSERT` commande est exécutée sur la table contenant la colonne d'identité et qu'aucune valeur n'est explicitement spécifiée pour la colonne d'identité, une valeur générée par la séquence implicite est insérée. Par exemple, avec les définitions précédentes et en supposant que des colonnes supplémentaires soient appropriées, en écrivant :
```
INSERT INTO people (name, address) VALUES ('A', 'foo');
INSERT INTO people (name, address) VALUES ('B', 'bar');
```
générerait des valeurs pour la `id` colonne commençant à 1 et produirait les données de table suivantes :
```
id | name | address
----+------+---------
1 | A | foo
2 | B | bar
```
Vous pouvez également spécifier le mot-clé `DEFAULT` à la place d'une valeur pour demander explicitement la valeur générée par la séquence :
```
INSERT INTO people (id, name, address) VALUES (DEFAULT, 'C', 'baz');
```
De même, le mot-clé `DEFAULT` peut être utilisé dans `UPDATE` les commandes.
Ainsi, à bien des égards, une colonne d'identité se comporte comme une colonne avec une valeur par défaut.
Les clauses `ALWAYS` et la définition `BY DEFAULT` de colonne déterminent la manière dont les valeurs spécifiées explicitement par l'utilisateur sont traitées dans `UPDATE` les commandes `INSERT` et. Dans une `INSERT` commande, si elle `ALWAYS` est sélectionnée, une valeur spécifiée par l'utilisateur n'est acceptée que si l'`INSERT`instruction le précise`OVERRIDING SYSTEM VALUE`. Si cette option `BY DEFAULT` est sélectionnée, la valeur spécifiée par l'utilisateur est prioritaire. Ainsi, l'utilisation `BY DEFAULT` entraîne un comportement plus proche des valeurs par défaut, où la valeur par défaut peut être remplacée par une valeur explicite, tout en `ALWAYS` offrant une protection supplémentaire contre l'insertion accidentelle d'une valeur explicite.
Le type de données d'une colonne d'identité doit être l'un des types de données pris en charge par les séquences. (Consultez [`CREATE SEQUENCE`](create-sequence-syntax-support.md).) Les propriétés de la séquence associée peuvent être spécifiées lors de la création d'une colonne d'identité (voir[`CREATE TABLE`](create-table-syntax-support.md)) ou modifiées ultérieurement (voir[`ALTER TABLE`](alter-table-syntax-support.md)).
Une colonne d'identité est automatiquement marquée comme`NOT NULL`. Une colonne d'identité ne garantit toutefois pas l'unicité. (Une séquence renvoie normalement des valeurs uniques, mais une séquence peut être réinitialisée ou des valeurs peuvent être insérées manuellement dans la colonne d'identité, comme indiqué précédemment.) L'unicité devrait être appliquée à l'aide d'une `UNIQUE` contrainte `PRIMARY KEY` or.
# Utilisation de séquences et de colonnes d'identité
Cette section vous aide à comprendre comment utiliser au mieux les séquences et les colonnes d'identité en fonction des modèles de charge de travail.
**Important**
Consultez la légende Important de la [`CREATE SEQUENCE`](create-sequence-syntax-support.md) page pour plus de détails sur le comportement d'allocation et de mise en cache.
## Choix des types d'identificateurs
Amazon Aurora DSQL prend en charge à la fois les identifiants basés sur l'UUID et les valeurs entières générées à l'aide de séquences ou de colonnes d'identité. Ces options diffèrent quant à la manière dont les valeurs sont allouées et à leur mise à l'échelle en fonction de la charge.
Les valeurs UUID peuvent être générées sans coordination et conviennent parfaitement aux charges de travail dans lesquelles des identifiants sont créés fréquemment ou au cours de nombreuses sessions. Amazon Aurora DSQL étant conçu pour un fonctionnement distribué, il est souvent avantageux d'éviter la coordination. C'est pourquoi UUIDs ils sont recommandés comme type d'identifiant par défaut, en particulier pour les clés primaires dans les charges de travail où l'évolutivité est importante et où un ordre strict des identifiants n'est pas requis.
Les séquences et les colonnes d'identité génèrent des valeurs entières compactes qui sont pratiques pour les identificateurs lisibles par l'homme, les rapports et les interfaces externes. Lorsque les identifiants numériques sont préférés pour des raisons d'utilisabilité ou d'intégration, envisagez d'utiliser une séquence ou une colonne d'identité en combinaison avec des identifiants basés sur l'UUID. Lorsque des séquences entières ou des valeurs d'identité sont requises, le choix d'une taille de cache appropriée devient un élément important de la conception de la charge de travail. Consultez la section suivante pour savoir comment choisir une taille de cache.
## Choix d'une taille de cache
La sélection d'une valeur de cache appropriée est un élément important pour utiliser efficacement les séquences et les colonnes d'identité. Le paramètre du cache détermine le comportement de l'allocation des identifiants sous charge, influençant à la fois le débit du système et la mesure dans laquelle les valeurs reflètent l'ordre d'allocation.
**Une taille de cache plus importante `CACHE >= 65536` est idéale lorsque :**
+ Les identifiants sont générés à haute fréquence
+ De nombreuses sessions s'insèrent simultanément
+ La charge de travail peut tolérer des écarts et des effets de commande visibles
Par exemple, les charges de travail d'ingestion d'événements à volume élevé (comme l'IoT ou la télémétrie), ainsi que les identifiants opérationnels tels que l'exécution des tâches IDs, les références de dossiers d'assistance ou les numéros de commande internes bénéficient généralement de tailles de cache plus importantes, où des identifiants sont générés fréquemment et un ordre strict n'est pas requis.
**Une taille de cache de 1 est mieux alignée lorsque :**
+ Les taux d'allocation sont relativement bas
+ Les identifiants devraient suivre de plus près l'ordre d'allocation au fil du temps
+ Il est plus important de minimiser les écarts que de maximiser le débit
Les charges de travail telles que l'attribution de numéros de compte ou de référence, pour lesquelles les identifiants sont générés moins souvent et où un ordre plus serré est souhaitable, sont mieux adaptées à une taille de cache de 1.
# 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 :
**`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 la réussite 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.
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 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 ]
```
## Parameters
**`UNIQUE`**
Indique à Aurora DSQL de vérifier les 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 pas de nom, Aurora DSQL le génère automatiquement 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’index `table1_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 une colonne non clé dans une qualification de recherche par analyse d’index. Aurora DSQL ignore la colonne en termes d’unicité pour 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 commande `CREATE INDEX ASYNC` 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 procédure `sys.wait_for_job(job_id)'your_index_creation_job_id'` est utile. Cela garantit que les opérations DDL et DML suivantes ciblent l’index nouvellement créé.
+ Chaque fois qu’Aurora DSQL exécute une nouvelle tâche asynchrone, il vérifie la vue `sys.jobs` et supprime les tâches dont le statut est `completed` ou `failed` pendant plus de 30 minutes. Ainsi, `sys.jobs` affiche 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 reste `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.
1. Créez une nouvelle 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));
```
1. Insérez une ligne dans la table.
```
INSERT INTO test.departments VALUES ('Human Resources', 'John Doe', '10')
```
1. Créez un index asynchrone.
```
CREATE INDEX ASYNC test_index on test.departments(name, manager, size);
```
La commande `CREATE INDEX` renvoie un identifiant de tâche, comme indiqué ci-dessous.
```
job_id
--------------------------
jh2gbtx4mzhgfkbimtgwn5j45y
```
`job_id` indique qu’Aurora DSQL a soumis une nouvelle tâche pour créer l’index. Vous pouvez utiliser la procédure `sys.wait_for_job(job_id)'your_index_creation_job_id'` pour bloquer d’autres tâches au cours de la session jusqu’à cette tâche soit terminée ou expire.
## 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 where job_id = 'wqhu6ewifze5xitg3umt24h5ua';
```
Aurora DSQL renvoie une réponse semblable à ce qui suit.
```
job_id | status | details | job_type | class_id | object_id | object_name | start_time | update_time
----------------------------+-----------+---------+-------------+----------+-----------+-------------------+------------------------+------------------------
wqhu6ewifze5xitg3umt24h5ua | completed | | INDEX_BUILD | 1259 | 26433 | public.nt2_c1_idx | 2025-09-25 22:07:31+00 | 2025-09-25 22:07:46+00
```
La colonne d’état peut avoir l’une des valeurs suivantes.
| Statut | Description |
| --- | --- |
| submitted | La tâche est envoyée, mais Aurora DSQL n’a pas encore commencé à la traiter. |
| processing | Aurora DSQL est en train de traiter la tâche. |
| failed | La tâche a échoué. Consultez la colonne « 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 commande DROP INDEX. |
| completed | Aurora DSQL a terminé la tâche avec succès. |
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é.
**Résolution des problèmes de défaillances de création d’index uniques**
1. 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.
1. Supprimez l’index défaillant.
1. Émettez une nouvelle commande de création d’index.
## 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)
```
# Tables et commandes système dans Aurora DSQL
Consultez les sections suivantes pour en savoir plus sur les tables système et les catalogues pris en charge dans Aurora DSQL, ainsi que sur les requêtes utiles pour récupérer des informations sur le système, telles que la version.
## Tables système
Aurora DSQL est compatible avec PostgreSQL, de sorte que de [nombreuses tables du catalogue système](https://www.PostgreSQL.org/docs/current/catalogs-overview.html) et de nombreuses [vues](https://www.PostgreSQL.org/docs/current/views.html) de PostgreSQL existent également dans Aurora DSQL.
### Tables et vues du catalogue PostgreSQL importantes
Le tableau suivant décrit les tables et les vues les plus courantes que vous pouvez utiliser dans Aurora DSQL.
| Nom | Description |
| --- | --- |
| `pg_namespace` | Informations sur tous les schémas |
| `pg_tables` | Informations sur toutes les tables |
| `pg_attribute` | Informations sur tous les attributs |
| `pg_views` | Informations sur les vues (pré)-définies |
| `pg_class` | Décrit toutes les tables, toutes les colonnes, tous les index et tous les objets similaires |
| `pg_stats` | Vue des statistiques du planificateur |
| `pg_user` | Informations sur les utilisateurs |
| `pg_roles` | Informations sur les utilisateurs et les groupes |
| `pg_indexes` | Répertorie tous les index |
| `pg_constraint` | Répertorie les contraintes sur les tables |
### Tables de catalogue prises en charge et non prises en charge
Le tableau suivant indique les tables prises en charge et celles qui ne le sont pas dans Aurora DSQL.
| Nom | Applicable à Aurora DSQL |
| --- | --- |
| `pg_aggregate` | Non |
| `pg_am` | Oui |
| `pg_amop` | Non |
| `pg_amproc` | Non |
| `pg_attrdef` | Oui |
| `pg_attribute` | Oui |
| `pg_authid` | Non (utiliser `pg_roles`) |
| `pg_auth_members` | Oui |
| `pg_cast` | Oui |
| `pg_class` | Oui |
| `pg_collation` | Oui |
| `pg_constraint` | Oui |
| `pg_conversion` | Non |
| `pg_database` | Non |
| `pg_db_role_setting` | Oui |
| `pg_default_acl` | Oui |
| `pg_depend` | Oui |
| `pg_description` | Oui |
| `pg_enum` | Non |
| `pg_event_trigger` | Non |
| `pg_extension` | Non |
| `pg_foreign_data_wrapper` | Non |
| `pg_foreign_server` | Non |
| `pg_foreign_table` | Non |
| `pg_index` | Oui |
| `pg_inherits` | Oui |
| `pg_init_privs` | Non |
| `pg_language` | Non |
| `pg_largeobject` | Non |
| `pg_largeobject_metadata` | Oui |
| `pg_namespace` | Oui |
| `pg_opclass` | Non |
| `pg_operator` | Oui |
| `pg_opfamily` | Non |
| `pg_parameter_acl` | Oui |
| `pg_partitioned_table` | Non |
| `pg_policy` | Non |
| `pg_proc` | Non |
| `pg_publication` | Non |
| `pg_publication_namespace` | Non |
| `pg_publication_rel` | Non |
| `pg_range` | Oui |
| `pg_replication_origin` | Non |
| `pg_rewrite` | Non |
| `pg_seclabel` | Non |
| `pg_sequence` | Non |
| `pg_shdepend` | Oui |
| `pg_shdescription` | Oui |
| `pg_shseclabel` | Non |
| `pg_statistic` | Oui |
| `pg_statistic_ext` | Non |
| `pg_statistic_ext_data` | Non |
| `pg_subscription` | Non |
| `pg_subscription_rel` | Non |
| `pg_tablespace` | Non |
| `pg_transform` | Non |
| `pg_trigger` | Non |
| `pg_ts_config` | Oui |
| `pg_ts_config_map` | Oui |
| `pg_ts_dict` | Oui |
| `pg_ts_parser` | Oui |
| `pg_ts_template` | Oui |
| `pg_type` | Oui |
| `pg_user_mapping` | Non |
### Vues système prises en charge et non prises en charge
Le tableau suivant indique les vues prises en charge et celles qui ne le sont pas dans Aurora DSQL.
| Nom | Applicable à Aurora DSQL |
| --- | --- |
| `pg_available_extensions` | Non |
| `pg_available_extension_versions` | Non |
| `pg_backend_memory_contexts` | Oui |
| `pg_config` | Non |
| `pg_cursors` | Non |
| `pg_file_settings` | Non |
| `pg_group` | Oui |
| `pg_hba_file_rules` | Non |
| `pg_ident_file_mappings` | Non |
| `pg_indexes` | Oui |
| `pg_locks` | Non |
| `pg_matviews` | Non |
| `pg_policies` | Non |
| `pg_prepared_statements` | Non |
| `pg_prepared_xacts` | Non |
| `pg_publication_tables` | Non |
| `pg_replication_origin_status` | Non |
| `pg_replication_slots` | Non |
| `pg_roles` | Oui |
| `pg_rules` | Non |
| `pg_seclabels` | Non |
| `pg_sequences` | Non |
| `pg_settings` | Oui |
| `pg_shadow` | Oui |
| `pg_shmem_allocations` | Oui |
| `pg_stats` | Oui |
| `pg_stats_ext` | Non |
| `pg_stats_ext_exprs` | Non |
| `pg_tables` | Oui |
| `pg_timezone_abbrevs` | Oui |
| `pg_timezone_names` | Oui |
| `pg_user` | Oui |
| `pg_user_mappings` | Non |
| `pg_views` | Oui |
| `pg_stat_activity` | Non |
| `pg_stat_replication` | Non |
| `pg_stat_replication_slots` | Non |
| `pg_stat_wal_receiver` | Non |
| `pg_stat_recovery_prefetch` | Non |
| `pg_stat_subscription` | Non |
| `pg_stat_subscription_stats` | Non |
| `pg_stat_ssl` | Oui |
| `pg_stat_gssapi` | Non |
| `pg_stat_archiver` | Non |
| `pg_stat_io` | Non |
| `pg_stat_bgwriter` | Non |
| `pg_stat_wal` | Non |
| `pg_stat_database` | Non |
| `pg_stat_database_conflicts` | Non |
| `pg_stat_all_tables` | Non |
| `pg_stat_all_indexes` | Non |
| `pg_statio_all_tables` | Non |
| `pg_statio_all_indexes` | Non |
| `pg_statio_all_sequences` | Non |
| `pg_stat_slru` | Non |
| `pg_statio_user_tables` | Non |
| `pg_statio_user_sequences` | Non |
| `pg_stat_user_functions` | Non |
| `pg_stat_user_indexes` | Non |
| `pg_stat_progress_analyze` | Non |
| `pg_stat_progress_basebackup` | Non |
| `pg_stat_progress_cluster` | Non |
| `pg_stat_progress_create_index` | Non |
| `pg_stat_progress_vacuum` | Non |
| `pg_stat_sys_indexes` | Non |
| `pg_stat_sys_tables` | Non |
| `pg_stat_xact_all_tables` | Non |
| `pg_stat_xact_sys_tables` | Non |
| `pg_stat_xact_user_functions` | Non |
| `pg_stat_xact_user_tables` | Non |
| `pg_statio_sys_indexes` | Non |
| `pg_statio_sys_sequences` | Non |
| `pg_statio_sys_tables` | Non |
| `pg_statio_user_indexes` | Non |
### La vue sys.jobs
`sys.jobs` fournit des informations sur le statut des tâches asynchrones. Par exemple, après avoir [créé un index asynchrone](working-with-create-index-async.md), Aurora DSQL renvoie `job_uuid`. Vous pouvez utiliser `job_uuid` avec `sys.jobs` pour consulter le statut de la tâche.
```
SELECT * FROM sys.jobs;
```
Aurora DSQL renvoie une réponse semblable à ce qui suit.
```
job_id | status | details | job_type | class_id | object_id | object_name | start_time | update_time
----------------------------+-----------+---------+-------------+----------+-----------+-------------------+------------------------+------------------------
wqhu6ewifze5xitg3umt24h5ua | completed | | INDEX_BUILD | 1259 | 26433 | public.nt2_c1_idx | 2025-09-25 22:07:31+00 | 2025-09-25 22:07:46+00
kkngzf33dndl3daacxehpx5eba | completed | | ANALYZE | 1259 | 26419 | public.nt | 2025-09-25 21:57:05+00 | 2025-09-25 21:57:27+00
fyopxjb6ovdn7po6lrkj63cyea | completed | | DROP | 1259 | 26422 | | 2025-09-25 22:05:57+00 | 2025-09-25 22:06:03+00
```
Le tableau suivant décrit les colonnes de la `sys.jobs` vue.
**colonnes d'affichage sys.jobs**
| Colonne | Type | Description |
| --- | --- | --- |
| job\$1id | text | Un UUID en base 32 représentant la tâche. |
| status | text | État actuel de la tâche. Les valeurs possibles sont submitted, processing, completed et failed. Pour de plus amples informations, veuillez consulter [valeurs de statut sys.jobs](#dsql-sys-jobs-status-values). |
| details | text | Tous les détails pertinents concernant le poste. Si la tâche échoue, une raison détaillée est fournie. |
| job\$1type | text | Type de tâche asynchrone. Les valeurs possibles sont les suivantes : INDEX\$1BUILD — une construction d'index asynchrone. ANALYZE— une tâche d'analyse automatique soumise par le système. DROP— supprime les données physiques après une DROP INDEX opération DROP TABLE OR. |
| class\$1id | oid | L'OID de la table de catalogue qui contient l'objet. |
| object\$1id | oid | L'OID de l'objet. |
| object\$1name | text | Nom complet de l'objet. DROPles tâches ne peuvent pas référencer des objets déjà déposés. Si un objet référencé a déjà été supprimé, il object\$1name peut être NULL. |
| start\$1time | timestamp with time zone | Horodatage auquel le travail a été soumis. |
| update\$1time | timestamp with time zone | Horodatage auquel la ligne de tâche a été mise à jour pour la dernière fois. |
**valeurs de statut sys.jobs**
| Statut | Description |
| --- | --- |
| submitted | La tâche est envoyée, mais Aurora DSQL n’a pas encore commencé à la traiter. |
| processing | Aurora DSQL est en train de traiter la tâche. |
| failed | La tâche a échoué. Consultez la details colonne pour plus d'informations. |
| completed | Aurora DSQL a terminé la tâche avec succès. |
### La vue sys.iam\$1pg\$1role\$1mappings
La vue `sys.iam_pg_role_mappings` fournit des informations sur les autorisations accordées aux utilisateurs IAM. Par exemple, si `DQSLDBConnect` est un rôle IAM qui donne accès à Aurora DSQL à des non-administrateurs et qu’un utilisateur nommé `testuser` reçoit le rôle `DQSLDBConnect` et les autorisations correspondantes, vous pouvez interroger la vue `sys.iam_pg_role_mappings` pour voir quels utilisateurs ont obtenu quelles autorisations.
```
SELECT * FROM sys.iam_pg_role_mappings;
```
## Requêtes utiles sur les métadonnées du système
Utilisez ces requêtes pour obtenir les statistiques des tables et les métadonnées du système sans effectuer d'opérations coûteuses telles que l'analyse complète des tables.
### Obtenir une estimation du nombre de lignes pour un tableau
Pour obtenir le nombre approximatif de lignes d'une table sans effectuer une analyse complète de la table, utilisez la requête suivante :
```
SELECT reltuples FROM pg_class WHERE relname = 'table_name';
```
La commande renvoie un résultat semblable à ce qui suit :
```
reltuples
--------------
9.993836e+08
```
Cette approche est plus efficace que `SELECT COUNT(*)` pour les grandes tables dans Aurora DSQL.
### Obtenir la version majeure actuelle d'Aurora DSQL
Pour obtenir la version majeure actuelle du cluster Aurora DSQL, utilisez la requête suivante :
```
SELECT * FROM sys.dsql_major_version();
```
La commande renvoie un résultat semblable à ce qui suit :
```
dsql_major_version
--------------------
1
```
Cela renvoie la version principale sur laquelle se trouve la connexion SQL dans Aurora DSQL.
### Obtenir la version actuelle de PostgreSQL
Pour obtenir la version actuelle de PostgreSQL du cluster Aurora DSQL, utilisez la requête suivante :
```
SHOW server_version;
```
La commande renvoie un résultat semblable à ce qui suit :
```
server_version
----------------
16.13
```
Cela renvoie la version de PostgreSQL utilisée par la connexion SQL dans Aurora DSQL.
## Commande `ANALYZE`.
La commande `ANALYZE `collecte des statistiques sur le contenu des tables de la base de données et enregistre les résultats dans la vue système `pg_stats`. Le planificateur de requêtes utilise ensuite ces statistiques pour déterminer les plans d’exécution les plus efficaces pour les requêtes.
Dans Aurora DSQL, vous ne pouvez pas exécuter la commande `ANALYZE` dans le cadre d’une transaction explicite. `ANALYZE` n’est pas soumis au délai d’expiration des transactions de base de données.
Pour réduire le besoin d’intervention manuelle et maintenir les statistiques constamment à jour, Aurora DSQL exécute automatiquement `ANALYZE` en tant que processus d’arrière-plan. Cette tâche en arrière-plan est déclenchée automatiquement en fonction du taux de variation observé dans le tableau. Il est lié au nombre de lignes (tuples) qui ont été insérées, mises à jour ou supprimées depuis la dernière analyse.
`ANALYZE` s’exécute de manière asynchrone en arrière-plan et son activité peut être surveillée dans la vue système sys.jobs avec la requête suivante :
```
SELECT * FROM sys.jobs WHERE job_type = 'ANALYZE';
```
**Considérations clés**
**Note**
Les tâches `ANALYZE` sont facturées comme les autres tâches asynchrones dans Aurora DSQL. Lorsque vous modifiez une table, cela peut déclencher indirectement une tâche automatique de collecte de statistiques en arrière-plan, ce qui peut entraîner des frais de comptage en raison de l’activité associée au niveau du système.
Les tâches `ANALYZE` en arrière-plan, déclenchées automatiquement, collectent les mêmes types de statistiques qu’une `ANALYZE` manuelle et les appliquent par défaut aux tables utilisateur. Les tables du système et du catalogue sont exclues de ce processus automatisé.
# Utilisation des plans Aurora SQL EXPLAIN
Aurora DSQL utilise une structure de plan EXPLAIN similaire à celle de PostgreSQL, mais avec des ajouts clés qui reflètent son architecture distribuée et son modèle d'exécution.
Dans cette documentation, nous allons fournir un aperçu des plans Aurora DSQL EXPLAIN, en mettant en évidence les similitudes et les différences par rapport à PostgreSQL. Nous aborderons les différents types d'opérations de scan disponibles dans Aurora DSQL et vous aiderons à comprendre le coût de l'exécution de vos requêtes.
## Plans PostgreSQL VS Aurora DSQL EXPLAIN
Aurora DSQL repose sur la base de données PostgreSQL et partage la plupart des structures de plan avec PostgreSQL, mais présente des différences architecturales majeures qui ont une incidence sur l'exécution et l'optimisation des requêtes :
| Fonctionnalité | PostgreSQL | Aurora DSQL |
| --- | --- | --- |
| Stockage des données | Stockage en tas | Pas de tas, toutes les lignes sont indexées par un identifiant unique |
| Clé primaire | L'index de clé primaire est distinct des données de table | L'index de clé primaire est la table avec toutes les colonnes supplémentaires sous forme de colonnes INCLUDE |
| Index secondaires | Index secondaires standard | Fonctionne de la même manière que PostgreSQL, avec la possibilité d'inclure des colonnes non clés |
| Capacités de filtrage | État de l'index, filtre en tas | État de l'index, filtre de stockage, filtre du processeur de requêtes |
| Types d’analyse | Numérisation séquentielle, analyse de l'index, analyse de l'index uniquement | Scan complet, scan de l'index uniquement, scan de l'index |
| Exécution de requêtes | Local dans la base de données | Distribué (le calcul et le stockage sont séparés) |
Aurora DSQL stocke les données des tables directement dans l'ordre des clés primaires plutôt que dans un tas séparé. Chaque ligne est identifiée par une clé unique, généralement la clé primaire, qui permet à la base de données d'optimiser les recherches de manière plus efficace. Cette différence architecturale explique pourquoi Aurora DSQL utilise souvent des scans d'index uniquement dans les cas où PostgreSQL choisit un scan séquentiel.
Autre distinction essentielle : Aurora DSQL sépare le calcul du stockage, ce qui permet d'appliquer des filtres plus tôt dans le processus d'exécution afin de réduire le mouvement des données et d'améliorer les performances.
[Pour en savoir plus sur l'utilisation des plans EXPLAIN avec PostgreSQL, consultez la documentation de PostgreSQL EXPLAIN.](https://www.postgresql.org/docs/current/using-explain.html)
## Éléments clés des plans Aurora SQL EXPLAIN
Les plans Aurora DSQL EXPLAIN fournissent des informations détaillées sur la manière dont les requêtes sont exécutées, notamment sur l'emplacement du filtrage et sur les colonnes extraites du stockage. La compréhension de ce résultat vous permet d'optimiser les performances des requêtes.
Indice Condo
Conditions utilisées pour naviguer dans l'index. Filtrage le plus efficace qui réduit les données numérisées. Dans Aurora DSQL, les conditions d'index peuvent être appliquées à plusieurs couches du plan d'exécution.
Projections
Colonnes extraites du stockage. Moins de projections sont synonymes de meilleures performances.
Filtre de stockage
Conditions appliquées au niveau du stockage. Plus efficace que les filtres du processeur de requêtes.
Filtre du processeur de requêtes
Conditions appliquées au niveau du processeur de requêtes. Nécessite le transfert de toutes les données avant le filtrage, ce qui entraîne une augmentation des mouvements de données et une surcharge de traitement.
## Filtres dans Aurora DSQL
Aurora DSQL sépare le calcul du stockage, ce qui signifie que le moment où les filtres sont appliqués pendant l'exécution des requêtes a un impact significatif sur les performances. Les filtres appliqués avant le transfert de gros volumes de données réduisent la latence et améliorent l'efficacité. Plus un filtre est appliqué tôt, moins les données doivent être traitées, déplacées et numérisées, ce qui accélère les requêtes.
Aurora DSQL peut appliquer des filtres à plusieurs étapes du chemin de requête. Il est essentiel de comprendre ces étapes pour interpréter les plans de requêtes et optimiser les performances.
| Niveau | Type de filtre | Description |
| --- | --- | --- |
| 1 | État de l'indice | Appliqué lors de la numérisation de l'index. Limite la quantité de données lues depuis le stockage et réduit le nombre de données envoyées à la couche de calcul. |
| 2 | Filtre de stockage | Appliqué après la lecture des données depuis le stockage, mais avant leur envoi au calcul. Voici un exemple de filtre sur une colonne d'inclusion d'un index. Réduit le transfert de données, mais pas la quantité lue. |
| 3 | Filtre du processeur de requêtes | Appliqué une fois que les données ont atteint la couche de calcul. Toutes les données doivent d'abord être transférées, ce qui augmente le temps de latence et les coûts. À l'heure actuelle, Aurora DSQL ne peut pas effectuer toutes les opérations de filtrage et de projection sur le stockage. Certaines requêtes peuvent donc être obligées de recourir à ce type de filtrage. |
# Lecture des plans Aurora SQL EXPLAIN
Comprendre comment lire les plans EXPLAIN est essentiel pour optimiser les performances des requêtes. Dans cette section, nous allons passer en revue des exemples concrets de plans de requêtes SQL Aurora, montrer le comportement des différents types de scan, expliquer où les filtres sont appliqués et mettre en évidence les opportunités d'optimisation.
## Exemples de tableaux utilisés dans ces exemples
Les exemples ci-dessous font référence à deux tableaux : `transaction` et`account`.
La `transaction` table ne possède pas de clé primaire, ce qui oblige Aurora DSQL à effectuer des analyses complètes de la table lorsqu'elle l'interroge.
La `account` table contient un index activé`customer_id`. Cet index inclut `balance` et `status` en tant que colonnes de couverture, ce qui permet de répondre à certaines requêtes directement à partir de l'index sans avoir à lire dans la table de base. Toutefois, l'index n'inclut pas`created_at`, de sorte que les requêtes qui font référence à cette colonne nécessitent un accès supplémentaire à la table.
```
CREATE TABLE transaction (
account_id uuid,
transaction_date timestamp,
description text
);
CREATE TABLE account (
customer_id uuid,
balance numeric,
status varchar,
created_at timestamp
);
CREATE INDEX ASYNC idx1 ON account (customer_id) INCLUDE (balance, status);
```
## Exemple de scan complet
Aurora DSQL propose à la fois des scans séquentiels, qui sont fonctionnellement identiques à PostgreSQL, ainsi que des scans complets. La seule différence entre les deux est que les scans complets peuvent utiliser un filtrage supplémentaire sur le stockage. Pour cette raison, il est presque toujours sélectionné au-dessus des scans séquentiels. En raison de la similitude, nous ne couvrirons que des exemples des scans complets les plus intéressants.
Les scans complets seront principalement utilisés sur des tables sans clé primaire. Étant donné que les clés primaires Aurora DSQL sont par défaut des index de couverture complets, Aurora DSQL utilisera très probablement des scans d'index uniquement sur la clé primaire dans de nombreuses situations où PostgreSQL utiliserait un scan séquentiel. Comme c'est le cas pour la plupart des autres bases de données, une table dépourvue d'index risque d'être mal dimensionnée.
```
EXPLAIN SELECT account_id FROM transaction WHERE transaction_date > '2025-01-01' AND description LIKE '%external%';
```
```
QUERY PLAN
----------------------------------------------------------------------------------------------------------------
Full Scan (btree-table) on transaction (cost=125100.05..177933.38 rows=33333 width=16)
Filter: (description ~~ '%external%'::text)
-> Storage Scan on transaction (cost=12510.05..17793.38 rows=66666 width=16)
Projections: account_id, description
Filters: (transaction_date > '2025-01-01 00:00:00'::timestamp without time zone)
-> B-Tree Scan on transaction (cost=12510.05..17793.38 rows=100000 width=30)
```
Ce plan montre deux filtres appliqués à différentes étapes. La `transaction_date > '2025-01-01'` condition est appliquée au niveau de la couche de stockage, ce qui réduit la quantité de données renvoyées. La `description LIKE '%external%'` condition est appliquée ultérieurement dans le processeur de requêtes, une fois les données transférées, ce qui le rend moins efficace. L'introduction de filtres plus sélectifs dans les couches de stockage ou d'index améliore généralement les performances.
## Exemple de scan avec index uniquement
Les scans d'index uniquement sont les types de scan les plus optimaux dans Aurora DSQL, car ils permettent de réduire le nombre d'allers-retours vers la couche de stockage et sont ceux qui peuvent effectuer le plus de filtrage. Mais ce n'est pas parce que vous voyez Index Only Scan que vous avez le meilleur plan. En raison des différents niveaux de filtrage qui peuvent se produire, il est essentiel de toujours faire attention aux différents endroits où le filtrage peut se produire.
```
EXPLAIN SELECT balance FROM account
WHERE customer_id = '4b18a761-5870-4d7c-95ce-0a48eca3fceb'
AND balance > 100
AND status = 'pending';
```
```
QUERY PLAN
-------------------------------------------------------------------------------
Index Only Scan using idx1 on account (cost=725.05..1025.08 rows=8 width=18)
Index Cond: (customer_id = '4b18a761-5870-4d7c-95ce-0a48eca3fceb'::uuid)
Filter: (balance > '100'::numeric)
-> Storage Scan on idx1 (cost=12510.05..17793.38 rows=9 width=16)
Projections: balance
Filters: ((status)::text = 'pending'::text)
-> B-Tree Scan on idx1 (cost=12510.05..17793.38 rows=10 width=30)
Index Cond: (customer_id = '4b18a761-5870-4d7c-95ce-0a48eca3fceb'::uuid)
```
Dans ce plan, la condition de l'index `customer_id = '4b18a761-5870-4d7c-95ce-0a48eca3fceb'` () est d'abord évaluée lors de l'analyse de l'index, qui est l'étape la plus efficace car elle limite la quantité de données lues depuis le stockage. Le filtre de stockage est appliqué après la lecture des données`status = 'pending'`, mais avant leur envoi à la couche de calcul, ce qui réduit la quantité de données transférées. Enfin, le filtre du processeur de requêtes s'exécute en dernier, une fois les données déplacées, ce qui le rend le moins efficace. `balance > 100` Parmi celles-ci, la condition d'index fournit les meilleures performances car elle contrôle directement la quantité de données numérisées.
## Exemple de scan d'index
Les scans d'index sont similaires aux scans d'index uniquement, sauf qu'ils comportent l'étape supplémentaire d'appel à la table de base. Comme Aurora DSQL peut spécifier des filtres de stockage, il est en mesure de le faire à la fois lors de l'appel d'index et lors de l'appel de recherche.
Pour que cela soit clair, Aurora DSQL présente le plan sous la forme de deux nœuds. De cette façon, vous pouvez clairement voir dans quelle mesure l'ajout d'une colonne d'inclusion sera utile en termes de lignes renvoyées par le stockage.
```
EXPLAIN SELECT balance FROM account
WHERE customer_id = '4b18a761-5870-4d7c-95ce-0a48eca3fceb'
AND balance > 100
AND status = 'pending'
AND created_at > '2025-01-01';
```
```
QUERY PLAN
----------------------------------------------------------------------------------------------------------
Index Scan using idx1 on account (cost=728.18..1132.20 rows=3 width=18)
Filter: (balance > '100'::numeric)
Index Cond: (customer_id = '4b18a761-5870-4d7c-95ce-0a48eca3fceb'::uuid)
-> Storage Scan on idx1 (cost=12510.05..17793.38 rows=8 width=16)
Projections: balance
Filters: ((status)::text = 'pending'::text)
-> B-Tree Scan on account (cost=12510.05..17793.38 rows=10 width=30)
Index Cond: (customer_id = '4b18a761-5870-4d7c-95ce-0a48eca3fceb'::uuid)
-> Storage Lookup on account (cost=12510.05..17793.38 rows=4 width=16)
Filters: (created_at > '2025-01-01 00:00:00'::timestamp without time zone)
-> B-Tree Lookup on transaction (cost=12510.05..17793.38 rows=8 width=30)
```
Ce plan montre comment le filtrage s'effectue en plusieurs étapes :
+ La condition d'index sur les `customer_id ` filtres permet de filtrer les données à un stade précoce.
+ Le filtre de stockage permet de `status` restreindre davantage les résultats avant qu'ils ne soient envoyés au calcul.
+ Le filtre du processeur de requêtes activé `balance` est appliqué ultérieurement, après le transfert.
+ Le filtre de recherche activé `created_at` est évalué lors de la récupération de colonnes supplémentaires dans la table de base.
L'ajout de colonnes fréquemment utilisées en tant que `INCLUDE` champs permet souvent d'éliminer cette recherche et d'améliorer les performances.
## Bonnes pratiques
+ **Alignez les filtres sur les colonnes indexées** pour accélérer le filtrage.
+ **Utilisez les colonnes INCLUDE** pour autoriser les scans d'index uniquement et éviter les recherches.
+ **Validez les estimations de lignes** lorsque vous étudiez les problèmes de performances. Aurora DSQL gère automatiquement les statistiques `ANALYZE` en s'exécutant en arrière-plan en fonction des taux de modification des données. Si les estimations semblent inexactes, vous pouvez les exécuter `ANALYZE` manuellement pour actualiser immédiatement les statistiques.
+ **Évitez les requêtes non indexées** sur de grandes tables afin d'éviter des scans complets coûteux.
# Comprendre DPUs dans EXPLAIN ANALYZE
Aurora DSQL fournit des informations **sur les unités de traitement distribué (DPU) au niveau** des instructions dans les résultats du `EXPLAIN ANALYZE VERBOSE` plan, ce qui vous donne une meilleure visibilité sur le coût des requêtes pendant le développement. Cette section explique ce DPUs que c'est et comment les interpréter dans le `EXPLAIN ANALYZE VERBOSE` résultat.
## Qu'est-ce qu'un DPU ?
Une unité de traitement distribuée (DPU) est la mesure normalisée du travail effectué par Aurora DSQL. Il est composé de :
+ **ComputedPU** — Temps passé à exécuter des requêtes SQL
+ **ReadDPU** — Ressources utilisées pour lire les données depuis le stockage
+ **WriteDPU** - Ressources utilisées pour écrire des données dans le stockage
+ **MultiRegionWriteDPU** : ressources utilisées pour répliquer les écritures sur des clusters homologues dans des configurations multirégionales.
## Utilisation du DPU dans EXPLAIN ANALYZE VERBOSE
Aurora DSQL s'étend `EXPLAIN ANALYZE VERBOSE` pour inclure une estimation de l'utilisation du DPU au niveau des instructions jusqu'à la fin de la sortie. Cela fournit une visibilité immédiate sur le coût des requêtes, vous aidant à identifier les facteurs de coût de la charge de travail, à optimiser les performances des requêtes et à mieux prévoir l'utilisation des ressources.
Les exemples suivants montrent comment interpréter les estimations du DPU au niveau des instructions incluses dans la sortie EXPLAIN ANALYZE VERBOSE.
### Exemple 1 : requête SELECT
```
EXPLAIN ANALYZE VERBOSE SELECT * FROM test_table;
```
```
QUERY PLAN
----------------------------------------------------
Index Only Scan using test_table_pkey on public.test_table (cost=125100.05..171100.05 rows=1000000 width=36) (actual time=2.973..4.482 rows=120 loops=1)
Output: id, context
-> Storage Scan on test_table_pkey (cost=125100.05..171100.05 rows=1000000 width=36) (actual rows=120 loops=1)
Projections: id, context
-> B-Tree Scan on test_table_pkey (cost=125100.05..171100.05 rows=1000000 width=36) (actual rows=120 loops=1)
Query Identifier: qymgw1m77maoe
Planning Time: 11.415 ms
Execution Time: 4.528 ms
Statement DPU Estimate:
Compute: 0.01607 DPU
Read: 0.04312 DPU
Write: 0.00000 DPU
Total: 0.05919 DPU
```
Dans cet exemple, l'instruction SELECT effectue une analyse d'index uniquement. La majeure partie du coût provient donc de Read DPU (0,04312), qui représente les données extraites du stockage, et de Compute DPU (0,01607), qui reflète les ressources de calcul utilisées pour traiter et renvoyer les résultats. Il n'y a pas de DPU d'écriture puisque la requête ne modifie pas les données. Le DPU total (0,05919) est la somme de Compute \$1 Read \$1 Write.
### Exemple 2 : requête INSERT
```
EXPLAIN ANALYZE VERBOSE INSERT INTO test_table VALUES (1, 'name1'), (2, 'name2'), (3, 'name3');
```
```
QUERY PLAN
----------------------------------------------------
Insert on public.test_table (cost=0.00..0.04 rows=0 width=0) (actual time=0.055..0.056 rows=0 loops=1)
-> Values Scan on "*VALUES*" (cost=0.00..0.04 rows=3 width=122) (actual time=0.003..0.008 rows=3 loops=1)
Output: "*VALUES*".column1, "*VALUES*".column2
Query Identifier: jtkjkexhjotbo
Planning Time: 0.068 ms
Execution Time: 0.543 ms
Statement DPU Estimate:
Compute: 0.01550 DPU
Read: 0.00307 DPU (Transaction minimum: 0.00375)
Write: 0.01875 DPU (Transaction minimum: 0.05000)
Total: 0.03732 DPU
```
Cette instruction effectue principalement des écritures, de sorte que la majeure partie du coût est associée au DPU d'écriture. Le Compute DPU (0,01550) représente le travail effectué pour traiter et insérer les valeurs. Le DPU de lecture (0,00307) reflète les lectures mineures du système (pour les recherches de catalogue ou les vérifications d'index).
Notez les minimums de transaction indiqués à côté de Lecture et écriture DPUs. Ils indiquent les coûts de base par transaction qui s'appliquent *uniquement lorsque l'opération inclut des lectures ou des écritures*. Cela ne signifie pas que chaque transaction entraîne automatiquement une charge de 0,00375 DPU en lecture ou de 0,05 en écriture DPU. Ces minimums sont plutôt appliqués au niveau de la transaction lors de l'agrégation des coûts et uniquement si des lectures ou des écritures ont lieu dans le cadre de cette transaction. En raison de cette différence de portée, les estimations au niveau des relevés `EXPLAIN ANALYZE VERBOSE` peuvent ne pas correspondre exactement aux mesures au niveau des transactions indiquées dans les données de facturation. CloudWatch
## Utilisation des informations du DPU pour l'optimisation
Les estimations du DPU par instruction vous offrent un moyen puissant d'optimiser les requêtes au-delà du simple temps d'exécution. Cas d’utilisation courants :
+ **Connaissance des coûts :** déterminez le coût d'une requête par rapport aux autres.
+ **Optimisation du schéma :** comparez l'impact des index ou des modifications de schéma sur les performances et l'efficacité des ressources.
+ **Planification du budget :** estimez le coût de la charge de travail en fonction de l'utilisation observée du DPU.
+ **Comparaison des requêtes :** évaluez les approches de requête alternatives en fonction de leur consommation relative de DPU.
## Interprétation des informations du DPU
Tenez compte des meilleures pratiques suivantes lorsque vous utilisez des données DPU provenant de `EXPLAIN ANALYZE VERBOSE` :
+ **Utilisez-le de manière directionnelle :** considérez le DPU indiqué comme un moyen de comprendre le coût *relatif* d'une requête plutôt que comme une correspondance exacte avec les CloudWatch métriques ou les données de facturation. Des différences sont attendues car les `EXPLAIN ANALYZE VERBOSE` rapports indiquent les coûts au niveau des relevés, tandis qu'ils CloudWatch regroupent l'activité au niveau des transactions. CloudWatch inclut également les opérations en arrière-plan (telles que ANALYZE ou les compactages) et les frais généraux de transaction (`BEGIN`/`COMMIT`) qui sont `EXPLAIN ANALYZE VERBOSE` intentionnellement exclus.
+ **La variabilité du DPU entre les cycles est normale** dans les systèmes distribués et n'indique aucune erreur. Des facteurs tels que la mise en cache, les modifications du plan d'exécution, la simultanéité ou les changements dans la distribution des données peuvent tous entraîner la consommation de ressources différentes d'une requête à l'autre.
+ **Petites opérations par lots :** si votre charge de travail génère de nombreux petits relevés, envisagez de les regrouper en opérations plus importantes (ne dépassant pas 10 Mo). Cela permet de réduire les frais généraux d'arrondissement et de produire des estimations de coûts plus pertinentes.
+ **À utiliser pour le réglage, pas pour la facturation :** les données DPU entrées `EXPLAIN ANALYZE VERBOSE` sont conçues pour la prise en compte des coûts, le réglage des requêtes et l'optimisation. Il ne s'agit pas d'un indicateur de facturation. Fiez-vous toujours aux CloudWatch indicateurs ou aux rapports de facturation mensuels pour obtenir des données fiables sur les coûts et l'utilisation.