Redgate Hub (한국어)

임시 테이블은 바로 그것입니다. 배치 또는 절차 내에서 데이터를 처리 할 때 중간 결과를위한 작업 공간을 제공하기 위해 가장 자주 사용됩니다. 또한 테이블 반환 함수에서 테이블을 전달하거나, 저장 프로 시저간에 테이블 기반 데이터를 전달하거나, 최근에는 테이블 반환 매개 변수 형식으로 응용 프로그램에서 SQL Server 루틴으로 전체 읽기 전용 테이블을 보내는 데 사용됩니다. 또는 읽기 전용 임시 테이블을 매개 변수로 전달하십시오. 사용이 끝나면 자동으로 삭제됩니다.

기술에 대해 자세히 알아보기 전에 가능한 경우 테이블 변수를 사용하는 것이 좋습니다. 간단하며 SQL Server가 자동으로 수행합니다. 또한 열심히 일하는 OLTP 시스템에 더 적은 문제를 일으키는 경향이 있습니다. 가끔 조인에서 좋은 성능을 얻기 위해 미세 조정해야 할 수도 있지만 잠시 후에 설명하겠습니다. 그러나 임시 데이터에 대해 더 복잡한 처리를 수행하거나 합리적으로 작은 것보다 더 많이 사용할 가능성이있는 경우 데이터 양이 많으면 로컬 임시 테이블이 더 나은 선택 일 수 있습니다.

테이블 변수

테이블 변수는 루틴 또는 배치 범위 내에서 사용됩니다. 정의되었으며 원래 테이블 반환 함수를 가능하게하기 위해 만들어졌습니다. 그러나 전통적인 임시 테이블이 배치 된 많은 용도에 적합합니다. 범위 지정 규칙에서 다른 변수처럼 작동합니다. 범위를 벗어나면 폐기됩니다. 이것들은 작업하기가 훨씬 쉽고 매우 안전하며 임시 테이블을 사용할 때보 다 사용되는 루틴에서 재 컴파일을 더 적게 트리거합니다. 테이블 변수는이를 생성 한 프로세스에 대해 개인이므로 잠금 리소스가 덜 필요합니다. 트랜잭션 롤백은 테이블 변수의 범위가 제한되고 영구 데이터베이스의 일부가 아니기 때문에 영향을주지 않으므로 로그 항목과 같은 롤백에서 살아남 아야하는 데이터를 생성하거나 저장하는 데 편리합니다. 테이블 변수의 단점은 디버깅을 위해 내용을 조사하거나 대화식으로 다른 SQL 표현식을 시도하기 위해이를 사용하기 전에 종종 폐기된다는 것입니다.

응용 프로그램이 보수적이고 데이터 볼륨이 충분하다면 다른 것은 절대 원하지 않을 것입니다. 그러나 문제가 발생할 수 있습니다. 한 가지 어려움은 테이블 변수가 로컬 범위에서만 참조 될 수 있으므로 임시 테이블 또는 테이블 반환 매개 변수를 사용하는 것처럼 동적 SQL을 사용하여 처리 할 수 없다는 것입니다. 이는 동적 SQL이 범위 밖에서 실행되기 때문에 EXEC 문 또는 sp_ExecuteSQL 저장 프로 시저를 통해 실행하는 동적 SQL 내에서 외부 정의 테이블 변수를 참조 할 수 없기 때문입니다. 테이블 변수의. 물론 테이블 변수가 범위 내에 있기 때문에 동적 SQL 내에서 테이블 변수를 만든 다음 사용할 수 있습니다. 그러나 동적 SQL이 실행되면 테이블 변수가 없습니다.

주의해야 할 몇 가지 예외 사항도 있습니다. 예를 들어 초기 DECLARE 문 후에는 테이블 정의를 변경할 수 없습니다. SQL Server 2000에서 테이블 변수는 SELECT INTO 문의 대상이나 INSERT EXEC (현재 수정 됨)가 될 수 없습니다. CHECK 제약 조건, DEFAULT 값 및 테이블 변수의 계산 된 열에서 사용자 정의 함수를 호출 할 수 없습니다. CHECK 제약 조건을 넘어서 허용되는 유일한 제약 조건은 PRIMARY KEY, UNIQUE KEY 및 NULL / NOT NULL입니다

