`ALTER TABLE`

ALTER TABLE은 테이블의 정의를 변경합니다.

지원되는 구문


ALTER TABLE [ IF EXISTS ] [ ONLY ] name [ * ]
    action [, ... ]
ALTER TABLE [ IF EXISTS ] [ ONLY ] name [ * ]
    RENAME [ COLUMN ] column_name TO new_column_name
ALTER TABLE [ IF EXISTS ] [ ONLY ] name [ * ]
    RENAME CONSTRAINT constraint_name TO new_constraint_name
ALTER TABLE [ IF EXISTS ] name
    RENAME TO new_name
ALTER TABLE [ IF EXISTS ] name
    SET SCHEMA new_schema
ALTER TABLE ASYNC [ IF EXISTS ] [ ONLY ] name [ * ]
    VALIDATE CONSTRAINT constraint_name

where action is one of:

    ADD [ COLUMN ] [ IF NOT EXISTS ] column_name data_type [ STORAGE { PLAIN | EXTERNAL | EXTENDED | MAIN | DEFAULT } ]
    DROP [ COLUMN ] [ IF EXISTS ] column_name [ RESTRICT | CASCADE ]
    ALTER [ COLUMN ] column_name SET DEFAULT expression
    ALTER [ COLUMN ] column_name DROP DEFAULT
    ALTER [ COLUMN ] column_name DROP NOT NULL
    ALTER [ COLUMN ] column_name DROP EXPRESSION [ IF EXISTS ]
    ALTER [ COLUMN ] column_name ADD GENERATED { ALWAYS | BY DEFAULT } AS IDENTITY [ ( sequence_options ) ]
    ALTER [ COLUMN ] column_name { SET GENERATED { ALWAYS | BY DEFAULT } | SET sequence_option | RESTART [ [ WITH ] restart ] } [...]
    ALTER [ COLUMN ] column_name DROP IDENTITY [ IF EXISTS ]
    ALTER [ COLUMN ] column_name SET STORAGE { PLAIN | EXTERNAL | EXTENDED | MAIN | DEFAULT }
    ADD table_constraint NOT VALID
    ADD table_constraint_using_index
    DROP CONSTRAINT [ IF EXISTS ] constraint_name [ RESTRICT | CASCADE ]
    OWNER TO { new_owner | CURRENT_ROLE | CURRENT_USER | SESSION_USER }

and table_constraint is:

    [ CONSTRAINT constraint_name ]
    CHECK ( expression )

and table_constraint_using_index is:

    [ CONSTRAINT constraint_name ]
    UNIQUE USING INDEX index_name

설명

ADD [ COLUMN ] [ IF NOT EXISTS ]

이 양식은 CREATE TABLE와 동일한 구문을 사용하여 테이블에 새 열을 추가합니다. IF NOT EXISTS가 지정되어 있고 이 이름의 열이 이미 있는 경우 오류가 발생하지 않습니다.

DROP [ COLUMN ] [ IF EXISTS ]

이 양식은 테이블에서 열을 삭제합니다. 프라이머리 키 제약 조건을 제외하고 열과 관련된 인덱스 및 테이블 제약 조건은 자동으로 삭제됩니다. 프라이머리 키 열 삭제는 지원되지 않습니다. 열 삭제로 인해 통계에 단일 열에 대한 데이터만 포함될 경우 삭제된 열을 참조하는 다변량 통계도 제거됩니다. 외래 키 참조 또는 뷰와 같이 테이블 외부의 무언가가 해당 열에 의존하는 경우 CASCADE를 사용해야 합니다. IF EXISTS가 지정되고 열이 존재하지 않으면 오류가 발생하지 않습니다. 이 경우 대신 알림이 발행됩니다.

SET/DROP DEFAULT

이러한 양식은 열의 기본값을 설정 또는 제거합니다(제거는 기본값을 NULL로 설정하는 것과 동일함). 새 기본값은 후속 INSERT 또는 UPDATE 명령에만 적용되며 테이블에 이미 있는 행은 변경되지 않습니다.

DROP NOT NULL

이 양식은 null 값을 허용하도록 열을 변경합니다.

DROP EXPRESSION [ IF EXISTS ]

이 양식은 저장된 생성 열을 일반 기본 열로 바꿉니다. 열의 기존 데이터는 유지되지만 향후 변경 사항은 더 이상 생성 표현식을 적용하지 않습니다. DROP EXPRESSION IF EXISTS가 지정되어 있고 열이 생성 열이 아닌 경우 오류가 발생하지 않습니다. 이 경우 대신 알림이 발행됩니다.

