Amazon Redshift는 패치 198부터 새 Python UDF 생성을 더 이상 지원하지 않습니다. 기존 Python UDF는 2026년 6월 30일까지 계속 작동합니다. 자세한 내용은 [블로그 게시물](https://aws.amazon.com/blogs/big-data/amazon-redshift-python-user-defined-functions-will-reach-end-of-support-after-june-30-2026/)을 참조하세요.
# EXPLAIN
쿼리를 실행하지 않고 쿼리 문에 대한 실행 계획을 표시합니다. 쿼리 분석 워크플로에 대한 자세한 내용은 [쿼리 분석 워크플로우](c-query-analysis-process.md) 섹션을 참조하세요.
## 구문
```
EXPLAIN [ VERBOSE ] query
```
## 파라미터
상세 표시
단순한 요약 대신 전체 쿼리 계획을 표시합니다.
*query*()
설명할 쿼리 문입니다. 쿼리는 SELECT, INSERT, CREATE TABLE AS, UPDATE 또는 DELETE 문일 수 있습니다.
## 사용 노트
EXPLAIN 성능은 때때로 임시 테이블 생성에 걸리는 시간의 영향을 받습니다. 예를 들어, 공통 하위 표현식 최적화를 사용하는 쿼리는 EXPLAIN 출력을 반환하기 위해 임시 테이블을 생성하고 분석해야 합니다. 쿼리 계획은 임시 테이블의 스키마와 통계에 따라 다릅니다. 따라서 이 유형의 쿼리에 대한 EXPLAIN 명령 실행 시간은 예상보다 길 수 있습니다.
다음 명령에만 EXPLAIN을 사용할 수 있습니다.
+ SELECT
+ SELECT INTO
+ CREATE TABLE AS
+ INSERT
+ UPDATE
+ DELETE
EXPLAIN 명령을 DDL(데이터 정의 언어) 또는 데이터베이스 작업 등의 다른 SQL 명령에 사용할 경우 실패하게 됩니다.
EXPLAIN 출력 상대 단위 비용은 Amazon Redshift에서 쿼리 계획을 선택하는 데 사용됩니다. Amazon Redshift는 다양한 리소스 추정치의 크기를 비교하여 계획을 결정합니다.
## 쿼리 계획 및 실행 단계
특정 Amazon Redshift 쿼리 문에 대한 실행 계획은 쿼리의 실행과 계산을 별개의 단계 순서와 테이블 작업으로 분리하며, 결국은 쿼리에 대한 최종 결과 집합을 생성하게 됩니다. 쿼리 계획에 대한 자세한 내용은 [쿼리 처리](c-query-processing.md) 섹션을 참조하세요.
다음 표에는 Amazon Redshift에서 사용자가 실행을 위해 제출하는 쿼리를 위한 실행 계획을 개발하는 데 사용할 수 있는 단계가 요약되어 있습니다.
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/redshift/latest/dg/r_EXPLAIN.html)
## RLS에 EXPLAIN 사용
쿼리에 행 수준 보안(RLS) 정책이 적용되는 테이블이 포함되어 있는 경우 EXPLAIN은 특별한 RLS SecureScan 노드를 표시합니다. 또한 Amazon Redshift는 STL\$1EXPLAIN 시스템 테이블에 동일한 노드 유형을 로깅합니다. EXPLAIN은 dim\$1tbl에 적용되는 RLS 조건자를 표시하지 않습니다. RLS SecureScan 노드 유형은 현재 사용자에게 보이지 않는 추가 작업이 실행 계획에 포함되어 있음을 나타내는 표시자로 사용됩니다.
다음 예는 RLS SecureScan 노드를 보여줍니다.
```
EXPLAIN
SELECT D.cint
FROM fact_tbl F INNER JOIN dim_tbl D ON F.k_dim = D.k
WHERE F.k_dim / 10 > 0;
QUERY PLAN
------------------------------------------------------------------------
XN Hash Join DS_DIST_ALL_NONE (cost=0.08..0.25 rows=1 width=4)
Hash Cond: ("outer".k_dim = "inner"."k")
-> *XN* *RLS SecureScan f (cost=0.00..0.14 rows=2 width=4)*
Filter: ((k_dim / 10) > 0)
-> XN Hash (cost=0.07..0.07 rows=2 width=8)
-> XN Seq Scan on dim_tbl d (cost=0.00..0.07 rows=2 width=8)
Filter: (("k" / 10) > 0)
```
RLS가 적용되는 전체 쿼리 계획을 살펴볼 수 있도록, Amazon Redshift는 EXPLAIN RLS 시스템 권한을 제공합니다. 이 권한이 부여된 사용자는 RLS 조건자까지 포함한 전체 쿼리 계획을 살펴볼 수 있습니다.
다음 예는 RLS SecureScan 노드 아래의 추가 Seq Scan에 RLS 정책 조건자(k\$1dim > 1)도 포함되어 있음을 보여줍니다.
```
EXPLAIN SELECT D.cint
FROM fact_tbl F INNER JOIN dim_tbl D ON F.k_dim = D.k
WHERE F.k_dim / 10 > 0;
QUERY PLAN
---------------------------------------------------------------------------------
XN Hash Join DS_DIST_ALL_NONE (cost=0.08..0.25 rows=1 width=4)
Hash Cond: ("outer".k_dim = "inner"."k")
*-> XN RLS SecureScan f (cost=0.00..0.14 rows=2 width=4)
Filter: ((k_dim / 10) > 0)*
-> *XN* *Seq Scan on fact_tbl rls_table (cost=0.00..0.06 rows=5 width=8)
Filter: (k_dim > 1)*
-> XN Hash (cost=0.07..0.07 rows=2 width=8)
-> XN Seq Scan on dim_tbl d (cost=0.00..0.07 rows=2 width=8)
Filter: (("k" / 10) > 0)
```
사용자에게 EXPLAIN RLS 권한이 부여되지만, Amazon Redshift는 RLS 조건자를 포함한 전체 쿼리 계획을 STL\$1EXPLAIN 시스템 테이블에 로깅합니다. 이 권한이 부여되지 않은 상태에서 실행되는 쿼리는 RLS 내부 정보 없이 로깅됩니다. EXPLAIN RLS 권한을 부여하거나 제거해도 Amazon Redshift가 이전 쿼리와 관련하여 STL\$1EXPLANT에 로깅한 내용은 변경되지 않습니다.
### AWS Lake Formation-RLS 보호 Redshift 관계
다음 예는 Lake Formation-RLS 관계를 보는 데 사용할 수 있는 LF SecureScan 노드를 보여줍니다.
```
EXPLAIN
SELECT *
FROM lf_db.public.t_share
WHERE a > 1;
QUERY PLAN
---------------------------------------------------------------
XN LF SecureScan t_share (cost=0.00..0.02 rows=2 width=11)
(2 rows)
```
## 예제
**참고**
다음 예의 경우 샘플 출력은 Amazon Redshift 구성에 따라 다를 수 있습니다.
다음 예에서는 EVENT 및 VENUE 테이블에서 EVENTID, EVENTNAME, VENUEID 및 VENUENAME을 선택하는 쿼리를 위한 쿼리 계획을 반환합니다.
```
explain
select eventid, eventname, event.venueid, venuename
from event, venue
where event.venueid = venue.venueid;
```
```
QUERY PLAN
--------------------------------------------------------------------------
XN Hash Join DS_DIST_OUTER (cost=2.52..58653620.93 rows=8712 width=43)
Hash Cond: ("outer".venueid = "inner".venueid)
-> XN Seq Scan on event (cost=0.00..87.98 rows=8798 width=23)
-> XN Hash (cost=2.02..2.02 rows=202 width=22)
-> XN Seq Scan on venue (cost=0.00..2.02 rows=202 width=22)
(5 rows)
```
다음 예에서는 상세한 출력을 포함한 동일한 쿼리를 위한 쿼리 계획을 반환합니다.
```
explain verbose
select eventid, eventname, event.venueid, venuename
from event, venue
where event.venueid = venue.venueid;
```
```
QUERY PLAN
--------------------------------------------------------------------------
{HASHJOIN
:startup_cost 2.52
:total_cost 58653620.93
:plan_rows 8712
:plan_width 43
:best_pathkeys <>
:dist_info DS_DIST_OUTER
:dist_info.dist_keys (
TARGETENTRY
{
VAR
:varno 2
:varattno 1
...
XN Hash Join DS_DIST_OUTER (cost=2.52..58653620.93 rows=8712 width=43)
Hash Cond: ("outer".venueid = "inner".venueid)
-> XN Seq Scan on event (cost=0.00..87.98 rows=8798 width=23)
-> XN Hash (cost=2.02..2.02 rows=202 width=22)
-> XN Seq Scan on venue (cost=0.00..2.02 rows=202 width=22)
(519 rows)
```
다음 예에서는 CREATE TABLE AS(CTAS) 문을 위한 쿼리 계획을 반환합니다.
```
explain create table venue_nonulls as
select * from venue
where venueseats is not null;
QUERY PLAN
-----------------------------------------------------------
XN Seq Scan on venue (cost=0.00..2.02 rows=187 width=45)
Filter: (venueseats IS NOT NULL)
(2 rows)
```