가장 까다로운 문제는 SQL Server 2016 이전에 테이블 크기가 증가하기 때문입니다. , 인덱스를 명시 적으로 선언 할 수 없으며 UNIQUE 및 PRIMARY KEY 제약 조건을 적용한 인덱스에 배포 인덱스가 유지되지 않았습니다. 이제 테이블 정의와 함께 특정 인덱스 유형을 인라인으로 만들 수 있지만 배포 통계는 여전히 유지되지 않습니다. 쿼리 최적화 프로그램은 테이블에 행이 하나만 있다고 가정합니다. 또한 테이블 내용을 수정하는 SQL 표현식에 대한 병렬 쿼리 계획을 생성 할 수 없습니다. 인덱스 제한을 부분적으로 피하려면 제약 조건을 사용하여 동일한 작업을 수행 할 수 있습니다. 가장 중요한 것은 클러스터 된 인덱스를 적용 할 수있는 기본 키 제약 조건이지만 고유 제약 조건은 성능에 유용합니다. 쿼리 옵티마이 저는 주변에 있으면 기꺼이 사용할 것입니다.

테이블 변수의 가장 큰 문제는 통계가 열에서 유지되지 않는다는 것입니다. 이것은 쿼리 옵티마이 저가 데이터의 크기와 분포에 대해 추측해야 함을 의미하며, 데이터가 잘못되면 조인 성능이 저하 될 것입니다.이 경우 다른 작업을 수행 할 수있는 것이 거의 없습니다 클래식 로컬 임시 테이블을 사용하는 것보다. SQL Server 2019부터 Microsoft는이 문제를 해결하는 Table Variable Deferred Compilation이라는 새로운 기능을 도입했습니다. 자세한 내용은 Greg Larsen의이 기사를 참조하십시오.

SQL Server 2019를 사용하지 않는 경우 시도 할 수있는 한 가지 방법은 다른 테이블과 조인하는 테이블 변수를 포함하는 문에 OPTION (RECOMPILE)을 추가하는 것입니다. 이렇게하면 행이 이미 채워져 있으므로 SQL Server는 재 컴파일시 행 수를 감지 할 수 있습니다. 옵티 마이저에는 여전히 분포 통계가없고 일반적으로 분포가 왜곡 된 경우 잘못된 계획을 생성 할 수 있으므로이 방법으로 문제가 완전히 해결되지는 않습니다. 이 데모에서는 OPTION (RECOMPILE)을 추가하기 만하면 조인 시간이 3/4 단축되었습니다.

이제 테이블에 들어가는 것을 고유하게 만들 수 있다면 이들에 대해 기본 키 제약 조건을 사용할 수 있습니다. 테이블. 이로 인해 옵티마이 저는 테이블 스캔 대신 클러스터형 인덱스 탐색을 사용할 수 있었고 실행 시간이 너무 빨라서 측정 할 수 없었습니다.

테이블 변수로 시작했지만 성능 문제가 발생하면 로컬 임시 테이블 사용으로 돌아갔습니다. 어떤 사람들은 테이블의 행 수에 대해 조언을 할만큼 대담하며 최대로 100 개 또는 1000 개가 제공되는 것을 보았습니다. 그러나 훨씬 더 큰 테이블 변수가 시간이 지남에 따라 완벽하게 만족스럽게 수행되고 훨씬 작은 테이블 변수가 문제를 일으키는 것을 보았습니다. 그러나 작은 테이블에서는 문제가 덜 감지됩니다!

테이블 반환 매개 변수

TVP (테이블 반환 매개 변수)는 사용을 확장하는 특수한 유형의 테이블 변수입니다. 테이블 변수가 매개 변수로 전달되면 테이블은 TempDB 시스템 데이터베이스에서 테이블 변수로 구체화되고 TempDB의 테이블에 대한 포인터 인 참조로 전달됩니다.

그 이후로 테이블 반환 매개 변수가 사용되었습니다. SQL Server 2008은 여러 행의 데이터를 Transact-SQL 루틴 또는 sp_ExecuteSQL를 통해 일괄 처리로 보냅니다. 프로그래머에게 특별한 가치는 TSQL 코드 내에서 다음과 같이 사용할 수 있다는 것입니다. 클라이언트 응용 프로그램에서도 마찬가지이므로 클라이언트 테이블을 서버로 보내는 데 좋습니다. TSQL에서 테이블 반환 변수를 선언하고, 데이터를 삽입하고, 이러한 변수를 테이블 반환 매개 변수로 저장 프로 시저 및 함수에 전달할 수 있습니다 .TSQL에서 테이블 반환 변수를 저장 프로 시저 및 함수에 전달할 수 있습니다.이 변수의 일반적인 유용성은 읽기 전용으로 만 전달된다는 사실에 의해 제한됩니다. 테이블 값에서 UPDATE, DELETE 또는 INSERT 문을 수행 할 수 없습니다. 루틴 본문의 매개 변수.