ADD GENERATED { ALWAYS | BY DEFAULT } AS IDENTITY

SET GENERATED { ALWAYS | BY DEFAULT }

DROP IDENTITY [ IF EXISTS ]

이러한 양식은 열이 ID 열인지 아니면 기존 ID 열의 생성 속성을 변경하는지 여부를 변경합니다. 세부 정보는 CREATE TABLE 섹션을 참조하세요. SET DEFAULT와 마찬가지로 이러한 형식은 후속 INSERT 및 UPDATE 명령의 동작에만 영향을 미치며 테이블에 이미 있는 행은 변경되지 않습니다.

sequence_option은 INCREMENT BY와 같이 ALTER SEQUENCE에서 지원하는 옵션입니다. 이러한 형식은 기존 ID 열의 기반이 되는 시퀀스를 변경합니다.

참고

Amazon Aurora DSQL은 ADD GENERATED AS IDENTITY를 사용할 때 명시적 CACHE 값을 요구합니다. 또한 자격 증명 열은 bigint 열에서만 지원됩니다.

ID 열을 사용할 때는 캐시 값을 신중하게 고려해야 합니다. 자세한 내용은 CREATE SEQUENCE 페이지의 중요 안내를 참조하세요.

워크로드 패턴을 기반으로 ID 열을 가장 잘 사용하는 방법에 대한 지침은 시퀀스 및 자격 증명 열 작업 섹션을 참조하세요.

SET STORAGE { PLAIN | EXTERNAL | EXTENDED | MAIN | DEFAULT }

이 양식은 열의 스토리지 모드를 설정합니다. 사용 가능한 스토리지 모드에 대한 자세한 내용은 CREATE TABLE 페이지의 스토리지 모드 섹션을 참조하세요.

ADD table_constraint NOT VALID

이 양식은 테이블에 새 CHECK 제약 조건을 추가합니다. Aurora DSQL에서 ALTER TABLE ADD CONSTRAINT를 통해 추가된 CHECK 제약 조건은 NOT VALID 옵션을 사용해야 합니다. Aurora DSQL은 제약 조건을 생성하지만 기존 데이터에 대해 즉시 검증하지는 않습니다. 이렇게 하면 전체 테이블을 스캔하지 않고도 제약 조건을 추가할 수 있습니다. 제약 조건은 모든 새 행 및 업데이트에 즉시 적용됩니다.

NOT VALID를 사용하여 제약 조건을 추가한 후 ALTER TABLE ASYNC ... VALIDATE CONSTRAINT를 사용하여 기존 데이터도 제약 조건을 충족하는지 확인합니다. 검증은 비동기 DDL 작업으로 실행됩니다. sys.jobs를 사용하여 진행 상황을 모니터링할 수 있습니다.

ADD table_constraint_using_index

이 양식은 기존 고유 인덱스를 기반으로 테이블에 새 UNIQUE 제약 조건을 추가합니다. 인덱스의 모든 열이 제약 조건에 포함됩니다.

인덱스는 VALID 상태여야 합니다. 인덱스가 현재 빌드 중인 동안 해당 인덱스를 사용하여 고유한 제약 조건을 추가하는 것은 지원되지 않습니다.

제약 조건의 이름을 지정하면 제약 조건 이름과 일치하도록 인덱스의 이름이 변경됩니다. 그렇지 않으면 제약 조건의 이름이 인덱스와 동일하게 지정됩니다.

이 명령이 실행된 후 인덱스는 일반 CREATE UNIQUE INDEX ASYNC 명령으로 인덱스를 빌드한 것과 동일한 방식으로 제약 조건에 의해 "소유"됩니다. 특히, 제약 조건을 삭제하면 인덱스도 사라집니다.

VALIDATE CONSTRAINT

이 양식은 이전에 NOT VALID 옵션을 사용하여 생성된 제약 조건을 검증합니다. 이 명령은 다른 트랜잭션을 차단하지 않는 비동기 DDL 작업입니다. ALTER TABLE ASYNC ... VALIDATE CONSTRAINT를 실행하면 Aurora DSQL이 즉시 job_id를 반환합니다.

sys.jobs 시스템 뷰를 사용하여 이 비동기 작업의 상태를 모니터링할 수 있습니다. sys.wait_for_job('job_id')을 사용하여 검증이 완료되거나 실패할 때까지 현재 세션을 차단할 수도 있습니다.

검증 작업은 전체 테이블을 스캔하여 모든 기존 행이 제약 조건을 충족하는지 확인합니다. 검증이 성공적으로 완료되면 Aurora DSQL은 제약 조건을 유효함으로 표시하고 쿼리 플래너는 이를 모든 쿼리에 적용합니다. 기존 행이 제약 조건을 위반하여 검증에 실패하면 작업이 실패하고 제약 조건이 NOT VALID 상태로 유지됩니다.

