# Aurora DSQL y PostgreSQL
Aurora DSQL es una base de datos relacional distribuida, compatible con PostgreSQL, diseñada para cargas de trabajo transaccionales. Aurora DSQL utiliza componentes principales de PostgreSQL, como el analizador, el planificador, el optimizador y el sistema de tipos.
El diseño de Aurora DSQL garantiza que toda la sintaxis de PostgreSQL admitida proporcione un comportamiento compatible y arroje resultados de consulta idénticos. Por ejemplo, Aurora DSQL proporciona conversiones de tipo, operaciones aritméticas y precisión y escala numéricas que son idénticas a PostgreSQL. Cualquier desviación queda documentada.
Aurora DSQL también incorpora capacidades avanzadas como el control de simultaneidad optimizada y la administración de esquemas distribuida. Con estas características, puede utilizar las herramientas familiares de PostgreSQL mientras se beneficia del rendimiento y la escalabilidad de las aplicaciones modernas, distribuidas y nativas en la nube.
## Aspectos destacados de la compatibilidad con PostgreSQL
Aurora DSQL se basa actualmente en la versión 16 de PostgreSQL. Entre las funciones más destacadas se incluyen las siguientes:
**Protocolo de conexión**
Aurora DSQL utiliza el protocolo de conexión estándar de PostgreSQL v3. Esto habilita la integración con clientes, controladores y herramientas de PostgreSQL estándar. Por ejemplo, Aurora DSQL es compatible con `psql`, `pgjdbc` y `psycopg`.
**Sintaxis SQL**
Aurora DSQL es compatible con un amplio intervalo de expresiones y funciones de PostgreSQL estándar que se utilizan habitualmente en cargas de trabajo transaccionales. Las expresiones SQL admitidas producen resultados idénticos a los de PostgreSQL, incluidos los siguientes:
+ Gestión de valores nulos
+ Comportamiento del orden de clasificación
+ Escala y precisión para operaciones numéricas
+ Equivalencia para operaciones con cadenas
Para obtener más información, consulte [Compatibilidad con características SQL en Aurora DSQL](working-with-postgresql-compatibility.md).
**Administración de transacciones**
Aurora DSQL conserva las principales características de PostgreSQL, como las transacciones ACID y un nivel de aislamiento equivalente a la lectura repetible de PostgreSQL. Para obtener más información, consulte [Control de simultaneidad en Aurora DSQL](working-with-concurrency-control.md).
## Ventajas de la arquitectura distribuida
El diseño distribuido y sin recursos compartidos de Aurora DSQL ofrece ventajas en cuanto a rendimiento y escalabilidad que superan a las bases de datos tradicionales de un solo nodo. Las funciones principales incluyen las siguientes:
**Control de simultaneidad optimista (OCC)**
Aurora DSQL utiliza un modelo de control de simultaneidad optimista. Este enfoque sin bloqueos impide que las transacciones se bloqueen entre sí, elimina los bloqueos y habilita una ejecución paralela de alto rendimiento. Estas características hacen que Aurora DSQL tenga especial valor en aplicaciones que requieren un rendimiento coherente a escala. Para obtener más ejemplos, consulte [Control de simultaneidad en Aurora DSQL](working-with-concurrency-control.md).
**Operaciones DDL asíncronas**
Aurora DSQL ejecuta las operaciones DDL de forma asíncrona, lo que permite lecturas y escrituras ininterrumpidas durante los cambios de esquema. Su arquitectura distribuida permite a Aurora DSQL realizar las siguientes acciones:
+ Ejecutar operaciones DDL como tareas en segundo plano, lo que minimiza las interrupciones.
+ Coordinar los cambios de catálogo como transacciones distribuidas de alta coherencia. Esto garantiza visibilidad atómica en todos los nodos, incluso durante errores u operaciones simultáneas.
+ Operar de forma totalmente distribuida y sin nodo principal en múltiples zonas de disponibilidad con capas de computación y almacenamiento desacopladas.
Para obtener más información sobre el uso del comando EXPLAIN en PostgreSQL, consulte [DDL y las transacciones distribuidas en Aurora DSQL](working-with-ddl.md).
# Compatibilidad con características SQL en Aurora DSQL
En las siguientes secciones, conozca la compatibilidad de Aurora DSQL con los tipos de datos y comandos SQL de PostgreSQL.
**Topics**
+ [Tipos de datos admitidos en Aurora DSQL](working-with-postgresql-compatibility-supported-data-types.md)
+ [SQL compatible con Aurora DSQL](working-with-postgresql-compatibility-supported-sql-features.md)
+ [Subconjuntos de comandos SQL admitidos en Aurora DSQL](working-with-postgresql-compatibility-supported-sql-subsets.md)
+ [Migración de PostgreSQL a Aurora DSQL](working-with-postgresql-compatibility-migration-guide.md)
# Tipos de datos admitidos en Aurora DSQL
Aurora DSQL admite un subconjunto de los tipos comunes de PostgreSQL.
**Topics**
+ [Tipos de datos numéricos](#numeric-data-types)
+ [Tipos de datos de caracteres](#character-data-types)
+ [Tipos de datos de fecha y hora](#date-time-data-types)
+ [Tipos de datos varios](#miscellaneous-data-types)
+ [Tipos de datos de tiempo de ejecución de consultas](#working-with-postgresql-compatibility-query-runtime)
## Tipos de datos numéricos
Aurora DSQL admite los siguientes tipos de datos numéricos de PostgreSQL.
| Nombre | Alias | Intervalo y precisión | Tamaño del almacenamiento | Compatibilidad con índices |
| --- | --- | --- | --- | --- |
| smallint | int2 | De -32768 a \$132767 | 2 bytes | Sí |
| `integer` | `int`, `int4` | De -2147483648 a 2147483647 | 4 bytes | Sí |
| `bigint` | `int8` | De -9223372036854775808 a \$19223372036854775807 | 8 bytes | Sí |
| `real` | `float4` | Precisión de 6 dígitos decimales | 4 bytes | Sí |
| `double precision` | `float8` | Precisión de 15 dígitos decimales | 8 bytes | Sí |
| `numeric` [ `(`*p*, *s*`)` ] | `decimal` [ `(`*p*, *s*`)` ] `dec`[ `(`*p*,*s*`)`] | Numérico exacto de precisión seleccionable. La precisión máxima es 38 y la escala máxima es 37.1 El valor predeterminado es `numeric (18,6)`. | 8 bytes \$1 2 bytes por dígito de precisión. El tamaño máximo es de 27 bytes. | Sí |
1: si no especifica explícitamente un tamaño cuando ejecuta `CREATE TABLE` o `ALTER TABLE ADD COLUMN`, Aurora DSQL aplica los valores predeterminados. Aurora DSQL aplica límites cuando ejecuta las instrucciones `INSERT` o `UPDATE`.
## Tipos de datos de caracteres
Aurora DSQL admite los siguientes tipos de datos de caracteres de PostgreSQL.
| Nombre | Alias | Descripción | Límite de Aurora DSQL | Tamaño del almacenamiento | Compatibilidad con índices |
| --- | --- | --- | --- | --- | --- |
| `character` [ `(`*n*`)` ] | `char` [ `(`*n*`)` ] | Cadena de caracteres de longitud fija | 4096 bytes1 | Variable hasta 4100 bytes | Sí |
| `character varying` [ `(`*n*`)` ] | `varchar` [ `(`*n*`)` ] | Cadena de caracteres de longitud variable | 65 535 bytes1 | Variable hasta 65539 bytes | Sí |
| `bpchar` [ `(`*n*`)` ] | | Si es de longitud fija, es un alias de `char`. Si es de longitud variable, es un alias de `varchar`, donde los espacios al final no tienen significado semántico. | 4096 bytes1 | Variable hasta 4100 bytes | Sí |
| `text` | | Cadena de caracteres de longitud variable | 1 MiB1 | Variable de hasta 1 MiB | Sí |
1: si no especifica explícitamente un tamaño cuando ejecuta `CREATE TABLE` o `ALTER TABLE ADD COLUMN`, Aurora DSQL aplica los valores predeterminados. Aurora DSQL aplica límites cuando ejecuta las instrucciones `INSERT` o `UPDATE`.
## Tipos de datos de fecha y hora
Aurora DSQL admite los siguientes tipos de datos de fecha y hora de PostgreSQL.
| Nombre | Alias | Descripción | Range | Resolución | Tamaño del almacenamiento | Compatibilidad con índices |
| --- | --- | --- | --- | --- | --- | --- |
| `date` | | Fecha de calendario (año, mes, día) | De 4713 a. C. a 5874897 d. C. | 1 día | 4 bytes | Sí |
| `time` [ `(`*p*`)` ] [ `without time zone` ] | `timestamp` | Hora del día, sin zona horaria | De 0 a 1 | 1 microsegundo | 8 bytes | Sí |
| `time` [ `(`*p*`)` ] `with time zone` | `timetz` | Hora del día, con zona horaria | De 00:00:00\$11559 a 24:00:00 -1559 | 1 microsegundo | 12 bytes | No |
| `timestamp` [ `(`*p*`)` ] [ `without time zone` ] | | Fecha y hora, sin zona horaria | De 4713 a. C. a 294276 d. C. | 1 microsegundo | 8 bytes | Sí |
| `timestamp` [ `(`*p*`)` ] `with time zone` | `timestamptz` | Fecha y hora, con zona horaria | De 4713 a. C. a 294276 d. C. | 1 microsegundo | 8 bytes | Sí |
| `interval` [ `fields` ] [ `(`*p*`)` ] | | Intervalo de tiempo | De -178000000 años a 178000000 años | 1 microsegundo | 16 bytes | No |
## Tipos de datos varios
Aurora DSQL soporta los siguientes tipos de datos varios de PostgreSQL.
| Nombre | Alias | Descripción | Límite de Aurora DSQL | Tamaño del almacenamiento | Compatibilidad con índices |
| --- | --- | --- | --- | --- | --- |
| `boolean` | `bool` | Booleano lógico (true/false) | | 1 byte | Sí |
| `bytea` | | Datos binarios (“matriz de bytes”) | 1 MiB1 | Variable hasta un límite de 1 MiB | No |
| `UUID` | | Identificador único universal | | 16 bytes | Sí |
1: si no especifica explícitamente un tamaño cuando ejecuta `CREATE TABLE` o `ALTER TABLE ADD COLUMN`, Aurora DSQL aplica los valores predeterminados. Aurora DSQL aplica límites cuando ejecuta las instrucciones `INSERT` o `UPDATE`.
## Tipos de datos de tiempo de ejecución de consultas
Los tipos de datos de tiempo de ejecución de consultas son tipos de datos internos que se utilizan en tiempo de ejecución de consultas. Estos tipos son distintos de los tipos compatibles con PostgreSQL como `varchar` y `integer` que define en el esquema. En su lugar, estos tipos son representaciones en tiempo de ejecución que Aurora DSQL utiliza al procesar una consulta.
Los siguientes tipos de datos son compatibles solo durante el tiempo de ejecución de consultas:
**Tipo de matriz**
Aurora DSQL admite matrices de los tipos de datos admitidos. Por ejemplo, puede tener una matriz de enteros. La función `string_to_array` divide una cadena en una matriz al estilo de PostgreSQL mediante el delimitador de comas (`,`) como se muestra en el ejemplo siguiente. Puede utilizar matrices en expresiones, salidas de funciones o cálculos temporales durante la ejecución de consultas.
```
SELECT string_to_array('1,2', ',');
```
La función devuelve una respuesta similar a lo siguiente:
```
string_to_array
-----------------
{1,2}
(1 row)
```
****Tipo inet****
Este tipo de datos representa direcciones de host IPv4, IPv6 y las subredes. Este tipo es útil al analizar registros, filtrar por subredes IP o realizar cálculos de red en una consulta. Para obtener más información, consulte [inet en la documentación de PostgreSQL](https://www.PostgreSQL.org/docs/16/datatype-net-types.html#DATATYPE-INET).
**Funciones de tiempo de ejecución de JSON**
Aurora DSQL admite JSON y JSONB como tipos de datos en tiempo de ejecución para el procesamiento de consultas. Almacene los datos JSON como columnas de `text` y conviértalos a JSON durante la ejecución de la consulta para utilizar las funciones y operadores JSON de PostgreSQL.
Aurora DSQL admite la mayoría de las funciones de PostgreSQL JSON de [la sección 9.1.6 Funciones y operadores JSON](https://www.postgresql.org/docs/current/functions-json.html) con un comportamiento idéntico.
Las funciones que devuelven tipos JSON o JSONB pueden requerir una conversión adicional a `text` para que se muestren correctamente.
```
SELECT json_build_array(1, 2, 'foo', 4, 5)::text;
```
La función devuelve una respuesta similar a lo siguiente:
```
json_build_array
---------------------
[1, 2, "foo", 4, 5]
(1 row)
```
# SQL compatible con Aurora DSQL
Aurora DSQL admite un amplio intervalo de características de SQL de PostgreSQL básicas. En las siguientes secciones, podrá conocer la compatibilidad general con expresiones PostgreSQL. Esta lista no es exhaustiva.
## `SELECT`Comando de la
Aurora DSQL admite las siguientes cláusulas del comando `SELECT`.
| Cláusula principal | Cláusulas admitidas |
| --- | --- |
| `FROM` | |
| `GROUP BY` | `ALL`, `DISTINCT` |
| `ORDER BY` | `ASC`, `DESC`, `NULLS` |
| `LIMIT` | |
| `DISTINCT` | |
| `HAVING` | |
| `USING` | |
| `WITH` (expresiones de tabla comunes) | |
| `INNER JOIN` | `ON` |
| `OUTER JOIN` | `LEFT`, `RIGHT`, `FULL`, `ON` |
| `CROSS JOIN` | `ON` |
| `UNION` | `ALL` |
| `INTERSECT` | `ALL` |
| `EXCEPT` | `ALL` |
| `OVER` | `RANK ()`, `PARTITION BY` |
| `FOR UPDATE` | |
## Lenguaje de definición de datos (DDL)
Aurora DSQL admite los siguientes comandos DDL de PostgreSQL.
| Comando | Cláusula principal | Cláusulas admitidas |
| --- | --- | --- |
| `CREATE` | `TABLE` | Para obtener información sobre la sintaxis admitida del comando `CREATE TABLE`, consulte [`CREATE TABLE`](create-table-syntax-support.md). |
| `ALTER` | `TABLE` | Para obtener información sobre la sintaxis admitida del comando `ALTER TABLE`, consulte [`ALTER TABLE`](alter-table-syntax-support.md). |
| `DROP` | `TABLE` | |
| `CREATE` | `[UNIQUE] INDEX ASYNC` | Puede utilizar este comando con los siguientes parámetros: `ON`, `NULLS FIRST` y `NULLS LAST`. Para obtener información sobre la sintaxis admitida del comando `CREATE INDEX ASYNC`, consulte [Índices asíncronos en Aurora DSQL](working-with-create-index-async.md). |
| `DROP` | `INDEX` | |
| `CREATE` | `VIEW` | Para obtener más información sobre la sintaxis admitida del comando `CREATE VIEW`, consulte [`CREATE VIEW`](create-view.md). |
| ALTER | VIEW | Para obtener información sobre la sintaxis admitida del comando `ALTER VIEW`, consulte [`ALTER VIEW`](alter-view-syntax-support.md). |
| DROP | VIEW | Para obtener información sobre la sintaxis admitida del comando DROP VIEW, consulte [`DROP VIEW`](drop-view-overview.md). |
| `CREATE` | `SEQUENCE` | Para obtener información sobre la sintaxis admitida del comando `CREATE SEQUENCE`, consulte [`CREATE SEQUENCE`](create-sequence-syntax-support.md). |
| `ALTER` | `SEQUENCE` | Para obtener información sobre la sintaxis admitida del comando `ALTER SEQUENCE`, consulte [`ALTER SEQUENCE`](alter-sequence-syntax-support.md). |
| `DROP` | `SEQUENCE` | Para obtener información sobre la sintaxis admitida del comando `DROP SEQUENCE`, consulte [`DROP SEQUENCE`](drop-sequence-syntax-support.md). |
| `CREATE` | `ROLE`, `WITH` | |
| `CREATE` | `FUNCTION` | `LANGUAGE SQL` |
| `CREATE` | `DOMAIN` | |
## Lenguaje de manipulación de datos (DML)
Aurora DSQL admite los siguientes comandos DML de PostgreSQL.
| Comando | Cláusula principal | Cláusulas admitidas |
| --- | --- | --- |
| `INSERT` | `INTO` | `VALUES`SELECT |
| `UPDATE` | `SET` | `WHERE (SELECT)` `FROM, WITH` |
| DELETE | FROM | USING, WHERE |
## Lenguaje de control de datos (DCL)
Aurora DSQL admite los siguientes comandos DCL de PostgreSQL.
| Comando | Cláusulas admitidas |
| --- | --- |
| `GRANT` | `ON`, `TO` |
| `REVOKE` | `ON`, `FROM`, `CASCADE`, `RESTRICT` |
## Lenguaje de control de transacciones (TCL)
Aurora DSQL admite los siguientes comandos TCL de PostgreSQL.
| Comando | Cláusulas admitidas | 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` |
## Comandos de utilidad
Aurora DSQL admite los siguientes comandos de utilidad de PostgreSQL:
+ `EXPLAIN`
+ `ANALYZE` (solo el nombre de la relación)
# Subconjuntos de comandos SQL admitidos en Aurora DSQL
Esta sección proporciona información detallada sobre los comandos SQL compatibles, centrándose en los comandos con conjuntos de parámetros y subcomandos extensos. Por ejemplo, CREATE TABLE en PostgreSQL ofrece muchas cláusulas y parámetros, un subconjunto de los cuales es compatible con Aurora DSQL. En esta sección se describen todos los elementos de la sintaxis de PostgreSQL que Aurora DSQL admite para estos comandos.
**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` define una nueva tabla.
```
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 [, ... ] ) ]
```
## Columnas de identidad
**nota**
Cuando se utilizan columnas de identidad, se debe considerar con cuidado el valor de la caché. Para obtener más información, consulte el aviso Importante de la página [`CREATE SEQUENCE`](create-sequence-syntax-support.md).
Para obtener orientación sobre la mejor manera de utilizar las columnas de identidad en función de los patrones de carga de trabajo, consulte [Trabajar con secuencias y columnas de identidad](sequences-identity-columns-working-with.md).
La cláusula `GENERATED { ALWAYS | BY DEFAULT } AS IDENTITY ( sequence_options )` crea la columna como una *columna de identidad*. Tendrá una secuencia implícita asociada y, en las filas recién insertadas, la columna tendrá automáticamente los valores de la secuencia que se le haya asignado. Dicha columna es implícitamente `NOT NULL`.
Las cláusulas `ALWAYS` y `BY DEFAULT` determinar cómo se gestionan explícitamente los valores especificados por el usuario en los comandos `INSERT` y `UPDATE`.
En un comando `INSERT`, si se selecciona `ALWAYS`, solo se acepta un valor especificado por el usuario si la instrucción `INSERT` especifica `OVERRIDING SYSTEM VALUE`. Si se selecciona `BY DEFAULT`, prevalece el valor especificado por el usuario.
En un comando `UPDATE`, si se selecciona `ALWAYS`, cualquier actualización de la columna a un valor distinto de `DEFAULT` se rechazará. Si se selecciona `BY DEFAULT`, la columna se puede actualizar de forma normal. (No hay una cláusula `OVERRIDING` para el comando `UPDATE`).
La cláusula *sequence\$1options* se puede utilizar para anular los parámetros de la secuencia. Las opciones disponibles incluyen las que se muestran para [`CREATE SEQUENCE`](create-sequence-syntax-support.md) más `SEQUENCE NAME name`. Sin `SEQUENCE NAME`, el sistema elige un nombre no utilizado para la secuencia.
# `ALTER TABLE`
`ALTER TABLE` cambia la definición de una tabla.
```
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 }
```
## Acciones de la columna de identidad
**`SET GENERATED { ALWAYS | BY DEFAULT }` / `SET sequence_option` / `RESTART`**
Estos formularios cambian si una columna es una columna de identidad o cambian el atributo de generación de una columna de identidad existente. Para obtener más información, consulte [`CREATE TABLE`](create-table-syntax-support.md). Al igual que `SET DEFAULT`, estos formularios solo afectan al comportamiento de los comandos `INSERT` y `UPDATE` posteriores; no provocan cambios en las filas que ya se encuentran en la tabla.
La opción *sequence\$1option* es una opción compatible con [`ALTER SEQUENCE`](alter-sequence-syntax-support.md) como `INCREMENT BY`. Estos formularios modifican la secuencia que subyace a una columna de identidad existente.
**`DROP IDENTITY [ IF EXISTS ]`**
Este formulario elimina la propiedad de identidad de una columna. Si se especifica `DROP IDENTITY IF EXISTS` y la columna no es una columna de identidad, no se genera ningún error. En este caso, se emite un aviso en su lugar.
# `CREATE SEQUENCE`
`CREATE SEQUENCE`: definir un nuevo generador de secuencias.
**importante**
En PostgreSQL, especificar `CACHE` es opcional y el valor predeterminado es 1. En un sistema distribuido como Amazon Aurora DSQL, las operaciones de secuencia implican coordinación, y un tamaño de caché de 1 puede aumentar la sobrecarga de coordinación en condiciones de alta simultaneidad. Si bien los valores de caché más grandes permiten que los números de secuencia se sirvan desde rangos preasignados localmente, lo que mejora el rendimiento, los valores reservados no utilizados pueden perderse, lo que hace que las brechas y los efectos de ordenación sean más visibles. Dado que las aplicaciones difieren en su sensibilidad al orden de asignación frente al rendimiento, Amazon Aurora DSQL requiere que se especifique explícitamente `CACHE` y, actualmente, admite `CACHE = 1` o `CACHE >= 65536`, lo que proporciona una clara distinción entre el comportamiento de asignación más cercano a la generación estrictamente secuencial y la asignación optimizada para cargas de trabajo altamente simultáneas.
Cuando `CACHE >= 65536`, los valores de secuencia siguen garantizando su unicidad, pero es posible que no se generen en estricto orden ascendente entre sesiones, y pueden producirse brechas, especialmente cuando los valores en caché no se consumen por completo. Estas características son coherentes con la semántica de PostgreSQL para secuencias en caché en uso simultáneo, donde ambos sistemas garantizan valores distintos, pero no garantizan un orden estrictamente secuencial entre sesiones.
Dentro de una misma sesión de cliente, es posible que los valores de secuencia no siempre aparezcan en estricto orden ascendente, especialmente fuera de transacciones explícitas. Este comportamiento es similar al de las implementaciones de PostgreSQL que utilizan agrupación de conexiones. Se puede lograr un comportamiento de asignación más cercano al de un entorno PostgreSQL de sesión única utilizando `CACHE = 1` u obteniendo valores de secuencia dentro de transacciones explícitas.
Con `CACHE = 1`, la asignación de secuencias sigue el comportamiento de secuencias no en caché de PostgreSQL.
Para obtener orientación sobre cómo utilizar mejor las secuencias basadas en patrones de carga de trabajo, consulte [Trabajar con secuencias y columnas de identidad](sequences-identity-columns-working-with.md).
## Sintaxis admitida
```
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
```
## Descripción
`CREATE SEQUENCE` crea un nuevo generador de números de secuencia. Esto implica crear e inicializar una nueva tabla especial de una sola fila con el nombre *name*. El generador será propiedad del usuario que emita el comando.
Si se proporciona un nombre de esquema, la secuencia se crea en el esquema especificado. En caso contrario, se crea en el esquema actual. El nombre de la secuencia debe ser distinto del nombre de cualquier otra relación (tabla, secuencia, índice, vista, vista materializada o tabla externa) en el mismo esquema.
Una vez creada una secuencia, se utilizan las funciones `nextval` `currval` y `setval` para operar en la secuencia. Estas funciones están documentadas en [Funciones de manipulación de secuencias](sequence-functions-syntax-support.md).
Aunque no puede actualizar una secuencia directamente, puede utilizar una consulta como:
```
SELECT * FROM name;
```
para examinar algunos de los parámetros y el estado actual de una secuencia. En particular, el campo `last_value` de la secuencia muestra el último valor asignado por cualquier sesión. (Por supuesto, este valor podría estar obsoleto en el momento de su impresión, si otras sesiones están realizando llamadas de `nextval` de forma activa). En la vista `pg_sequences` se pueden observar otros parámetros, como *increment* y *maxvalue*.
## Parameters
**`IF NOT EXISTS`**
No se genera un error si ya existe una relación con el mismo nombre. En este caso, se emite un aviso. Tenga en cuenta que no hay garantía de que la relación existente sea similar a la secuencia que se habría creado; es posible que ni siquiera sea una secuencia.
***name***
El nombre (opcionalmente calificado por el esquema) de la secuencia que se va a crear.
***data\$1type***
La cláusula opcional `AS data_type` especifica el tipo de datos de la secuencia. Los valores válidos son `bigint`. `bigint` es el valor predeterminado. El tipo de datos determina los valores mínimo y máximo predeterminados de la secuencia.
***incremento***
La cláusula opcional `INCREMENT BY increment` especifica qué valor se añade al valor de secuencia actual para crear un valor nuevo. Un valor positivo formará una secuencia ascendente y uno negativo una secuencia descendente. El valor predeterminado es 1.
***minvalue* / `NO MINVALUE`**
La cláusula opcional `MINVALUE minvalue` determina el valor mínimo que puede generar una secuencia. Si esta cláusula no se proporciona o se especifica `NO MINVALUE`, se utilizarán los valores predeterminados. El valor predeterminado para una secuencia ascendente es 1. El valor predeterminado para una secuencia descendente es el valor mínimo del tipo de datos.
***maxvalue* / `NO MAXVALUE`**
La cláusula opcional `MAXVALUE maxvalue` determina el valor máximo para la secuencia. Si esta cláusula no se proporciona o se especifica `NO MAXVALUE`, se utilizarán los valores predeterminados. El valor predeterminado para una secuencia ascendente es el valor máximo del tipo de datos. El valor predeterminado para una secuencia descendente es -1.
**`CYCLE` / `NO CYCLE`**
La opción `CYCLE` permite que la secuencia se repita cuando los valores *maxvalue* o *minvalue* se han alcanzado mediante una secuencia ascendente o descendente, respectivamente. Si se alcanza el límite, el siguiente número generado será el valor *minvalue* o *maxvalue*, respectivamente.
Si `NO CYCLE` se especifica, cualquier llamada realizada a `nextval` después de que la secuencia haya alcanzado su valor máximo devolverá un error. Si `CYCLE` o `NO CYCLE` no se especifican, `NO CYCLE` es el valor predeterminado.
***iniciar***
La cláusula opcional `START WITH start` permite que la secuencia comience en cualquier lugar. El valor inicial predeterminado es *minvalue* para las secuencias ascendentes y *maxvalue* para las descendentes.
***cache***
La cláusula `CACHE cache` especifica cuántos números de secuencia se deben preasignar y almacenar en la memoria para un acceso más rápido. Los valores aceptables para `CACHE` en Aurora DSQL son 1 o cualquier número >= 65536. El valor mínimo es 1 (solo se puede generar un valor a la vez, lo que significa que no caché).
**`OWNED BY table_name.column_name` / `OWNED BY NONE`**
La opción `OWNED BY` hace que la secuencia se asocie a una columna de tabla específica, de modo que si se elimina esa columna (o su tabla completa), la secuencia también se eliminará automáticamente. La tabla especificada debe tener el mismo propietario y estar en el mismo esquema que la secuencia `OWNED BY NONE`, el valor predeterminado, especifica que no existe tal asociación.
## Notas
Use [`DROP SEQUENCE`](drop-sequence-syntax-support.md) para eliminar una secuencia.
Las secuencias se basan en la aritmética `bigint`, por lo que el rango no puede superar el rango de un entero de ocho bytes (-9223372036854775808 a 9223372036854775807).
Dado que las llamadas de `nextval` y `setval` nunca se revierten, los objetos de secuencia no se pueden utilizar si se necesita una asignación “sin brechas” de números de secuencia.
Cada sesión asignará y almacenará en caché valores de secuencia sucesivos durante un acceso al objeto de secuencia y aumentará el `last_value` del objeto de secuencia en consecuencia. A continuación, los siguientes usos de `nextval` en la *caché*-1 dentro de esa sesión simplemente devuelven los valores preasignados sin tocar el objeto de secuencia. De este modo, cualquier número asignado pero no utilizado dentro de una sesión se perderá cuando esta finalice, lo que provocará “huecos” en la secuencia.
Además, aunque se garantiza que las sesiones múltiples asignarán valores de secuencia distintos, los valores podrían generarse fuera de secuencia cuando se tienen en cuenta todas las sesiones. Por ejemplo, con una configuración de *caché* de 10, la sesión A podría reservar los valores 1..10 y devolver `nextval`=1; a continuación, la sesión B podría reservar los valores 11..20 y devolver `nextval`=11 antes de que la sesión A genere `nextval`=2. Por lo tanto, con una configuración de *caché* de uno, es seguro suponer que los valores `nextval` se generan de forma secuencial; con una configuración de *caché* superior a uno, solo se debe suponer que los valores `nextval` son todos distintos, no que se generan de forma puramente secuencial. Además, `last_value` reflejará el último valor reservado por cualquier sesión, independientemente de si `nextval` ya lo ha devuelto.
Otra consideración es que un `setval` ejecutado en dicha secuencia no será detectado por otras sesiones hasta que hayan agotado los valores preasignados que tienen almacenados en caché.
## Ejemplos
Cree una secuencia ascendente llamada de `serial`, empezando por 101:
```
CREATE SEQUENCE serial CACHE 65536 START 101;
```
Seleccione el siguiente número de esta secuencia:
```
SELECT nextval('serial');
nextval
---------
101
```
Seleccione el siguiente número de esta secuencia:
```
SELECT nextval('serial');
nextval
---------
102
```
Utilice esta secuencia en un comando `INSERT`:
```
INSERT INTO distributors VALUES (nextval('serial'), 'nothing');
```
Restablezca la secuencia a un valor específico usando `setval`:
```
SELECT setval('serial', 200);
SELECT nextval('serial');
nextval
---------
201
```
## Compatibilidad
`CREATE SEQUENCE` cumple con el estándar SQL con las siguientes excepciones:
+ La obtención del siguiente valor se realiza mediante la función `nextval()` en lugar de la expresión `NEXT VALUE FOR` del estándar.
+ La cláusula `OWNED BY` es una extensión de PostgreSQL.
# `ALTER SEQUENCE`
`ALTER SEQUENCE`: cambiar la definición de un generador de secuencias.
**importante**
Al utilizar secuencias, se debe tener muy en cuenta el valor de la caché. Para obtener más información, consulte el aviso Importante de la página [`CREATE SEQUENCE`](create-sequence-syntax-support.md).
Para obtener orientación sobre cómo utilizar mejor las secuencias basadas en patrones de carga de trabajo, consulte [Trabajar con secuencias y columnas de identidad](sequences-identity-columns-working-with.md).
## Sintaxis admitida
```
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
```
## Descripción
`ALTER SEQUENCE` cambia los parámetros de un generador de secuencias existente. Todos los parámetros que no estén establecidos específicamente en el comando `ALTER SEQUENCE` conservan su configuración anterior.
Debe ser el propietario de la secuencia para utilizar `ALTER SEQUENCE`. Para modificar el esquema de una secuencia, también debe tener el privilegio `CREATE` en el nuevo esquema. Para modificar el propietario, debe poder utilizar `SET ROLE` en el nuevo rol de propietario y ese rol debe tener el privilegio `CREATE` en el esquema de la secuencia. (Estas restricciones garantizan que modificar el propietario no haga nada que no se pueda hacer eliminando y volviendo a crear la secuencia. Sin embargo, un superusuario puede cambiar la propiedad de cualquier secuencia de todos modos).
## Parameters
***name***
El nombre (opcionalmente calificado por el esquema) de una secuencia que se va a modificar.
**`IF EXISTS`**
No se genera un error si la secuencia no existe. En este caso, se emite un aviso.
***incremento***
La cláusula `INCREMENT BY increment` es opcional. Un valor positivo formará una secuencia ascendente y uno negativo una secuencia descendente. Si no se especifica, se mantendrá el valor de incremento anterior.
***minvalue* / `NO MINVALUE`**
La cláusula opcional `MINVALUE minvalue` determina el valor mínimo que puede generar una secuencia. Si se especifica `NO MINVALUE`, se utilizarán los valores predeterminados de 1 y el valor mínimo del tipo de datos para secuencias ascendentes y descendentes, respectivamente. Si no se especifica ninguna opción, se mantendrá el valor mínimo actual.
***maxvalue* / `NO MAXVALUE`**
La cláusula opcional `MAXVALUE maxvalue` determina el valor máximo para la secuencia. Si se especifica `NO MAXVALUE`, se utilizarán los valores predeterminados del valor máximo del tipo de datos y -1 para secuencias ascendentes y descendentes, respectivamente. Si no se especifica ninguna opción, se mantendrá el valor máximo actual.
**`CYCLE`**
La palabra clave `CYCLE` opcional se puede utilizar para permitir que la secuencia se repita cuando los valores *maxvalue* o *minvalue* se han alcanzado mediante una secuencia ascendente o descendente, respectivamente. Si se alcanza el límite, el siguiente número generado será el valor *minvalue* o *maxvalue*, respectivamente.
**`NO CYCLE`**
Si se especifica la palabra clave `NO CYCLE` opcional, cualquier llamada a `nextval` después de que la secuencia haya alcanzado su máximo valor devolverá un error. Si no se especifica `CYCLE` ni `NO CYCLE`, se mantendrá el comportamiento del ciclo antiguo.
***iniciar***
La cláusula opcional `START WITH start` cambia el valor inicial registrado de la secuencia. Esto no afecta al valor de secuencia actual; simplemente establece el valor que utilizarán los futuros comandos `ALTER SEQUENCE RESTART`.
***restart***
La cláusula opcional `RESTART [ WITH restart ]` cambia el valor actual de la secuencia. Esto es similar a llamar a la función `setval` con `is_called` = `false`: el valor especificado se devolverá en la siguiente llamada de `nextval`. Escribir `RESTART` sin un valor de *reinicio* equivale a proporcionar el valor inicial registrado por `CREATE SEQUENCE` o establecido por última vez por `ALTER SEQUENCE START WITH`.
A diferencia de una llamada de `setval`, una operación `RESTART` en una secuencia es transaccional e impide que las transacciones simultáneas obtengan números de la misma secuencia. Si ese no es el modo de operación deseado, debería usarse `setval`.
***cache***
La cláusula `CACHE cache` permite preasignar números de secuencia y almacenarlos en la memoria para un acceso más rápido. El valor debe ser 1 o algún valor >= 65536. Si no se especifica, se mantendrá el valor de caché antiguo. Para obtener más información sobre el comportamiento de la caché, consulte las instrucciones que se incluyen en [`CREATE SEQUENCE`](create-sequence-syntax-support.md).
**`OWNED BY table_name.column_name` / `OWNED BY NONE`**
La opción `OWNED BY` hace que la secuencia se asocie a una columna de tabla específica, de modo que si se elimina esa columna (o su tabla completa), la secuencia también se eliminará automáticamente. Si se especifica, esta asociación reemplaza cualquier asociación previamente especificada para la secuencia. La tabla especificada debe tener el mismo propietario y estar en el mismo esquema que la secuencia. Especificar `OWNED BY NONE` elimina cualquier asociación existente, haciendo que la secuencia sea “independiente”.
***new\$1owner***
El nombre de usuario del nuevo propietario de la secuencia.
***new\$1name***
El nuevo nombre de la secuencia.
***new\$1schema***
El nuevo esquema de la secuencia.
## Notas
`ALTER SEQUENCE` no afectará inmediatamente a los resultados de `nextval` en los backends, salvo en el actual, que tienen valores de secuencia preasignados (almacenados en caché). Utilizarán todos los valores en caché antes de detectar los parámetros de generación de secuencias modificados. El backend actual se verá afectado de forma inmediata.
`ALTER SEQUENCE` no afecta al estado de `currval` para la secuencia.
`ALTER SEQUENCE` puede provocar otras transacciones a OCC.
Por razones históricas, `ALTER TABLE` también se puede utilizar con secuencias; pero las variantes de `ALTER TABLE` que se permiten con secuencias son solo las equivalentes a las formas mostradas anteriormente.
## Ejemplos
Reinicie una secuencia llamada `serial` en 105:
```
ALTER SEQUENCE serial RESTART WITH 105;
```
## Compatibilidad
`ALTER SEQUENCE` cumple con el estándar SQL, excepto por las cláusulas `AS`, `START WITH`, `OWNED BY`, `OWNER TO`, `RENAME TO` y `SET SCHEMA`, que son extensiones de PostgreSQL.
# `DROP SEQUENCE`
`DROP SEQUENCE`: eliminar una secuencia.
## Sintaxis admitida
```
DROP SEQUENCE [ IF EXISTS ] name [, ...] [ CASCADE | RESTRICT ]
```
## Descripción
`DROP SEQUENCE` elimina los generadores de números de secuencia. Solo su propietario o un superusuario pueden eliminar una secuencia.
## Parameters
**`IF EXISTS`**
No se genera un error si la secuencia no existe. En este caso, se emite un aviso.
***name***
El nombre (opcionalmente calificado por el esquema) de una secuencia.
**`CASCADE`**
Elimine automáticamente los objetos que dependen de la secuencia y, a su vez, todos los objetos que dependen de esos objetos.
**`RESTRICT`**
Rechace eliminar la secuencia si hay objetos que dependen de ella. Esta es la opción predeterminada.
## Ejemplos
Para eliminar la secuencia `seq`:
```
DROP SEQUENCE seq;
```
## Compatibilidad
`DROP SEQUENCE` cumple con el estándar SQL, excepto que el estándar solo permite eliminar una secuencia por comando, y aparte de la opción `IF EXISTS`, que es una extensión de PostgreSQL.
# `CREATE VIEW`
`CREATE VIEW` define una nueva vista persistente. Aurora DSQL no admite vistas temporales; solo admite vistas permanentes.
## Sintaxis admitida
```
CREATE [ OR REPLACE ] [ RECURSIVE ] VIEW name [ ( column_name [, ...] ) ]
[ WITH ( view_option_name [= view_option_value] [, ... ] ) ]
AS query
[ WITH [ CASCADED | LOCAL ] CHECK OPTION ]
```
## Descripción
`CREATE VIEW` define una vista de una consulta. La vista no está materializada físicamente. En su lugar, la consulta se ejecuta cada vez que se hace referencia a la vista en una consulta.
`CREATE or REPLACE VIEW` es similar, pero, si ya existe una vista con el mismo nombre, se reemplaza. La nueva consulta debe generar las mismas columnas que generó la consulta de la vista existente (es decir, los mismos nombres de columna en el mismo orden y con los mismos tipos de datos), pero puede agregar columnas adicionales al final de la lista. Los cálculos que dan lugar a las columnas de salida pueden ser diferentes.
Si se indica un nombre de esquema, como `CREATE VIEW myschema.myview ...`), la vista se crea en el esquema especificado. En caso contrario, se crea en el esquema actual.
El nombre de la vista debe ser distinto del nombre de cualquier otra relación (tabla, índice o vista) en el mismo esquema.
## Parameters
`CREATE VIEW` admite varios parámetros para controlar el comportamiento de las vistas actualizables automáticamente.
**`RECURSIVE`**
Crea una vista recursiva. La sintaxis `CREATE RECURSIVE VIEW [ schema . ] view_name (column_names) AS SELECT ...;` es equivalente a `CREATE VIEW [ schema . ] view_name AS WITH RECURSIVE view_name (column_names) AS (SELECT ...) SELECT column_names FROM view_name;`.
Para una vista recursiva, debe especificarse una lista de nombres de columna de vista.
**`name`**
El nombre de la vista que se va a crear, que puede estar opcionalmente cualificado por el esquema. Para una vista recursiva, debe especificarse una lista de nombres de columna.
**`column_name`**
Una lista opcional de nombres que se utilizarán para las columnas de la vista. Si no se indican, los nombres de columna se deducen de la consulta.
**`WITH ( view_option_name [= view_option_value] [, ... ] )`**
Esta cláusula especifica parámetros opcionales para una vista; se admiten los siguientes parámetros.
+ `check_option (enum)`: este parámetro puede ser `local` o `cascaded`, y equivale a especificar `WITH [ CASCADED | LOCAL ] CHECK OPTION`.
+ `security_barrier (boolean)`: se debe utilizar si se pretende que la vista proporcione seguridad en la fila. Aurora DSQL no admite actualmente la seguridad a nivel de fila, pero esta opción aún forzará a que las condiciones `WHERE` de la vista (y cualquier condición que utilice operadores marcados como `LEAKPROOF`) se evalúen primero.
+ `security_invoker (boolean)`: esta opción hace que las relaciones base subyacentes se comprueben con los privilegios del usuario de la vista en lugar del propietario de la vista. Consulte las notas siguientes para obtener todos los detalles.
Todas las opciones anteriores pueden modificarse en las vistas existentes mediante `ALTER VIEW`.
**`query`**
Un comando `SELECT` o `VALUES` que proporcionará las columnas y filas de la vista.
**`WITH [ CASCADED | LOCAL ] CHECK OPTION`**
Esta opción controla el comportamiento de las vistas actualizables automáticamente. Cuando se especifica esta opción, los comandos `INSERT` y `UPDATE` de la vista se comprobarán para asegurarse de que las nuevas filas satisfacen la condición que define la vista (es decir, se comprueba que las nuevas filas son visibles a través de la vista). Si no lo son, se rechazará la actualización. Si no se especifica `CHECK OPTION`, se permite que los comandos `INSERT` y `UPDATE` en la vista creen filas que no son visibles a través de la vista.
`LOCAL`: las nuevas filas solo se comprueban con las condiciones definidas directamente en la propia vista. Las condiciones definidas en las vistas base subyacentes no se comprueban (a menos que también especifiquen `CHECK OPTION`).
`CASCADED`: las filas nuevas se comprueban con las condiciones de la vista y de todas las vistas base subyacentes. Si se especifica `CHECK OPTION` y no se especifican `LOCAL` ni `CASCADED`, entonces se supone `CASCADED`.
`CHECK OPTION` no se puede usar con vistas `RECURSIVE`. `CHECK OPTION` solo se admite en las vistas que se actualizan automáticamente.
## Notas
Utilice la instrucción `DROP VIEW` para descartar vistas.
Los nombres y tipos de datos de las columnas de la vista deben considerarse cuidadosamente. Por ejemplo, no se recomienda CREATE VIEW vista AS SELECT 'Hello World'; ya que el nombre de la columna está predeterminado como `?column?;`. Además, el tipo de datos de la columna es `text` de forma predeterminada, que puede no ser lo que se deseaba.
Un enfoque mejor es especificar explícitamente el nombre de la columna y el tipo de datos, como por ejemplo: `CREATE VIEW vista AS SELECT text 'Hello World' AS hello;`.
De forma predeterminada, el acceso a las relaciones base subyacentes a las que se hace referencia en la vista viene determinado por los permisos del propietario de la vista. En algunos casos, esto puede utilizarse para proporcionar un acceso seguro pero restringido a las tablas subyacentes. No obstante, no todas las vistas están protegidas contra la manipulación.
+ Si la vista tiene la propiedad `security_invoker` establecida en true, el acceso a las relaciones base subyacentes viene determinado por los permisos del usuario que ejecuta la consulta, en lugar de por el propietario de la vista. Así, el usuario de una vista de invocación de seguridad debe tener los permisos pertinentes en la vista y las relaciones base subyacentes.
+ Si alguna de las relaciones base subyacentes es una vista de invocación de seguridad, se tratará como si se hubiera accedido a ella directamente desde la consulta original. Así, una vista de invocación de seguridad siempre comprobará las relaciones base subyacentes mediante los permisos del usuario actual, incluso si se accede a ella desde una vista sin la propiedad `security_invoker`.
+ Las funciones a las que se llama en la vista se tratan igual que si se hubieran llamado directamente desde la consulta que utiliza la vista. Por lo tanto, el usuario de una vista debe tener permisos para llamar a todas las funciones que utiliza la vista. Las funciones en la vista se ejecutan con los privilegios del usuario que ejecuta la consulta o del propietario de la función, dependiendo de si las funciones están definidas como `SECURITY INVOKER` o `SECURITY DEFINER`.
+ El usuario que crea o reemplaza una vista debe tener privilegios `USAGE` en cualquier esquema al que se haga referencia en la consulta de la vista, para poder buscar los objetos a los que se hace referencia en esos esquemas.
+ Cuando se utiliza `CREATE OR REPLACE VIEW` en una vista existente, solo se modifica la regla `SELECT` de definición de la vista, además de cualquier parámetro `WITH ( ... )` y `CHECK OPTION`. Las demás propiedades de la vista, incluidas la propiedad, los permisos y las reglas no SELECT, permanecen sin alterarse. Debe tener la propiedad de la vista para reemplazarla (esto incluye ser miembro del rol de propietario).
## Vistas actualizables
Las vistas simples son actualizables automáticamente: el sistema permitirá que se utilicen las instrucciones `INSERT`, `UPDATE` y `DELETE` en la vista del mismo modo que en una tabla normal. Una vista es actualizable automáticamente si cumple todas las condiciones siguientes:
+ La vista debe tener exactamente una entrada en la lista `FROM`, que debe ser una tabla u otra vista actualizable.
+ La definición de la vista no debe contener las cláusulas `WITH`, `DISTINCT`, `GROUP BY`, `HAVING`, `LIMIT` o `OFFSET` en el nivel superior.
+ La definición de la vista no debe contener operaciones de conjunto (`UNION`, `INTERSECT` o `EXCEPT`) en el nivel superior.
+ La lista de selección de la vista no debe contener agregados, funciones de ventana ni funciones que devuelvan conjuntos.
Una vista actualizable automáticamente puede contener una mezcla de columnas actualizables y no actualizables. Una columna es actualizable si es una simple referencia a una columna actualizable de la relación base subyacente. En caso contrario, la columna es de solo lectura y se produce un error si una instrucción `INSERT` o `UPDATE` intenta asignarle un valor.
Una vista más compleja que no satisfaga todas estas condiciones es de solo lectura de forma predeterminada: el sistema no permite una inserción, actualización o eliminación en la vista.
**nota**
El usuario que realiza la inserción, actualización o eliminación en la vista debe tener el correspondiente privilegio de inserción, actualización o eliminación en la vista. De forma predeterminada, el propietario de la vista debe tener los privilegios correspondientes en las relaciones base subyacentes, mientras que el usuario que realiza la actualización no necesita ningún permiso en las relaciones base subyacentes. No obstante, si la vista tiene security\$1invoker establecido en true, el usuario que realiza la actualización, en lugar del propietario de la vista, debe tener los privilegios pertinentes en las relaciones base subyacentes.
## Ejemplos
Crear una vista compuesta por todas las películas de comedia.
```
CREATE VIEW comedies AS
SELECT *
FROM films
WHERE kind = 'Comedy';
```
Cree una vista con `LOCAL CHECK OPTION`.
```
CREATE VIEW pg_comedies AS
SELECT *
FROM comedies
WHERE classification = 'PG'
WITH CASCADED CHECK OPTION;
```
Cree una vista recursiva.
```
CREATE RECURSIVE VIEW public.nums_1_100 (n) AS
VALUES (1)
UNION ALL
SELECT n+1 FROM nums_1_100 WHERE n < 100;
```
## Compatibilidad
`CREATE OR REPLACE VIEW` es una extensión del lenguaje PostgreSQL. La cláusula `WITH ( ... )` también es una extensión, al igual que las vistas de barrera de seguridad y las vistas de invocación de seguridad. Aurora DSQL admite estas extensiones de lenguaje.
# `ALTER VIEW`
La instrucción `ALTER VIEW` permite cambiar varias propiedades de una vista existente y Aurora DSQL soporta toda la sintaxis de PostgreSQL para este comando.
## Sintaxis admitida
```
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 [, ... ] )
```
## Descripción
`ALTER VIEW` modifica varias propiedades auxiliares de una vista. (Si desea modificar la consulta que define la vista, utilice `CREATE OR REPLACE VIEW`). Para usar`ALTER VIEW`, debe ser propietario de la vista. Para modificar el esquema de una vista, también debe tener el privilegio `CREATE` en el nuevo esquema. Para modificar el propietario, debe poder utilizar `SET ROLE` en el nuevo rol de propietario y ese rol debe tener el privilegio `CREATE` en el esquema de la vista.
## Parameters
**`name`**
El nombre (opcionalmente cualificado por el esquema) de una vista existente.
**`column_name`**
Nombre de una columna existente o nombre nuevo para una columna existente.
**`IF EXISTS`**
No genere un error si la vista no existe. En este caso, se emite un aviso.
**`SET/DROP DEFAULT`**
Estas formas establecen o eliminan el valor predeterminado de una columna. El valor predeterminado para una columna de una vista se sustituye en cualquier comando `INSERT` o `UPDATE` donde el objetivo sea la vista.
**`new_owner`**
El nombre de usuario del nuevo propietario de la vista.
**`new_name`**
El nuevo nombre de la vista.
**`new_schema`**
El nuevo esquema de la vista.
**`SET ( view_option_name [= view_option_value] [, ... ] )`**
Establece una opción de vista. Las siguientes son las opciones admitidas:
+ `check_option (enum)`: cambia la opción de comprobación de la vista. El valor debe ser `local` o `cascaded`.
+ `security_barrier (boolean)`: cambia la propiedad de barrera de seguridad de la vista.
+ `security_invoker (boolean)`: cambia la propiedad de invocador de seguridad de la vista.
**`RESET ( view_option_name [, ... ] )`**
Restablece una opción de vista a su valor predeterminado.
## Ejemplos
Cambiar el nombre de la vista `foo` a `bar`:
```
ALTER VIEW foo RENAME TO bar;
```
Asociar un valor de columna predeterminado a una vista actualizable:
```
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
```
## Compatibilidad
`ALTER VIEW` es una extensión de PostgreSQL del estándar SQL que Aurora DSQL admite.
# `DROP VIEW`
La instrucción `DROP VIEW` elimina una vista existente. Aurora DSQL admite la sintaxis de PostgreSQL completa para este comando.
## Sintaxis admitida
```
DROP VIEW [ IF EXISTS ] name [, ...] [ CASCADE | RESTRICT ]
```
## Descripción
`DROP VIEW` descarta una vista existente. Para ejecutar este comando, debe ser el propietario de la vista.
## Parameters
**`IF EXISTS`**
No genere un error si la vista no existe. En este caso, se emite un aviso.
**`name`**
El nombre (opcionalmente cualificado por el esquema) de la vista que se eliminará.
**`CASCADE`**
Eliminar automáticamente los objetos que dependan de la vista (como otras vistas) y, a su vez, todos los objetos que dependan de esos objetos.
**`RESTRICT`**
Rechazar el descarte de la vista si algún objeto depende de ella. Esta es la opción predeterminada.
## Ejemplos
```
DROP VIEW kinds;
```
## Compatibilidad
Este comando se ajusta al estándar SQL, excepto que el estándar solo permite descartar una vista por comando y, aparte de la opción `IF EXISTS`, que es una extensión de PostgreSQL que Aurora DSQL admite.
# Migración de PostgreSQL a Aurora DSQL
Aurora DSQL se ha diseñado para ser [compatible con PostgreSQL](working-with-postgresql-compatibility.md) y admite características relacionales básicas como las transacciones ACID, los índices secundarios, las uniones y las operaciones DML estándar. La mayoría de las aplicaciones PostgreSQL existentes pueden migrar a Aurora DSQL con cambios mínimos.
En esta sección se proporcionan orientaciones prácticas para migrar la aplicación a Aurora DSQL, incluidos la compatibilidad con marcos, los patrones de migración y consideraciones de la arquitectura.
## Compatibilidad con marcos y ORM
Aurora DSQL usa el protocolo de conexión estándar de PostgreSQL, lo que garantiza la compatibilidad con controladores y marcos de PostgreSQL. Las asignaciones relacionales de objetos (ORM) más populares funcionan con Aurora DSQL con cambios mínimos o sin cambios. Consulte [Adaptadores y dialectos de Aurora DSQL](aws-sdks.md#aurora-dsql-adapters) para ver implementaciones de referencia e integraciones de ORM disponibles.
## Patrones de migración comunes
Al migrar de PostgreSQL a Aurora DSQL, algunas características funcionan de forma diferente o tienen una sintaxis alternativa. En esta sección se proporciona orientación sobre escenarios de migración comunes.
### Alternativas a las operaciones DDL
Aurora DSQL ofrece alternativas modernas a las operaciones de lenguaje de definición de datos (DDL) tradicionales de PostgreSQL:
**Creación de índices**
Utilice `CREATE INDEX ASYNC` en lugar de `CREATE INDEX` para la creación de índices sin bloqueo.
**Ventaja:** Creación de índices sin tiempo de inactividad en tablas grandes.
**Eliminación de datos**
Use `DELETE FROM table_name` en lugar de `TRUNCATE`.
**Alternativa:** Para una recreación completa de las tablas, utilice `DROP TABLE` y, a continuación, `CREATE TABLE`.
**Configuración del sistema**
Aurora DSQL está totalmente administrado, por lo que la configuración se gestiona automáticamente en función de los patrones de carga de trabajo. Use la consola de administración de AWS o la API para administrar la configuración del clúster.
**Ventaja:** No es necesario ajustar la base de datos ni administrar los parámetros.
### Patrones de diseño de esquema
Adapte estos patrones comunes de PostgreSQL para que sean compatibles con Aurora DSQL:
**Patrones de integridad referencial**
Aurora DSQL admite relaciones de tabla y operaciones de `JOIN`. Para garantizar la integridad referencial, implemente la validación en la capa de aplicación. Este diseño se ajusta a los patrones modernos de bases de datos distribuidas, en los que la validación de la capa de aplicaciones proporciona más flexibilidad y evita cuellos de botella en el rendimiento derivados de las operaciones en cascada.
**Patrón:** Implemente comprobaciones de integridad referencial en la capa de aplicaciones mediante convenciones de nomenclatura, lógica de validación y límites de transacción coherentes. Muchas aplicaciones a gran escala prefieren este enfoque para controlar mejor la gestión de errores y el rendimiento.
**Gestión de datos temporales**
Utilice CTE, subconsultas o tablas normales con lógica de limpieza en lugar de tablas temporales.
**Alternativa:** Cree tablas con nombres específicos de cada sesión y límpielas en su aplicación.
## Descripción de las diferencias arquitectónicas
La arquitectura distribuida y sin servidor de Aurora DSQL se diferencia de manera intencionada de PostgreSQL tradicional en varias áreas. Estas diferencias hacen posibles los beneficios clave de simplicidad y escala de Aurora DSQL.
### Modelo simplificado de la base de datos
**Base de datos única por clúster**
Aurora DSQL proporciona una base de datos integrada denominada `postgres` por clúster.
**Consejo de migración:** Si la aplicación utiliza varias bases de datos, cree clústeres de Aurora DSQL independientes para una separación lógica o utilice esquemas dentro de un único clúster.
**Ausencia de tablas temporales**
Para la gestión temporal de datos, DEBERÍA utilizar expresiones de tabla comunes (CTE) y subconsultas, que ofrecen alternativas flexibles para consultas complejas.
**Alternativa:** Utilice CTE con cláusulas `WITH` para conjuntos de resultados temporales o tablas normales con nombres únicos para datos específicos de la sesión.
**Administración de almacenamiento automática**
Aurora DSQL elimina los espacios de tabla y la administración de almacenamiento manual. El almacenamiento se escala y se optimiza automáticamente en función de sus patrones de datos.
**Ventaja:** No es necesario supervisar el espacio en disco, planificar la asignación de almacenamiento ni administrar las configuraciones de los espacios de tabla.
### Patrones de aplicación modernos
Aurora DSQL fomenta los patrones de desarrollo de aplicaciones modernos que mejoran la capacidad de mantenimiento y el rendimiento:
**Lógica de nivel de aplicación en lugar de desencadenadores de bases de datos**
Para obtener una funcionalidad similar a la de un activador, implemente una lógica basada en eventos en la capa de aplicación.
**Estrategia de migración:** Traslade la lógica de los desencadenadores al código de la aplicación, utilice arquitecturas basadas en eventos con servicios de AWS como EventBridge o implemente registros de auditoría mediante el registro de aplicaciones.
**Funciones SQL para el procesamiento de datos**
Aurora DSQL admite funciones basadas en SQL, pero no lenguajes procedurales como PL/pgSQL.
**Alternativa:** Utilice funciones SQL para las transformaciones de datos o traslade la lógica compleja a la capa de aplicación o a funciones de AWS Lambda.
**Control de simultaneidad optimista en lugar de bloqueo pesimista**
Aurora DSQL utiliza el control de simultaneidad optimista (OCC), un enfoque sin bloqueos diferente a los mecanismos de bloqueo de bases de datos tradicionales. En lugar de adquirir bloqueos que afecten a otras transacciones, Aurora DSQL permite que las transacciones continúen sin bloquearse y detecta los conflictos en el momento de la confirmación. De este modo, se eliminan los interbloqueos y se impide que las transacciones lentas bloqueen otras operaciones.
**Diferencia clave:** Cuando se producen conflictos, Aurora DSQL devuelve un error de serialización en lugar de hacer que las transacciones esperen bloqueos. Esto requiere que las aplicaciones implementen una lógica de reintento, similar a la gestión de tiempos de espera de bloqueo en las bases de datos tradicionales, pero los conflictos se resuelven de forma inmediata en lugar de provocar esperas de bloqueo.
**Patrón de diseño:** Implemente lógica de transacción idempotente con mecanismos de reintento. Diseñe esquemas para minimizar la contención mediante claves principales aleatorias y la distribución de actualizaciones en todo su intervalo de claves. Para obtener más información, consulte [Control de simultaneidad en Aurora DSQL](working-with-concurrency-control.md).
**Relaciones e integridad referencial**
Aurora DSQL admite relaciones de claves externas entre tablas, incluidas las operaciones ` JOIN `. Para garantizar la integridad referencial, implemente la validación en la capa de aplicación. Si bien aplicar la integridad referencial puede resultar útil, las operaciones en cascada (como las eliminaciones en cascada) pueden provocar problemas de rendimiento inesperados; por ejemplo, eliminar un pedido con mil partidas se convierte en una transacción de mil y una filas. Por este motivo, muchos clientes evitan las restricciones de clave externa.
**Patrón de diseño:** Implemente comprobaciones de integridad referencial en la capa de aplicaciones, utilice patrones de coherencia final o aproveche los servicios de AWS para la validación de datos.
### Simplificaciones operativas
Aurora DSQL elimina muchas de las tareas tradicionales de mantenimiento de bases de datos, lo que reduce la sobrecarga operativa:
**No se requiere mantenimiento manual**
Aurora DSQL administra automáticamente la optimización del almacenamiento, la recopilación de estadísticas y el ajuste del rendimiento. Los comandos de mantenimiento tradicionales como `VACUUM` son gestionados por el sistema.
**Ventaja:** Elimina la necesidad de ventanas de mantenimiento de base de datos, la programación del vaciado y la afinación de los parámetros del sistema.
**Particionamiento y escalado automáticos**
Aurora DSQL particiona y distribuye sus datos de forma automática en función de los patrones de acceso. Utilice UUID o ID generados por la aplicación para una distribución óptima.
**Consejo de migración:** Elimine la lógica de particionamiento manual y deje que Aurora DSQL se encargue de la distribución de datos. Utilice UUID o ID generados por la aplicación para una distribución óptima. Si su aplicación requiere identificadores secuenciales, consulte [Secuencias y columnas de identidad](sequences-identity-columns.md).
# Migración agéntica con herramientas de IA
Los agentes de codificación de IA pueden acelerar su migración a Aurora DSQL mediante el análisis de esquemas, la transformación de código y la ejecución de migraciones DDL con comprobaciones de seguridad integradas.
## Uso de Kiro para la migración
Los agentes de codificación como [Kiro](https://kiro.dev/) pueden ayudarle a analizar y migrar su código PostgreSQL a Aurora DSQL:
+ **Análisis del esquema:** Cargue sus archivos de esquema existentes y pida a Kiro que identifique los posibles problemas de compatibilidad y que sugiera alternativas
+ **Transformación de código:** Proporcione el código de su aplicación y pida a Kiro que ayude a refactorizar la lógica de desencadenador, reemplazar secuencias con UUID o modificar patrones de transacción
+ **Planificación de la migración:** Pida a Kiro que cree un plan de migración paso a paso basado en la arquitectura específica de su aplicación
+ **Migraciones DDL:** ejecute modificaciones del esquema utilizando el patrón de recreación de tablas con comprobaciones de seguridad integradas y verificación de usuarios.
**Ejemplos de peticiones:**
```
"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"
```
## Migración DDL con recreación de tablas.
Al utilizar agentes de IA con el servidor MCP de Aurora DSQL, ciertas operaciones ALTER TABLE utilizan un *patrón de recreación de tablas* que migra sus datos de forma segura. El agente gestiona la complejidad y, al mismo tiempo, le mantiene informado en cada paso.
Las siguientes operaciones utilizan el patrón de recreación de tablas:
| Operación | Enfoque |
| --- | --- |
| DROP COLUMN | Excluir columna de la nueva tabla |
| ALTER COLUMN TYPE | Tipo de datos de conversión durante la migración |
| ALTER COLUMN SET/DROP NOT NULL | Cambiar restricción en la definición de la nueva tabla |
| ALTER COLUMN SET/DROP DEFAULT | Definir el valor predeterminado en la definición de la nueva tabla |
| ADD/DROP CONSTRAINT | Incluir o eliminar una restricción en la nueva tabla |
| MODIFY PRIMARY KEY | Definir una nueva clave principal con validación de unicidad |
| Dividir/fusionar columnas | Usar SPLIT\$1PART, SUBSTRING o CONCAT |
Las siguientes operaciones ALTER TABLE se admiten directamente sin necesidad de recrear la tabla:
+ `ALTER TABLE ... RENAME COLUMN`: cambiar el nombre de una columna
+ `ALTER TABLE ... RENAME TO`: cambiar el nombre de una tabla
+ `ALTER TABLE ... ADD COLUMN`: añadir una nueva columna
**Características de seguridad:** al ejecutar migraciones DDL, los agentes de IA presentan el plan de migración, verifican la compatibilidad de los datos, confirman el recuento de filas y solicitan una aprobación explícita antes de realizar cualquier operación destructiva, como DROP TABLE.
**Migraciones por lotes:** para tablas que superan las 3000 filas, el agente divide automáticamente la migración en lotes de entre 500 y 1000 filas para mantenerse dentro de los límites de transacción.
## Servidor MCP de Aurora DSQL
El servidor de protocolo de contexto para modelos (MCP) de Aurora DSQL permite a los asistentes de IA conectarse directamente a su clúster de Aurora DSQL y consultar la documentación de Aurora DSQL. Esto permite a la IA:
+ Analizar el esquema existente y sugerir cambios de migración
+ Ejecutar migraciones DDL con el patrón de recreación de tablas
+ Probar consultas y comprobar la compatibilidad durante la migración
+ Proporcionar directrices precisas y actualizadas basadas en la documentación más reciente de Aurora DSQL
Para utilizar el servidor MCP de Aurora DSQL con asistentes de IA, consulte las instrucciones de configuración para el [servidor MCP de Aurora DSQL](SECTION_aurora-dsql-mcp-server.md).
## Consideraciones de Aurora DSQL para la compatibilidad de PostgreSQL
Aurora DSQL presenta diferencias en la compatibilidad de las características con respecto a la instancia de PostgreSQL autoadministrada, las cuales permiten su arquitectura distribuida, funcionamiento sin servidor y escalado automático. La mayoría de las aplicaciones funcionan dentro de estas diferencias sin hacer ninguna modificación.
Para obtener información general, consulte [Consideraciones para trabajar con Amazon Aurora DSQL](considerations.md). Para obtener información acerca de las cuotas y los límites, consulte [Cuotas de clúster y límites de base de datos en Amazon Aurora DSQL](CHAP_quotas.md).
+ Aurora DSQL utiliza una única base de datos integrada denominada `postgres` por clúster. Para una separación lógica, cree clústeres de Aurora DSQL independientes o utilice esquemas dentro de un único clúster.
+ La base de datos `postgres` utiliza la codificación de caracteres UTF-8, que ofrece una amplia compatibilidad con caracteres internacionales.
+ La base de datos usa solo la intercalación de `C`.
+ Aurora DSQL utiliza `UTC` como la zona horaria del sistema. Postgres almacena internamente todas las fechas y horas que tienen en cuenta las zonas horarias en UTC. Puede configurar el parámetro de configuración `TimeZone` para convertir la forma en que se muestra en el cliente y que sirva como valor predeterminado para las entradas del cliente que el servidor utilizará para convertir internamente a UTC.
+ El nivel de aislamiento de las transacciones se fija en PostgreSQL `Repeatable Read`.
+ Las transacciones tienen las siguientes restricciones:
+ Las operaciones DDL y DML requieren transacciones separadas.
+ Una transacción solo puede incluir 1 instrucción DDL
+ Una transacción puede modificar hasta 3000 filas, independientemente del número de índices secundarios
+ El límite de 3000 filas se aplica a todas las instrucciones DML (`INSERT`, `UPDATE`, `DELETE`)
+ Las conexiones a la base de datos caducan después de 1 hora.
+ Aurora DSQL administra los permisos a través de concesiones a nivel de esquema. Los usuarios administradores crean esquemas utilizando `CREATE SCHEMA` y conceden acceso utilizando `GRANT USAGE ON SCHEMA`. Los usuarios administradores gestionan objetos en el esquema público, mientras que los usuarios no administradores crean objetos en esquemas creados por usuarios para establecer límites claros de propiedad. Para obtener más información, consulte [Autorización de roles de base de datos para utilizar SQL en la base de datos](using-database-and-iam-roles.md#using-database-and-iam-roles-custom-database-roles-sql).
## ¿Necesita ayuda con la migración?
Si encuentra características que son fundamentales para la migración pero que actualmente no son compatibles con Aurora DSQL, consulte [Aportación de comentarios sobre Amazon Aurora DSQL](providing-feedback.md) para obtener información sobre cómo compartir comentarios con AWS.
# Control de simultaneidad en Aurora DSQL
La simultaneidad permite que varias sesiones accedan y modifiquen datos simultáneamente sin poner en riesgo la integridad y la coherencia de los datos. Aurora DSQL proporciona [compatibilidad con PostgreSQL](https://docs.aws.amazon.com/aurora-dsql/latest/userguide/working-with-postgresql-compatibility.html) a la vez que implementa un moderno mecanismo de control de simultaneidad sin bloqueos. Mantiene el pleno cumplimiento de ACID mediante el aislamiento de instantáneas, lo que garantiza la coherencia y la fiabilidad de los datos.
Una ventaja clave de Aurora DSQL es la arquitectura sin bloqueo, que elimina los cuellos de botella habituales en el rendimiento de las bases de datos. Aurora DSQL impide que las transacciones lentas bloqueen otras operaciones y elimina el riesgo de bloqueos. Gracias a este enfoque, Aurora DSQL resulta especialmente valioso para aplicaciones de alto rendimiento en las que el rendimiento y la escalabilidad son fundamentales.
## Conflictos de transacción
Aurora DSQL utiliza el control de simultaneidad optimista (OCC), que funciona de forma diferente a los sistemas tradicionales basados en bloqueos. En lugar de utilizar bloqueos, OCC evalúa los conflictos en el momento de la confirmación. Cuando varias transacciones entran en conflicto al actualizar la misma fila, Aurora DSQL administra las transacciones de la siguiente manera:
+ Aurora DSQL procesa la transacción con el tiempo de confirmación más temprano.
+ Las transacciones en conflicto reciben un error de serialización de PostgreSQL, lo que indica la necesidad de que se vuelvan a intentar.
Diseñe las aplicaciones para implementar la lógica de reintento para gestionar los conflictos. El patrón de diseño ideal es idempotente, lo que habilita el reintento de transacciones como primer recurso siempre que sea posible. La lógica recomendada es similar a la lógica de anular y reintentar en una situación estándar de tiempo de espera de bloqueo o interbloqueo de PostgreSQL. No obstante, OCC requiere que las aplicaciones ejerciten esta lógica con mayor frecuencia.
## Directrices para optimizar el rendimiento de las transacciones
Para optimizar el rendimiento, minimice la alta contención en claves únicas o en intervalos de claves pequeños. Para alcanzar este objetivo, diseñe el esquema de forma que las actualizaciones se repartan por el intervalo de claves del clúster mediante las siguientes directrices:
+ Elija una clave principal aleatoria para las tablas.
+ Evite patrones que aumenten la contención en claves únicas. Este enfoque garantiza un rendimiento óptimo incluso a medida que crezca el volumen de transacciones.
# DDL y las transacciones distribuidas en Aurora DSQL
En Aurora DSQL, el comportamiento del lenguaje de definición de datos (DDL) es distinto al de PostgreSQL. Aurora DSQL presenta una capa de base de datos distribuida y compartida Multi-AZ basada en flotas de computación y almacenamiento de varios inquilinos. Dado que no existe un único nodo principal o líder de base de datos, el catálogo de base de datos está distribuido. Por tanto, Aurora DSQL administra los cambios de esquema DDL como transacciones distribuidas.
En concreto, el comportamiento de DDL en Aurora DSQL es distinto según se indica a continuación:
**Errores de control de simultaneidad**
Aurora DSQL devuelve un error de infracción de control de simultaneidad si ejecuta una transacción mientras otra transacción actualiza un recurso. Por ejemplo, considere la siguiente secuencia de acciones:
1. En la sesión 1, un usuario agrega una columna a la tabla `mytable`.
1. En la sesión 2, un usuario intenta insertar una fila en `mytable`.
Aurora DSQL devuelve el error `SQL Error [40001]: ERROR: schema has been updated by another transaction, please retry: (OC001).`
**DDL y DML en la misma transacción**
Las transacciones en Aurora DSQL pueden contener solo una instrucción DDL y no pueden tener tanto instrucciones DDL como DML. Esta restricción significa que no se puede crear una tabla e insertar datos en la misma tabla dentro de la misma transacción. Por ejemplo, Aurora DSQL admite las siguientes transacciones secuenciales.
```
BEGIN;
CREATE TABLE mytable (ID_col integer);
COMMIT;
BEGIN;
INSERT into FOO VALUES (1);
COMMIT;
```
Aurora DSQL no admite la siguiente transacción, que incluye instrucciones `CREATE` e `INSERT`.
```
BEGIN;
CREATE TABLE FOO (ID_col integer);
INSERT into FOO VALUES (1);
COMMIT;
```
**DDL asíncrono**
En PostgreSQL estándar, operaciones DDL como `CREATE INDEX` bloquean la tabla afectada, por lo que no está disponible para lecturas y escrituras desde otras sesiones. En Aurora DSQL, estas instrucciones DDL se ejecutan de forma asíncrona mediante un administrador en segundo plano. El acceso a la tabla afectada no se bloquea. De este modo, las sentencias DDL en tablas de gran tamaño pueden ejecutarse sin tiempo de inactividad ni impacto en el rendimiento. Para obtener más información sobre el administrador de trabajos asíncronos en Aurora DSQL, consulte [Índices asíncronos en Aurora DSQL](working-with-create-index-async.md).
# Claves principales en Aurora DSQL
En Aurora DSQL, una clave principal es una característica que organiza físicamente los datos de las tablas. Es similar a la operación `CLUSTER` en PostgreSQL o a un índice en clúster en otras bases de datos. Cuando se define una clave principal, Aurora DSQL crea un índice que incluye todas las columnas de la tabla. La estructura de clave principal en Aurora DSQL garantiza que el acceso a los datos y la administración sean eficientes.
## Estructura y almacenamiento de datos
Cuando define una clave principal, Aurora DSQL almacena los datos de la tabla en orden de clave principal. Esta estructura organizada en índices permite que una búsqueda de clave principal recupere todos los valores de las columnas directamente, en lugar de seguir un puntero a los datos como en un índice de árbol B tradicional. A diferencia de la operación `CLUSTER` en PostgreSQL, que reorganiza los datos solo una vez, Aurora DSQL mantiene este orden de forma automática y continua. Este enfoque mejora el rendimiento de las consultas que dependen del acceso a la clave principal.
Aurora DSQL también utiliza la clave principal para generar una clave única en todo el clúster para cada fila en las tablas y los índices. Esta clave única también sustenta la gestión de datos distribuidos. Habilita la partición automática de los datos en varios nodos, lo que permite un almacenamiento escalable y una alta simultaneidad. Como resultado, la estructura de clave principal ayuda a Aurora DSQL a escalar automáticamente y a administrar con eficiencia las cargas de trabajo simultáneas.
## Directrices para elegir una clave principal
Al elegir y utilizar una clave principal en Aurora DSQL, tenga en cuenta las siguientes directrices:
+ Defina una clave principal cuando cree una tabla. No podrá cambiar esta clave ni agregar una nueva clave principal más adelante. La clave principal pasa a formar parte de la clave de todo el clúster utilizada para la partición de datos y el escalado automático del rendimiento de escritura. Si no especifica una clave principal, Aurora DSQL asigna un ID oculto sintético.
+ Para tablas con grandes volúmenes de escritura, evite utilizar números enteros que aumenten de forma monótona como claves principales. Esto puede provocar problemas de rendimiento al dirigir todas las nuevas inserciones a una única partición. En su lugar, utilice claves principales con distribución aleatoria para garantizar una distribución uniforme de las escrituras entre las particiones de almacenamiento.
+ En el caso de las tablas que cambian con poca frecuencia o son de solo lectura, puede utilizar una clave ascendente. Ejemplos de claves ascendentes son las marcas temporales o los números de secuencia. Una clave densa tiene muchos valores poco espaciados o duplicados. Puede utilizar una clave ascendente aunque sea densa porque el rendimiento de escritura es menos crítico.
+ Si un examen completo de la tabla no satisface los requisitos de rendimiento, elija un método de acceso más eficiente. En la mayoría de los casos, esto significa utilizar una clave principal que coincida con la clave de unión y búsqueda más común en las consultas.
+ El tamaño máximo combinado de las columnas de una clave principal es de 1 kibibyte. Para obtener más información, consulte [Límites de base de datos en Aurora DSQL](https://docs.aws.amazon.com/aurora-dsql/latest/userguide/CHAP_quotas.html#SECTION_database-limits) y [Tipos de datos admitidos en Aurora DSQL](https://docs.aws.amazon.com/aurora-dsql/latest/userguide/working-with-postgresql-compatibility-supported-data-types).
+ Puede incluir hasta 8 columnas en una clave principal o un índice secundario. Para obtener más información, consulte [Límites de base de datos en Aurora DSQL](https://docs.aws.amazon.com/aurora-dsql/latest/userguide/CHAP_quotas.html#SECTION_database-limits) y [Tipos de datos admitidos en Aurora DSQL](https://docs.aws.amazon.com/aurora-dsql/latest/userguide/working-with-postgresql-compatibility-supported-data-types).
# Secuencias y columnas de identidad
Las secuencias y las columnas de identidad generan valores enteros y son útiles cuando se necesitan identificadores compactos o legibles por humanos. Estos valores implican el comportamiento de asignación y almacenamiento en caché descrito en la documentación [`CREATE SEQUENCE`](create-sequence-syntax-support.md).
**Topics**
+ [Funciones de manipulación de secuencias](sequence-functions-syntax-support.md)
+ [Columnas de identidad](sequences-identity-columns-overview.md)
+ [Trabajar con secuencias y columnas de identidad](sequences-identity-columns-working-with.md)
# Funciones de manipulación de secuencias
En esta sección se describen las funciones para operar con objetos de secuencia, también denominados generadores de secuencias o simplemente secuencias. Los objetos de secuencia son tablas especiales de una sola fila creadas con [`CREATE SEQUENCE`](create-sequence-syntax-support.md). Los objetos de secuencia se utilizan habitualmente para generar identificadores únicos para las filas de una tabla. Las funciones de secuencia proporcionan métodos sencillos y seguros para varios usuarios que permiten obtener valores de secuencia sucesivos a partir de objetos de secuencia.
**importante**
Al utilizar secuencias, se debe tener muy en cuenta el valor de la caché. Para obtener más información, consulte el aviso Importante de la página [`CREATE SEQUENCE`](create-sequence-syntax-support.md).
Para obtener orientación sobre cómo utilizar mejor las secuencias basadas en patrones de carga de trabajo, consulte [Trabajar con secuencias y columnas de identidad](sequences-identity-columns-working-with.md).
| Función | Descripción |
| --- | --- |
| nextval ( regclass ) → bigint | Hace avanzar el objeto secuencial a su siguiente valor y devuelve ese valor. Esto se hace de forma atómica: incluso si se ejecutan varias sesiones nextval simultáneamente, cada una recibirá de forma segura un valor de secuencia distinto. Si el objeto de secuencia se ha creado con los parámetros predeterminados, las llamadas de nextval sucesivas devolverán valores crecientes que comiencen por 1. Se pueden obtener otros comportamientos utilizando los parámetros adecuados en el comando [`CREATE SEQUENCE`](create-sequence-syntax-support.md). Esta función requiere un privilegio USAGE o UPDATE en la secuencia. |
| setval ( regclass, bigint [, boolean ] ) → bigint | Establece el valor actual del objeto de secuencia y, opcionalmente, su indicador is\$1called. La forma de dos parámetros establece el campo last\$1value de la secuencia en el valor especificado y establece su campo is\$1called en true, lo que significa que el siguiente nextval hará avanzar la secuencia antes de devolver un valor. El valor que indicará currval también se establece en el valor especificado. En el formulario de tres parámetros, is\$1called se puede establecer en true o false. true tiene el mismo efecto que el formulario de dos parámetros. Si se establece en false, el nextval siguiente devolverá exactamente el valor especificado y el avance de la secuencia comenzará con el nextval siguiente. Además, el valor indicado por currval no cambia aquí. Por ejemplo: 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 El resultado devuelto por setval es solo el valor de su segundo argumento. Esta función requiere el privilegio UPDATE en la secuencia. |
| currval ( regclass ) → bigint | Devuelve el valor obtenido más recientemente por nextval para esta secuencia en la sesión actual. (Se informa de un error si nextval nunca se ha llamado para esta secuencia en esta sesión). Dado que esto devuelve un valor local de la sesión, ofrece una respuesta predecible sobre si otras sesiones han ejecutado nextval o no, ya que la sesión actual lo ha hecho. Esta función requiere un privilegio USAGE o SELECT en la secuencia. |
| lastval () → bigint | Devuelve el valor devuelto más recientemente por nextval en la transacción actual. Esta función es idéntica a currval, excepto que, en lugar de tomar el nombre de la secuencia como argumento, se refiere a la secuencia a la que nextval se haya aplicado más recientemente en la transacción actual. Es un error llamar a lastval si aún no se ha llamado a nextval en la transacción actual. Esta función requiere un privilegio USAGE o SELECT en la última secuencia utilizada. |
**aviso**
El valor obtenido por `nextval` no se recupera para su reutilización si la transacción de llamada se cancela posteriormente. Esto significa que las interrupciones de transacciones o los fallos de la base de datos pueden provocar brechas en la secuencia de valores asignados. Eso también puede ocurrir sin que se cancele la transacción. Por ejemplo, un `INSERT` con una cláusula `ON CONFLICT` calculará la tupla que se va a insertar, incluida la realización de las llamadas de `nextval` necesarias, antes de detectar cualquier conflicto que pueda provocar que siga la regla `ON CONFLICT`. Por lo tanto, los objetos de secuencia de Aurora DSQL *no se pueden utilizar para obtener secuencias “sin brechas”*.
Del mismo modo, los cambios de estado de secuencia realizados por `setval` son inmediatamente visibles para otras transacciones y no se deshacen si la transacción que realiza la llamada se revierte.
La secuencia sobre la que va a operar una función de secuencia se especifica mediante un argumento `regclass`, que es simplemente el OID de la secuencia en el catálogo del sistema `pg_class`. Sin embargo, no tiene que buscar el OID manualmente, ya que el convertidor de entrada del tipo de datos `regclass` hará el trabajo por usted. Consulte la documentación de PostgreSQL sobre los [tipos de identificadores de objetos](https://www.postgresql.org/docs/current/datatype-oid.html) para obtener más información.
# Columnas de identidad
**importante**
Cuando se utilizan columnas de identidad, se debe considerar con cuidado el valor de la caché. Para obtener más información, consulte el aviso Importante de la página [`CREATE SEQUENCE`](create-sequence-syntax-support.md).
Para obtener orientación sobre la mejor manera de utilizar las columnas de identidad en función de los patrones de carga de trabajo, consulte [Trabajar con secuencias y columnas de identidad](sequences-identity-columns-working-with.md).
Una columna de identidad es una columna especial que se genera automáticamente a partir de una secuencia implícita. Se puede usar para generar valores clave. Para crear una columna de identidad, utilice la cláusula `GENERATED ... AS IDENTITY` en [`CREATE TABLE`](create-table-syntax-support.md), por ejemplo:
```
CREATE TABLE people (
id bigint GENERATED ALWAYS AS IDENTITY (CACHE 70000),
...
);
```
o, de forma alternativa:
```
CREATE TABLE people (
id bigint GENERATED BY DEFAULT AS IDENTITY (CACHE 70000),
...
);
```
Consulte [`CREATE TABLE`](create-table-syntax-support.md) para obtener más detalles.
Si se ejecuta un comando `INSERT` en la tabla con la columna de identidad y no se especifica ningún valor explícito para la columna de identidad, se inserta un valor generado por la secuencia implícita. Por ejemplo, con las definiciones anteriores y suponiendo que haya columnas adicionales adecuadas, escribir:
```
INSERT INTO people (name, address) VALUES ('A', 'foo');
INSERT INTO people (name, address) VALUES ('B', 'bar');
```
generaría valores para la columna `id` empezando por 1 y daría como resultado los siguientes datos de la tabla:
```
id | name | address
----+------+---------
1 | A | foo
2 | B | bar
```
Como alternativa, la clave `DEFAULT` se puede especificar en lugar de un valor para solicitar explícitamente el valor generado por la secuencia:
```
INSERT INTO people (id, name, address) VALUES (DEFAULT, 'C', 'baz');
```
Del mismo modo, la palabra clave `DEFAULT` se puede utilizar en los comandos `UPDATE`.
Por lo tanto, en muchos aspectos, una columna de identidad se comporta como una columna con un valor predeterminado.
Las cláusulas `ALWAYS` y `BY DEFAULT` en la definición de la columna determinan cómo se gestionan de forma explícita los valores especificados por el usuario en los comandos `INSERT` y `UPDATE`. En un comando `INSERT`, si se selecciona `ALWAYS`, solo se acepta un valor especificado por el usuario si la instrucción `INSERT` especifica `OVERRIDING SYSTEM VALUE`. Si se selecciona `BY DEFAULT`, prevalece el valor especificado por el usuario. Por lo tanto, el uso de `BY DEFAULT` da como resultado un comportamiento más similar a los valores predeterminados, donde el valor predeterminado puede ser anulado por un valor explícito, mientras que `ALWAYS` proporciona una mayor protección contra la inserción accidental de un valor explícito.
El tipo de datos de una columna de identidad debe ser uno de los tipos de datos compatibles con las secuencias. (Consulte [`CREATE SEQUENCE`](create-sequence-syntax-support.md).) Las propiedades de la secuencia asociada se pueden especificar al crear una columna de identidad (consulte [`CREATE TABLE`](create-table-syntax-support.md)) o modificarse posteriormente (consulte [`ALTER TABLE`](alter-table-syntax-support.md)).
Una columna de identidad se marca automáticamente como `NOT NULL`. Sin embargo, una columna de identidad no garantiza la unicidad. (Una secuencia normalmente devuelve valores únicos, pero una secuencia podría restablecerse, o los valores podrían insertarse manualmente en la columna de identidad, como se ha comentado anteriormente). La unicidad tendría que imponerse mediante una restricción `UNIQUE` o `PRIMARY KEY`.
# Trabajar con secuencias y columnas de identidad
Esta sección le ayudará a comprender cómo utilizar mejor las secuencias y las columnas de identidad en función de los patrones de carga de trabajo.
**importante**
Consulte el aviso Importante de la página [`CREATE SEQUENCE`](create-sequence-syntax-support.md) para obtener más información sobre el comportamiento de asignación y almacenamiento en caché.
## Elección de los tipos de identificadores
Amazon Aurora DSQL admite tanto identificadores basados en UUID como valores enteros generados mediante secuencias o columnas de identidad. Estas opciones difieren en la forma en que se asignan los valores y en la forma en que se escalan bajo carga.
Los valores UUID se pueden generar sin coordinación y son adecuados para cargas de trabajo en las que se crean identificadores con frecuencia o en muchas sesiones. Dado que Amazon Aurora DSQL está diseñado para funcionar de forma distribuida, a menudo resulta beneficioso evitar la coordinación. Por este motivo, se recomienda utilizar UUID como tipo de identificador predeterminado, especialmente para claves principales en cargas de trabajo en las que la escalabilidad es importante y no se requiere un orden estricto de los identificadores.
Las secuencias y las columnas de identidad generan valores enteros compactos que resultan muy prácticos para los identificadores legibles por el ser humano, la generación de informes y las interfaces externas. Cuando se prefieran los identificadores numéricos por motivos de usabilidad o integración, considere la posibilidad de utilizar una columna de secuencia o identidad en combinación con identificadores basados en UUID. Cuando se requieren secuencias de números enteros o valores de identidad, elegir un tamaño de caché adecuado se convierte en una parte importante del diseño de la carga de trabajo. Consulte la siguiente sección para obtener instrucciones sobre cómo elegir un tamaño de caché.
## Elección de un tamaño de caché
Seleccionar un valor de caché adecuado es una parte importante del uso eficaz de secuencias y columnas de identidad. La configuración de la caché determina cómo se comporta la asignación de identificadores bajo carga, lo que influye tanto en el rendimiento del sistema como en la precisión con la que los valores reflejan el orden de asignación.
**Un tamaño de caché mayor de `CACHE >= 65536` es adecuado cuando:**
+ Los identificadores se generan a alta frecuencia.
+ Muchas sesiones se insertan de forma simultánea.
+ La carga de trabajo puede tolerar las brechas y los efectos de ordenamiento visibles.
Por ejemplo, las cargas de trabajo de ingestión de eventos de gran volumen (como IoT o telemetría), así como los identificadores operativos como los ID de ejecución de trabajos, las referencias de casos de soporte o los números de pedido internos, suelen beneficiarse de tamaños de caché más grandes, donde los identificadores se generan con frecuencia y no se requiere un orden estricto.
**Un tamaño de caché de 1 se alinea mejor cuando:**
+ Las tasas de asignación son relativamente bajas.
+ Se espera que los identificadores sigan el orden de asignación más de cerca con el tiempo.
+ Minimizar las brechas es más importante que el máximo rendimiento.
Las cargas de trabajo como la asignación de números de cuenta o de referencia, en las que los identificadores se generan con menos frecuencia y es deseable un orden más cercano, se ajustan mejor a un tamaño de caché de 1.
# Índices asíncronos en Aurora DSQL
El comando `CREATE INDEX ASYNC` crea un índice en una o más columnas de una tabla específica. Este comando es una operación DDL asíncrona que no bloquea otras transacciones. Cuando ejecute `CREATE INDEX ASYNC`, Aurora DSQL devuelve de forma inmediata un `job_id`.
Puede supervisar el estado de este trabajo asíncrono mediante la vista de sistema `sys.jobs`. Mientras el trabajo de creación de índices esté en curso, puede usar estos procedimientos y comandos:
**`sys.wait_for_job(job_id)'your_index_creation_job_id'`**
Bloquea la sesión actual hasta que el trabajo especificado finalice o se produzca un error. Devuelve un valor booleano que indica éxito o error.
**`DROP INDEX`**
Cancela un trabajo de creación de índices en curso.
Cuando se completa la creación de índices asíncrona, Aurora DSQL actualiza el catálogo del sistema para marcar el índice como activo.
Tenga en cuenta que las transacciones simultáneas que acceden a objetos en el mismo espacio de nombres durante esta actualización pueden encontrar errores de simultaneidad.
Cuando Aurora DSQL finaliza una tarea de índice asíncrona, actualiza el catálogo del sistema para mostrar que el índice está activo. Si otras transacciones hacen referencia a los objetos en el mismo espacio de nombres en ese momento, podría aparecer un error de simultaneidad.
## Sintaxis
`CREATE INDEX ASYNC` utiliza la siguiente sintaxis.
```
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 a Aurora DSQL que compruebe si hay valores duplicados en la tabla cuando crea el índice y cada vez que agrega datos. Si especifica este parámetro, las operaciones de inserción y actualización que dan lugar a entradas duplicadas generan un error.
**`IF NOT EXISTS`**
Indica que Aurora DSQL no debe lanzar una excepción si ya existe un índice con el mismo nombre. En esta situación, Aurora DSQL no crea el nuevo índice. Tenga en cuenta que el índice que intenta crear podría tener una estructura muy diferente del índice que existe. Si especifica este parámetro, el nombre del índice es obligatorio.
**`name`**
El nombre del índice. No puede incluir el nombre del esquema en este parámetro.
Aurora DSQL crea el índice en el mismo esquema que la tabla principal. El nombre del índice debe ser distinto del nombre de cualquier otro objeto, como una tabla o un índice, en el esquema.
Si no especifica un nombre, Aurora DSQL genera un nombre automáticamente basándose en el nombre de la tabla principal y la columna indexada. Por ejemplo, si ejecuta `CREATE INDEX ASYNC on table1 (col1, col2)`, Aurora DSQL asigna automáticamente el nombre `table1_col1_col2_idx` al índice.
**`NULLS FIRST | LAST`**
El orden de clasificación de las columnas nulas y no nulas. `FIRST` indica que Aurora DSQL debe ordenar las columnas nulas antes que las columnas no nulas. `LAST` indica que Aurora DSQL debe ordenar las columnas nulas después de las columnas no nulas.
**`INCLUDE`**
Una lista de columnas para incluir en el índice como columnas no clave. No puede utilizar una columna no clave en una cualificación de búsqueda de examen de índice. Aurora DSQL ignora la columna en términos de unicidad para un índice.
**`NULLS DISTINCT | NULLS NOT DISTINCT`**
Especifica si Aurora DSQL debe considerar los valores nulos como distintos en un índice único. El valor predeterminado es `DISTINCT`, lo que significa que un índice único puede contener múltiples valores nulos en una columna. `NOT DISTINCT` indica que un índice no puede contener múltiples valores nulos en una columna.
## Notas de uso
Tenga en cuenta estas directrices:
+ El comando `CREATE INDEX ASYNC` no introduce bloqueos. Tampoco afecta la tabla base que Aurora DSQL utiliza para crear el índice.
+ Durante las operaciones de migración de esquemas, el procedimiento `sys.wait_for_job(job_id)'your_index_creation_job_id'` resulta útil. Garantiza que las operaciones DDL y DML posteriores se dirijan al índice recién creado.
+ Cada vez que Aurora DSQL ejecuta una nueva tarea asíncrona, comprueba la vista `sys.jobs` y elimina las tareas que tienen un estado de `completed` o `failed` durante más de 30 minutos. Así, `sys.jobs` muestra principalmente las tareas en curso y no contiene información sobre las tareas antiguas.
+ Si Aurora DSQL no crea un índice asíncrono, el índice permanece como `INVALID`. Para los índices únicos, las operaciones DML están sujetas a restricciones de unicidad hasta que descarte el índice. Le recomendamos que elimine los índices no válidos y los vuelva a crear.
## Creación de un índice: ejemplo
En el siguiente ejemplo se muestra cómo crear un esquema, una tabla y, a continuación, un índice.
1. Cree una tabla denominada `test.departments`.
```
CREATE SCHEMA test;
CREATE TABLE test.departments (name varchar(255) primary key NOT null,
manager varchar(255),
size varchar(4));
```
1. Inserte una fila en la tabla.
```
INSERT INTO test.departments VALUES ('Human Resources', 'John Doe', '10')
```
1. Cree un índice asíncrono.
```
CREATE INDEX ASYNC test_index on test.departments(name, manager, size);
```
El comando `CREATE INDEX` devuelve un ID de trabajo, como se muestra a continuación.
```
job_id
--------------------------
jh2gbtx4mzhgfkbimtgwn5j45y
```
Con `job_id` se indica que Aurora DSQL ha enviado un nuevo trabajo para crear el índice. Puede utilizar el procedimiento `sys.wait_for_job(job_id)'your_index_creation_job_id'` para bloquear otros trabajos en la sesión hasta que el trabajo finalice o se agote el tiempo de espera.
## Consulta del estado de la creación del índice: ejemplo
Consulte la vista del sistema `sys.jobs` para comprobar el estado de creación del índice, como se muestra en el siguiente ejemplo.
```
SELECT * FROM sys.jobs where job_id = 'wqhu6ewifze5xitg3umt24h5ua';
```
Aurora DSQL devuelve una respuesta similar a la siguiente.
```
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 columna de estado puede ser uno de los siguientes valores.
| Estado | Descripción |
| --- | --- |
| submitted | La tarea se ha enviado, pero Aurora DSQL aún no ha empezado a procesarla. |
| processing | Aurora DSQL está procesando la tarea. |
| failed | La tarea ha fallado. Consulte la columna de detalles para obtener más información. Si Aurora DSQL no ha podido crear el índice, no elimina automáticamente la definición del índice. Debe eliminar manualmente el índice con el comando DROP INDEX. |
| completed | Aurora DSQL ha completado la tarea correctamente. |
También puede consultar el estado del índice a través de las tablas `pg_index` y `pg_class` del catálogo. En concreto, los atributos `indisvalid` y `indisimmediate` pueden indicarle en qué estado se encuentra el índice. Mientras Aurora DSQL crea el índice, este tiene un estado inicial de `INVALID`. La marca `indisvalid` del índice devuelve `FALSE` o `f`, lo que indica que el índice no es válido. Si la marca devuelve `TRUE` o `t`, el índice está listo.
```
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)
```
## Errores en la creación de índices únicos
Si el trabajo de creación de índices únicos asíncrona muestra un estado erróneo con el detalle `Found duplicate key while validating index for UCVs`, esto indica que no se pudo crear un índice único debido a infracciones de restricciones de exclusividad.
**Resolución de errores en la creación de índices únicos**
1. Elimine las filas de la tabla principal que tengan entradas duplicadas para las claves especificadas en su índice secundario único.
1. Elimine el índice erróneo.
1. Emita un nuevo comando de creación de índice.
## Detección de infracciones de unicidad en las tablas principales
La siguiente consulta SQL le ayuda a identificar los valores duplicados en una columna específica de la tabla. Esto resulta especialmente útil cuando se necesita imponer la unicidad en una columna que actualmente no está configurada como clave principal o que no tiene una restricción única, como las direcciones de correo electrónico en una tabla de usuarios.
Los ejemplos siguientes muestran cómo crear una tabla de usuarios de ejemplo, rellenarla con datos de ejemplo que contengan duplicados conocidos y, a continuación, ejecutar la consulta de detección.
** Definición del esquema de la tabla **
```
-- 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
);
```
**Inserción de datos de ejemplo que incluyan conjuntos de direcciones de correo electrónico duplicadas**
```
-- 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');
```
** Ejecución de una consulta de detección de duplicados **
```
-- 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;
```
** Visualización de todos los registros con direcciones de correo electrónico duplicadas **
```
user_id | email | first_name | last_name | created_at | duplicate_count
---------+------------------------+------------+-----------+----------------------------+-----------------
4 | akua.mansa@example.com | Akua | Mansa | 2025-05-21 20:55:53.714432 | 2
6 | akua.mansa@example.com | Akua | Mansa | 2025-05-21 20:55:53.714432 | 2
1 | john.doe@example.com | John | Doe | 2025-05-21 20:55:53.714432 | 2
3 | john.doe@example.com | Johnny | Doe | 2025-05-21 20:55:53.714432 | 2
(4 rows)
```
**Si intentáramos la instrucción de creación del índice ahora, produciría un error: **
```
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)
```
# Tablas y comandos del sistema en Aurora DSQL
Consulte las secciones siguientes para obtener información sobre las tablas y los catálogos del sistema compatibles con Aurora DSQL, así como sobre consultas útiles para obtener información sobre el sistema, como la versión.
## Tablas del sistema
Aurora DSQL es compatible con PostgreSQL, por lo que muchas [tablas](https://www.PostgreSQL.org/docs/current/catalogs-overview.html) y [vistas de catálogo del sistema](https://www.PostgreSQL.org/docs/current/views.html) de PostgreSQL también existen en Aurora DSQL.
### Tablas y vistas de catálogo de PostgreSQL importantes
En la siguiente tabla se describen las tablas y las vistas más comunes que podría utilizar en Aurora DSQL.
| Nombre | Descripción |
| --- | --- |
| `pg_namespace` | Información sobre todos los esquemas |
| `pg_tables` | Información sobre todas las tablas |
| `pg_attribute` | Información sobre todos los atributos |
| `pg_views` | Información sobre vistas (pre)definidas |
| `pg_class` | Describe todas las tablas, columnas, índices y objetos similares |
| `pg_stats` | Una vista sobre las estadísticas del planificador |
| `pg_user` | Información sobre usuarios |
| `pg_roles` | Información sobre usuarios y grupos |
| `pg_indexes` | Enumera todos los índices |
| `pg_constraint` | Enumera las restricciones de las tablas |
### Tablas de catálogo admitidas y no admitidas
En la siguiente tabla se indican las tablas admitidas y no admitidas en Aurora DSQL.
| Nombre | Aplicable a Aurora DSQL |
| --- | --- |
| `pg_aggregate` | No |
| `pg_am` | Sí |
| `pg_amop` | No |
| `pg_amproc` | No |
| `pg_attrdef` | Sí |
| `pg_attribute` | Sí |
| `pg_authid` | No (utilice `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 |
### Vistas del sistema admitidas y no admitidas
En la siguiente tabla se indican las vistas admitidas y no admitidas en Aurora DSQL.
| Nombre | Aplicable a 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` proporciona información sobre el estado de los trabajos asíncronos. Por ejemplo, después de [crear un índice asíncrono](working-with-create-index-async.md), Aurora DSQL devuelve un `job_uuid`. Puede utilizar este `job_uuid` con `sys.jobs` para consultar el estado del trabajo.
```
SELECT * FROM sys.jobs;
```
Aurora DSQL devuelve una respuesta similar a la siguiente.
```
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
```
En la siguiente tabla se describen las columnas de la vista `sys.jobs`.
**Columnas de la vista sys.jobs**
| Columna | Tipo | Descripción |
| --- | --- | --- |
| job\$1id | text | Un UUID de base 32 que representa el trabajo. |
| status | text | El estado actual del trabajo. Los valores posibles son submitted, processing, completed y failed. Para obtener más información, consulte [Valores de estado de sys.jobs](#dsql-sys-jobs-status-values). |
| details | text | Cualquier dato relevante sobre el trabajo. Si el trabajo falla, se proporciona un motivo detallado. |
| job\$1type | text | El tipo de trabajo asíncrono. Los valores posibles son: INDEX\$1BUILD: una creación de índices asíncrona. ANALYZE: un trabajo de análisis automático enviado por el sistema. DROP: elimina los datos físicos tras una operación de DROP TABLE o DROP INDEX. |
| class\$1id | oid | El OID de la tabla de catálogo que contiene el objeto. |
| object\$1id | oid | El OID del objeto. |
| object\$1name | text | El nombre completo del objeto. Los trabajos de DROP no pueden hacer referencia a objetos que ya se han eliminado. Si el objeto al que se hace referencia ya se ha eliminado, el valor object\$1name puede ser NULL. |
| start\$1time | timestamp with time zone | La marca de tiempo en la que se envió el trabajo. |
| update\$1time | timestamp with time zone | La marca de tiempo en la que se actualizó por última vez la fila del trabajo. |
**Valores de estado de sys.jobs**
| Estado | Descripción |
| --- | --- |
| submitted | La tarea se ha enviado, pero Aurora DSQL aún no ha empezado a procesarla. |
| processing | Aurora DSQL está procesando la tarea. |
| failed | La tarea ha fallado. Consulte la columna details para obtener más información. |
| completed | Aurora DSQL ha completado la tarea correctamente. |
### La vista sys.iam\$1pg\$1role\$1mappings
La vista `sys.iam_pg_role_mappings` proporciona información sobre los permisos concedidos a los usuarios de IAM. Por ejemplo, si `DQSLDBConnect` es un rol de IAM que da acceso a Aurora DSQL a usuarios no administradores y a un usuario llamado `testuser` se le concede el rol `DQSLDBConnect` y los permisos correspondientes, puede consultar la vista `sys.iam_pg_role_mappings` para ver qué permisos se han concedido a qué usuarios.
```
SELECT * FROM sys.iam_pg_role_mappings;
```
## Consultas de metadatos de sistemas útiles
Utilice estas consultas para obtener estadísticas de tabla y metadatos de sistema sin realizar operaciones costosas como escanear tablas completas.
### Obtención del recuento estimado de filas de una tabla
Para obtener el recuento aproximado de filas en una tabla sin realizar un escaneo de tabla completo, use la consulta siguiente:
```
SELECT reltuples FROM pg_class WHERE relname = 'table_name';
```
El comando devuelve un resultado similar al siguiente:
```
reltuples
--------------
9.993836e+08
```
Este enfoque es más eficaz que en el caso de `SELECT COUNT(*)` para las tablas grandes en Aurora DSQL.
### Obtención de la versión principal actual de Aurora DSQL
Para obtener la versión principal actual del clúster de Aurora DSQL, utilice la siguiente consulta:
```
SELECT * FROM sys.dsql_major_version();
```
El comando devuelve un resultado similar al siguiente:
```
dsql_major_version
--------------------
1
```
Esto devuelve la versión principal en la que se encuentra la conexión SQL en Aurora DSQL.
### Obtención de la versión actual de la plataforma
Para obtener la versión actual de PostgreSQL del clúster de Aurora DSQL, utilice la siguiente consulta:
```
SHOW server_version;
```
El comando devuelve un resultado similar al siguiente:
```
server_version
----------------
16.13
```
Esto devuelve la versión en la que se encuentra la conexión SQL en Aurora DSQL.
## El comando `ANALYZE`
El comando `ANALYZE ` recopila estadísticas sobre el contenido de las tablas de la base de datos y almacena los resultados en la vista del sistema `pg_stats`. Posteriormente, el planificador de consultas utiliza estas estadísticas para ayudar a determinar los planes de ejecución más eficaces para las consultas.
En Aurora DSQL, no puede ejecutar el comando `ANALYZE` en una transacción explícita. `ANALYZE` no está sujeto al límite de tiempo de espera de la transacción de la base de datos.
Para reducir la necesidad de intervención manual y mantener las estadísticas actualizadas de manera coherente, Aurora DSQL ejecuta automáticamente `ANALYZE` como un proceso en segundo plano. Este trabajo en segundo plano se activa automáticamente en función de la tasa de cambio observada en la tabla. Está vinculado al número de filas (tuplas) que se han insertado, actualizado o eliminado desde el último análisis.
`ANALYZE` se ejecuta de forma asíncrona en segundo plano y su actividad se puede supervisar en la vista del sistema sys.jobs con la siguiente consulta:
```
SELECT * FROM sys.jobs WHERE job_type = 'ANALYZE';
```
**Consideraciones clave**
**nota**
Los trabajos `ANALYZE` se facturan como otros trabajos asíncronos en Aurora DSQL. Cuando modifica una tabla, esto puede desencadenar indirectamente un trabajo automático de recopilación de estadísticas en segundo plano, lo que puede provocar cargos de medición debido a la actividad asociada al nivel del sistema.
Los trabajos `ANALYZE` en segundo plano, que se activan automáticamente, recopilan los mismos tipos de estadísticas que los `ANALYZE` manuales y los aplican de forma predeterminada a las tablas de los usuarios. Las tablas del sistema y del catálogo se excluyen de este proceso automatizado.
# Trabajo con planes EXPLAIN de Aurora DSQL
Aurora DSQL utiliza una estructura de plan EXPLAIN similar a la de PostgreSQL, pero con adiciones clave que reflejan su arquitectura distribuida y su modelo de ejecución.
En esta documentación, proporcionaremos información general de los planes EXPLAIN de Aurora DSQL y destacaremos las similitudes y diferencias en comparación con PostgreSQL. Cubriremos los distintos tipos de operaciones de escaneo disponibles en Aurora DSQL y lo ayudaremos a comprender el costo de ejecutar las consultas.
## Planes EXPLAIN de PostgreSQL frente a Aurora DSQL
Aurora SQL se basa en la base de datos de PostgreSQL y comparte la mayoría de las estructuras planificadas con PostgreSQL, pero presenta diferencias arquitectónicas clave que afectan a la ejecución y optimización de las consultas:
| Característica | PostgreSQL | Aurora DSQL |
| --- | --- | --- |
| Almacenamiento de datos | Almacenamiento de montón | Sin montón, todas las filas están indexadas por un identificador único |
| Clave principal | El índice de clave principal está separado de los datos de la tabla | El índice de clave principal es la tabla con todas las columnas adicionales como columnas INCLUDE |
| Índices secundarios | Índices secundarios estándar | Funciona igual que PostgreSQL, con la posibilidad de incluir columnas no clave |
| Capacidades de filtrado | Condición de índice, filtro de montón | Condición de índice, filtro de almacenamiento, filtro de procesador de consultas |
| Tipos de exámenes | Escaneo secuencial, escaneo de índice, escaneo solo de índice | Escaneo completo, escaneo solo de índice, escaneo de índice |
| Ejecución de consulta | Local en la base de datos | Distribuido (el procesamiento y el almacenamiento son independientes) |
Aurora DSQL almacena los datos de la tabla directamente en orden de clave principal en lugar de en un montón independiente. Cada fila se identifica mediante una clave única, normalmente la clave principal, que permite a la base de datos optimizar las búsquedas de manera más eficiente. La diferencia arquitectónica explica por qué Aurora DSQL suele utilizar escaneos solo de índice en los casos en que PostgreSQL puede elegir un escaneo secuencial.
Otra distinción clave es que Aurora DSQL separa la informática del almacenamiento, lo que permite aplicar filtros en una fase más temprana de la ruta de ejecución para reducir el movimiento de datos y mejorar el rendimiento.
Para obtener más información sobre el uso de los planes EXPLAIN con PostgreSQL, consulte la [documentación EXPLAIN de PostgreSQL](https://www.postgresql.org/docs/current/using-explain.html).
## Elementos clave de los planes EXPLAIN de Aurora DSQL
Los planes EXPLAIN de Aurora DSQL proporcionan información detallada sobre cómo se ejecutan las consultas, incluido dónde se produce el filtrado y qué columnas se recuperan del almacenamiento. La comprensión de este resultado ayuda a optimizar el rendimiento de las consultas.
Condición de índice
Condiciones utilizadas para navegar por el índice. El filtrado más eficiente que reduce los datos escaneados. En Aurora DSQL, las condiciones de índice se pueden aplicar en varios niveles del plan de ejecución.
Proyecciones
Columnas recuperadas del almacenamiento. Menos proyecciones significan un mejor rendimiento.
Filtro de almacenamiento
Condiciones aplicadas por almacenamiento. Más eficiente que los filtros del procesador de consultas.
Filtro de procesador de consultas
Condiciones aplicadas por procesador de consultas. Requiere transferir todos los datos antes de filtrarlos, lo que se traduce en una mayor sobrecarga de procesamiento y movimiento de datos.
## Filtros en Aurora DSQL
Aurora DSQL separa la informática del almacenamiento, lo que significa que el punto en el que se aplican los filtros durante la ejecución de la consulta tiene un impacto significativo en el rendimiento. Los filtros que se aplican antes de transferir grandes volúmenes de datos reducen la latencia y mejoran la eficiencia. Cuanto antes se aplique un filtro, menos datos deberán procesarse, moverse y escanearse, lo que se traducirá en consultas más rápidas.
Aurora DSQL puede aplicar filtros en varias etapas de la ruta de consulta. la comprensión de estas etapas es clave para interpretar los planes de consultas y optimizar el rendimiento.
| Nivel | Tipo de filtro | Descripción |
| --- | --- | --- |
| 1 | Condición de índice | Se aplica al escanear el índice. Limita la cantidad de datos que se leen del almacenamiento y reduce los datos que se envían a la capa de procesamiento. |
| 2 | Filtro de almacenamiento | Se aplica después de leer los datos del almacenamiento, pero antes de enviarlos a informática. Un ejemplo de esto es un filtro en una columna de inclusión de un índice. Reduce la transferencia de datos, pero no la cantidad leída. |
| 3 | Filtro de procesador de consultas | Se aplica después de que los datos lleguen a la capa de informática. Todos los datos se deben transferir primero, lo que aumenta la latencia y el costo. Actualmente, Aurora DSQL no puede realizar todas las operaciones de filtrado y proyección en el almacenamiento, por lo que es posible que algunas consultas se vean obligadas a recurrir a este tipo de filtrado. |
# Lectura de los planes EXPLAIN de Aurora DSQL
Comprender cómo leer los planes EXPLAIN es clave para optimizar el rendimiento de las consultas. En esta sección, analizaremos ejemplos reales de planes de consultas de Aurora DSQL, mostraremos cómo se comportan los diferentes tipos de escaneo, explicaremos dónde se aplican los filtros y destacaremos las oportunidades de optimización.
## Tablas de muestra utilizadas en estos ejemplos
Los ejemplos siguientes hacen referencia a dos tablas: `transaction` y `account`.
La tabla `transaction` o dispone de clave principal, lo que provoca que Aurora DSQL escanee toda la tabla al consultarla.
La tabla `account` tiene un índice en `customer_id`. Este índice incluye `balance` y `status` como columnas de cobertura, lo que permite responder a determinadas consultas directamente desde el índice sin necesidad de leer la tabla base. Sin embargo, el índice no incluye `created_at`, por lo que las consultas que hacen referencia a esta columna requieren un acceso adicional a la tabla.
```
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);
```
## Ejemplo de escaneo completo
Aurora DSQL tiene escaneos secuenciales, que funcionan de manera idéntica a PostgreSQL, así como escaneos completos. La única diferencia entre estos dos es que los escaneos completos pueden utilizar filtros adicionales en el almacenamiento. Debido a esto, casi siempre se selecciona por encima de los escaneos secuenciales. Debido a la similitud, solo trataremos ejemplos de los escaneos completos más interesantes.
Los escaneos completos se utilizarán principalmente en tablas sin clave principal. Como las claves principales de Aurora DSQL son índices de cobertura completa de forma predeterminada, lo más probable es que Aurora DSQL utilice escaneos solo indexados en la clave principal en muchas situaciones en las que PostgreSQL utilizaría un escaneo secuencial. Como ocurre con la mayoría de las demás bases de datos, una tabla sin índices se escalará mal.
```
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)
```
Este plan muestra dos filtros aplicados en diferentes etapas. La condición `transaction_date > '2025-01-01'` se aplica en la capa de almacenamiento, lo que reduce la cantidad de datos que se devuelven. La condición `description LIKE '%external%'` se aplica más adelante en el procesador de consultas, una vez transferidos los datos, lo que hace que sea menos eficiente. Insertar filtros más selectivos en las capas de almacenamiento o índice generalmente mejora el rendimiento.
## Ejemplo de escaneo solo de índices
Los escaneos solo de índices son los tipos de escaneo más óptimos en Aurora DSQL, ya que producen el menor número de viajes de ida y vuelta a la capa de almacenamiento y son los que más filtran. Sin embargo, el hecho de que vea escaneo solo de índice no significa que tenga el mejor plan. Debido a los diferentes niveles de filtrado que se pueden producir, es esencial seguir prestando atención a los diferentes lugares en los que se puede producir el filtrado.
```
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)
```
En este plan, la condición de indexación (`customer_id = '4b18a761-5870-4d7c-95ce-0a48eca3fceb'`), se evalúa primero durante el escaneo del índice, que es la etapa más eficiente porque limita la cantidad de datos que se leen del almacenamiento. El filtro de almacenamiento, `status = 'pending'`, se aplica después de leer los datos, pero antes de enviarlos a la capa de procesamiento, lo que reduce la cantidad de datos transferidos. Por último, el filtro del procesador de consultas, `balance > 100`, se ejecuta en último lugar, después de mover los datos, por lo que es el menos eficiente. De estas, la condición de índice es la que ofrece el mejor rendimiento, ya que controla directamente la cantidad de datos que se escanean.
## Ejemplo de escaneo de índices
Los escaneos de índices son similares a los escaneos solo de índices, excepto que tienen el paso adicional de tener que llamar a la tabla base. Como Aurora DSQL puede especificar filtros de almacenamiento, puede hacerlo tanto en la llamada de índice como en la llamada de búsqueda.
Para que quede claro, Aurora DSQL presenta el plan como dos nodos. De esta forma, puede ver claramente en qué medida puede ayudar agregar una columna de inclusión en términos de filas devueltas desde el almacenamiento.
```
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)
```
Este plan muestra cómo se filtra en varias etapas:
+ La condición de indexación en `customer_id ` filtra los datos de forma temprana.
+ El filtro de almacenamiento en `status` reduce aún más los resultados antes de que se envíen a informática.
+ El filtro del procesador de consultas en `balance` se aplica más adelante, después de la transferencia.
+ El filtro de búsqueda en `created_at` se evalúa al buscar columnas adicionales de la tabla base.
Agregar columnas de uso frecuente como campos de `INCLUDE` suele eliminar esta búsqueda y mejorar el rendimiento.
## Prácticas recomendadas
+ **Alinee los filtros con las columnas indexadas** para acelerar el filtrado.
+ **Utilice las columnas INCLUDE** para permitir escaneos solo de índices y evitar búsquedas.
+ **Valide las estimaciones de filas** al investigar los problemas de rendimiento. Aurora DSQL administra las estadísticas automáticamente ejecutando `ANALYZE` en segundo plano en función de las tasas de cambio de los datos. Si las estimaciones parecen inexactas, puede ejecutar `ANALYZE` manualmente para actualizar las estadísticas inmediatamente.
+ **Evite las consultas no indexadas** en tablas grandes para evitar costosos escaneos completos.
# Descripción de las DPU en EXPLAIN ANALYZE
Aurora DSQL proporciona información sobre la unidad de procesamiento distribuido (DPU) **por instrucción** en la producción del plan de `EXPLAIN ANALYZE VERBOSE`, lo que le brinda una mayor visibilidad del costo de las consultas durante el desarrollo. Esta sección explica qué son las DPU y cómo interpretarlas en el resultado de `EXPLAIN ANALYZE VERBOSE`.
## ¿Qué es una DPU?
Una unidad de procesamiento distribuido (DPU) es la medida normalizada del trabajo realizado por Aurora DSQL. Está compuesta por:
+ **ComputeDPU**: tiempo dedicado a ejecutar consultas SQL
+ **ReadDPU**: recursos utilizados para leer datos del almacenamiento
+ **WriteDPU**: recursos que se utilizan para escribir datos en el almacenamiento
+ **MultiRegionWriteDPU**: recursos que se utilizan para replicar las escrituras en clústeres interconectados en configuraciones multirregionales.
## Uso de la DPU en EXPLAIN ANALYZE VERBOSE
Aurora DSQL amplía `EXPLAIN ANALYZE VERBOSE` para incluir una estimación del uso de la DPU por instrucción al final del resultado. Esto proporciona una visibilidad inmediata del costo de las consultas, lo que le ayuda a identificar los factores de costo de la carga de trabajo, ajustar el rendimiento de las consultas y pronosticar mejor el uso de los recursos.
Los siguientes ejemplos muestran cómo interpretar las estimaciones de la DPU por instrucción incluidas en el resultado de EXPLAIN ANALYZE VERBOSE.
### Ejemplo 1: consulta SELECT
```
EXPLAIN ANALYZE VERBOSE SELECT * FROM test_table;
```
```
QUERY PLAN
----------------------------------------------------
Index Only Scan using test_table_pkey on public.test_table (cost=125100.05..171100.05 rows=1000000 width=36) (actual time=2.973..4.482 rows=120 loops=1)
Output: id, context
-> Storage Scan on test_table_pkey (cost=125100.05..171100.05 rows=1000000 width=36) (actual rows=120 loops=1)
Projections: id, context
-> B-Tree Scan on test_table_pkey (cost=125100.05..171100.05 rows=1000000 width=36) (actual rows=120 loops=1)
Query Identifier: qymgw1m77maoe
Planning Time: 11.415 ms
Execution Time: 4.528 ms
Statement DPU Estimate:
Compute: 0.01607 DPU
Read: 0.04312 DPU
Write: 0.00000 DPU
Total: 0.05919 DPU
```
En este ejemplo, la instrucción SELECT realiza un análisis solo de índices, por lo que la mayor parte del costo proviene de la DPU de lectura (0.04312), que representa los datos recuperados del almacenamiento y Compute DPU (0.01607), que refleja los recursos informáticos utilizados para procesar y devolver los resultados. No hay ninguna DPU de escritura, ya que la consulta no modifica los datos. La DPU total (0.05919) es la suma de Informática \$1 Lectura \$1 Escritura.
### Ejemplo 2: consulta INSERT
```
EXPLAIN ANALYZE VERBOSE INSERT INTO test_table VALUES (1, 'name1'), (2, 'name2'), (3, 'name3');
```
```
QUERY PLAN
----------------------------------------------------
Insert on public.test_table (cost=0.00..0.04 rows=0 width=0) (actual time=0.055..0.056 rows=0 loops=1)
-> Values Scan on "*VALUES*" (cost=0.00..0.04 rows=3 width=122) (actual time=0.003..0.008 rows=3 loops=1)
Output: "*VALUES*".column1, "*VALUES*".column2
Query Identifier: jtkjkexhjotbo
Planning Time: 0.068 ms
Execution Time: 0.543 ms
Statement DPU Estimate:
Compute: 0.01550 DPU
Read: 0.00307 DPU (Transaction minimum: 0.00375)
Write: 0.01875 DPU (Transaction minimum: 0.05000)
Total: 0.03732 DPU
```
Esta instrucción realiza principalmente escrituras, por lo que la mayor parte del costo está asociado a una DPU de escritura. La DPU de informática (0.01550) representa el trabajo realizado para procesar e insertar los valores. La DPU de lectura (0.00307) refleja las lecturas menores del sistema (para búsquedas en catálogos o comprobaciones de índices).
Observe los mínimos de transacciones que se muestran junto a las DPU de lectura y escritura. Indican los costos básicos por transacción que se aplican *solo cuando la operación incluye lecturas o escrituras*. No significan que cada transacción incurra automáticamente en un cargo de DPU de lectura de 0.00375 o DPU de escritura de 0.05. En cambio, estos mínimos se aplican por transacción durante la agregación de costos y solo si se realizan lecturas o escrituras dentro de esa transacción. Debido a esta diferencia de alcance, es posible que las estimaciones por instrucción en `EXPLAIN ANALYZE VERBOSE` no coincidan exactamente con las métricas por transacción de las que se informa en CloudWatch o en los datos de facturación.
## Uso de la información de la DPU para la optimización
Las estimaciones de la DPU por instrucción ofrecen una forma eficaz de optimizar las consultas más allá del tiempo de ejecución. Los casos de uso comunes incluyen:
+ **Conocimiento de los costos:** comprenda lo caro que es una consulta en relación con otras.
+ **Optimización del esquema:** compare el impacto de los índices o los cambios en el esquema tanto en el rendimiento como en la eficiencia de los recursos.
+ **Planificación presupuestaria:** calcule el costo de la carga de trabajo en función del uso observado de la DPU.
+ **Comparación de consultas:** evalúe los enfoques de consulta alternativos según su consumo relativo de DPU.
## Interpretación de la información de la DPU
Tenga en cuenta las siguientes prácticas recomendadas al utilizar datos de DPU de `EXPLAIN ANALYZE VERBOSE`:
+ **Úselo de forma direccional:** trate la DPU de la que se ha informado como una forma de entender el costo *relativo* de una consulta, en lugar de una coincidencia exacta con las métricas o los datos de facturación de CloudWatch. Se esperan diferencias porque `EXPLAIN ANALYZE VERBOSE` informa del costo por instrucción, mientras que CloudWatch agrega la actividad por transacción. CloudWatch también incluye operaciones en segundo plano (como ANALYZE o compactaciones) y gastos de transacción (`BEGIN`/`COMMIT`) que `EXPLAIN ANALYZE VERBOSE` excluye intencionadamente.
+ **La variabilidad de la DPU entre las ejecuciones es normal** en los sistemas distribuidos y no indica errores. Factores como el almacenamiento en caché, los cambios en el plan de ejecución, la simultaneidad o los cambios en la distribución de los datos pueden provocar que la misma consulta consuma recursos diferentes de una ejecución a la siguiente.
+ **Operaciones pequeñas por lotes:** si la carga de trabajo emite muchas instrucciones pequeñas, considere agruparlas en lotes en operaciones más grandes (que no superen los 10 MB). Esto reduce los gastos generales de redondeo y produce estimaciones de costos más significativas.
+ **Úselo para ajustar, no para facturar:** los datos de la DPU en `EXPLAIN ANALYZE VERBOSE` están diseñados para conocer los costos, ajustar las consultas y optimizar. No es una métrica apta para la facturación. Confíe siempre en las métricas de CloudWatch o en los informes de facturación mensuales para obtener datos fiables sobre costos y uso.