사용자 정의 테이블 유형을 생성하고이를 사용하기위한 테이블 구조를 정의해야합니다. 다음은 TSQL에서의 간단한 사용 예입니다.

테이블 변수와 마찬가지로 테이블 반환 매개 변수는 범위를 벗어나면 더 이상 존재하지 않지만 유형 정의는 명시 적으로 삭제 될 때까지 유지됩니다.테이블 변수와 마찬가지로 클라이언트에서 데이터를 채울 때 잠금을 획득하지 않으며 테이블 반환 매개 변수의 열에 대한 통계가 유지되지 않습니다. SELECT INTO 또는 INSERT EXEC 문의 대상으로 테이블 반환 매개 변수를 사용할 수 없습니다. 예상대로 테이블 반환 매개 변수는 SELECT INTO의 FROM 절 또는 string 또는 stored-procedure.

TVP는 로컬 변수를 동적 SQL에 전달하고 sp_ExecuteSQL. Microsoft에서 제대로 문서화하지 않았으므로 시작하는 데 유용한 예제를 보여 드리겠습니다.

보다 전통적인 임시 테이블과 그 사용을 설명하기 전에 다음을 자세히 살펴 보겠습니다. 임시 테이블이있는 장소. TempDB.

TempDB

임시 테이블과 테이블 변수는 TempDB 데이터베이스에 생성됩니다.이 데이터베이스는 단순한 복구가 가능한 또 다른 데이터베이스입니다. TempDB를 사용하면 충분한 최소로깅 만 수행됩니다. 롤백 및 기타 ACID 기능을 허용합니다. TempDB의 특별한 차이점은 테이블과 같은 모든 개체가 시작시 지워진다는 것입니다. TempDB는 항상 단순 복구 모델을 사용하기 때문에 완료된 트랜잭션은 다음 TempDB 검사 점의 로그 로그에서 지워지고 라이브 트랜잭션 만 유지됩니다. 이것은 임시 테이블이 기록되고 저장된다는 점에서 다른 종류의 기본 테이블처럼 작동한다는 것을 의미합니다. 실제로 임시 테이블은 메모리에 캐시 된 상태로 유지되지만 자주 사용되는 경우에만 기본 테이블과 동일합니다. TempDB는 임시 개체 재사용이라는 시스템을 운영합니다.이 시스템은 충분한 메모리가있는 경우 계획과 함께 임시 개체의 일부를 캐시합니다. 이것은 임시 개체가 메모리에만 존재한다는 범례를 설명 할 수 있습니다. 진실은 상황에 따라 달라집니다 …입니다.

TempDB에서는 다른 많은 일이 진행됩니다. 데이터베이스 엔진은 DBCC 검사를위한 작업 테이블을 배치하고 인덱스, 커서를 만들거나 다시 작성하는 데 사용할 수 있습니다. 예를 들면. 해시, 정렬및 스풀로 설명 된 쿼리의 중간 테이블은 예를 들어 SQL 문을 실행하는 여러 물리적작업에 필요한 테이블과 함께 TempDB에서 구체화됩니다. 또한 스냅 샷 격리, MARS (Multiple Active Results Set), 트리거 및 온라인 인덱스 빌드를위한 버전 저장소로도 사용됩니다.

임시 테이블은 기본 테이블과 마찬가지로 저장되기 때문에 하나 또는 두 개가 있습니다. 주의해야 할 것. 예를 들어 일반 테이블을 만들려면 TempDB에 CREATE TABLE 권한이 있어야합니다. 문제를 해결하기 위해 기본적으로 DBO (db owner) 역할에 할당되지만 DBO 역할이 할당되지 않은 사용자에 대해 명시 적으로 수행해야 할 수도 있습니다. GUEST 사용자 보안 컨텍스트를 통해 할당되기 때문에 모든 사용자는 TempDB에서 로컬 또는 전역 임시 테이블을 만들 수있는 권한이 있습니다.

