Le traduzioni sono generate tramite traduzione automatica. In caso di conflitto tra il contenuto di una traduzione e la versione originale in Inglese, quest'ultima prevarrà.
# Aurora DSQL e PostgreSQL
Aurora DSQL è un database relazionale distribuito compatibile con PostgreSQL progettato per carichi di lavoro transazionali. Aurora DSQL utilizza componenti di base di PostgreSQL come parser, planner, optimizer e type system.
Il design di Aurora DSQL garantisce che tutta la sintassi PostgreSQL supportata fornisca un comportamento compatibile e produca risultati di query identici. Ad esempio, Aurora DSQL fornisce conversioni di tipo, operazioni aritmetiche e precisione e scalabilità numeriche identiche a PostgreSQL. Eventuali deviazioni sono documentate.
Aurora DSQL introduce anche funzionalità avanzate come il controllo ottimistico della concorrenza e la gestione distribuita dello schema. Con queste funzionalità, puoi utilizzare gli strumenti familiari di PostgreSQL beneficiando al contempo delle prestazioni e della scalabilità di applicazioni distribuite moderne, native del cloud.
## Aspetti salienti della compatibilità con PostgreSQL
Aurora DSQL è attualmente basato sulla versione 16 di PostgreSQL. I punti salienti principali includono quanto segue:
**Protocollo Wire**
Aurora DSQL utilizza il protocollo wire standard PostgreSQL v3. Ciò consente l’integrazione con client, driver e strumenti PostgreSQL standard. Ad esempio, Aurora DSQL è compatibile con `psql`, `pgjdbc` e `psycopg`.
**Sintassi SQL**
Aurora DSQL supporta un’ampia gamma di espressioni e funzioni PostgreSQL standard comunemente utilizzate nei carichi di lavoro transazionali. Le espressioni SQL supportate producono risultati identici a PostgreSQL, tra cui:
+ Gestione dei valori nulli
+ Comportamento dell’ordinamento
+ Scala e precisione per le operazioni numeriche
+ Equivalenza per le operazioni sulle stringhe
Per maggiori informazioni, consultare [Compatibilità delle funzionalità SQL in Aurora DSQL](working-with-postgresql-compatibility.md).
**Gestione delle transazioni**
Aurora DSQL conserva le caratteristiche principali di PostgreSQL, come le transazioni ACID e un livello di isolamento equivalente a PostgreSQL Repeatable Read. Per ulteriori informazioni, consulta [Controllo della concorrenza in Aurora DSQL](working-with-concurrency-control.md).
## Vantaggi dell'architettura distribuita
Il design distribuito e senza condivisione di Aurora DSQL offre vantaggi in termini di prestazioni e scalabilità oltre ai tradizionali database a nodo singolo. Le funzionalità principali includono quanto segue:
**Controllo ottimistico della concorrenza (OCC)**
Aurora DSQL utilizza un modello ottimistico di controllo della concorrenza. Questo approccio senza blocchi impedisce alle transazioni di bloccarsi a vicenda, elimina i deadlock e consente l’esecuzione parallela ad alto throughput. Queste funzionalità rendono Aurora DSQL particolarmente utile per le applicazioni che richiedono prestazioni costanti su larga scala. Per ulteriori esempi, consulta [Controllo della concorrenza in Aurora DSQL](working-with-concurrency-control.md).
**Operazioni DDL asincrone**
Aurora DSQL esegue le operazioni DDL in modo asincrono, il che consente letture e scritture ininterrotte durante le modifiche allo schema. La sua architettura distribuita consente ad Aurora DSQL di eseguire le seguenti operazioni:
+ Esecuzione di operazioni DDL come attività in background, riducendo al minimo le interruzioni.
+ Coordinamento delle modifiche al catalogo come transazioni distribuite fortemente coerenti. Ciò garantisce la visibilità atomica su tutti i nodi, anche in caso di malfunzionamenti o operazioni simultanee.
+ Funzionamento in modo completamente distribuito e senza leader su più zone di disponibilità con livelli di elaborazione e storage disaccoppiati.
Per ulteriori informazioni sull'utilizzo del comando EXPLAIN in PostgreSQL, vedere. [DDL e transazioni distribuite in Aurora DSQL](working-with-ddl.md)
# Compatibilità delle funzionalità SQL in Aurora DSQL
Nelle sezioni seguenti sono disponibile ulteriori informazioni sul supporto di Aurora DSQL per i tipi di dati e i comandi SQL di PostgreSQL.
**Topics**
+ [
# Tipi di dati supportati in Aurora DSQL
](working-with-postgresql-compatibility-supported-data-types.md)
+ [
# SQL supportato per Aurora DSQL
](working-with-postgresql-compatibility-supported-sql-features.md)
+ [
# Sottoinsiemi di comandi SQL supportati in Aurora DSQL
](working-with-postgresql-compatibility-supported-sql-subsets.md)
+ [
# Migrazione da PostgreSQL ad Aurora SQL
](working-with-postgresql-compatibility-migration-guide.md)
# Tipi di dati supportati in Aurora DSQL
Aurora DSQL supporta un sottoinsieme di questi tipi di dati comuni di PostgreSQL.
**Topics**
+ [
## Tipi di dati numerici
](#numeric-data-types)
+ [
## Tipi di dati dei caratteri
](#character-data-types)
+ [
## Tipi di dati data e ora
](#date-time-data-types)
+ [
## Tipi di dati vari
](#miscellaneous-data-types)
+ [
## Tipi di dati di runtime delle query
](#working-with-postgresql-compatibility-query-runtime)
## Tipi di dati numerici
Aurora DSQL supporta i seguenti tipi di dati numerici di PostgreSQL.
| Name | Alias | Intervallo e precisione | Dimensioni dell’archiviazione | Supporto dell’indicizzazione |
| --- | --- | --- | --- | --- |
| smallint | int2 | Da -32768 a \$132767 | 2 byte | Sì |
| `integer` | `int`, `int4` | Da -2147483648 a \$12147483647 | 4 byte | Sì |
| `bigint` | `int8` | Da -9223372036854775808 a 9223372036854775807 | 8 byte | Sì |
| `real` | `float4` | Precisione a 6 cifre decimali | 4 byte | Sì |
| `double precision` | `float8` | Precisione a 15 cifre decimali | 8 byte | Sì |
| `numeric` [ `(`*p*, *s*`)` ] | `decimal` [ `(`*p*, *s*`)` ] `dec`[ `(`*p*,*s*`)`] | Numerico esatto con precisione selezionabile. La precisione massima è 38 e la scala massima è 37.1 Il valore predefinito è `numeric (18,6)`. | 8 byte \$1 2 byte per cifra di precisione. La dimensione massima è di 27 byte. | Sì |
1 - Se non si specifica esplicitamente una dimensione durante l’esecuzione di `CREATE TABLE` o `ALTER TABLE ADD COLUMN`, Aurora DSQL applica le impostazioni predefinite. Aurora DSQL applica dei limiti durante l’esecuzione delle istruzioni `INSERT` o `UPDATE`.
## Tipi di dati dei caratteri
Aurora DSQL supporta i seguenti tipi di dati di caratteri PostgreSQL.
| Name | Alias | Description | Limite di Aurora SQL | Dimensioni dell’archiviazione | Supporto dell’indicizzazione |
| --- | --- | --- | --- | --- | --- |
| `character` [ `(`*n*`)` ] | `char` [ `(`*n*`)` ] | Stringa di caratteri a lunghezza fissa | 4096 byte1 | Variabile fino a 4100 byte | Sì |
| `character varying` [ `(`*n*`)` ] | `varchar` [ `(`*n*`)` ] | Stringa di caratteri a lunghezza variabile | 65535 byte1 | Variabile fino a 65539 byte | Sì |
| `bpchar` [ `(`*n*`)` ] | | Se a lunghezza fissa, si tratta di un alias per `char`. Se a lunghezza variabile, si tratta di un alias per `varchar`, dove gli spazi finali sono semanticamente insignificanti. | 4096 byte1 | Variabile fino a 4100 byte | Sì |
| `text` | | Stringa di caratteri a lunghezza variabile | 1 MiB1 | Variabile fino a 1 MiB | Sì |
1 - Se non si specifica esplicitamente una dimensione quando si eseguono le istruzioni `CREATE TABLE` o `ALTER TABLE ADD COLUMN`, Aurora DSQL applica le impostazioni predefinite. Aurora DSQL applica dei limiti durante l’esecuzione delle istruzioni `INSERT` o `UPDATE`.
## Tipi di dati data e ora
Aurora DSQL supporta i seguenti tipi di dati di data e ora PostgreSQL.
| Name | Alias | Description | Intervallo | Risoluzione | Dimensioni dell’archiviazione | Supporto dell’indicizzazione |
| --- | --- | --- | --- | --- | --- | --- |
| `date` | | Data di calendario (anno, mese, giorno) | 4713 A.C. - 5874897 D.C. | 1 giorno | 4 byte | Sì |
| `time` [ `(`*p*`)` ] [ `without time zone` ] | `timestamp` | Ora del giorno senza fuso orario | 0 – 1 | 1 microsecondo | 8 byte | Sì |
| `time` [ `(`*p*`)` ] `with time zone` | `timetz` | ora del giorno, compreso il fuso orario | 00:00:00\$11559 – 24:00:00 –1559 | 1 microsecondo | 12 byte | No |
| `timestamp` [ `(`*p*`)` ] [ `without time zone` ] | | Data e ora, senza fuso orario | 4713 A.C. - 294276 D.C. | 1 microsecondo | 8 byte | Sì |
| `timestamp` [ `(`*p*`)` ] `with time zone` | `timestamptz` | Data e ora, incluso il fuso orario | 4713 A.C. - 294276 D.C. | 1 microsecondo | 8 byte | Sì |
| `interval` [ `fields` ] [ `(`*p*`)` ] | | Intervallo di tempo | -178000000 anni - 178000000 anni | 1 microsecondo | 16 byte | No |
## Tipi di dati vari
Aurora DSQL supporta i seguenti tipi di dati PostgreSQL vari.
| Name | Alias | Description | Limite di Aurora SQL | Dimensioni dell’archiviazione | Supporto dell’indicizzazione |
| --- | --- | --- | --- | --- | --- |
| `boolean` | `bool` | Booleano logico (true/false) | | 1 byte | Sì |
| `bytea` | | Dati binari (“array di byte”) | 1 MiB1 | Variabile fino al limite di 1 MiB | No |
| `UUID` | | Identificatore univoco universale | | 16 byte | Sì |
1 - Se non si specifica esplicitamente una dimensione quando si eseguono le istruzioni `CREATE TABLE` o `ALTER TABLE ADD COLUMN`, Aurora DSQL applica le impostazioni predefinite. Aurora DSQL applica dei limiti durante l’esecuzione delle istruzioni `INSERT` o `UPDATE`.
## Tipi di dati di runtime delle query
I tipi di dati di runtime delle query sono tipi di dati interni utilizzati al momento dell’esecuzione delle query. Questi tipi sono distinti dai tipi compatibili con PostgreSQL come `varchar` e `integer` che è possibile definire nello schema. Questi tipi sono invece rappresentazioni di runtime utilizzate da Aurora DSQL per l’elaborazione di una query.
I seguenti tipi di dati sono supportati solo durante il runtime delle query:
**Tipo array**
Aurora DSQL supporta array dei tipi di dati supportati. Ad esempio, è possibile avere un array di numeri interi. La funzione `string_to_array` divide una stringa in un array in stile PostgreSQL con il delimitatore virgola (`,`) come mostrato nell’esempio seguente. È possibile utilizzare gli array nelle espressioni, negli output di funzioni o nei calcoli temporanei durante l’esecuzione delle query.
```
SELECT string_to_array('1,2', ',');
```
La funzione restituisce un risultato simile al seguente:
```
string_to_array
-----------------
{1,2}
(1 row)
```
****Tipo inet****
Il tipo di dati rappresenta IPv4 gli indirizzi IPv6 host e le relative sottoreti. Questo tipo è utile per l’analisi dei log, il filtraggio su sottoreti IP o l’esecuzione di calcoli di rete all’interno di una query. Per maggiori informazioni, consulta [inet nella documentazione di PostgreSQL](https://www.PostgreSQL.org/docs/16/datatype-net-types.html#DATATYPE-INET).
**Funzioni JSON di runtime**
Aurora DSQL supporta JSON e JSONB come tipi di dati di runtime per l'elaborazione delle query. Archivia i dati JSON come `text` colonne e trasmettili in JSON durante l'esecuzione delle query per utilizzare le funzioni e gli operatori JSON di PostgreSQL.
Aurora DSQL supporta la maggior parte delle funzioni JSON di PostgreSQL della [sezione 9.1.6 Funzioni e operatori JSON](https://www.postgresql.org/docs/current/functions-json.html) con un comportamento identico.
Le funzioni che restituiscono tipi JSON o JSONB potrebbero richiedere una trasformazione aggiuntiva in `text` per una corretta visualizzazione.
```
SELECT json_build_array(1, 2, 'foo', 4, 5)::text;
```
La funzione restituisce un risultato simile al seguente:
```
json_build_array
---------------------
[1, 2, "foo", 4, 5]
(1 row)
```
# SQL supportato per Aurora DSQL
Aurora DSQL supporta un’ampia serie di funzionalità SQL di base di PostgreSQL. Nelle sezioni seguenti, è possibile ottenere informazioni sul supporto generale delle espressioni PostgreSQL. Questo elenco non è completo.
## Comando `SELECT`
Aurora DSQL supporta le seguenti clausole del comando `SELECT`.
| Clausola primaria | Clausole supportate |
| --- | --- |
| `FROM` | |
| `GROUP BY` | `ALL`, `DISTINCT` |
| `ORDER BY` | `ASC`, `DESC`, `NULLS` |
| `LIMIT` | |
| `DISTINCT` | |
| `HAVING` | |
| `USING` | |
| `WITH` (espressioni di tabella comuni) | |
| `INNER JOIN` | `ON` |
| `OUTER JOIN` | `LEFT`, `RIGHT`, `FULL`, `ON` |
| `CROSS JOIN` | `ON` |
| `UNION` | `ALL` |
| `INTERSECT` | `ALL` |
| `EXCEPT` | `ALL` |
| `OVER` | `RANK ()`, `PARTITION BY` |
| `FOR UPDATE` | |
## Data Definition Language (DDL)
Aurora DSQL supporta i seguenti comandi DDL di PostgreSQL.
| Comando | Clausola primaria | Clausole supportate |
| --- | --- | --- |
| `CREATE` | `TABLE` | Per informazioni sulla sintassi supportata del comando `CREATE TABLE`, consulta [`CREATE TABLE`](create-table-syntax-support.md). |
| `ALTER` | `TABLE` | Per informazioni sulla sintassi supportata del comando `ALTER TABLE`, consulta [`ALTER TABLE`](alter-table-syntax-support.md). |
| `DROP` | `TABLE` | |
| `CREATE` | `[UNIQUE] INDEX ASYNC` | È possibile eseguire questo comando con i seguenti parametri: `ON`, `NULLS FIRST`, `NULLS LAST`. Per informazioni sulla sintassi supportata del comando `CREATE INDEX ASYNC`, consulta [Indici asincroni in Aurora SQL](working-with-create-index-async.md). |
| `DROP` | `INDEX` | |
| `CREATE` | `VIEW` | Per maggiori informazioni sulla sintassi supportata del comando `CREATE VIEW`, consulta [`CREATE VIEW`](create-view.md). |
| ALTER | VIEW | Per informazioni sulla sintassi supportata del comando `ALTER VIEW`, consulta [`ALTER VIEW`](alter-view-syntax-support.md). |
| DROP | VIEW | Per informazioni sulla sintassi supportata del comando DROP VIEW, consulta [`DROP VIEW`](drop-view-overview.md). |
| `CREATE` | `SEQUENCE` | Per informazioni sulla sintassi supportata del comando `CREATE SEQUENCE`, consulta [`CREATE SEQUENCE`](create-sequence-syntax-support.md). |
| `ALTER` | `SEQUENCE` | Per informazioni sulla sintassi supportata del comando `ALTER SEQUENCE`, consulta [`ALTER SEQUENCE`](alter-sequence-syntax-support.md). |
| `DROP` | `SEQUENCE` | Per informazioni sulla sintassi supportata del comando `DROP SEQUENCE`, consulta [`DROP SEQUENCE`](drop-sequence-syntax-support.md). |
| `CREATE` | `ROLE`, `WITH` | |
| `CREATE` | `FUNCTION` | `LANGUAGE SQL` |
| `CREATE` | `DOMAIN` | |
## Data Manipulation Language (DML)
Aurora DSQL supporta i seguenti comandi DML di PostgreSQL.
| Comando | Clausola primaria | Clausole supportate |
| --- | --- | --- |
| `INSERT` | `INTO` | `VALUES`SELECT |
| `UPDATE` | `SET` | `WHERE (SELECT)` `FROM, WITH` |
| DELETE | FROM | USING, WHERE |
## Data Control Language (DCL)
Aurora DSQL supporta i seguenti comandi DCL di PostgreSQL.
| Comando | Clausole supportate |
| --- | --- |
| `GRANT` | `ON`, `TO` |
| `REVOKE` | `ON`, `FROM`, `CASCADE`, `RESTRICT` |
## Transaction Control Language (TCL)
Aurora DSQL supporta i seguenti comandi TCL di PostgreSQL.
| Comando | Clausole supportate | 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` |
## Comandi di utilità
Aurora DSQL supporta i seguenti comandi di utilità di PostgreSQL:
+ `EXPLAIN`
+ `ANALYZE` (solo nome della relazione)
# Sottoinsiemi di comandi SQL supportati in Aurora DSQL
Questa sezione fornisce informazioni dettagliate sui comandi SQL supportati, concentrandosi sui comandi con set di parametri e sottocomandi estesi. Ad esempio, CREATE TABLE in PostgreSQL offre molte clausole e parametri, un sottoinsieme dei quali è supportato da Aurora DSQL. Questa sezione descrive i sottoinsiemi supportati dei comandi SQL comuni utilizzando elementi di sintassi PostgreSQL familiari supportati da 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` definisce una nuova tabella.
```
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 [, ... ] ) ]
```
## Colonne di identità
**Nota**
Quando si utilizzano le colonne di identità, il valore della cache deve essere considerato attentamente. Per ulteriori informazioni, consulta il callout importante nella [`CREATE SEQUENCE`](create-sequence-syntax-support.md) pagina.
Per indicazioni su come utilizzare al meglio le colonne di identità in base ai modelli di carico di lavoro, consulta. [Utilizzo di sequenze e colonne di identità](sequences-identity-columns-working-with.md)
La `GENERATED { ALWAYS | BY DEFAULT } AS IDENTITY ( sequence_options )` clausola crea la colonna come colonna di *identità*. Alla colonna sarà associata una sequenza implicita e nelle righe appena inserite la colonna avrà automaticamente i valori della sequenza assegnata. Tale colonna è implicita. `NOT NULL`
Le clausole `ALWAYS` e i comandi `BY DEFAULT` determinano la modalità di gestione esplicita dei valori e dei comandi specificati dall'utente. `INSERT` `UPDATE`
In un `INSERT` comando, se `ALWAYS` è selezionato, un valore specificato dall'utente viene accettato solo se l'istruzione lo specifica. `INSERT` `OVERRIDING SYSTEM VALUE` Se `BY DEFAULT` è selezionato, il valore specificato dall'utente ha la precedenza.
In un `UPDATE` comando, se `ALWAYS` selezionato, qualsiasi aggiornamento della colonna a qualsiasi valore diverso da quello `DEFAULT` verrà rifiutato. Se `BY DEFAULT` è selezionata, la colonna può essere aggiornata normalmente. (Non esiste alcuna `OVERRIDING` clausola per il `UPDATE` comando.)
La *sequence\$1options* clausola può essere utilizzata per sovrascrivere i parametri della sequenza. Le opzioni disponibili includono quelle mostrate per[`CREATE SEQUENCE`](create-sequence-syntax-support.md), plus. `SEQUENCE NAME name` `SEQUENCE NAME`In caso contrario, il sistema sceglie un nome inutilizzato per la sequenza.
# `ALTER TABLE`
`ALTER TABLE` modifica la definizione di una tabella.
```
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 }
```
## Azioni della colonna Identity
**`SET GENERATED { ALWAYS | BY DEFAULT }` / `SET sequence_option` / `RESTART`**
Questi moduli modificano se una colonna è una colonna di identità o modificano l'attributo di generazione di una colonna di identità esistente. Per informazioni dettagliate, vedi [`CREATE TABLE`](create-table-syntax-support.md). Ad esempio`SET DEFAULT`, questi moduli influiscono solo sul comportamento dei `UPDATE` comandi `INSERT` e successivi e non modificano le righe già presenti nella tabella.
*sequence\$1option*È un'opzione supportata da [`ALTER SEQUENCE`](alter-sequence-syntax-support.md)`INCREMENT BY`. Questi moduli alterano la sequenza che sta alla base di una colonna di identità esistente.
**`DROP IDENTITY [ IF EXISTS ]`**
Questo modulo rimuove la proprietà identity da una colonna. Se `DROP IDENTITY IF EXISTS` viene specificato e la colonna non è una colonna di identità, non viene generato alcun errore. In questo caso viene invece emesso un avviso.
# `CREATE SEQUENCE`
`CREATE SEQUENCE`— definire un nuovo generatore di sequenze.
**Importante**
In PostgreSQL, la `CACHE` specificazione è facoltativa e il valore predefinito è 1. In un sistema distribuito come Amazon Aurora DSQL, le operazioni di sequenza implicano il coordinamento e una dimensione della cache pari a 1 può aumentare il sovraccarico di coordinamento in caso di elevata concorrenza. Sebbene valori di cache più elevati consentano di fornire numeri di sequenza da intervalli preallocati localmente, migliorando la velocità di trasmissione, è possibile perdere i valori riservati non utilizzati, rendendo più visibili le lacune e gli effetti di ordinamento. Poiché le applicazioni differiscono nella loro sensibilità all'ordinamento delle allocazioni rispetto alla velocità effettiva, Amazon Aurora DSQL richiede di essere specificato in modo esplicito e attualmente supporta `CACHE = 1` o `CACHE >= 65536` fornisce una chiara distinzione tra un comportamento di allocazione più vicino `CACHE` alla generazione strettamente sequenziale e l'allocazione ottimizzata per carichi di lavoro altamente simultanei.
Quando`CACHE >= 65536`, è garantito che i valori della sequenza siano unici, ma potrebbero non essere generati in ordine crescente tra le sessioni, e possono verificarsi lacune, in particolare quando i valori memorizzati nella cache non vengono consumati completamente. Queste caratteristiche sono coerenti con la semantica di PostgreSQL per le sequenze memorizzate nella cache in uso simultaneo, in cui entrambi i sistemi garantiscono valori distinti ma non garantiscono un ordinamento strettamente sequenziale tra le sessioni.
All'interno di una singola sessione client, i valori di sequenza potrebbero non apparire sempre strettamente crescenti, in particolare al di fuori delle transazioni esplicite. Questo comportamento è simile alle distribuzioni PostgreSQL che utilizzano il pool di connessioni. Un comportamento di allocazione più simile a un ambiente PostgreSQL a sessione singola può essere ottenuto utilizzando `CACHE = 1` o ottenendo valori di sequenza all'interno di transazioni esplicite.
Con`CACHE = 1`, l'allocazione delle sequenze segue il comportamento delle sequenze non memorizzate nella cache di PostgreSQL.
Per indicazioni su come utilizzare al meglio le sequenze basate sui modelli di carico di lavoro, consulta. [Utilizzo di sequenze e colonne di identità](sequences-identity-columns-working-with.md)
## Sintassi supportata
```
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`crea un nuovo generatore di numeri di sequenza. Ciò comporta la creazione e l'inizializzazione di una nuova tabella speciale a riga singola con il nome. *name* Il generatore sarà di proprietà dell'utente che emette il comando.
Se viene fornito un nome di schema, la sequenza viene creata nello schema specificato. Altrimenti viene creata nello schema corrente. Il nome della sequenza deve essere distinto dal nome di qualsiasi altra relazione (tabella, sequenza, indice, vista, vista materializzata o tabella esterna) nello stesso schema.
Dopo aver creato una sequenza, è possibile utilizzare le funzioni `nextval` e `setval` operare sulla sequenza. `currval` Queste funzioni sono documentate in[Funzioni di manipolazione di sequenze](sequence-functions-syntax-support.md).
Sebbene non sia possibile aggiornare direttamente una sequenza, è possibile utilizzare una query come:
```
SELECT * FROM name;
```
per esaminare alcuni parametri e lo stato corrente di una sequenza. In particolare, il `last_value` campo della sequenza mostra l'ultimo valore assegnato da ogni sessione. (Naturalmente, questo valore potrebbe essere obsoleto nel momento in cui viene stampato, se altre sessioni effettuano `nextval` chiamate attivamente.) Altri parametri come *increment* e *maxvalue* possono essere osservati nella `pg_sequences` vista.
## Parameters
**`IF NOT EXISTS`**
Non generare un errore se esiste già una relazione con lo stesso nome. In questo caso viene emesso un avviso. Nota che non c'è alcuna garanzia che la relazione esistente sia qualcosa di simile alla sequenza che sarebbe stata creata: potrebbe anche non essere una sequenza.
***name***
Il nome (facoltativamente qualificato dallo schema) della sequenza da creare.
***data\$1type***
La clausola facoltativa `AS data_type` specifica il tipo di dati della sequenza. I tipi validi sono. `bigint` `bigint`è l'impostazione predefinita. Il tipo di dati determina i valori minimo e massimo predefiniti della sequenza.
***increment***
La clausola facoltativa `INCREMENT BY increment` specifica quale valore viene aggiunto al valore della sequenza corrente per creare un nuovo valore. Un valore positivo creerà una sequenza crescente, uno negativo una sequenza discendente. Il valore predefinito è 1.
***minvalue* / `NO MINVALUE`**
La clausola opzionale `MINVALUE minvalue` determina il valore minimo che una sequenza può generare. Se questa clausola non viene fornita o `NO MINVALUE` viene specificata, verranno utilizzate le impostazioni predefinite. L'impostazione predefinita per una sequenza crescente è 1. L'impostazione predefinita per una sequenza decrescente è il valore minimo del tipo di dati.
***maxvalue* / `NO MAXVALUE`**
La clausola opzionale `MAXVALUE maxvalue` determina il valore massimo per la sequenza. Se questa clausola non viene fornita o `NO MAXVALUE` viene specificata, verranno utilizzati i valori predefiniti. L'impostazione predefinita per una sequenza crescente è il valore massimo del tipo di dati. L'impostazione predefinita per una sequenza decrescente è -1.
**`CYCLE` / `NO CYCLE`**
L'`CYCLE`opzione consente alla sequenza di avvolgersi quando la *maxvalue* o *minvalue* è stata raggiunta rispettivamente da una sequenza ascendente o discendente. Se viene raggiunto il limite, il numero successivo generato sarà rispettivamente il *minvalue* o*maxvalue*.
Se `NO CYCLE` è specificato, tutte le chiamate effettuate `nextval` dopo che la sequenza ha raggiunto il valore massimo restituiranno un errore. Se non viene specificato nessuno dei due`CYCLE`, `NO CYCLE` è l'impostazione predefinita. `NO CYCLE`
***start***
La clausola opzionale `START WITH start` consente alla sequenza di iniziare da qualsiasi punto. Il valore iniziale predefinito è *minvalue* per le sequenze ascendenti e *maxvalue* per quelle discendenti.
***cache***
La clausola `CACHE cache` specifica quanti numeri di sequenza devono essere preallocati e archiviati in memoria per un accesso più rapido. I valori accettabili per `CACHE` Aurora DSQL sono 1 o qualsiasi numero >= 65536. Il valore minimo è 1 (è possibile generare solo un valore alla volta, il che significa nessuna cache).
**`OWNED BY table_name.column_name` / `OWNED BY NONE`**
L'`OWNED BY`opzione fa sì che la sequenza venga associata a una colonna specifica della tabella, in modo che se quella colonna (o l'intera tabella) viene eliminata, anche la sequenza verrà eliminata automaticamente. La tabella specificata deve avere lo stesso proprietario e appartenere allo stesso schema della sequenza. `OWNED BY NONE`, l'impostazione predefinita, specifica che tale associazione non esiste.
## Note
Utilizzare [`DROP SEQUENCE`](drop-sequence-syntax-support.md) per rimuovere una sequenza.
Le sequenze sono basate sull'`bigint`aritmetica, quindi l'intervallo non può superare l'intervallo di un numero intero di otto byte (da -9223372036854775808 a 9223372036854775807).
Poiché le chiamate e non vengono mai annullate, gli oggetti di sequenza non possono essere utilizzati se è necessaria l'assegnazione «senza interruzioni» dei numeri di sequenza. `nextval` `setval`
Ogni sessione allocherà e memorizzerà nella cache i valori di sequenza successivi durante un accesso all'oggetto sequenza e aumenterà di conseguenza quelli dell'oggetto sequenza. `last_value` Quindi, i successivi utilizzi *cache* -1 di `nextval` quella sessione restituiscono semplicemente i valori preallocati senza toccare l'oggetto della sequenza. Pertanto, tutti i numeri assegnati ma non utilizzati all'interno di una sessione andranno persi al termine di quella sessione, con conseguenti «buchi» nella sequenza.
Inoltre, sebbene sia garantito che più sessioni assegnino valori di sequenza distinti, i valori potrebbero essere generati in modo non sequenziale se si considerano tutte le sessioni. Ad esempio, con un'*cache*impostazione di 10, la sessione A potrebbe riservare i valori 1.. 10 e restituire `nextval` =1, quindi la sessione B potrebbe riservare i valori 11.. 20 e restituire `nextval` =11 prima che la sessione A abbia generato =2. `nextval` Pertanto, con un'*cache*impostazione pari a uno si può presumere che `nextval` i valori vengano generati in sequenza; con un'*cache*impostazione maggiore di uno si deve solo supporre che `nextval` i valori siano tutti distinti, non che vengano generati in modo puramente sequenziale. Inoltre, `last_value` rifletterà il valore più recente riservato da qualsiasi sessione, indipendentemente dal fatto che sia stato ancora restituito da. `nextval`
Un'altra considerazione è che un'`setval`esecuzione su tale sequenza non verrà notata dalle altre sessioni finché non avranno esaurito i valori preallocati che hanno memorizzato nella cache.
## Esempi
Create una sequenza crescente chiamata`serial`, a partire da 101:
```
CREATE SEQUENCE serial CACHE 65536 START 101;
```
Seleziona il numero successivo da questa sequenza:
```
SELECT nextval('serial');
nextval
---------
101
```
Seleziona il numero successivo da questa sequenza:
```
SELECT nextval('serial');
nextval
---------
102
```
Usa questa sequenza in un `INSERT` comando:
```
INSERT INTO distributors VALUES (nextval('serial'), 'nothing');
```
Reimposta la sequenza su un valore specifico utilizzando`setval`:
```
SELECT setval('serial', 200);
SELECT nextval('serial');
nextval
---------
201
```
## Compatibilità
`CREATE SEQUENCE`è conforme allo standard SQL, con le seguenti eccezioni:
+ L'ottenimento del valore successivo viene eseguito utilizzando la `nextval()` funzione anziché l'espressione dello `NEXT VALUE FOR` standard.
+ La `OWNED BY` clausola è un'estensione PostgreSQL.
# `ALTER SEQUENCE`
`ALTER SEQUENCE`— modificare la definizione di un generatore di sequenze.
**Importante**
Quando si usano sequenze, il valore della cache deve essere considerato attentamente. Per ulteriori informazioni, consultate il callout importante nella [`CREATE SEQUENCE`](create-sequence-syntax-support.md) pagina.
Per indicazioni su come utilizzare al meglio le sequenze basate sui modelli di carico di lavoro, consulta. [Utilizzo di sequenze e colonne di identità](sequences-identity-columns-working-with.md)
## Sintassi supportata
```
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`modifica i parametri di un generatore di sequenze esistente. Tutti i parametri non specificatamente impostati nel `ALTER SEQUENCE` comando mantengono le impostazioni precedenti.
È necessario possedere la sequenza da utilizzare`ALTER SEQUENCE`. Per modificare lo schema di una sequenza, è necessario disporre anche dei `CREATE` privilegi sul nuovo schema. Per modificare il proprietario, dovete essere in grado di `SET ROLE` ricoprire il nuovo ruolo di proprietario e quel ruolo deve avere `CREATE` i privilegi sullo schema della sequenza. (Queste restrizioni impongono che la modifica del proprietario non comporti nulla che non si possa fare eliminando e ricreando la sequenza. Tuttavia, un superutente può comunque modificare la proprietà di qualsiasi sequenza.)
## Parameters
***name***
Il nome (facoltativamente qualificato dallo schema) di una sequenza da modificare.
**`IF EXISTS`**
Non generare un errore se la sequenza non esiste. In questo caso viene emesso un avviso.
***increment***
La clausola `INCREMENT BY increment` è facoltativa. Un valore positivo creerà una sequenza crescente, uno negativo una sequenza decrescente. Se non specificato, verrà mantenuto il vecchio valore di incremento.
***minvalue* / `NO MINVALUE`**
La clausola opzionale `MINVALUE minvalue` determina il valore minimo che una sequenza può generare. Se `NO MINVALUE` viene specificato, verranno utilizzati i valori predefiniti di 1 e il valore minimo del tipo di dati per le sequenze ascendenti e discendenti, rispettivamente. Se non viene specificata nessuna opzione, verrà mantenuto il valore minimo corrente.
***maxvalue* / `NO MAXVALUE`**
La clausola opzionale `MAXVALUE maxvalue` determina il valore massimo per la sequenza. Se `NO MAXVALUE` viene specificato, verranno utilizzati i valori predefiniti del valore massimo del tipo di dati e -1 per le sequenze ascendenti e discendenti, rispettivamente. Se non viene specificata nessuna opzione, verrà mantenuto il valore massimo corrente.
**`CYCLE`**
La parola `CYCLE` chiave opzionale può essere utilizzata per consentire alla sequenza di avvolgersi quando la *maxvalue* o *minvalue* è stata raggiunta rispettivamente da una sequenza crescente o decrescente. Se viene raggiunto il limite, il numero successivo generato sarà rispettivamente il *minvalue* o*maxvalue*.
**`NO CYCLE`**
Se viene specificata la parola `NO CYCLE` chiave opzionale, tutte le chiamate effettuate `nextval` dopo che la sequenza ha raggiunto il valore massimo restituiranno un errore. Se non `NO CYCLE` viene specificato nessuno `CYCLE` dei due, verrà mantenuto il comportamento del vecchio ciclo.
***start***
La clausola opzionale `START WITH start` modifica il valore iniziale registrato della sequenza. Ciò non ha alcun effetto sul valore della sequenza corrente; imposta semplicemente il valore che verranno utilizzati `ALTER SEQUENCE RESTART` dai comandi futuri.
***restart***
La clausola opzionale `RESTART [ WITH restart ]` modifica il valore corrente della sequenza. È simile alla chiamata alla `setval` funzione con `is_called` =`false`: il valore specificato verrà restituito dalla successiva chiamata di`nextval`. Scrivere `RESTART` senza *restart* valore equivale a fornire il valore iniziale registrato da `CREATE SEQUENCE` o impostato per l'ultima volta da`ALTER SEQUENCE START WITH`.
A differenza di una `setval` chiamata, un'`RESTART`operazione su una sequenza è transazionale e impedisce alle transazioni simultanee di ottenere numeri dalla stessa sequenza. Se questa non è la modalità operativa desiderata, `setval` dovrebbe essere utilizzata.
***cache***
La clausola `CACHE cache` consente di preallocare e archiviare i numeri di sequenza in memoria per un accesso più rapido. Il valore deve essere 1 o un valore diverso >= 65536. Se non specificato, il vecchio valore della cache verrà mantenuto. Per ulteriori informazioni sul comportamento della cache, consulta la guida [`CREATE SEQUENCE`](create-sequence-syntax-support.md) riportata di seguito.
**`OWNED BY table_name.column_name` / `OWNED BY NONE`**
L'`OWNED BY`opzione fa sì che la sequenza venga associata a una colonna specifica della tabella, in modo che se quella colonna (o l'intera tabella) viene eliminata, anche la sequenza verrà eliminata automaticamente. Se specificata, questa associazione sostituisce qualsiasi associazione precedentemente specificata per la sequenza. La tabella specificata deve avere lo stesso proprietario e appartenere allo stesso schema della sequenza. La specificazione `OWNED BY NONE` rimuove qualsiasi associazione esistente, rendendo la sequenza «indipendente».
***new\$1owner***
Il nome utente del nuovo proprietario della sequenza.
***new\$1name***
Il nuovo nome per la sequenza.
***new\$1schema***
Il nuovo schema per la sequenza.
## Note
`ALTER SEQUENCE`non influirà immediatamente sui `nextval` risultati nei backend, diversi da quello corrente, che hanno valori di sequenza preallocati (memorizzati nella cache). Utilizzeranno tutti i valori memorizzati nella cache prima di notare i parametri di generazione della sequenza modificati. Il backend corrente verrà modificato immediatamente.
`ALTER SEQUENCE`non influisce sullo `currval` stato della sequenza.
`ALTER SEQUENCE`può causare altre transazioni verso OCC.
Per ragioni storiche, `ALTER TABLE` può essere utilizzato anche con le sequenze; ma le uniche varianti consentite con `ALTER TABLE` le sequenze sono equivalenti ai moduli mostrati sopra.
## Esempi
Riavvia una sequenza chiamata`serial`, a 105:
```
ALTER SEQUENCE serial RESTART WITH 105;
```
## Compatibilità
`ALTER SEQUENCE`è conforme allo standard SQL, ad eccezione delle `SET SCHEMA` clausole`AS`,`START WITH`, `OWNED BY``OWNER TO`, e`RENAME TO`, che sono estensioni PostgreSQL.
# `DROP SEQUENCE`
`DROP SEQUENCE`— rimuovere una sequenza.
## Sintassi supportata
```
DROP SEQUENCE [ IF EXISTS ] name [, ...] [ CASCADE | RESTRICT ]
```
## Description
`DROP SEQUENCE`rimuove i generatori di numeri di sequenza. Una sequenza può essere eliminata solo dal suo proprietario o da un superutente.
## Parameters
**`IF EXISTS`**
Non generare un errore se la sequenza non esiste. In questo caso viene emesso un avviso.
***name***
Il nome (facoltativamente qualificato dallo schema) di una sequenza.
**`CASCADE`**
Rilascia automaticamente gli oggetti che dipendono dalla sequenza e, a loro volta, tutti gli oggetti che dipendono da tali oggetti.
**`RESTRICT`**
Rifiuta di eliminare la sequenza se alcuni oggetti dipendono da essa. Questa è l’impostazione predefinita.
## Esempi
Per rimuovere la sequenza`seq`:
```
DROP SEQUENCE seq;
```
## Compatibilità
`DROP SEQUENCE`è conforme allo standard SQL, tranne per il fatto che lo standard consente di eliminare solo una sequenza per comando e a parte l'`IF EXISTS`opzione, che è un'estensione PostgreSQL.
# `CREATE VIEW`
`CREATE VIEW` definisce una nuova vista persistente. Aurora DSQL non supporta le viste temporanee, sono supportate solo le viste permanenti.
## Sintassi supportata
```
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` definisce una vista basata su una query. La vista non è materializzata fisicamente. Al contrario, la query viene eseguita ogni volta che si fa riferimento alla vista in una query.
`CREATE or REPLACE VIEW` è simile, ma se esiste già una vista con lo stesso nome, questa viene sostituita. La nuova query deve generare le stesse colonne generate dalla query della vista esistente (ovvero gli stessi nomi di colonna nello stesso ordine e con gli stessi tipi di dati), ma può aggiungere ulteriori colonne alla fine dell’elenco. I calcoli che danno origine alle colonne di output possono essere diversi.
Se viene specificato un nome di schema (come `CREATE VIEW myschema.myview ...`), la vista viene creata utilizzando lo schema specificato. In caso contrario la vista viene creata nello schema corrente.
Il nome della vista deve essere distinto dal nome di qualsiasi altra relazione (tabella, indice, vista) nello stesso schema.
## Parameters
`CREATE VIEW` supporta vari parametri per controllare il comportamento delle viste aggiornabili automaticamente.
**`RECURSIVE`**
Crea una vista ricorsiva. La sintassi: `CREATE RECURSIVE VIEW [ schema . ] view_name (column_names) AS SELECT ...;` è equivalente a `CREATE VIEW [ schema . ] view_name AS WITH RECURSIVE view_name (column_names) AS (SELECT ...) SELECT column_names FROM view_name;`.
Per una vista ricorsiva è necessario specificare un elenco di nomi di colonne della vista.
**`name`**
Il nome della vista da creare, che può essere facoltativamente accompagnato dallo schema. Per una vista ricorsiva è necessario specificare un elenco di nomi di colonne.
**`column_name`**
Un elenco facoltativo di nomi da utilizzare per le colonne nella vista. Se non vengono specificati nomi di colonne, questi ricavati dalla query.
**`WITH ( view_option_name [= view_option_value] [, ... ] )`**
Questa clausola specifica i parametri opzionali per una vista. Sono supportati i seguenti parametri.
+ `check_option (enum)` - Questo parametro può assumere i valori `local` o `cascaded` ed è equivalente a specificare `WITH [ CASCADED | LOCAL ] CHECK OPTION`.
+ `security_barrier (boolean)` - Deve essere usato se la vista è destinata a fornire una sicurezza a livello di riga. Aurora DSQL attualmente non supporta la sicurezza a livello di riga, ma questa opzione forzerà comunque la valutazione delle condizioni della vista (e di tutte `WHERE` le condizioni che utilizzano operatori contrassegnati come`LEAKPROOF`) a essere valutate per prime.
+ `security_invoker (boolean)` - Questa opzione fa sì che le relazioni di base sottostanti vengano verificate con i privilegi dell’utente della vista anziché con quelli del proprietario della vista. Per dettagli completi, consulta le note riportate di seguito.
Tutte le opzioni precedenti possono essere modificate nelle viste esistenti utilizzando `ALTER VIEW`.
**`query`**
Un `VALUES` comando `SELECT` or che fornirà le colonne e le righe della vista.
**`WITH [ CASCADED | LOCAL ] CHECK OPTION`**
Questa opzione controlla il comportamento delle viste aggiornabili automaticamente. Quando viene specificata questa opzione, i comandi `INSERT` e `UPDATE` sulla vista verranno controllati per garantire che le nuove righe soddisfino la condizione di definizione della vista (ovvero, le nuove righe vengono controllate per garantire che siano visibili attraverso la vista). In caso contrario, l’aggiornamento verrà rifiutato. Se `CHECK OPTION` non è specificato, i comandi `INSERT` e `UPDATE` sulla vista possono creare righe che non sono visibili attraverso la vista stessa.
`LOCAL` - Le nuove righe vengono verificate solo in base alle condizioni definite direttamente nella vista stessa. Qualsiasi condizione definita nelle viste di base sottostanti non viene verificata (a meno che anch’esse non specifichino l’opzione `CHECK OPTION`).
`CASCADED` - Le nuove righe vengono verificate rispetto alle condizioni della vista e di tutte le viste di base sottostanti. Se viene indicato `CHECK OPTION` e non viene specifica l’opzioni `LOCAL` né l’opzione `CASCADED`, viene assunto il valore `CASCADED`.
`CHECK OPTION` può essere utilizzato con le viste `RECURSIVE`. `CHECK OPTION` è supportato solo nelle viste aggiornabili automaticamente.
## Note
Utilizzare l’istruzione `DROP VIEW` per eliminare le viste.
I nomi e i tipi di dati delle colonne della vista devono essere considerati attentamente. Ad esempio, CREATE VIEW vista AS SELECT ’Hello World’; non è consigliato perché il nome della colonna predefinito è `?column?;`. Inoltre, il tipo di dati della colonna predefinito è `text`, il che potrebbe non essere quello desiderato.
Un approccio migliore consiste nello specificare esplicitamente il nome della colonna e il tipo di dati, ad esempio: `CREATE VIEW vista AS SELECT text 'Hello World' AS hello;`.
Per impostazione predefinita, l’accesso alle relazioni di base sottostanti a cui si fa riferimento nella vista è determinato dalle autorizzazioni del proprietario della vista. In alcuni casi, questo può essere utilizzato per fornire un accesso sicuro ma limitato alle tabelle sottostanti. Tuttavia, non tutte le viste sono protette dalla manomissione.
+ Se la proprietà `security_invoker` della vista è impostata su true, l’accesso alle relazioni di base sottostanti è determinato dalle autorizzazioni dell’utente che esegue la query, anziché su quelle del proprietario della vista. Pertanto, l’utente di una vista con l’opzione Security Invoker deve disporre delle autorizzazioni pertinenti sulla vista e sulle relative relazioni di base sottostanti.
+ Se una delle relazioni di base sottostanti è una vista con l’opzione Security Invoker, verrà trattata come se vi fosse stato effettuato l’accesso direttamente dalla query originale. Pertanto, una vista con l’opzione Security Invoker verificherà sempre le relazioni di base sottostanti utilizzando le autorizzazioni dell’utente corrente, anche se vi si accede da una vista senza la proprietà `security_invoker`.
+ Le funzioni chiamate nella vista vengono trattate come se fossero state chiamate direttamente dalla query che utilizza la vista. Pertanto, l’utente di una vista deve disporre delle autorizzazioni per chiamare tutte le funzioni utilizzate dalla vista. Le funzioni nella vista vengono eseguite con i privilegi dell’utente che esegue la query o del proprietario della funzione, a seconda che le funzioni siano definite come `SECURITY INVOKER` o `SECURITY DEFINER`.
+ L’utente che crea o sostituisce una vista deve disporre dei privilegi `USAGE` su tutti gli schemi a cui si fa riferimento nella query della vista, al fine di poter accedere agli oggetti a cui si fa riferimento in tali schemi.
+ Quando `CREATE OR REPLACE VIEW` viene utilizzato su una vista esistente, vengono modificate solo la regola di `SELECT` di definizione della vista, più eventuali parametri `WITH ( ... )` e relativa `CHECK OPTION`. Le altre caratteristiche della vista, tra cui proprietà, autorizzazioni e regole non selezionate, rimangono invariate. Per sostituire una vista è necessario esserne proprietari (ciò include essere un membro del ruolo proprietario).
## Viste aggiornabili
Le viste semplici sono aggiornabili automaticamente: il sistema consentirà alle istruzioni `INSERT`, `UPDATE` e `DELETE` di operare sulla vista allo stesso modo in cui avrebbe fatto su una normale tabella. Una vista è aggiornabile automaticamente se soddisfa tutte le seguenti condizioni:
+ La vista deve avere esattamente una voce nell’elenco della clausola `FROM`, e tale elemento deve essere una tabella o un’altra vista aggiornabile.
+ La definizione della vista non deve contenere clausole `WITH`, `DISTINCT`, `GROUP BY`, `HAVING`, `LIMIT` o `OFFSET` al livello principale.
+ La definizione della vista non deve contenere operazioni sugli insiemi (`UNION`, `INTERSECT` o`EXCEPT`) al livello principale.
+ L’elenco di selezione della vista non deve contenere aggregati, funzioni finestra o funzioni che restituiscono insiemi.
Una vista aggiornabile automaticamente può contenere una combinazione di colonne aggiornabili e non aggiornabili. Una colonna è aggiornabile se è un semplice riferimento a una colonna aggiornabile della relazione di base sottostante. In caso contrario, la colonna è di sola lettura e si verifica un errore se un’istruzione `INSERT` o `UPDATE` tenta di assegnarle un valore.
Una vista più complessa che non soddisfa tutte queste condizioni è di sola lettura per impostazione predefinita: il sistema non consente inserimenti, aggiornamento o eliminazioni sulla vista.
**Nota**
L’utente che esegue l’inserimento, l’aggiornamento o l’eliminazione sulla vista deve disporre del privilegio di inserimento, aggiornamento o eliminazione corrispondente sulla vista. Per impostazione predefinita, il proprietario della vista deve disporre dei privilegi pertinenti sulle relazioni di base sottostanti, mentre l’utente che esegue l’aggiornamento non necessita di alcuna autorizzazione sulle relazioni di base sottostanti. Tuttavia, se la vista ha l’opzione security\$1invoker impostata su true, è l’utente che esegue l’aggiornamento, anziché il proprietario della vista, che deve disporre dei privilegi pertinenti sulle relazioni di base sottostanti.
## Esempi
Per creare una visualizzazione composta da tutti i film comici.
```
CREATE VIEW comedies AS
SELECT *
FROM films
WHERE kind = 'Comedy';
```
Creazione di una vista con `LOCAL CHECK OPTION`.
```
CREATE VIEW pg_comedies AS
SELECT *
FROM comedies
WHERE classification = 'PG'
WITH CASCADED CHECK OPTION;
```
Crea una vista ricorsiva.
```
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` è un’estensione del linguaggio PostgreSQL. Anche la `WITH ( ... )` clausola è un’estensione, così come le viste con guardabarriere e le viste con security invoker. Aurora DSQL supporta queste estensioni del linguaggio.
# `ALTER VIEW`
L’istruzione `ALTER VIEW` consente di modificare varie proprietà di una vista esistente e Aurora DSQL supporta tutta la sintassi PostgreSQL per questo comando.
## Sintassi supportata
```
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`modifica varie proprietà ausiliarie di una vista. (Se vuoi modificare la query di definizione della vista, usa`CREATE OR REPLACE VIEW`.) È necessario possedere la vista da utilizzare`ALTER VIEW`. Per modificare lo schema di una vista, occorre anche disporre del privilegio `CREATE` sul nuovo schema. Per modificare il proprietario, bisogna essere in grado di eseguire l’istruzione `SET ROLE` sul nuovo ruolo proprietario e tale ruolo deve disporre del privilegio `CREATE` sullo schema della vista.
## Parameters
**`name`**
Il nome (facoltativamente qualificato dallo schema) di una vista esistente.
**`column_name`**
Nome di una colonna esistente o nuovo nome per una colonna esistente.
**`IF EXISTS`**
Non generare un errore se la vista non esiste. In questo caso viene emesso un avviso.
**`SET/DROP DEFAULT`**
Questi moduli impostano o rimuovono il valore predefinito per una colonna. Il valore predefinito per una colonna di visualizzazione viene sostituito in qualsiasi comando `INSERT` o `UPDATE` in cui la destinazione è la vista.
**`new_owner`**
Il nome utente del nuovo proprietario della vista.
**`new_name`**
Il nuovo nome della vista.
**`new_schema`**
Il nuovo schema della vista.
**`SET ( view_option_name [= view_option_value] [, ... ] )`**
Imposta un'opzione di visualizzazione. Le opzioni supportate sono le seguenti:
+ `check_option (enum)` - Modifica l’opzione di controllo della vista. Il valore deve essere `local` o `cascaded`.
+ `security_barrier (boolean)` - Modifica la proprietà guardabarriere della vista.
+ `security_invoker (boolean)`- Modifica la proprietà security-invoker della vista.
**`RESET ( view_option_name [, ... ] )`**
Reimposta un'opzione di visualizzazione al valore predefinito.
## Esempi
Rinominare la vista in: `foo` `bar`
```
ALTER VIEW foo RENAME TO bar;
```
Associare un valore di colonna predefinito a una vista aggiornabile:
```
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` è un’estensione PostgreSQL dello standard SQL supportato da Aurora DSQL.
# `DROP VIEW`
L’istruzione `DROP VIEW` rimuove una vista esistente. Aurora DSQL supporta la sintassi PostgreSQL completa per questo comando.
## Sintassi supportata
```
DROP VIEW [ IF EXISTS ] name [, ...] [ CASCADE | RESTRICT ]
```
## Description
`DROP VIEW` elimina una vista esistente. Per eseguire questo comando è necessario essere proprietari della vista.
## Parameters
**`IF EXISTS`**
Non generare un errore se la vista non esiste. In questo caso viene emesso un avviso.
**`name`**
Il nome (facoltativamente qualificato dallo schema) della vista da rimuovere.
**`CASCADE`**
Rilascia automaticamente gli oggetti che dipendono dalla vista (come le altre viste) e, a loro volta, tutti gli oggetti che dipendono da tali oggetti.
**`RESTRICT`**
Rifiuta di eliminare la vista se alcuni oggetti dipendono da essa. Questa è l’impostazione predefinita.
## Esempi
```
DROP VIEW kinds;
```
## Compatibilità
Questo comando è conforme allo standard SQL, tranne per il fatto che lo standard consente di eliminare una sola vista per comando e a parte l’opzione `IF EXISTS`, che è un’estensione PostgreSQL supportata da Aurora DSQL.
# Migrazione da PostgreSQL ad Aurora SQL
Aurora DSQL è progettata per essere [compatibile con](working-with-postgresql-compatibility.md) PostgreSQL e supporta funzionalità relazionali di base come transazioni ACID, indici secondari, join e operazioni DML standard. La maggior parte delle applicazioni PostgreSQL esistenti può migrare ad Aurora DSQL con modifiche minime.
Questa sezione fornisce linee guida pratiche per la migrazione dell'applicazione ad Aurora DSQL, tra cui compatibilità del framework, modelli di migrazione e considerazioni sull'architettura.
## Compatibilità con framework e ORM
Aurora DSQL utilizza il protocollo wire PostgreSQL standard, garantendo la compatibilità con i driver e i framework PostgreSQL. I più diffusi ORMs funzionano con Aurora DSQL con modifiche minime o nulle. Vedi [Adattatori e dialetti di Aurora DSQL](aws-sdks.md#aurora-dsql-adapters) per le implementazioni di riferimento e le integrazioni ORM disponibili.
## Modelli di migrazione comuni
Durante la migrazione da PostgreSQL ad Aurora DSQL, alcune funzionalità funzionano in modo diverso o hanno una sintassi alternativa. Questa sezione fornisce indicazioni sugli scenari di migrazione più comuni.
### Alternative operative DDL
Aurora DSQL offre alternative moderne alle tradizionali operazioni DDL PostgreSQL:
**Creazione di indici**
Utilizzare `CREATE INDEX ASYNC` invece che `CREATE INDEX` per la creazione di indici non bloccanti.
**Vantaggio:** creazione di indici senza tempi di inattività su tabelle di grandi dimensioni.
**Rimozione dei dati**
Usa `DELETE FROM table_name` invece di`TRUNCATE`.
**Alternativa:** per una completa ricreazione a tavola, utilizzare `DROP TABLE` seguito da`CREATE TABLE`.
**Configurazione del sistema**
Aurora DSQL è completamente gestito, quindi la configurazione viene gestita automaticamente in base ai modelli di carico di lavoro. Utilizza la console di AWS gestione o l'API per gestire le impostazioni del cluster.
**Vantaggio:** non è necessario ottimizzare il database o gestire i parametri.
### Modelli di progettazione dello schema
Adatta questi modelli PostgreSQL comuni per la compatibilità con Aurora SQL:
**Modelli di integrità referenziale**
Aurora DSQL supporta le relazioni e le operazioni tra tabelle. `JOIN` Per l'integrità referenziale, implementate la convalida a livello di applicazione. Questo design è in linea con i moderni modelli di database distribuiti in cui la convalida a livello di applicazione offre maggiore flessibilità ed evita i colli di bottiglia delle prestazioni dovuti alle operazioni a cascata.
**Modello:** implementa i controlli di integrità referenziale a livello di applicazione utilizzando convenzioni di denominazione, logica di convalida e limiti di transazione coerenti. Molte applicazioni su larga scala preferiscono questo approccio per un migliore controllo sulla gestione degli errori e sulle prestazioni.
**Gestione temporanea dei dati**
Utilizza CTEs sottoquery o tabelle normali con logica di pulizia anziché tabelle temporanee.
**Alternativa:** crea tabelle con nomi specifici della sessione e puliscile nell'applicazione.
## Comprendere le differenze architettoniche
L'architettura distribuita e serverless di Aurora DSQL si differenzia intenzionalmente da PostgreSQL tradizionale in diverse aree. Queste differenze consentono i principali vantaggi di semplicità e scalabilità di Aurora DSQL.
### Modello di database semplificato
**Un unico database per cluster**
Aurora DSQL fornisce un database integrato denominato `postgres` per cluster.
**Suggerimento per la migrazione:** se l'applicazione utilizza più database, create cluster Aurora DSQL separati per la separazione logica o utilizzate schemi all'interno di un singolo cluster.
**Nessuna tabella temporanea**
Per la gestione temporanea dei dati, DOVRESTI usare espressioni di tabella (CTEs) e sottoquery comuni, che forniscono alternative flessibili per query complesse.
**Alternativa:** da utilizzare CTEs con `WITH` clausole per set di risultati temporanei o tabelle normali con denominazione univoca per dati specifici della sessione.
**Gestione automatica dello storage**
Aurora DSQL elimina i tablespace e la gestione manuale dello storage. Lo storage si ridimensiona e si ottimizza automaticamente in base ai modelli di dati.
**Vantaggio:** non è necessario monitorare lo spazio su disco, pianificare l'allocazione dello storage o gestire le configurazioni dei tablespace.
### Modelli di applicazione moderni
Aurora DSQL incoraggia modelli di sviluppo di applicazioni moderni che migliorano la manutenibilità e le prestazioni:
**Logica a livello di applicazione anziché trigger di database**
Per funzionalità simili a quelle dei trigger, implementa la logica basata sugli eventi nel livello dell'applicazione.
**Strategia di migrazione:** sposta la logica di attivazione nel codice dell'applicazione, utilizza architetture basate sugli eventi con AWS servizi come EventBridge o implementa gli audit trail utilizzando la registrazione delle applicazioni.
**Funzioni SQL per l'elaborazione dei dati**
Aurora DSQL supporta funzioni basate su SQL ma non linguaggi procedurali come PL/pgSQL.
**Alternativa:** utilizza le funzioni SQL per le trasformazioni dei dati o sposta la logica complessa sul livello dell'applicazione o sulle funzioni AWS Lambda.
**Controllo ottimistico della concorrenza anziché blocco pessimistico**
Aurora DSQL utilizza il controllo ottimistico della concorrenza (OCC), un approccio privo di blocchi che si differenzia dai tradizionali meccanismi di blocco del database. Invece di acquisire blocchi che bloccano altre transazioni, Aurora DSQL consente alle transazioni di procedere senza blocchi e rileva i conflitti al momento del commit. Ciò elimina le situazioni di stallo e impedisce che le transazioni lente blocchino altre operazioni.
**Differenza fondamentale:** quando si verificano conflitti, Aurora DSQL restituisce un errore di serializzazione anziché far attendere le transazioni per i blocchi. Ciò richiede che le applicazioni implementino una logica di ripetizione, simile alla gestione dei timeout di blocco nei database tradizionali, ma i conflitti vengono risolti immediatamente anziché causare attese di blocco.
**Modello di progettazione:** implementa una logica di transazione idempotente con meccanismi di ripetizione. Progetta schemi per ridurre al minimo i conflitti utilizzando chiavi primarie casuali e distribuendo gli aggiornamenti su tutta la gamma di chiavi. Per informazioni dettagliate, vedi [Controllo della concorrenza in Aurora DSQL](working-with-concurrency-control.md).
**Relazioni e integrità referenziale**
Aurora DSQL supporta le relazioni con chiavi esterne tra le tabelle, incluse le operazioni. ` JOIN ` Per l'integrità referenziale, implementate la convalida a livello di applicazione. Sebbene l'applicazione dell'integrità referenziale possa essere utile, le operazioni a cascata (come le eliminazioni a cascata) possono creare problemi di prestazioni imprevisti, ad esempio l'eliminazione di un ordine con 1.000 voci diventa una transazione di 1.001 righe. Per questo motivo, molti clienti evitano i vincoli relativi alle chiavi esterne.
**Modello di progettazione:** implementa i controlli di integrità referenziale a livello applicativo, utilizza eventuali modelli di coerenza o sfrutta AWS i servizi per la convalida dei dati.
### Semplificazioni operative
Aurora DSQL elimina molte attività tradizionali di manutenzione del database, riducendo il sovraccarico operativo:
**Non è richiesta alcuna manutenzione manuale**
Aurora DSQL gestisce automaticamente l'ottimizzazione dello storage, la raccolta di statistiche e l'ottimizzazione delle prestazioni. I comandi di manutenzione tradizionali, ad esempio, `VACUUM` vengono gestiti dal sistema.
**Vantaggio:** elimina la necessità di finestre di manutenzione del database, pianificazione a vuoto e regolazione dei parametri di sistema.
**Partizionamento e scalabilità automatici**
Aurora DSQL partiziona e distribuisce automaticamente i dati in base ai modelli di accesso. Utilizza UUIDs o generati dall'applicazione per una distribuzione ottimale IDs .
**Suggerimento per la migrazione:** rimuovete la logica di partizionamento manuale e lasciate che Aurora DSQL gestisca la distribuzione dei dati. Usa UUIDs o generato dall'applicazione per una distribuzione ottimale IDs . Se l'applicazione richiede identificatori sequenziali, vedere. [Sequenze e colonne di identità](sequences-identity-columns.md)
# Migrazione agentica con strumenti di intelligenza artificiale
Gli agenti di codifica AI possono accelerare la migrazione ad Aurora DSQL analizzando gli schemi, trasformando il codice ed eseguendo migrazioni DDL con controlli di sicurezza integrati.
## Usare Kiro per la migrazione
Gli agenti di codifica come [Kiro](https://kiro.dev/) possono aiutarti ad analizzare e migrare il codice PostgreSQL su Aurora DSQL:
+ **Analisi dello schema:** carica i file di schema esistenti e chiedi a Kiro di identificare potenziali problemi di compatibilità e suggerire alternative
+ **Trasformazione del codice:** fornisci il codice dell'applicazione e chiedi a Kiro di aiutarti a rifattorizzare la logica di attivazione, sostituire le sequenze con o modificare i modelli di UUIDs transazione
+ **Pianificazione della migrazione:** chiedi a Kiro di creare un piano di step-by-step migrazione basato sulla tua architettura applicativa specifica
+ **Migrazioni DDL:** esegui modifiche allo schema utilizzando il modello di ricreazione delle tabelle con controlli di sicurezza e verifica utente integrati
**Esempi di istruzioni:**
```
"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"
```
## Migrazione DDL con ricreazione delle tabelle
Quando si utilizzano agenti AI con il server MCP Aurora DSQL, alcune operazioni ALTER TABLE utilizzano un *modello di ricreazione* delle tabelle che migra i dati in modo sicuro. L'agente gestisce la complessità tenendoti informato in ogni fase.
Le seguenti operazioni utilizzano il modello di ricreazione della tabella:
| Operation | Approccio |
| --- | --- |
| DROP COLUMN | Escludi colonna dalla nuova tabella |
| ALTER COLUMN TYPE | Trasmetti il tipo di dati durante la migrazione |
| ALTER COLUMN SET/DROP NOT NULL | Modifica il vincolo nella nuova definizione della tabella |
| ALTER COLUMN SET/DROP DEFAULT | Definisci il valore predefinito nella nuova definizione della tabella |
| ADD/DROP CONSTRAINT | Includi o rimuovi il vincolo nella nuova tabella |
| MODIFY PRIMARY KEY | Definisci un nuovo PK con convalida dell'unicità |
| Divide/Unisci colonne | Usa SPLIT\$1PART, SUBSTRING o CONCAT |
Le seguenti operazioni ALTER TABLE sono supportate direttamente senza ricreare la tabella:
+ `ALTER TABLE ... RENAME COLUMN`— Rinominare una colonna
+ `ALTER TABLE ... RENAME TO`— Rinominare una tabella
+ `ALTER TABLE ... ADD COLUMN`— Aggiungere una nuova colonna
**Funzionalità di sicurezza:** durante l'esecuzione di migrazioni DDL, gli agenti AI presentano il piano di migrazione, verificano la compatibilità dei dati, confermano il conteggio delle righe e richiedono l'approvazione esplicita prima di qualsiasi operazione distruttiva come DROP TABLE.
**Migrazioni in batch:** per le tabelle che superano le 3.000 righe, l'agente esegue automaticamente in batch la migrazione con incrementi di 500-1.000 righe per rimanere entro i limiti delle transazioni.
## Server MCP Aurora DSQL
Il server Aurora DSQL Model Context Protocol (MCP) consente agli assistenti AI di connettersi direttamente al cluster Aurora DSQL e di cercare la documentazione di Aurora DSQL. Ciò consente all'IA di:
+ Analizza lo schema esistente e suggerisci modifiche alla migrazione
+ Esegui migrazioni DDL con il modello di ricreazione delle tabelle
+ Verifica le query e verifica la compatibilità durante la migrazione
+ Fornisci up-to-date linee guida accurate basate sulla più recente documentazione di Aurora DSQL
[Per utilizzare il server MCP Aurora DSQL con gli assistenti AI, consulta le istruzioni di configurazione per il server MCP Aurora DSQL.](SECTION_aurora-dsql-mcp-server.md)
## Considerazioni su Aurora DSQL rispetto alla compatibilità con PostgreSQL
Aurora DSQL presenta differenze nel supporto delle funzionalità rispetto a PostgreSQL autogestito che ne consentono l'architettura distribuita, il funzionamento senza server e la scalabilità automatica. La maggior parte delle applicazioni funziona entro queste differenze senza modifiche.
Per le considerazioni generali, consulta [Considerazioni sull’utilizzo di Amazon Aurora DSQL](considerations.md). Per quote e limiti, consulta [Quote di cluster e limiti del database in Amazon Aurora DSQL](CHAP_quotas.md).
+ Aurora DSQL utilizza un unico database integrato denominato `postgres` per cluster. Per la separazione logica, crea cluster Aurora DSQL separati o utilizza schemi all'interno di un singolo cluster.
+ Il `postgres` database utilizza la codifica dei caratteri UTF-8, che fornisce un ampio supporto internazionale per i caratteri.
+ Il database utilizza solo le regole di confronto `C`.
+ Aurora DSQL utilizza `UTC` come fuso orario del sistema. Postgres memorizza internamente tutte le date e gli orari in base al fuso orario in UTC. È possibile impostare il parametro di `TimeZone` configurazione per convertire il modo in cui viene visualizzato al client e fungere da impostazione predefinita per l'input del client che il server utilizzerà per la conversione in UTC internamente.
+ Il livello di isolamento delle transazioni è fisso su PostgreSQL `Repeatable Read`.
+ Le transazioni sono soggette ai seguenti vincoli:
+ Le operazioni DDL e DML richiedono transazioni separate
+ Una transazione può includere solo 1 istruzione DDL
+ Una transazione può modificare fino a 3.000 righe, indipendentemente dal numero di indici secondari
+ Il limite di 3.000 righe si applica a tutte le istruzioni DML (`INSERT`, `UPDATE`, `DELETE`)
+ Le connessioni al database scadono dopo 1 ora.
+ Aurora DSQL gestisce le autorizzazioni tramite concessioni a livello di schema. Gli utenti amministratori creano schemi utilizzando e concedono l'accesso utilizzando. `CREATE SCHEMA` `GRANT USAGE ON SCHEMA` Gli utenti amministratori gestiscono gli oggetti nello schema pubblico, mentre gli utenti non amministratori creano oggetti in schemi creati dall'utente per chiarire i limiti di proprietà. Per ulteriori informazioni, consulta [Autorizzazione dei ruoli del database a utilizzare SQL nel database](using-database-and-iam-roles.md#using-database-and-iam-roles-custom-database-roles-sql).
## Hai bisogno di aiuto con la migrazione?
Se riscontri funzionalità fondamentali per la migrazione ma attualmente non supportate in Aurora DSQL, consulta [Fornire feedback su Amazon Aurora DSQL](providing-feedback.md) per informazioni su come condividere il feedback con AWS.
# Controllo della concorrenza in Aurora DSQL
La concorrenza consente a più sessioni di accedere e modificare i dati contemporaneamente senza compromettere l’integrità e la coerenza dei dati. Aurora DSQL offre la [compatibilità con PostgreSQL](https://docs.aws.amazon.com/aurora-dsql/latest/userguide/working-with-postgresql-compatibility.html) implementando al contempo un meccanismo di controllo della concorrenza moderno e senza blocchi. Mantiene la piena conformità ACID attraverso l’isolamento degli snapshot, garantendo la coerenza e l’affidabilità dei dati.
Un vantaggio chiave di Aurora DSQL è la sua architettura priva di blocchi, che elimina i comuni colli di bottiglia nelle prestazioni del database. Aurora DSQL impedisce che le transazioni lente blocchino altre operazioni ed elimina il rischio di deadlock. Questo approccio rende Aurora DSQL particolarmente utile per applicazioni ad alto throughput, in cui le prestazioni e la scalabilità sono fondamentali.
## Conflitti tra transazioni
Aurora DSQL utilizza il controllo ottimistico della concorrenza (OCC), che funziona in modo diverso dai tradizionali sistemi basati su blocchi. Invece di utilizzare i blocchi, OCC valuta i conflitti al momento del commit. Quando più transazioni entrano in conflitto durante l’aggiornamento della stessa riga, Aurora SQL gestisce le transazioni come segue:
+ La transazione con il tempo di commit più breve viene elaborata da Aurora DSQL.
+ Le transazioni in conflitto ricevono un errore di serializzazione PostgreSQL, che indica la necessità di riprovare.
È opportuno progettare le applicazioni in modo da implementare una logica di ripetizione per gestire i conflitti. Il modello di progettazione ideale è idempotente e consente di ripetere la transazione come primo rimedio, quando possibile. La logica consigliata è simile alla logica abort and retry in una situazione di timeout o deadlock di PostgreSQL standard. Tuttavia, OCC richiede che le applicazioni applichino questa logica più frequentemente.
## Linee guida per l’ottimizzazione delle prestazioni delle transazioni
Per ottimizzare le prestazioni, è opportuno ridurre al minimo contese elevate su chiavi singole o intervalli di chiavi ridotti. Per raggiungere questo obiettivo, progetta lo schema in modo da distribuire gli aggiornamenti sull’intervallo di chiavi del cluster utilizzando le seguenti linee guida:
+ Scegli una chiave primaria casuale per le tabelle.
+ Evita i modelli che fanno aumentare la contesa sulle singole chiavi. Questo approccio garantisce prestazioni ottimali anche con l’aumento del volume delle transazioni.
# DDL e transazioni distribuite in Aurora DSQL
Il DDL (Data Definition Language) si comporta in modo diverso in Aurora DSQL rispetto a PostgreSQL. Aurora DSQL offre un livello di database Multi-AZ distribuito e senza condivisione basato su parchi di risorse di calcolo e archiviazione multi-tenant. Poiché non esiste un singolo nodo o leader del database primario, il catalogo del database viene distribuito. Pertanto, Aurora DSQL gestisce le modifiche DDL allo schema come transazioni distribuite.
In particolare, DDL si comporta in modo diverso in Aurora DSQL come segue:
**Errori di controllo della concorrenza**
Aurora DSQL restituisce un errore di violazione del controllo della concorrenza se si esegue una transazione mentre un’altra transazione aggiorna una risorsa. Considera, ad esempio, la seguente sequenza di azioni:
1. Nella sessione 1, un utente aggiunge una colonna alla tabella `mytable`.
1. Nella sessione 2, un utente tenta di inserire una riga in `mytable`.
Aurora DSQL restituisce l’errore `SQL Error [40001]: ERROR: schema has been updated by another transaction, please retry: (OC001).`
**DDL e DML nella stessa transazione**
Le transazioni in Aurora DSQL possono contenere solo un’istruzione DDL e non possono avere sia istruzioni DDL che DML. Questa restrizione significa che non è possibile creare una tabella e inserire dati nella stessa tabella all’interno della stessa transazione. Ad esempio, Aurora DSQL supporta le seguenti transazioni sequenziali.
```
BEGIN;
CREATE TABLE mytable (ID_col integer);
COMMIT;
BEGIN;
INSERT into FOO VALUES (1);
COMMIT;
```
Aurora DSQL non supporta la seguente transazione, che include contemporaneamente istruzioni `CREATE` e `INSERT`.
```
BEGIN;
CREATE TABLE FOO (ID_col integer);
INSERT into FOO VALUES (1);
COMMIT;
```
**DDL asincrono**
In PostgreSQL standard, le operazioni DDL come `CREATE INDEX` bloccano la tabella interessata, rendendola non disponibile per le letture e le scritture da altre sessioni. In Aurora DSQL, queste istruzioni DDL vengono eseguite in modo asincrono utilizzando un gestore in background. L’accesso alla tabella interessata non è bloccato. Pertanto, istruzioni DDL su tabelle di grandi dimensioni possono esseri eseguito senza tempo di inattività o impatto sulle prestazioni. Per maggiori informazioni sull’utilizzo dello strumento di gestione dei processi asincroni in Aurora DSQL, consulta [Indici asincroni in Aurora SQL](working-with-create-index-async.md).
# Chiavi primarie in Aurora DSQL
In Aurora DSQL, una chiave primaria è una funzionalità che organizza fisicamente i dati delle tabelle. È simile all’operazione `CLUSTER` in PostgreSQL o a un indice cluster in altri database. Quando si definisce una chiave primaria, Aurora DSQL crea un indice che include tutte le colonne della tabella. La struttura a chiave primaria di Aurora DSQL garantisce un accesso e una gestione efficienti dei dati.
## Struttura e archiviazione dei dati
Quando si definisce una chiave primaria, Aurora DSQL memorizza i dati della tabella nell’ordine delle chiavi primarie. Questa struttura organizzata a indice consente una ricerca tramite chiave primaria per recuperare direttamente tutti i valori delle colonne, invece di seguire un puntatore ai dati come in un tradizionale indice B-tree. A differenza dell’operazione `CLUSTER` in PostgreSQL, che riorganizza i dati una sola volta, Aurora DSQL mantiene questo ordine automaticamente e continuamente. Questo approccio migliora le prestazioni delle query che si basano sull’accesso alla chiave primaria.
Aurora DSQL utilizza anche la chiave primaria per generare una chiave unica a livello di cluster per ogni riga di tabelle e indici. Questa chiave unica è anche alla base della gestione distribuita dei dati. Consente il partizionamento automatico dei dati su più nodi, supportando uno storage scalabile e un’elevata concorrenza. Di conseguenza, la struttura a chiave primaria permette ad Aurora DSQL di scalare automaticamente e di gestire i carichi di lavoro simultanei in modo efficiente.
## Linee guida per la scelta di una chiave primaria
Quando si sceglie e si utilizza una chiave primaria in Aurora DSQL, bisogna tenere presenti le seguenti linee guida:
+ Definire una chiave primaria quando si crea una tabella. Non è possibile modificare questa chiave né aggiungere una nuova chiave primaria in un secondo momento. La chiave primaria diventa parte della chiave a livello di cluster utilizzata per il partizionamento dei dati e il dimensionamento automatico del throughput di scrittura. Se non si specifica una chiave primaria, Aurora DSQL assegna un ID sintetico nascosto.
+ Per le tabelle con volumi di scrittura elevati, evitare di utilizzare numeri interi che aumentano in modo monotono come chiavi primarie. Ciò può causare problemi di prestazioni se si indirizzano tutti i nuovi inserimenti su un’unica partizione. Utilizzare invece chiavi primarie con distribuzione casuale per garantire una distribuzione uniforme delle scritture tra le partizioni di archiviazione.
+ Per le tabelle che vengono modificate raramente o sono di sola lettura, è possibile utilizzare una chiave crescente. Esempi di chiavi crescenti sono i timestamp o i numeri di sequenza. Una chiave densa contiene molti valori ravvicinati o duplicati. È possibile utilizzare una chiave crescente anche se è densa, poiché le prestazioni di scrittura sono meno importanti.
+ Se una scansione completa della tabella non soddisfa i requisiti di prestazione, scegliere un metodo di accesso più efficiente. Nella maggior parte dei casi, ciò significa utilizzare una chiave primaria che corrisponda alla chiave di join e lookup più comune nelle query.
+ La dimensione massima combinata delle colonne in una chiave primaria è 1 kibibyte. Per maggiori informazioni, consulta [Limiti del database in Aurora DSQL](https://docs.aws.amazon.com/aurora-dsql/latest/userguide/CHAP_quotas.html#SECTION_database-limits) e [Tipi di dati supportati in Aurora DSQL](https://docs.aws.amazon.com/aurora-dsql/latest/userguide/working-with-postgresql-compatibility-supported-data-types).
+ È possibile includere fino a 8 colonne in una chiave primaria o in un indice secondario. Per maggiori informazioni, consulta [Limiti del database in Aurora DSQL](https://docs.aws.amazon.com/aurora-dsql/latest/userguide/CHAP_quotas.html#SECTION_database-limits) e [Tipi di dati supportati in Aurora DSQL](https://docs.aws.amazon.com/aurora-dsql/latest/userguide/working-with-postgresql-compatibility-supported-data-types).
# Sequenze e colonne di identità
Le sequenze e le colonne di identità generano valori interi e sono utili quando sono necessari identificatori compatti o leggibili dall'uomo. Questi valori implicano il comportamento di allocazione e memorizzazione nella cache descritto nella documentazione. [`CREATE SEQUENCE`](create-sequence-syntax-support.md)
**Topics**
+ [
# Funzioni di manipolazione di sequenze
](sequence-functions-syntax-support.md)
+ [
# Colonne di identità
](sequences-identity-columns-overview.md)
+ [
# Utilizzo di sequenze e colonne di identità
](sequences-identity-columns-working-with.md)
# Funzioni di manipolazione di sequenze
Questa sezione descrive le funzioni per operare su oggetti di sequenza, chiamati anche generatori di sequenze o semplicemente sequenze. Gli oggetti Sequence sono tabelle speciali a riga singola create con. [`CREATE SEQUENCE`](create-sequence-syntax-support.md) Gli oggetti Sequence vengono comunemente utilizzati per generare identificatori univoci per le righe di una tabella. Le funzioni di sequenza forniscono metodi semplici e sicuri per più utenti per ottenere valori di sequenza successivi da oggetti di sequenza.
**Importante**
Quando si utilizzano sequenze, è necessario considerare attentamente il valore della cache. Per ulteriori informazioni, consultate il callout importante nella [`CREATE SEQUENCE`](create-sequence-syntax-support.md) pagina.
Per indicazioni su come utilizzare al meglio le sequenze basate sui modelli di carico di lavoro, consulta. [Utilizzo di sequenze e colonne di identità](sequences-identity-columns-working-with.md)
| Funzione | Description |
| --- | --- |
| nextval ( regclass ) → bigint | Fa avanzare l'oggetto della sequenza al valore successivo e restituisce quel valore. Questa operazione viene eseguita in modo atomico: anche se più sessioni vengono eseguite nextval contemporaneamente, ognuna riceverà in modo sicuro un valore di sequenza distinto. Se l'oggetto sequenza è stato creato con parametri predefiniti, nextval le chiamate successive restituiranno valori crescenti a partire da 1. È possibile ottenere altri comportamenti utilizzando i parametri appropriati nel [`CREATE SEQUENCE`](create-sequence-syntax-support.md) comando. Questa funzione richiede USAGE un UPDATE privilegio sulla sequenza. |
| setval ( regclass, bigint [, boolean ] ) → bigint | Imposta il valore corrente dell'oggetto della sequenza e, facoltativamente, il suo is\$1called flag. Il modulo a due parametri imposta il last\$1value campo della sequenza sul valore specificato e imposta il is\$1called campo sutrue, il che significa che il modulo successivo nextval farà avanzare la sequenza prima di restituire un valore. Anche il valore da cui verrà riportato currval viene impostato sul valore specificato. Nel formato a tre parametri, is\$1called può essere impostato su uno true ofalse. trueha lo stesso effetto del modulo a due parametri. Se è impostato sufalse, il successivo nextval restituirà esattamente il valore specificato e l'avanzamento della sequenza inizia con quanto segue. nextval Inoltre, il valore riportato da currval non viene modificato qui. Esempio: 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 Il risultato restituito da setval è solo il valore del secondo argomento. Questa funzione richiede UPDATE privilegi sulla sequenza. |
| currval ( regclass ) → bigint | Restituisce l'ultimo valore ottenuto da nextval per questa sequenza nella sessione corrente. (Viene segnalato un errore se non è mai nextval stato chiamato per questa sequenza in questa sessione.) Poiché restituisce un valore locale della sessione, fornisce una risposta prevedibile indipendentemente dal nextval fatto che altre sessioni siano state eseguite o meno rispetto alla sessione corrente. Questa funzione richiede un USAGE SELECT privilegio sulla sequenza. |
| lastval () → bigint | Restituisce l'ultimo valore restituito da nextval nella transazione corrente. Questa funzione è identica acurrval, tranne per il fatto che invece di prendere il nome della sequenza come argomento, si riferisce alla sequenza a cui nextval è stata applicata più di recente nella transazione corrente. È un errore chiamare lastval se non nextval è stato ancora chiamato nella transazione corrente. Questa funzione richiede USAGE o SELECT privilegia l'ultima sequenza utilizzata. |
**avvertimento**
Il valore ottenuto da `nextval` non viene recuperato per il riutilizzo se la transazione chiamante viene successivamente interrotta. Ciò significa che gli aborti delle transazioni o i crash del database possono causare lacune nella sequenza dei valori assegnati. Ciò può avvenire anche senza interrompere la transazione. Ad esempio, una `ON CONFLICT` clausola `INSERT` with an calcolerà la to-be-inserted tupla, inclusa l'esecuzione delle `nextval` chiamate richieste, prima di rilevare qualsiasi conflitto che potrebbe invece indurla a seguire la regola. `ON CONFLICT` Pertanto, gli oggetti sequenza di Aurora DSQL *non possono essere utilizzati per ottenere sequenze «*senza pause».
Allo stesso modo, le modifiche allo stato della sequenza effettuate da `setval` sono immediatamente visibili alle altre transazioni e non vengono annullate se la transazione chiamante viene ripristinata.
La sequenza su cui deve operare una funzione di sequenza è specificata da un `regclass` argomento, che è semplicemente l'OID della sequenza nel catalogo di `pg_class` sistema. Tuttavia, non è necessario cercare l'OID manualmente, perché il convertitore di input del tipo di `regclass` dati farà il lavoro per te. Consulta la documentazione di PostgreSQL [sui](https://www.postgresql.org/docs/current/datatype-oid.html) tipi di identificatori di oggetti per i dettagli.
# Colonne di identità
**Importante**
Quando si utilizzano le colonne di identità, il valore della cache deve essere considerato attentamente. Per ulteriori informazioni, consulta il callout importante nella [`CREATE SEQUENCE`](create-sequence-syntax-support.md) pagina.
Per indicazioni su come utilizzare al meglio le colonne di identità in base ai modelli di carico di lavoro, consulta. [Utilizzo di sequenze e colonne di identità](sequences-identity-columns-working-with.md)
Una colonna di identità è una colonna speciale generata automaticamente da una sequenza implicita. Può essere usata per generare valori chiave. Per creare una colonna di identità, usa la `GENERATED ... AS IDENTITY` clausola in[`CREATE TABLE`](create-table-syntax-support.md), ad esempio:
```
CREATE TABLE people (
id bigint GENERATED ALWAYS AS IDENTITY (CACHE 70000),
...
);
```
o in alternativa:
```
CREATE TABLE people (
id bigint GENERATED BY DEFAULT AS IDENTITY (CACHE 70000),
...
);
```
Per ulteriori dettagli, consulta [`CREATE TABLE`](create-table-syntax-support.md).
Se un `INSERT` comando viene eseguito sulla tabella con la colonna identity e non viene specificato esplicitamente alcun valore per la colonna identity, viene inserito un valore generato dalla sequenza implicita. Ad esempio, con le definizioni precedenti e assumendo colonne aggiuntive appropriate, scrivi:
```
INSERT INTO people (name, address) VALUES ('A', 'foo');
INSERT INTO people (name, address) VALUES ('B', 'bar');
```
genererebbe valori per la `id` colonna a partire da 1 e produrrebbe i seguenti dati della tabella:
```
id | name | address
----+------+---------
1 | A | foo
2 | B | bar
```
In alternativa, la parola chiave `DEFAULT` può essere specificata al posto di un valore per richiedere esplicitamente il valore generato dalla sequenza:
```
INSERT INTO people (id, name, address) VALUES (DEFAULT, 'C', 'baz');
```
Analogamente, la parola chiave `DEFAULT` può essere utilizzata nei comandi. `UPDATE`
Pertanto, in molti modi, una colonna di identità si comporta come una colonna con un valore predefinito.
Le clausole `ALWAYS` e `BY DEFAULT` la definizione della colonna determinano la modalità di gestione esplicita dei valori e dei comandi specificati dall'utente. `INSERT` `UPDATE` In un `INSERT` comando, se `ALWAYS` è selezionato, un valore specificato dall'utente viene accettato solo se l'istruzione lo specifica. `INSERT` `OVERRIDING SYSTEM VALUE` Se `BY DEFAULT` è selezionato, il valore specificato dall'utente ha la precedenza. Pertanto, l'utilizzo `BY DEFAULT` determina un comportamento più simile ai valori predefiniti, in cui il valore predefinito può essere sostituito da un valore esplicito, mentre `ALWAYS` fornisce una maggiore protezione contro l'inserimento accidentale di un valore esplicito.
Il tipo di dati di una colonna di identità deve essere uno dei tipi di dati supportati dalle sequenze. Consultare [`CREATE SEQUENCE`](create-sequence-syntax-support.md). Le proprietà della sequenza associata possono essere specificate durante la creazione di una colonna di identità (vedi[`CREATE TABLE`](create-table-syntax-support.md)) o modificate in seguito (vedi[`ALTER TABLE`](alter-table-syntax-support.md)).
Una colonna di identità viene contrassegnata automaticamente come`NOT NULL`. Una colonna di identità, tuttavia, non garantisce l'unicità. (Una sequenza normalmente restituisce valori univoci, ma una sequenza può essere reimpostata o i valori possono essere inseriti manualmente nella colonna dell'identità, come discusso in precedenza.) L'unicità dovrebbe essere applicata utilizzando un vincolo `PRIMARY KEY` or`UNIQUE`.
# Utilizzo di sequenze e colonne di identità
Questa sezione ti aiuta a capire come utilizzare al meglio le sequenze e le colonne di identità in base ai modelli di carico di lavoro.
**Importante**
Consulta il callout importante sulla [`CREATE SEQUENCE`](create-sequence-syntax-support.md) pagina per maggiori dettagli sull'allocazione e sul comportamento di memorizzazione nella cache.
## Scelta dei tipi di identificatori
Amazon Aurora DSQL supporta sia identificatori basati su UUID che valori interi generati utilizzando sequenze o colonne di identità. Queste opzioni differiscono nel modo in cui i valori vengono allocati e nella loro scalabilità sotto carico.
I valori UUID possono essere generati senza coordinamento e sono adatti ai carichi di lavoro in cui gli identificatori vengono creati frequentemente o in molte sessioni. Poiché Amazon Aurora DSQL è progettato per operazioni distribuite, evitare il coordinamento è spesso utile. Per questo motivo, UUIDs sono consigliati come tipo di identificatore predefinito, in particolare per le chiavi primarie nei carichi di lavoro in cui la scalabilità è importante e non è richiesto un ordine rigoroso degli identificatori.
Le sequenze e le colonne di identità generano valori interi compatti utili per identificatori, report e interfacce esterne leggibili dall'uomo. Quando gli identificatori numerici sono preferiti per motivi di usabilità o integrazione, prendi in considerazione l'utilizzo di una sequenza o di una colonna di identità in combinazione con identificatori basati su UUID. Quando sono richiesti valori interi di sequenza o identità, la scelta di una dimensione di cache appropriata diventa una parte importante della progettazione del carico di lavoro. Consulta la sezione seguente per indicazioni sulla scelta della dimensione della cache.
## Scelta della dimensione della cache
La selezione di un valore di cache appropriato è una parte importante dell'utilizzo efficace di sequenze e colonne di identità. L'impostazione della cache determina il comportamento dell'allocazione degli identificatori sotto carico, influenzando sia la velocità di trasmissione del sistema sia il modo in cui i valori riflettono fedelmente l'ordine di allocazione.
**Una cache di dimensioni maggiori di è adatta quando: `CACHE >= 65536`**
+ Gli identificatori vengono generati ad alta frequenza
+ Molte sessioni vengono inserite contemporaneamente
+ Il carico di lavoro può tollerare lacune ed effetti di ordinamento visibili
Ad esempio, i carichi di lavoro di acquisizione di eventi ad alto volume (come IoT o telemetria), così come gli identificatori operativi come job run, riferimenti ai casi di supporto o numeri d'ordine interni IDs, in genere traggono vantaggio da cache di dimensioni maggiori, in cui gli identificatori vengono generati frequentemente e non è richiesto un ordinamento rigoroso.
**Una dimensione della cache pari a 1 è meglio allineata quando:**
+ I tassi di allocazione sono relativamente bassi
+ Si prevede che gli identificatori seguiranno più da vicino l'ordine di allocazione nel tempo
+ Ridurre al minimo le lacune è più importante della produttività massima
I carichi di lavoro, come l'assegnazione di account o numeri di riferimento, in cui gli identificatori vengono generati meno spesso ed è preferibile un ordine più accurato, sono meglio allineati con una dimensione della cache pari a 1.
# Indici asincroni in Aurora SQL
Il comando `CREATE INDEX ASYNC` crea un indice su una o più colonne di una tabella specificata. Questo comando è un’operazione DDL asincrona che non blocca altre transazioni. Quando si esegue il comando `CREATE INDEX ASYNC`, Aurora DSQL restituisce immediatamente un `job_id`.
È possibile monitorare lo stato di questo processo asincrono utilizzando la vista di sistema `sys.jobs`. Mentre il processo di creazione dell’indice è in corso, è possibile utilizzare le procedure e i comandi seguenti:
**`sys.wait_for_job(job_id)'your_index_creation_job_id'`**
Bloccare la sessione corrente fino al completamento o all’esito negativo del processo specificato. Restituisce un valore booleano che indica la riuscita o l’errore.
**`DROP INDEX`**
Annullare un processo di creazione dell’indice in esecuzione.
Al termine della creazione dell’indice asincrono, Aurora DSQL aggiorna il catalogo di sistema per contrassegnare l’indice come attivo.
Tieni presente che le transazioni simultanee che accedono a oggetti nello stesso namespace durante questo aggiornamento potrebbero riscontrare errori di concorrenza.
Quando Aurora DSQL termina un’attività di indicizzazione asincrona, aggiorna il catalogo di sistema per mostrare che l’indice è attivo. Se altre transazioni fanno riferimento agli oggetti nello stesso namespace in tale momento, potrebbero visualizzare un errore di concorrenza.
## Sintassi
`CREATE INDEX ASYNC` utilizza la seguente sintassi.
```
CREATE [ UNIQUE ] INDEX ASYNC [ IF NOT EXISTS ] name ON table_name
( { column_name } [ NULLS { FIRST | LAST } ] )
[ INCLUDE ( column_name [, ...] ) ]
[ NULLS [ NOT ] DISTINCT ]
```
## Parameters
**`UNIQUE`**
Indica ad Aurora DSQL di verificare la presenza di valori duplicati nella tabella quando crea l’indice e ogni volta che si aggiungono dati. Se si specifica questo parametro, le operazioni di inserimento e aggiornamento che comporterebbero la duplicazione delle voci generano un errore.
**`IF NOT EXISTS`**
Indica che Aurora DSQL non deve generare un’eccezione se esiste già un indice con lo stesso nome. In questa situazione, Aurora DSQL non crea il nuovo indice. Nota che l’indice che stai cercando di creare potrebbe avere una struttura molto diversa dall’indice esistente. Se non viene specificato questo parametro, il nome dell’indice è obbligatorio.
**`name`**
Il nome dell’indice. Non è possibile includere il nome dello schema in questo parametro.
Aurora DSQL crea l’indice nello stesso schema della tabella principale. Il nome dell’indice deve essere distinto dal nome di qualsiasi altro oggetto, ad esempio una tabella o un indice, nello schema.
Se non si specifica un nome, Aurora DSQL genera automaticamente un nome basato sul nome della tabella principale e della colonna indicizzata. Ad esempio, se si esegue `CREATE INDEX ASYNC on table1 (col1, col2)`, Aurora DSQL assegna automaticamente un nome all’indice `table1_col1_col2_idx`.
**`NULLS FIRST | LAST`**
Criterio di ordinamento delle colonne nulle e non nulle. `FIRST` indica che Aurora DSQL deve ordinare le colonne nulle prima delle colonne non nulle. `LAST` indica che Aurora DSQL deve ordinare le colonne nulle dopo le colonne non nulle.
**`INCLUDE`**
Un elenco di colonne da includere nell’indice come colonne non chiave. Non è possibile utilizzare una colonna non chiave in una qualifica di ricerca basata sulla scansione dell’indice. Aurora DSQL ignora la colonna in termini di unicità di un indice.
**`NULLS DISTINCT | NULLS NOT DISTINCT`**
Specifica se Aurora DSQL deve considerare i valori null come distinti in un indice univoco. L’impostazione predefinita è `DISTINCT`, il che significa che un indice univoco può contenere più valori nulli in una colonna. `NOT DISTINCT` indica che un indice non può contenere più valori nulli in una colonna.
## Note per l’utilizzo
Considera le linee guida seguenti:
+ Il comando `CREATE INDEX ASYNC` non introduce blocchi. Inoltre, non influisce sulla tabella di base utilizzata da Aurora DSQL per creare l’indice.
+ Durante le operazioni di migrazione dello schema, è utile la procedura `sys.wait_for_job(job_id)'your_index_creation_job_id'`. Garantisce che le operazioni DDL e DML successive abbiano come target l’indice appena creato.
+ Ogni volta che Aurora DSQL esegue una nuova attività asincrona, controlla la vista `sys.jobs` ed elimina le attività con uno stato di `completed` o `failed` pari o superiore a 30 minuti. Pertanto, `sys.jobs` mostra principalmente le attività in corso e non contiene informazioni sulle attività precedenti.
+ Se Aurora DSQL non riesce a creare un indice asincrono, l’indice rimane in stato `INVALID`. Per gli indici univoci, le operazioni DML sono soggette a vincoli di unicità finché non si elimina l’indice. Si consiglia di eliminare gli indici non validi e di ricrearli.
## Creazione di un indice: esempio
L’esempio seguente mostra come creare uno schema, una tabella e quindi un indice.
1. Crea una nuova tabella denominata `test.departments`.
```
CREATE SCHEMA test;
CREATE TABLE test.departments (name varchar(255) primary key NOT null,
manager varchar(255),
size varchar(4));
```
1. Inserisci una riga di dati nella tabella.
```
INSERT INTO test.departments VALUES ('Human Resources', 'John Doe', '10')
```
1. Crea un indice asincrono.
```
CREATE INDEX ASYNC test_index on test.departments(name, manager, size);
```
Il comando `CREATE INDEX` restituisce un ID di processo, come mostrato di seguito.
```
job_id
--------------------------
jh2gbtx4mzhgfkbimtgwn5j45y
```
`job_id` indica che Aurora DSQL ha avviato un nuovo processo per creare l’indice. È possibile utilizzare la procedura `sys.wait_for_job(job_id)'your_index_creation_job_id'` per bloccare altri lavori sulla sessione fino al termine o al timeout del processo.
## Esecuzione di query sullo stato di creazione dell’indice: esempio
Eseguire la query sulla vista di sistema `sys.jobs` per verificare lo stato di creazione dell’indice, come illustrato nell’esempio seguente.
```
SELECT * FROM sys.jobs where job_id = 'wqhu6ewifze5xitg3umt24h5ua';
```
Aurora DSQL restituisce una risposta simile alla seguente.
```
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 colonna stato può assumere uno dei seguenti valori.
| Status | Description |
| --- | --- |
| submitted | L’attività è stata inviata, ma Aurora DSQL non ha ancora iniziato a elaborarla. |
| processing | Aurora DSQL sta elaborando l’operazione. |
| failed | L’attività non è andata a buon fine. Per maggiori informazioni, consulta la colonna dettagli. Se Aurora DSQL non è riuscita a creare l’indice, non rimuove automaticamente la sua definizione. È necessario rimuovere manualmente l’indice con il comando DROP INDEX. |
| completed | Aurora DSQL ha completato l'operazione con successo. |
È inoltre possibile eseguire la query sullo stato dell’indice tramite le tabelle `pg_index` e `pg_class` del catalogo. In particolare, gli attributi `indisvalid` e `indisimmediate` possono indicare in che stato si trova l’indice. Mentre Aurora DSQL crea l’indice, lo stato iniziale è `INVALID`. Il flag `indisvalid` dell’indice restituisce `FALSE` o `f`, che indica che l’indice non è valido. Se il flag restituisce `TRUE` o `t`, l’indice è pronto.
```
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)
```
## Errori di creazione dell’indice univoco
Se il processo di creazione dell’indice univoco asincrono mostra uno stato non riuscito con il dettaglio `Found duplicate key while validating index for UCVs`, significa che non è stato possibile creare un indice univoco a causa di violazioni del vincolo di unicità.
**Come risolvere gli errori di creazione dell’indice univoco**
1. Rimuovi tutte le righe della tabella principale che contengono voci duplicate per le chiavi specificate nell’indice secondario univoco.
1. Elimina l’indice non creato.
1. Esegui un nuovo comando create index.
## Rilevamento delle violazioni di unicità nelle tabelle primarie
La seguente query SQL consente di identificare i valori duplicati in una colonna specificata della tabella. Ciò è particolarmente utile quando è necessario applicare l’univocità a una colonna che attualmente non è impostata come chiave primaria o non ha un vincolo univoco, come gli indirizzi e-mail in una tabella utente.
Gli esempi seguenti mostrano come creare una tabella di utenti di esempio, popolarla con dati di test contenenti duplicati noti e quindi eseguire la query di rilevamento.
**Definire lo schema della tabella**
```
-- 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
);
```
**Inserire dati di esempio che includono set di indirizzi e-mail duplicati**
```
-- 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');
```
**Eseguire una query di rilevamento dei duplicati**
```
-- 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;
```
**Visualizzare tutti i record con indirizzi e-mail duplicati**
```
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)
```
**Se provassimo ora l’istruzione di creazione dell’indice, questa fallirebbe:**
```
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)
```
# Tabelle e comandi di sistema in Aurora DSQL
Consulta le sezioni seguenti per conoscere le tabelle e i cataloghi di sistema supportati in Aurora DSQL, nonché utili query per recuperare informazioni sul sistema, come la versione.
## Tabelle di sistema
Aurora DSQL è compatibile con PostgreSQL, quindi molte [tabelle](https://www.PostgreSQL.org/docs/current/catalogs-overview.html) e [viste del catalogo di sistema](https://www.PostgreSQL.org/docs/current/views.html) di PostgreSQL esistono anche in Aurora DSQL.
### Tabelle e viste importanti del catalogo di PostgreSQL
La tabella seguente descrive le tabelle e le viste più comuni che è possibile utilizzare in Aurora DSQL.
| Nome | Description |
| --- | --- |
| `pg_namespace` | Informazioni su tutti gli schemi |
| `pg_tables` | Informazioni su tutte le tabelle |
| `pg_attribute` | Informazioni su tutti gli attributi |
| `pg_views` | Informazioni sulle viste (pre)definite |
| `pg_class` | Descrive tutte le tabelle, le colonne, gli indici e gli oggetti simili |
| `pg_stats` | Una vista sulle statistiche del planner |
| `pg_user` | Informazioni sugli utenti |
| `pg_roles` | Informazioni su utenti e gruppi |
| `pg_indexes` | Elenca tutti gli indici |
| `pg_constraint` | Elenca i vincoli sulle tabelle |
### Tabelle di catalogo supportate e non supportate
La tabella seguente indica quali tabelle sono supportate e non supportate in Aurora DSQL.
| Name | Applicabile ad Aurora DSQL |
| --- | --- |
| `pg_aggregate` | No |
| `pg_am` | Sì |
| `pg_amop` | No |
| `pg_amproc` | No |
| `pg_attrdef` | Sì |
| `pg_attribute` | Sì |
| `pg_authid` | No (utilizzare `pg_roles`) |
| `pg_auth_members` | Sì |
| `pg_cast` | Sì |
| `pg_class` | Sì |
| `pg_collation` | Sì |
| `pg_constraint` | Sì |
| `pg_conversion` | No |
| `pg_database` | No |
| `pg_db_role_setting` | Sì |
| `pg_default_acl` | Sì |
| `pg_depend` | Sì |
| `pg_description` | Sì |
| `pg_enum` | No |
| `pg_event_trigger` | No |
| `pg_extension` | No |
| `pg_foreign_data_wrapper` | No |
| `pg_foreign_server` | No |
| `pg_foreign_table` | No |
| `pg_index` | Sì |
| `pg_inherits` | Sì |
| `pg_init_privs` | No |
| `pg_language` | No |
| `pg_largeobject` | No |
| `pg_largeobject_metadata` | Sì |
| `pg_namespace` | Sì |
| `pg_opclass` | No |
| `pg_operator` | Sì |
| `pg_opfamily` | No |
| `pg_parameter_acl` | Sì |
| `pg_partitioned_table` | No |
| `pg_policy` | No |
| `pg_proc` | No |
| `pg_publication` | No |
| `pg_publication_namespace` | No |
| `pg_publication_rel` | No |
| `pg_range` | Sì |
| `pg_replication_origin` | No |
| `pg_rewrite` | No |
| `pg_seclabel` | No |
| `pg_sequence` | No |
| `pg_shdepend` | Sì |
| `pg_shdescription` | Sì |
| `pg_shseclabel` | No |
| `pg_statistic` | Sì |
| `pg_statistic_ext` | No |
| `pg_statistic_ext_data` | No |
| `pg_subscription` | No |
| `pg_subscription_rel` | No |
| `pg_tablespace` | No |
| `pg_transform` | No |
| `pg_trigger` | No |
| `pg_ts_config` | Sì |
| `pg_ts_config_map` | Sì |
| `pg_ts_dict` | Sì |
| `pg_ts_parser` | Sì |
| `pg_ts_template` | Sì |
| `pg_type` | Sì |
| `pg_user_mapping` | No |
### Viste di sistema supportate e non supportate
La tabella seguente indica quali viste sono supportate e non supportate in Aurora DSQL.
| Name | Applicabile ad Aurora DSQL |
| --- | --- |
| `pg_available_extensions` | No |
| `pg_available_extension_versions` | No |
| `pg_backend_memory_contexts` | Sì |
| `pg_config` | No |
| `pg_cursors` | No |
| `pg_file_settings` | No |
| `pg_group` | Sì |
| `pg_hba_file_rules` | No |
| `pg_ident_file_mappings` | No |
| `pg_indexes` | Sì |
| `pg_locks` | No |
| `pg_matviews` | No |
| `pg_policies` | No |
| `pg_prepared_statements` | No |
| `pg_prepared_xacts` | No |
| `pg_publication_tables` | No |
| `pg_replication_origin_status` | No |
| `pg_replication_slots` | No |
| `pg_roles` | Sì |
| `pg_rules` | No |
| `pg_seclabels` | No |
| `pg_sequences` | No |
| `pg_settings` | Sì |
| `pg_shadow` | Sì |
| `pg_shmem_allocations` | Sì |
| `pg_stats` | Sì |
| `pg_stats_ext` | No |
| `pg_stats_ext_exprs` | No |
| `pg_tables` | Sì |
| `pg_timezone_abbrevs` | Sì |
| `pg_timezone_names` | Sì |
| `pg_user` | Sì |
| `pg_user_mappings` | No |
| `pg_views` | Sì |
| `pg_stat_activity` | No |
| `pg_stat_replication` | No |
| `pg_stat_replication_slots` | No |
| `pg_stat_wal_receiver` | No |
| `pg_stat_recovery_prefetch` | No |
| `pg_stat_subscription` | No |
| `pg_stat_subscription_stats` | No |
| `pg_stat_ssl` | Sì |
| `pg_stat_gssapi` | No |
| `pg_stat_archiver` | No |
| `pg_stat_io` | No |
| `pg_stat_bgwriter` | No |
| `pg_stat_wal` | No |
| `pg_stat_database` | No |
| `pg_stat_database_conflicts` | No |
| `pg_stat_all_tables` | No |
| `pg_stat_all_indexes` | No |
| `pg_statio_all_tables` | No |
| `pg_statio_all_indexes` | No |
| `pg_statio_all_sequences` | No |
| `pg_stat_slru` | No |
| `pg_statio_user_tables` | No |
| `pg_statio_user_sequences` | No |
| `pg_stat_user_functions` | No |
| `pg_stat_user_indexes` | No |
| `pg_stat_progress_analyze` | No |
| `pg_stat_progress_basebackup` | No |
| `pg_stat_progress_cluster` | No |
| `pg_stat_progress_create_index` | No |
| `pg_stat_progress_vacuum` | No |
| `pg_stat_sys_indexes` | No |
| `pg_stat_sys_tables` | No |
| `pg_stat_xact_all_tables` | No |
| `pg_stat_xact_sys_tables` | No |
| `pg_stat_xact_user_functions` | No |
| `pg_stat_xact_user_tables` | No |
| `pg_statio_sys_indexes` | No |
| `pg_statio_sys_sequences` | No |
| `pg_statio_sys_tables` | No |
| `pg_statio_user_indexes` | No |
### La vista sys.jobs
`sys.jobs` fornisce informazioni sullo stato dei processi asincroni. Ad esempio, dopo aver [creato un indice asincrono](working-with-create-index-async.md), Aurora DSQL restituisce un `job_uuid`. È possibile utilizzare tale `job_uuid` con `sys.jobs` per cercare lo stato del processo.
```
SELECT * FROM sys.jobs;
```
Aurora DSQL restituisce una risposta simile alla seguente.
```
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
```
La tabella seguente descrive le colonne della vista. `sys.jobs`
**colonne di visualizzazione sys.jobs**
| Colonna | Tipo | Description |
| --- | --- | --- |
| job\$1id | text | Un UUID base-32 che rappresenta il lavoro. |
| status | text | Lo stato attuale del lavoro. I valori possibili sono submitted, processing, completed e failed. Per ulteriori informazioni, consulta [valori di stato di sys.jobs](#dsql-sys-jobs-status-values). |
| details | text | Eventuali dettagli pertinenti sulla mansione. Se il lavoro fallisce, viene fornito un motivo dettagliato. |
| job\$1type | text | Il tipo di lavoro asincrono. I valori possibili sono: INDEX\$1BUILD — una build di indice asincrona. ANALYZE— un lavoro di analisi automatica inviato dal sistema. DROP— rimuove i dati fisici dopo un'DROP TABLEoperazione OR. DROP INDEX |
| class\$1id | oid | L'OID della tabella del catalogo che contiene l'oggetto. |
| object\$1id | oid | L'OID dell'oggetto. |
| object\$1name | text | Il nome completo dell'oggetto. DROPi lavori non possono fare riferimento a oggetti già rilasciati. Se un oggetto referenziato è già stato eliminato, object\$1name potrebbe essere NULL. |
| start\$1time | timestamp with time zone | Il timestamp in cui è stato inviato il lavoro. |
| update\$1time | timestamp with time zone | Il timestamp in cui la riga del lavoro è stata aggiornata l'ultima volta. |
**valori di stato di sys.jobs**
| Status | Description |
| --- | --- |
| submitted | L’attività è stata inviata, ma Aurora DSQL non ha ancora iniziato a elaborarla. |
| processing | Aurora DSQL sta elaborando l’operazione. |
| failed | L’attività non è andata a buon fine. Per ulteriori informazioni, consulta la details colonna. |
| completed | Aurora DSQL ha completato l'operazione con successo. |
### La vista sys.iam\$1pg\$1role\$1mappings
La vista `sys.iam_pg_role_mappings` fornisce informazioni sulle autorizzazioni concesse agli utenti IAM. Ad esempio, se `DQSLDBConnect` è un ruolo IAM che fornisce ad Aurora DSQL l’accesso ai non amministratori e a un utente denominato `testuser` vengono concessi il ruolo `DQSLDBConnect` e le autorizzazioni corrispondenti, è possibile interrogare la vista `sys.iam_pg_role_mappings` per vedere a quali utenti sono concesse quali autorizzazioni.
```
SELECT * FROM sys.iam_pg_role_mappings;
```
## Utili interrogazioni sui metadati di sistema
Utilizza queste query per ottenere statistiche sulle tabelle e metadati di sistema senza eseguire operazioni costose come scansioni complete delle tabelle.
### Ottieni il numero stimato di righe per una tabella
Per ottenere il conteggio approssimativo delle righe in una tabella senza eseguire una scansione completa della tabella, utilizzate la seguente query:
```
SELECT reltuples FROM pg_class WHERE relname = 'table_name';
```
Il comando restituisce un output simile al seguente:
```
reltuples
--------------
9.993836e+08
```
Questo approccio è più efficiente rispetto alle tabelle `SELECT COUNT(*)` di grandi dimensioni in Aurora DSQL.
### Scarica la versione principale attuale di Aurora DSQL
Per ottenere la versione principale corrente del cluster Aurora DSQL, utilizzare la seguente query:
```
SELECT * FROM sys.dsql_major_version();
```
Il comando restituisce un output simile al seguente:
```
dsql_major_version
--------------------
1
```
Ciò restituisce la versione principale su cui si trova la connessione SQL in Aurora DSQL.
### Ottieni la versione corrente di PostgreSQL
Per ottenere la versione PostgreSQL corrente del cluster Aurora DSQL, usa la seguente query:
```
SHOW server_version;
```
Il comando restituisce un output simile al seguente:
```
server_version
----------------
16.13
```
Ciò restituisce la versione PostgreSQL su cui si trova la connessione SQL in Aurora DSQL.
## Il comando `ANALYZE`.
Il comando `ANALYZE `raccoglie statistiche sul contenuto delle tabelle nel database e archivia i risultati nella vista di sistema `pg_stats`. In un secondo momento, il pianificatore di query utilizza queste statistiche per determinare i piani di esecuzione più efficienti per le query.
In Aurora DSQL, non è possibile eseguire il comando `ANALYZE` all’interno di una transazione esplicita. `ANALYZE`non è soggetto al limite di timeout delle transazioni del database.
Per ridurre la necessità di interventi manuali e mantenere le statistiche costantemente aggiornate, Aurora DSQL esegue automaticamente `ANALYZE` come processo in background. Questo processo in background viene attivato automaticamente in base al tasso di variazione osservato nella tabella. È collegato al numero di righe (tuple) che sono state inserite, aggiornate o eliminate dall’ultima analisi.
Il processo `ANALYZE` viene eseguito in modo asincrono in background e la relativa attività può essere monitorata nella vista di sistema sys.jobs con la seguente query:
```
SELECT * FROM sys.jobs WHERE job_type = 'ANALYZE';
```
**Considerazioni chiave**
**Nota**
I processi `ANALYZE` vengono fatturati come gli altri processi asincroni in Aurora DSQL. Quando modifichi una tabella, ciò può attivare indirettamente un processo automatico di raccolta di statistiche in background, che può comportare addebiti di costi dovuti all’attività associata a livello di sistema.
I processi `ANALYZE` in background, attivati automaticamente, raccolgono gli stessi tipi di statistiche utilizzate da un processo `ANALYZE` avviato manualmente e le applicano per impostazione predefinita alle tabelle utente. Le tabelle di sistema e di catalogo sono escluse da questo processo automatizzato.
# Utilizzo dei piani Aurora DSQL EXPLAIN
Aurora DSQL utilizza una struttura del piano EXPLAIN simile a PostgreSQL, ma con aggiunte chiave che riflettono l'architettura distribuita e il modello di esecuzione.
In questa documentazione, forniremo una panoramica dei piani di Aurora DSQL EXPLAIN, evidenziando le somiglianze e le differenze rispetto a PostgreSQL. Tratteremo i vari tipi di operazioni di scansione disponibili in Aurora DSQL e ti aiuteremo a comprendere i costi di esecuzione delle tue query.
## Piani EXPLAIN di PostgreSQL VS Aurora DSQL
Aurora DSQL si basa sul database PostgreSQL e condivide la maggior parte delle strutture del piano con PostgreSQL, ma presenta differenze architettoniche chiave che influiscono sull'esecuzione e l'ottimizzazione delle query:
| Funzionalità | PostgreSQL | Aurora DSQL |
| --- | --- | --- |
| Storage dei dati | Archiviazione Heap | Nessun heap, tutte le righe sono indicizzate da un identificatore univoco |
| Chiave primaria | L'indice della chiave primaria è separato dai dati della tabella | L'indice della chiave primaria è la tabella con tutte le colonne aggiuntive come colonne INCLUDE |
| Indici secondari | Indici secondari standard | Funziona come PostgreSQL, con la possibilità di includere colonne non chiave |
| Funzionalità di filtraggio | Condizione dell'indice, filtro Heap | Condizione dell'indice, filtro di archiviazione, filtro del processore di query |
| Tipi di scansione | Scansione sequenziale, scansione dell'indice, scansione solo dell'indice | Scansione completa, scansione solo indice, scansione indice |
| Esecuzione della query | Locale al database | Distribuito (elaborazione e archiviazione sono separati) |
Aurora DSQL archivia i dati della tabella direttamente nell'ordine della chiave primaria anziché in un heap separato. Ogni riga è identificata da una chiave univoca, in genere la chiave primaria, che consente al database di ottimizzare le ricerche in modo più efficiente. La differenza architetturale spiega perché Aurora DSQL utilizza spesso le scansioni Index Only nei casi in cui PostgreSQL potrebbe scegliere una scansione sequenziale.
Un'altra differenza fondamentale è che Aurora DSQL separa l'elaborazione dallo storage, consentendo l'applicazione di filtri nelle fasi iniziali del percorso di esecuzione per ridurre lo spostamento dei dati e migliorare le prestazioni.
[Per ulteriori informazioni sull'utilizzo dei piani EXPLAIN con PostgreSQL, consulta la documentazione di PostgreSQL EXPLAIN.](https://www.postgresql.org/docs/current/using-explain.html)
## Elementi chiave dei piani Aurora DSQL EXPLAIN
I piani Aurora DSQL EXPLAIN forniscono informazioni dettagliate su come vengono eseguite le query, incluso dove avviene il filtraggio e quali colonne vengono recuperate dallo storage. La comprensione di questo risultato consente di ottimizzare le prestazioni delle query.
Index Cond
Condizioni utilizzate per navigare nell'indice. Filtraggio più efficiente che riduce i dati scansionati. In Aurora DSQL, le condizioni dell'indice possono essere applicate a più livelli del piano di esecuzione.
Proiezioni
Colonne recuperate dalla memorizzazione. Un numero inferiore di proiezioni significa prestazioni migliori.
Filtro di archiviazione
Condizioni applicate a livello di archiviazione. Più efficiente dei filtri del processore di query.
Filtro del processore di query
Condizioni applicate a livello di processore di query. Richiede il trasferimento di tutti i dati prima del filtraggio, il che comporta un maggiore spostamento dei dati e un sovraccarico di elaborazione.
## Filtri in Aurora DSQL
Aurora DSQL separa l'elaborazione dallo storage, il che significa che il punto in cui vengono applicati i filtri durante l'esecuzione delle query ha un impatto significativo sulle prestazioni. I filtri applicati prima del trasferimento di grandi volumi di dati riducono la latenza e migliorano l'efficienza. Quanto prima viene applicato un filtro, tanto meno dati devono essere elaborati, spostati e scansionati, con conseguenti query più rapide.
Aurora DSQL può applicare filtri in più fasi del percorso della query. La comprensione di queste fasi è fondamentale per interpretare i piani di interrogazione e ottimizzare le prestazioni.
| Livello | Tipo di filtro | Description |
| --- | --- | --- |
| 1 | Condizione dell'indice | Applicata durante la scansione dell'indice. Limita la quantità di dati letti dallo storage e riduce i dati inviati al livello di elaborazione. |
| 2 | Filtro di archiviazione | Applicato dopo la lettura dei dati dallo storage ma prima di essere inviati al calcolo. Un esempio qui è un filter su una colonna di inclusione di un indice. Riduce il trasferimento di dati ma non la quantità letta. |
| 3 | Filtro Query Processor | Applicato dopo che i dati raggiungono il livello di elaborazione. Tutti i dati devono essere trasferiti per primi, il che aumenta la latenza e i costi. Attualmente, Aurora DSQL non è in grado di eseguire tutte le operazioni di filtraggio e proiezione sullo storage, quindi alcune query potrebbero essere costrette a ricorrere a questo tipo di filtro. |
# Leggere i piani di Aurora DSQL EXPLAIN
Capire come leggere i piani EXPLAIN è fondamentale per ottimizzare le prestazioni delle query. In questa sezione, esamineremo esempi reali di piani di query DSQL di Aurora, mostreremo come si comportano i diversi tipi di scansione, spiegheremo dove vengono applicati i filtri ed evidenzieremo le opportunità di ottimizzazione.
## Tabelle di esempio utilizzate in questi esempi
Gli esempi seguenti fanno riferimento a due tabelle: `transaction` e`account`.
La `transaction` tabella non dispone di una chiave primaria, il che fa sì che Aurora DSQL esegua scansioni complete della tabella durante l'interrogazione.
La `account` tabella ha un indice attivo. `customer_id` Questo indice include `balance` e `status` funge da colonne di copertura, che consentono di soddisfare determinate domande direttamente dall'indice senza dover leggere dalla tabella di base. Tuttavia, l'indice non include`created_at`, pertanto le query che fanno riferimento a questa colonna richiedono un accesso aggiuntivo alla tabella.
```
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);
```
## Esempio di scansione completa
Aurora DSQL dispone sia di scansioni sequenziali, identiche dal punto di vista funzionale a PostgreSQL, sia di scansioni complete. L'unica differenza tra queste due è che le scansioni complete possono utilizzare filtri aggiuntivi sullo storage. Per questo motivo, viene quasi sempre selezionato al di sopra delle scansioni sequenziali. A causa della somiglianza, tratteremo solo esempi delle scansioni complete più interessanti.
Le scansioni complete verranno utilizzate principalmente su tabelle prive di chiave primaria. Poiché le chiavi primarie Aurora DSQL sono per impostazione predefinita indici a copertura completa, Aurora DSQL utilizzerà molto probabilmente Index Only Scans sulla chiave primaria in molte situazioni in cui PostgreSQL utilizzerebbe una scansione sequenziale. Come con la maggior parte degli altri database, una tabella senza indici si ridimensionerà male.
```
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)
```
Questo piano mostra due filtri applicati in fasi diverse. La `transaction_date > '2025-01-01'` condizione viene applicata a livello di archiviazione, riducendo la quantità di dati restituiti. La `description LIKE '%external%'` condizione viene applicata successivamente nel processore di query, dopo il trasferimento dei dati, rendendolo meno efficiente. L'inserimento di filtri più selettivi nei livelli di archiviazione o di indice generalmente migliora le prestazioni.
## Esempio di scansione Index Only
Le scansioni indicizzate sono i tipi di scansione più ottimali in Aurora DSQL in quanto comportano il minor numero di round trip verso il livello di archiviazione e possono eseguire la maggior parte dei filtri. Ma solo perché vedi Index Only Scan non significa che tu abbia il piano migliore. A causa di tutti i diversi livelli di filtraggio che possono verificarsi, è essenziale prestare comunque attenzione ai diversi luoghi in cui può avvenire il filtraggio.
```
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)
```
In questo piano, la condizione dell'indice,`customer_id = '4b18a761-5870-4d7c-95ce-0a48eca3fceb'`), viene valutata innanzitutto durante la scansione dell'indice, che è la fase più efficiente perché limita la quantità di dati letti dallo storage. Il filtro di archiviazione,`status = 'pending'`, viene applicato dopo la lettura dei dati ma prima di essere inviati al livello di elaborazione, riducendo la quantità di dati trasferiti. Infine, il filtro del processore di query viene eseguito per ultimo, dopo lo spostamento dei dati, il che lo rende il meno efficiente. `balance > 100` Di queste, la condizione dell'indice offre le prestazioni migliori perché controlla direttamente la quantità di dati scansionati.
## Esempio di Index Scan
Le scansioni degli indici sono simili alle scansioni di solo indice, tranne per il fatto che hanno il passaggio aggiuntivo di dover richiamare la tabella di base. Poiché Aurora DSQL è in grado di specificare filtri di archiviazione, è in grado di farlo sia sulla chiamata di indice che sulla chiamata di ricerca.
Per chiarire questo punto, Aurora DSQL presenta il piano come due nodi. In questo modo, puoi vedere chiaramente quanto l'aggiunta di una colonna di inclusione possa aiutare in termini di righe restituite dall'archiviazione.
```
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)
```
Questo piano mostra come avviene il filtraggio in più fasi:
+ La condizione di indicizzazione `customer_id ` filtra i dati in anticipo.
+ Il filtro di archiviazione limita `status` ulteriormente i risultati prima che vengano inviati al calcolo.
+ Il filtro del processore di query attivo `balance` viene applicato successivamente, dopo il trasferimento.
+ Il filtro di ricerca attivato `created_at` viene valutato quando si recuperano colonne aggiuntive dalla tabella di base.
L'aggiunta di colonne utilizzate di frequente come `INCLUDE` campi può spesso eliminare questa ricerca e migliorare le prestazioni.
## Best practice
+ **Allinea i filtri alle colonne indicizzate per accelerare il filtraggio**.
+ **Utilizza le colonne INCLUDE** per consentire le scansioni solo indicizzate ed evitare le ricerche.
+ **Convalida le stime delle righe quando** esamini i problemi di prestazioni. Aurora DSQL gestisce automaticamente le statistiche eseguendole in background `ANALYZE` in base ai tassi di modifica dei dati. Se le stime sembrano imprecise, è possibile eseguirle `ANALYZE` manualmente per aggiornare immediatamente le statistiche.
+ **Evita le query non indicizzate** su tabelle di grandi dimensioni per evitare costose scansioni complete.
# Comprensione DPUs in EXPLAIN ANAL
Aurora DSQL fornisce informazioni DPU (Distributed Processing Unit) a **livello di dichiarazione** nell'output del `EXPLAIN ANALYZE VERBOSE` piano, offrendoti una visibilità più approfondita sui costi delle query durante lo sviluppo. Questa sezione spiega cosa DPUs sono e come interpretarli nell'output. `EXPLAIN ANALYZE VERBOSE`
## Che cos'è una DPU?
Un'unità di elaborazione distribuita (DPU) è la misura normalizzata del lavoro svolto da Aurora DSQL. È composta da:
+ **ComputedPU**: tempo impiegato per l'esecuzione di query SQL
+ **ReadDPU**: risorse utilizzate per leggere i dati dallo storage
+ **WriteDPU**: risorse utilizzate per scrivere dati nell'archivio
+ **MultiRegionWriteDPU**: risorse utilizzate per replicare le scritture su cluster peer in configurazioni multiregionali.
## Utilizzo della DPU in EXPLAIN ANALYZE VERBOSE
Aurora DSQL si estende `EXPLAIN ANALYZE VERBOSE` per includere una stima dell'utilizzo della DPU a livello di dichiarazione fino alla fine dell'output. Ciò offre una visibilità immediata sui costi delle query, aiutandoti a identificare i fattori di costo del carico di lavoro, ottimizzare le prestazioni delle query e prevedere meglio l'utilizzo delle risorse.
Gli esempi seguenti mostrano come interpretare le stime della DPU a livello di dichiarazione incluse nell'output EXPLAIN ANALYZE VERBOSE.
### Esempio 1: SELECT Query
```
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
```
In questo esempio, l'istruzione SELECT esegue una scansione solo indicizzata, quindi la maggior parte del costo proviene da Read DPU (0.04312), che rappresenta i dati recuperati dallo storage e Compute DPU (0,01607), che riflette le risorse di calcolo utilizzate per elaborare e restituire i risultati. Non esiste una DPU di scrittura poiché la query non modifica i dati. La DPU totale (0,05919) è la somma di Compute\$1Read\$1Write.
### Esempio 2: INSERT Query
```
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
```
Questa istruzione esegue principalmente le scritture, quindi la maggior parte del costo è associato a Write DPU. La Compute DPU (0,01550) rappresenta il lavoro svolto per elaborare e inserire i valori. La Read DPU (0.00307) riflette le letture secondarie del sistema (per le ricerche nel catalogo o il controllo degli indici).
Notate i valori minimi delle transazioni mostrati accanto a Lettura e scrittura. DPUs Questi indicano i costi di base per transazione che si applicano *solo quando l'operazione include operazioni* di lettura o scrittura. Ciò non significa che ogni transazione comporti automaticamente un costo di 0,00375 DPU in lettura o 0,05 DPU in scrittura. Questi minimi vengono invece applicati a livello di transazione durante l'aggregazione dei costi e solo se all'interno della transazione vengono eseguite operazioni di lettura o scrittura. A causa di questa differenza di ambito, le stime a livello di rendiconto `EXPLAIN ANALYZE VERBOSE` potrebbero non corrispondere esattamente alle metriche a livello di transazione riportate nei dati di fatturazione o nei dati di fatturazione. CloudWatch
## Utilizzo delle informazioni sulla DPU per l'ottimizzazione
Le stime della DPU per dichiarazione offrono un modo efficace per ottimizzare le query oltre il semplice tempo di esecuzione. Casi di utilizzo comune comprendono:
+ **Consapevolezza dei costi:** scopri quanto è costosa una query rispetto alle altre.
+ **Ottimizzazione dello schema:** confronta l'impatto degli indici o delle modifiche allo schema sulle prestazioni e sull'efficienza delle risorse.
+ **Pianificazione del budget:** stima del costo del carico di lavoro in base all'utilizzo della DPU osservato.
+ **Confronto tra query:** valuta gli approcci di interrogazione alternativi in base al consumo relativo di DPU.
## Interpretazione delle informazioni sulla DPU
Tieni a mente le seguenti best practice quando utilizzi dati DPU da: `EXPLAIN ANALYZE VERBOSE`
+ **Usalo in modo direzionale:** considera la DPU segnalata come un modo per comprendere il costo *relativo* di una query piuttosto che come una corrispondenza esatta con le CloudWatch metriche o i dati di fatturazione. Le differenze sono previste perché `EXPLAIN ANALYZE VERBOSE` riporta i costi a livello di rendiconto, mentre aggrega l'attività a livello di transazione. CloudWatch CloudWatch include anche operazioni in background (come ANALYZE o compactions) e il sovraccarico delle transazioni (/) che esclude intenzionalmente. `BEGIN` `COMMIT` `EXPLAIN ANALYZE VERBOSE`
+ La **variabilità della DPU tra le esecuzioni è normale** nei sistemi distribuiti e non indica errori. Fattori come la memorizzazione nella cache, le modifiche al piano di esecuzione, la concorrenza o i cambiamenti nella distribuzione dei dati possono tutti far sì che la stessa query utilizzi risorse diverse da un'esecuzione all'altra.
+ **Operazioni in batch di piccole dimensioni:** se il carico di lavoro genera molte istruzioni di piccole dimensioni, valuta la possibilità di raggrupparle in batch in operazioni più grandi (non superare i 10 MB). In questo modo si riducono le spese generali di arrotondamento e si ottengono stime dei costi più significative.
+ **Utilizzabile per l'ottimizzazione, non per la fatturazione:** i dati in `EXPLAIN ANALYZE VERBOSE` ingresso della DPU sono progettati per la consapevolezza dei costi, l'ottimizzazione delle query e l'ottimizzazione. Non è una metrica adatta alla fatturazione. Affidati sempre alle CloudWatch metriche o ai rapporti di fatturazione mensili per dati autorevoli su costi e utilizzo.