T-SQL 코드로 캐시 효율성 향상 메모리 소모량 감소
캐시 계획 검토
계획 캐시를 이용하고 있습니까?당신은 캐시 계획을 잘 이용합니까?당신의 응용 프로그램은 그것들을 사용한 적이 있습니까? 그것들은 여러 번 이용되었습니까?당신은 같은 시간에 저장 프로세스 캐시에서 같은 검색에 대해 여러 개의 캐시 계획을 가지고 있습니까?이러한 캐시 계획에는 몇 개의 공간이 사용됩니까?프로세스 캐시를 최적화하고 응용 프로그램이 만들 캐시 계획 수를 줄일 수 있도록 대답해야 할 질문들입니다.당신의 T-SQL 코드를 작성할 때 약간의 주의가 필요합니다. 이것은 SQL Server가 같은 T-SQL 코드를 위해 추가 작업을 수행하여 실행 계획을 컴파일하고 캐시할 수 있도록 합니다.
SQL Server에서 T-SQL 배치 처리를 처리하려면 먼저 실행 계획을 작성해야 합니다.SQL Server에서 실행 계획을 만들기 위해서는 CPU가 T-SQL 일괄 처리를 컴파일하는 등 귀중한 자원을 먼저 소모해야 한다.계획이 컴파일되면 캐시되기 때문에 프로그램이 같은 T-SQL 문장을 한 번도 호출하지 않을 때 다시 사용할 수 있습니다.자주 실행되는 T-SQL 문장의 캐시 계획을 향상시키기 위해 T-SQL 코드를 작성하면 코드 성능을 향상시킬 수 있습니다.
SQL Server 2005가 출시됨에 따라 마이크로소프트는 캐시 계획을 탐구할 수 있는 DMV를 제공했다.이 DMV를 사용하면 캐시 계획에 대해 확인할 수 있습니다. 다음은 확인할 수 있는 간단한 목록입니다.
• 캐시 계획과 관련된 텍스트
• 캐시 계획 실행 횟수
• 캐시 계획의 크기
뒤에서 나는 어떻게 DM을 사용하여 캐시 계획 정보를 탐구하는지 알려줄 것이다.
주석이나 여분의 공백으로 인해 여러 개의 계획이
나는 너희들 모두가 코드를 저장 과정에 넣을 생각을 가지고 있다고 믿는다.우리는 코드를 한 응용 프로그램이나 여러 응용 프로그램 사이에서 다시 사용하기 위해 이렇게 한다.그러나 SQL Server가 실행하지 않는 모든 코드는 저장 프로세스에 포함됩니다.일부 응용 프로그램은 T-SQL 코드를 순차적으로 작성할 수 있습니다.만약 당신이 순서 T-SQL 코드를 작성하고 있다면, 코드를 주석하고 빈칸을 놓는 방식을 알아야 합니다. 그러면 SQL Server가 같은 T-SQL 문장을 위해 여러 개의 캐시 계획을 만들 수 있습니다.
다음은 두 개의 다른 T-SQL 문을 포함하는 T-SQL 스크립트의 예입니다.
1
.
SELECT
*
FROM
AdventureWorks.Production.Product
2
.
GO
3
.
SELECT
*
FROM
AdventureWorks.Production.Product
--
return records
4
.
GO
보시다시피 저는 비슷한 T-SQL 문구가 두 개 있습니다.둘 다 AdventureWorks로 돌아갑니다.Production.Product 테이블의 모든 레코드입니다.그렇다면 이 코드 SQL Server를 실행하면 캐시 계획을 얼마나 세울 것 같습니까?이 질문에 대답하기 위해서, 나는 SQL Server 2005와 SQL Server 2008에서 제공한 한 쌍의 DMV를 사용하여 이 캐시 계획 정보를 보겠다.두 T-SQL 문에서 생성된 계획을 보려면 다음 코드를 실행합니다.
1
.
DBCC
FREEPROCCACHE
2
.
GO
3
.
SELECT
*
FROM
AdventureWorks.Production.Product
4
.
GO
5
.
SELECT
*
FROM
AdventureWorks.Production.Product
--
return records
6
.
GO
7
.
SELECT
stats.execution_count
AS
exec_count,
8
. p.size_in_bytes
as
[
size
]
,
9
.
[
sql
]
.
[
text
]
as
[
plan_text
]
10
.
FROM
sys.dm_exec_cached_plans p
11
.
outer
apply sys.dm_exec_sql_text (p.plan_handle) sql
12
.
join
sys.dm_exec_query_stats stats
ON
stats.plan_handle
=
p.plan_handle
13
.
GO
이 코드에서, 나는 먼저 DBCC FREEPROCCACHE 명령을 실행해서 이 과정의 캐시를 풀었다.이 명령은 메모리에 있는 모든 컴파일된 실행 계획을 삭제합니다.여기서 이 명령에 대해 나는 반드시 충고를 해야 한다.DBCC FREEPROCCACHE 명령을 운영 환경에서 실행하지 마십시오.생산 환경에서 이렇게 하면 생성된 캐시 계획을 모두 삭제할 수 있으며, 이렇게 하면 자주 사용하는 계획이 다시 컴파일되기 때문에 생산 환경에 심각한 영향을 줄 수 있다.프로세스 캐시를 풀고 나서, 나는 나의 두 개의 다른 SELECT 문장을 실행했다.마지막으로, 나는 서로 다른 DMV에서 얻은 정보를 연결해서 이 두 SELECT 문장에 캐시된 계획 정보를 되돌려줄 것이다.이것을 실행할 때 다른 DMV를 참조하는 SELECT 문에서 다음 출력을 얻을 수 있습니다.
1
. exec_count size plan_text
2
.
--
------------------ ----------- --------------------------------------------------------
3
.
1
40960
SELECT
*
FROM
AdventureWorks.Production.Product
--
return records
4
.
1
40960
SELECT
*
FROM
AdventureWorks.Production.Product
이 출력에서 보듯이, 내 위의 두 개의 SELECT 문장은 두 개의 다른 캐시 계획을 만들었고, 각각 한 번 (exec count 수) 실행되었다.그 이유는 이 SELECT 문구들이 완전히 같지 않기 때문이다.SELECT 문은 주석이 포함되어 있기 때문에 약간 다릅니다.그리고 캐시 계획의 크기를 주의하세요. 40960바이트!이것은 매우 큰 메모리를 차지하지만, 단지 이런 보잘것없는 T-SQL 문장에 사용될 뿐이다.
그래서 너는 네가 어떻게 너의 코드를 주석했는지 주의해야 한다.잘라내기와 붙여넣기는 응용 프로그램의 일부 문장을 다른 부분으로 복사하는 좋은 방법이지만, 유사한 T-SQL 문장의 앞뒤나 중간에 다른 주석을 두지 않도록 주의하십시오. 이것은 여러 계획을 초래할 수 있습니다.
같은 T-SQL 명령을 위해 여러 개의 캐시 계획을 만드는 또 다른 방법은 T-SQL 문장에 추가 공백 문자를 포함하는 것입니다.다음은 공백을 제외한 두 개의 유사한 명령입니다.
1
.
SELECT
*
FROM
AdventureWorks.Production.Product
2
.
GO
3
.
SELECT
*
FROM
AdventureWorks.Production.Product
4
.
GO
보시다시피 두 번째 문장은 FROM 종문과 대상 이름 사이에 여분의 공백을 포함합니다.이 여분의 공백으로 인해 SQL Server 최적화기는 이 두 문장이 다르다고 생각하고 이 두 문장에 대해 서로 다른 캐시 계획을 만들 수 있습니다.두 번째 T-SQL 문에는 여분의 공백이 있음을 알 수 있습니다.그러나 SELECT가 문장 앞이나 문장 뒤에 다른 문자를 추가하고 있다면, 이 문장은 똑같아 보일 수 있습니다. 이 빈칸을 볼 수 없지만, SQL Server에서 볼 수 있기 때문에, 이 여분의 빈칸으로 인해 여러 개의 메모리 계획을 만들 수 있습니다.
SQL Server는 일괄 처리를 볼 때 스토리지 프로세스 캐시에 이미 존재하는 계획과 비교합니다.컴파일할 문장을 존재하는 캐시 계획과 똑같다면, SQL Server는 이 계획을 메모리에 컴파일하고 캐시할 필요가 없습니다.SQL Server는 이 계획이 캐시에 이미 존재한다면 비슷한 문장에 대한 계획을 다시 사용할 수 있도록 합니다.코드를 최적화하기 위해서 가능한 한 캐시 계획을 다시 사용하도록 하세요.
응용 프로그램 코드를 개발하고 응용 프로그램에 T-SQL 코드를 설치하고 저장 프로세스를 사용하지 않을 때, 가능한 한 최선의 계획을 세워 다시 사용할 수 있도록 주의해야 한다.코드를 작성할 때, 만약 우리가 프로그램의 다른 코드 블록에서 같은 코드를 사용하고 싶다면, 우리는 모두 커팅과 접착을 사용합니다.위의 예에서 보듯이 너는 이렇게 할 때 조심해야 한다.만약 코드 블록에 여분의 빈칸을 추가하거나, 주석이 다를 수도 있다면, 캐시 계획이 다를 수도 있습니다.
성능 극대화 및 메모리 최소화
코드를 최적화하려면 모든 명령과 데이터베이스 디자인을 걱정해야 할 뿐만 아니라, 비슷한 T-SQL 문장에 주석과 빈칸이 남아 있는지 걱정해야 한다.만약 유사한 T-SQL 문장 주위의 세부 사항을 주의하지 않는다면, SQL Server에 여러 개의 캐시 계획을 만들 수 있습니다.같은 T-SQL 문에 대해 여러 개의 계획을 가지고 있으면 SQL Server의 작업이 더욱 번거롭고 이러한 캐시 계획을 저장하는 데 메모리가 낭비될 수 있다.그것은 그다지 중요하지 않은 것처럼 보일 수도 있지만, T-SQL 문장 작성자로서, 우리는 성능을 최적화하고 자원 이용을 최대한 줄이는 데 최선을 다해야 한다.그 중 하나는 같은 T-SQL 문장에 여러 개의 계획을 캐시하지 않도록 하는 것이다.
이 내용에 흥미가 있습니까?
현재 기사가 여러분의 문제를 해결하지 못하는 경우 AI 엔진은 머신러닝 분석(스마트 모델이 방금 만들어져 부정확한 경우가 있을 수 있음)을 통해 가장 유사한 기사를 추천합니다:
Kotlin + Spring Boot에서 DB 캐시를 Redis로 시도Kotlin + Spring-Boot 애플리케이션에서 Redis를 사용하여 DB (MySQL) 데이터를 캐시 해 보았습니다. Spring Boot 2.2.6 Spring Initializr에서 병아리를 만듭니다. 아...
텍스트를 자유롭게 공유하거나 복사할 수 있습니다.하지만 이 문서의 URL은 참조 URL로 남겨 두십시오.
CC BY-SA 2.5, CC BY-SA 3.0 및 CC BY-SA 4.0에 따라 라이센스가 부여됩니다.
좋은 웹페이지 즐겨찾기