클래식 임시 테이블이 제공됩니다. 두 가지 특징, 즉 ##접두사가 붙은 글로벌 또는 공유 가능한 임시 테이블과 이름이 #접두사가 붙은 로컬 임시 테이블 로컬 임시 테이블은 글로벌 임시 테이블보다 일반 테이블과 비슷합니다. 뷰를 만들거나 트리거를 연결할 수 없습니다. 어떤 프로세스, 세션 또는 절차가 그들을 생성했는지 알아내는 것은 약간 까다 롭습니다. 나중에 이에 대해 약간의 도움을 드리겠습니다. 가장 중요한 것은 소유 프로세스 만 볼 수 있으므로 전역 임시 테이블보다 더 안전합니다.

로컬 임시 테이블 (및 로컬 임시 저장 프로 시저)의 또 다른 이상한 점은 이름이 다르다는 것입니다. 루틴이나 배치에서 제공하는 메타 데이터에 여러 프로세스에서 동일한 루틴을 동시에 실행하는 경우 데이터베이스 엔진은 서로 다른 프로세스에서 만든 동일한 이름의 로컬 임시 테이블을 구별 할 수 있어야합니다. 밑줄 문자로 왼쪽이 채워지는 각 로컬 임시 테이블 이름에 숫자 문자열을 추가하여이를 수행합니다. #MyTempTable와 같은 짧은 이름을 지정하더라도 실제로 TempDB에 저장되는 것은 CREATE TABLE 문에 지정된 테이블 이름으로 구성됩니다. 및 접미사. 이 접미사로 인해 로컬 임시 테이블 이름은 116 자 이하 여야합니다.

상황을보고 싶다면 TempDB에서 다른 테이블과 똑같은 방식으로 테이블을 볼 수 있습니다. 표. TempDB에서 호출하는 경우에만 임시 테이블에서 sp_help 작업을 사용할 수도 있습니다.

또는 데이터베이스 swithching없이 TempDB의 시스템보기에서 찾을 수 있습니다.

또는 정보 스키마

더 나은 방법은 다음과 같습니다. 어떤 프로세스와 사용자가 TempDB의 거대한 임시 테이블을 잡고 있고 공간을 포기하지 않는지 알아 내십시오.

데이터 유형이 TempDB에 존재하지 않는 한 임시 테이블에서 사용자 정의 데이터 유형을 사용할 수 없습니다. 즉, 데이터 유형이 명시 적으로 생성되지 않은 경우

TempDB의 사용자 테이블

일반적인 사용에서 너무 깊이 생각하지 않고 임시 테이블 또는 테이블 변수를 생성합니다. 그러나 흥미로운 점은 TempDB가 모든 종류의 샌드 박스 활동에 있다는 것입니다. 일반 기본 테이블, 뷰 또는 원하는 다른 것을 만들 수 있습니다. 스키마, 저장 프로 시저 등을 만들 수 있습니다. 이 작업을하고 싶지는 않지만 TempDB는 다른 데이터베이스 일 뿐이므로 가능합니다. AdventureWorks를 설치하여 직접 확인한 후 개발 SQL Server를 다시 시작해야했습니다. 이것은 TempDB에 일종의 ..er… 임시 영구 테이블 인 기본 테이블을 만들 수 있음을 의미합니다. 전역 임시 테이블과는 달리 모든 관리 작업을 직접 수행해야합니다. 루틴도 마찬가지입니다. 이 작업의 장점은 모든 처리에서 TempDB의 간단한 복구를 사용하므로 정리에 실패하면 SQL Server가 다음 시작시 어머니 역할을합니다. 시간이 오래 걸릴 수도 있습니다. 다음 단계는 내가 지속적인 임시테이블이라고 부르는 것을 만드는 것입니다. 이 테이블에서 데이터 자체는 서버가 다시 시작될 때 휘발성이지만 테이블 자체는 유지됩니다. 영구 임시 테이블을 만드는 가장 일반적인 방법은 시작시 전역 임시 테이블을 다시 만드는 것입니다. 모든 데이터베이스가 복구되고 “복구 완료”메시지가 기록되면 자동으로 수행 할 수 있습니다. 이는 글로벌 임시라고하더라도이를 사용하는 모든 연결이 사라 졌을 때이를 실행하는 프로세스이므로 삭제되지 않습니다. 이 작업 테이블을 사용하는 데이터베이스에 이러한 종류의 작업 테이블을 만드는 것이 좋습니다. 그러나 전체 복구를 사용하는 경우 임시 작업은 로그에 남게됩니다. 물론 일반적인 작업 테이블을 만들 수도 있습니다. 전역 임시 테이블을 생성하는 마스터에 저장 프로 시저를 정의하여 시작시 이러한 영구테이블을 생성 할 수 있습니다.