이 명령은 NOT VALID 옵션을 사용하여 생성한 제약 조건만 검증합니다. 이미 유효한 제약 조건을 확인하려고 하면 오류가 발생합니다.

DROP CONSTRAINT [ IF EXISTS ]

이 양식은 테이블에 지정된 제약 조건을 그 기본 인덱스와 함께 삭제합니다. IF EXISTS가 지정되고 제약 조건이 존재하지 않으면 오류가 발생하지 않습니다. 이 경우 대신 알림이 발행됩니다.

OWNER TO

이 양식은 테이블 소유자를 지정된 사용자로 변경합니다.

RENAME

RENAME 양식은 테이블 이름, 테이블의 개별 열 이름 또는 테이블의 제약 조건 이름을 변경합니다. 기본 인덱스가 있는 제약 조건의 이름을 변경하면 인덱스의 이름도 변경됩니다. 저장된 데이터에 미치는 영향은 없습니다.

SET SCHEMA

이 양식은 테이블을 다른 스키마로 이동합니다. 연결된 인덱스, 제약 조건, 테이블 열이 소유한 시퀀스도 이동됩니다.

파라미터

IF EXISTS: 테이블이 없는 경우 오류가 발생하지 않습니다. 이 경우 알림이 발행됩니다.
이름: 변경할 기존 테이블 이름(선택적으로 스키마 한정)입니다. 테이블 이름 앞에 ONLY를 지정하면 해당 테이블만 변경됩니다. ONLY를 지정하지 않으면 테이블 및 모든 하위 테이블(있는 경우)이 변경됩니다. 선택적으로 테이블 이름 뒤에 *를 지정하여 하위 테이블이 포함되어 있음을 명시적으로 나타낼 수 있습니다.
column_name: 새 열 또는 기존 열의 이름입니다.
new_column_name: 기존 열의 새 이름입니다.
new_name: 테이블의 새 이름입니다.
data_type: 새 열의 데이터 형식입니다.
table_constraint: CHECK 제약 조건 정의입니다. Aurora DSQL에서는 ALTER TABLE ADD CONSTRAINT를 사용하여 CHECK 제약 조건을 NOT VALID 옵션과 함께 추가해야 합니다. 전체 CHECK 제약 조건 구문은 CREATE TABLE 섹션을 참조하세요.
constraint_name: 새 제약 조건 또는 기존 제약 조건의 이름입니다.
CASCADE: 삭제된 열 또는 제약 조건에 의존하는 객체(예: 열을 참조하는 뷰)를 자동으로 삭제한 다음 해당 객체에 의존하는 모든 객체를 삭제합니다.
RESTRICT: 종속 객체가 있는 경우 열 또는 제약 조건 삭제를 거부합니다. 이는 기본 설정 동작입니다.
new_owner: 테이블의 새 소유자의 사용자 이름입니다.
new_schema: 테이블을 이동할 스키마의 이름입니다.

참고

DROP COLUMN 양식은 열을 물리적으로 제거하지 않지만 SQL 작업에서는 볼 수 없게 만듭니다. 테이블의 후속 삽입 및 업데이트 작업은 해당 열에 null 값을 저장합니다. 따라서 열 삭제는 신속하지만, 삭제된 열이 차지하는 공간이 회수되지 않으므로 테이블의 온디스크 크기가 즉시 줄어들지는 않습니다. 시간이 지나면서 기존 행이 업데이트되면 공간이 회수됩니다.

삭제된 열이 프라이머리 키의 INCLUDE 열로 참조되는 경우 삭제된 열을 제거하도록 프라이머리 키 정의가 업데이트됩니다.

Aurora DSQL의 테이블은 한 번에 최대 255개의 활성 열을 가질 수 있으며, 테이블 수명 동안 최대 1,600개의 열을 가질 수 있습니다. 열을 삭제해도 해당 속성 번호는 회수되지 않습니다. 삭제된 열은 활성 열 세트에서 제거되지만 1,600개 열의 수명 한도에는 계속 포함됩니다. 자세한 내용은 Aurora DSQL의 데이터베이스 한도 섹션을 참조하세요.

javascript가 브라우저에서 비활성화되거나 사용이 불가합니다.

AWS 설명서를 사용하려면 Javascript가 활성화되어야 합니다. 지침을 보려면 브라우저의 도움말 페이지를 참조하십시오.

문서 규칙

CREATE TABLE

CREATE INDEX