이 종류의 하이브리드 테이블을 사용하는 이유는 무엇입니까? 데이터에 대한 일련의 처리를 수행하기 위해 다중 프로세스에 안전한 방식으로 영구적테이블을 통해 프로 시저간에 테이블을 전달하는 기술에 대해 설명합니다. 이러한 테이블을 프로세스 키가 지정된 테이블이라고합니다 ( 저장 프로 시저간에 데이터를 공유하는 방법참조). : Erland Sommarskog의 프로세스 키 테이블 ). 그들은 처음에는 노련한 DBA의 눈썹을 올릴 것이지만 제대로 수행하면 다년생 문제에 대한 효과적이고 안전한 해결책입니다.

임시 테이블뿐만 아니라 여러 테이블 유형도 있습니다. 이는 가짜테이블 및 파생 테이블과 같은 기본 테이블에서 직접 파생되지 않습니다.이 중 일부는 너무 덧 없어서 일시적인 것이 아니라 일시적인 것으로 가장 잘 생각됩니다. CTE는 인라인또는 파생이며 구체화되지 않은 임시 테이블을 사용합니다. BOL은이를 임시 명명 된 결과 집합이라고합니다. 표현식의 범위 내에서만 존재합니다. CTE에서는 두 번 이상 액세스 할 수 있다는 점에서 파생 테이블에 비해 이점이 있습니다.

로컬 임시 테이블

로컬 임시 테이블 (#로 시작하는 이름) 사용, 내부에서 일어나는 일은 놀랍게도 테이블 변수와 유사합니다. 테이블 변수와 마찬가지로 로컬 임시 테이블은이를 생성 한 프로세스에만 적용됩니다. 따라서 뷰에서 사용할 수 없으며 트리거를 뷰와 연결할 수 없습니다.

SELECT INTO를 사용하여 생성하려는 경우 테이블 변수보다 편리하지만 SELECT INTO 수정이 필요한 시스템에서 필요한 모든 제약 조건과 함께 임시 테이블을 명시 적으로 만드는 것이 좋습니다.

어떤 세션이나 프로 시저가 생성되었는지 쉽게 알 수 없습니다. 이 테이블. 이는 동일한 저장 프로 시저가 여러 프로세스에서 동시에 실행되는 경우 데이터베이스 엔진이 서로 다른 프로세스에서 만든 동일한 테이블을 구별 할 수 있어야하기 때문입니다. 데이터베이스 엔진은 각 로컬 임시 테이블 이름에 왼쪽으로 채워진 숫자 접미사를 내부적으로 추가하여이를 수행합니다. TempDB의 sys.objects 뷰에 저장된 임시 테이블의 전체 이름은 CREATE TABLE 문에 지정된 테이블 이름과 시스템에서 생성 된 숫자 접미사로 구성됩니다. 접미사를 허용하려면 로컬 임시 이름에 지정된 테이블 이름은 116 자 미만이어야합니다.

로컬 임시 테이블을 사용하여 정리할 수 있습니다. DROP TABLE를 사용하여 명시 적으로 삭제하지 않는 한 범위를 벗어나면 자동으로 삭제됩니다. 해당 범위는 테이블 변수보다 더 관대하므로 배치 또는 동적 SQL에서 참조하는 데 문제가 없습니다. 로컬 임시 테이블은 현재 세션 또는 프로 시저가 끝날 때 자동으로 삭제됩니다. 생성 한 프로 시저의 끝에서 삭제하면 헤드 스크래칭이 발생할 수 있습니다. 저장 프로 시저 또는 세션 내에서 생성 된 로컬 임시 테이블은 완료 될 때 삭제되므로 저장 프로 시저를 호출 한 프로세스에서 참조 할 수 없습니다. 테이블을 만들었습니다. 그러나 테이블을 생성 한 저장 프로 시저에서 실행하는 중첩 저장 프로 시저에서 참조 할 수 있습니다. 중첩 프로 시저가 임시 테이블을 참조하고 같은 이름을 가진 두 개의 임시 테이블이 동시에 존재하는 경우 쿼리가 해결되는 테이블은 무엇입니까?

호기심으로 다음을 사용하여 로컬 임시 저장 프로 시저를 만들 수도 있습니다. 로컬 임시 테이블과 동일한 범위 및 수명. 다른 루틴에 대해서도 똑같이 할 수 없습니다.

글로벌 임시 테이블.

로컬 임시 테이블과 마찬가지로 글로벌 임시 테이블 (##으로 시작)은 테이블을 생성 한 세션이 종료 될 때 자동으로 삭제됩니다. 그러나 글로벌 테이블은 생성 한 프로세스에 대해 비공개가 아니므로 생성 세션이 종료 될 때 테이블을 적극적으로 참조하고 있던 마지막 Transact-SQL 문이 실행을 완료하고 잠금이 삭제 될 때까지 그 이후에 유지되어야합니다. 이러한 전역 임시 테이블이 존재할 때 TempDB에 액세스 할 수있는 사람은 누구나 이러한 임시 개체를 직접 쿼리, 수정 또는 삭제할 수 있습니다.

규칙, 기본값 및 인덱스를 임시 테이블과 연결할 수 있지만 뷰를 만들 수는 없습니다. 임시 테이블에서 또는 트리거를 그들과 연관시킵니다. TempDB에 데이터 유형이있는 경우에만 임시 테이블을 생성 할 때 사용자 정의 데이터 유형을 사용할 수 있습니다.

저장 프로시 저는 현재 세션 중에 생성 된 임시 테이블을 참조 할 수 있습니다. 저장 프로 시저 내에서 임시 테이블을 생성하고 삭제 한 다음 동일한 이름의 새 임시 테이블을 생성 할 수 없습니다.

작동하지만….

… t

로컬 임시 테이블을 사용하여 저장 프로 시저가 사용될 때마다 의도하지 않게 강제로 다시 컴파일 할 수 있습니다. 저장 프로 시저가 제대로 수행되지 않을 가능성이 높기 때문에 좋지 않습니다. 재 컴파일을 방지하려면 호출 또는 호출 된 저장 프로 시저에서 생성 된 임시 테이블을 참조하지 마십시오. 그렇게 할 수없는 경우 EXECUTE 문 또는 sp_ExecuteSQL 저장 프로 시저. 또한 임시 테이블이 참조되기 전에 저장 프로 시저 또는 트리거에서 생성되고 이러한 참조 후에 삭제되는지 확인하십시오.IF... ELSE 또는 WHILE와 같은 흐름 제어 문 내에 임시 테이블을 만들지 마세요.

전역 임시 저장 프로 시저를 만들 수 있지만 아직 그 용도를 찾지 못했습니다. 전역 임시 기능은 허용되지 않습니다.

결론

공유 놀이터에서 배트를 휘두르는 방법에 매우주의하세요. 이 글을 읽는 동안 TempDB에서 많은 활동이 진행되고 있음을 깨달았을 것이며, 임시 테이블이 무엇이든지간에 불필요한 양으로 임시 테이블을 채우는 장기 실행 프로세스를 사용하여 전체 SQL Server에 혼란을 일으킬 수 있습니다. 데이터. 사실, 저는이 기사에서 소중한 공유 리소스 인 TempDB를 부주의하게 사용하여 DBA를 정말로, 정말로 화나게하는 방법에 대한 단서를 제공했습니다. (S2005 이전에는 거대한 테이블과 함께 SELECT INTO를 사용하는 것이 훌륭한 V- 무기 (Vergeltungswaffe)였습니다.

일반화 된 조언이지만, 저는 항상 내 데이터베이스가 테이블 변수를 사용하는 것을 선호하고, 가능하면 TVP를 사용하는 것이 좋습니다. 리소스가 덜 필요하고 작업을 마쳤을 때 보유 할 가능성이 적습니다. , 열 및 테이블 검사 및 제약 조건이 있습니다. 특히 테이블 크기가 커질 때 스팀이 부족한 시간을 찾을 수 있습니다. 이와 같은 경우 또는 제한된 범위로 인해 테이블 변수를 사용하는 것이 실용적이지 않은 경우 로컬 임시 테이블을 사용할 것입니다. 글로벌 임시 테이블 또는 영구 임시 테이블에 동의하기 전에 많은 입술과 머리를 흔들어야합니다. 그들은 몇 가지 유효하고 완벽하게 합리적인 용도를 가지고 있지만 프로그래머가 필요한 관리 작업을 수행